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 <[EMAIL PROTECTED]>
Trillian Messenger - http://www.trillianastra.com/
