[Standards] rfc3921bis: self-presence
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
> 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