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."
Apologies.
- 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
