[Standards] rfc3921bis: self-presence

Rachel Blackman rcb at ceruleanstudios.com
Wed Aug 29 23:50:47 UTC 2007


>>> 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).
>
> As far as we know, no clients depends on this behavior.

The issue is that the bis clarified something not really covered in  
the RFC, and did so in a way which breaks functionality that some  
client users wanted (i.e., the ability to have themselves in their  
own roster and see themselves as online).  Thus, the functionality  
was no longer available on any server which read the bis and tried to  
implement ahead, OR on any server which just guessed and acted that  
way for the undefined case in the original RFC.

To get around this, clients have to special-case presence-handling  
code, or else risk Many Fine Bug Reports when users submit tickets of  
'I log in but I still show as offline in my own contact list!'   
Please note that I have numerous Bugzilla tickets -- submitted in the  
course of a week, no less, and several with 'me too' additions from  
other testers -- all on that topic from when I pulled that special- 
case code from Astra to rework the presence/roster engine.

So, while I think putting yourself in your own roster is confusing  
and perhaps silly, we should recognize that at least some users  
desire this behavior.

Given this, I suggest that the implementation ideal is that the  
client should not have to special-case things.  No client that I know  
of reacts to an incoming presence packet from themselves in a harmful  
way, so at worst sending the packets is a tiny bit of extraneous  
data.  At best, it simply picks right up and just plain works if you  
are in your own roster.

The XMPP ideal is supposed to be simple clients, complex servers.  A  
noble goal, but one we increasingly slip away from.  In many cases --  
Jingle, hash-based caps, etc. -- the added complexity is for a very  
good reason; in /this/ case, however, the added complexity is because  
the behavior is ill-defined (where defined at all) at present, and so  
in order to get the desired behavior you need special-case code to  
allow for different server implementations.

That is an easily fixed situation.  So, let's fix it! :)

>>>> 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 ? :-)
>
> It's not a change, it's a clarification!

More to the point, it is a /definition/.  Right now, there is no real  
definition.  The bis is proposed changes for the next version of the  
RFC; those in this discussion are proposing (at least, I know I am!)  
that the behavior should be defined as A (receive self-presence),  
rather than B (do not receive self-presence).

-- 
Rachel Blackman <rcb at ceruleanstudios.com>
Trillian Messenger - http://www.trillianastra.com/





More information about the Standards mailing list