[Standards] rfc3921bis: self-presence

Mridul Muralidharan mridul at sun.com
Thu Aug 30 00:22:58 UTC 2007

Mridul Muralidharan wrote:
> Rachel Blackman wrote:
>>>>> 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! :)
> bis spec made addition of own jid to roster an error, presence broadcast 
> was already covered in 3921.
> 3921.Section 5.1.1 - "In addition, the user's server MUST broadcast 
> initial presence from the user's new available resource to any of the 
> user's existing available resources (if any)."
> I think this is pretty clear in stating that presence is to be sent to 
> existing resources 'if any' (and not the 'new available resource').
> So this proposed change is a modification of the MUST clause.
> If a) presence broadcast can result in an error being returned back to 
> client (like 'too frequent updates', etc) when the presence broadcast 
> 'fails', b) there is a transformation of the presence stanza.
> Both of which leads to a state mismatch between publisher and 
> subscribers (so caps does not count :) ) : there is no usecase for 
> ack'ing the presence to the publisher imo.

to be read as :
"... subscribers (so caps does not count :) ) : since this is not the 
case currently, there is no usecase for  ack'ing the presence to the 
publisher imo."


- Mridul

> If we do have any usecases, then there can be a case made for this 
> change imo.
> The main concern I have with this proposal is essentially that : we will 
> have bis compliant clients expecting this push, and thereby exhibiting 
> some loss of functionality while interoperating with 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 ? :-)
>>> 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).
> It looks pretty well defined in 3921 !
> Maybe the language might be clarified better - but the flow is pretty 
> clearly spelled out.
> - Mridul

More information about the Standards mailing list