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
