[Standards] rfc3921bis: self-presence

Mridul Muralidharan mridul at sun.com
Thu Aug 30 00:20:17 UTC 2007


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.

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