[jdev] Invisibility. Was: Presence of type "available" not allowed?

[Peter Saint-Andre]

On 05/06/2008 1:50 AM, Ralph Meijer wrote:
> On Mon, 2008-05-05 at 15:52 +0200, Tomasz Sterna wrote:
>> Dnia 2008-05-05, pon o godzinie 07:35 -0600, Peter Saint-Andre pisze:
>>>>> http://www.xmpp.org/extensions/xep-0186.html
>>>> I prefer: http://www.xmpp.org/extensions/xep-0126.html
>>> Or something. :)
>>>
>>> Let's get consensus on an approach that works so we can stop talking
>>> about <presence type='invisible'/> because that monstrosity will never
>>> be standardized.
>> If XEP-0018 (Invisible Presence) is such a monstrosity, why do you
>> propose XEP-0186?
>> These are after all nearly the same. The only difference is the switch
>> that turns the invisible mode (IQ instead of PRESENCE).
>> It requires the same as XEP-0018 (or even more) special casing in
>> presence handling and is similarly horrid to implement.
> 
> Any form of invisibility will require special casing in presence
> handling by the server, no? I believe XEP-0186 could be mapped to the
> same backend as Privacy Lists, and is just a protocol short-hand for
> XEP-0126 in that case.

Yes that seems reasonable.

> I am with Peter that adding new types to one of our three Stanza kinds
> is not the proper way to solve this problem. First of all, we extend
> through namespaces. Second, an iq is an ideal way to ask the server to
> process something differently for you, in this case, how it handles
> presence distribution. I think it is a nice separation of concerns.

If we were defining presence from the start, maybe we would include
type="invisible", but it was not something we defined in the beginning
and it has always been a kind of ugly stepchild. Either we can try to
dress up the ugly stepchild or use something that is functionally
equivalent, which I think the IQ approach is.

> My only concern with XEP-0186 is the security considerations section,
> which advises not to reply to IQs. I don't think that is proper. If the
> intend is for the client to not respond to incoming IQs, the server
> should respond on behalf of the client. XEP-0126's security
> considerations mention this nicely.

You're right, I will clean that up.

AFAIC, the fundamental problem here is that no one is excited enough
about invisibility to stand up and say "yes I love and need this feature
and I will implement Spec X in the next 3 days if we can agree that it's
the right way to go". Whenever I sense a lack of enthusiasm, I hesitate
about pushing something forward. But sometimes the only way to get
consensus is to ask for a Last Call, so perhaps that's in order soon...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20080508/e7032f90/attachment-0002.bin>