[Standards] rfc3921bis: self-presence

Mridul Muralidharan mridul at sun.com
Wed Aug 29 22:21:42 UTC 2007


Peter Saint-Andre wrote:
> Mridul Muralidharan wrote:
>> Peter Saint-Andre wrote:
>>> The old "xmppbis" page [1] had the following note:
>>>
>>> ***
>>>
>>> It is unnecessary, potentially confusing, and not recommended to add
>>> your own JID to your roster. However, RFC 3921 currently does not talk
>>> about how a server should handle such "self roster items" if they exist.
>>> The spec should probably specify that a server MUST NOT send presence
>>> probes to self roster items, since the server already knows that the
>>> entity is online once it receives initial presence from a specific
>>> resource. Thus a resource should never receive presence information
>>> about itself from its own server, although it will receive presence
>>> information about other available resources for that entity as currently
>>> specified in RFC 3921.
>>>
>>> ***
>>>
>>> This conflates two issues: (1) adding yourself to your roster and (2)
>>> receiving presence from your "self" resource.
>>>
>>> IIRC we had list consensus that (1) is something we want to discourage.
>>
>> 2.3.2 talks specifically not allowing user to add his own bare jid to
>> the roster (as a MUST).
> 
> You don't add yourself to your roster, but still you get presence from
> your other available resources. Roster and presence are separate things.


Yes, I was referring to (1) above, not (2).
(1) would be a MUST violation.

> 
>>> But (2) seems OK. When you send presence to your server, your server
>>> delivers that presence to all of your available resources. Consider a
>>> user with two resources ("foo" and "bar") who then comes online with a
>>> third resource ("baz").
>>>
>>> <presence from='user at example.com/baz'/>
>>>
>>> [ ... to "foo" resource ... ]
>>>
>>> <presence from='user at example.com/baz'
>>>           to='user at example.com'/>
>>>
>>> [ ... to "bar" resource ... ]
>>>
>>> <presence from='user at example.com/baz'
>>>           to='user at example.com'/>
>>>
>>> [ ... to "baz" resource ... ]
>>>
>>> <presence from='user at example.com/baz'
>>>           to='user at example.com'/>
>>>
>>
>> Why should an entity need to get its own presence ack'ed from the server
>> ? What is there a usecase for this ? Or is this a nice to have
>> modification just to make things easier ?
> 
> I don't think it's a modification, just a clarification.


As Rachel Blackman mentioned, this is a change of behavior between the 
rfc's, and any client depending on this behavior will not be able to 
work properly with existing servers - unless it adds the special case 
(which is required currently).

> 
>> There are way too many client and server deployments which already use
>> the existing behavior - that is presence is not sent to the publisher,
>> so we might want to weight against that when modifying this : since the
>> bis spec compliant client should be able to interop with existing servers.
> 
> Yet note that in PEP, the publisher does receive the published item. Why
> should the special "pubsub-like" data called network availability be any
> different? The special-casing here seems odd.


If we were doing 3921 now, it might make sense to not special case it - 
though imo it is useless to ack it back, since the server is expected 
not to modify the presence in any way (unlike pubsub where you might 
have other filters/server side processing in place).

> 
>>> Is it harmful for the "baz" resource to receive its self-presence? I
>>> don't see a particular reason why the server needs to avoid sending
>>> that. Would it confuse the client?
>>>
>>> /psa
>>
>> bis compliant clients will 'expect' this behavior - and so will break
> 
> How?


Assuming 'own presence' is used by bis-client (like showing itself as 
online, etc), it will not do so unless server ack's the presence - which 
will never happen for pre-bis servers.


> 
>> when they talk to older servers (assuming they do something with this
>> presence status).
> 
> As far as I know, they don't.

If they dont, then why should we do this change ? :-)
Actually in our client, we used to always special case this (when user 
was in his roster - long story of how jid got there).

> 
>> Reverse might also be the case - of existing clients breaking when they
>> get presence for their own jid (will they treat it as conflict ?)
> 
> We have a lot of speculation here from server developers. But the client
> developers who have posted say "this is fine, we like it better". So why
> all the worrying?


The problem is essentially because the bis compliant clients will have 
issues with 3920/3921 servers if they expect server to ack presence for 
same entity - if they depend on it (if they dont, then whether server 
ack's or not is redundent).
This is not the behavior for atleast a few servers (including our own) 
right now.

Mridul

> 
> Peter
> 




More information about the Standards mailing list