[Standards-JIG] RFC 3921 Better User PresenceExperience (Implementation Detail)

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Fri Oct 27 06:56:58 UTC 2006


There are (at least) two separate aspects in the problem:

1/ report back an abnormal state to the client.
2/ take action to restore connectivity. 

As to reporting back the abnormal state, using an "error" of some sort is
IMO the way to go, as it allow for a clear differentiation between the
presence and the connectivity state (see Mathias post). 
As a side effect, we also need to get away from the idea of it breaking
existing client implementation. I believe we should always make our best at
minimizing the impact or new extensions, but there are cases, such as this
one, where clients will have to be adapted for a better experience.

Restoring connectivity is a separate concern. As Robert pointed out, this is
one area where SIP is better than XMPP. SIP does not assume connectivity, as
it can use UDP as a transport. As a result it provides well defined and
documented timers for each network operation. As an example, if a message
cannot be delivered to destination for 69 sec, an error message is returned
to the sender. SIP even defines the time interval between each retry in
order to limit the network load, as the retries are atomic at each message
level. 
I believe we would gain implementing something along those lines in S2S.
Obviously, as XMPP S2S is connection oriented, we will be in a better
situation than SIP to retry at a remote domain level rather than for every
single address. The important point would be to clearly define the various
timeouts, and the associated error states.
It is also worth noting that detecting a lost connectivity will probably be
easy for the server. Consequently, following the XMPP mantra (complex
server, simple client), we could define a way for the server to advertise
the resulting error to any live client with roster items in the remote
domain that has become un-reachable. We have to be careful doing so, as this
will imply we also have to define the opposite mechanism for when the
connectivity is restored. In SIP, clients have their own timed retry
mechanism and will resend the message that created the error several time
before giving up. We do not have this in XMPP... So we'll need something at
the server level.

My $0.02, but I believe solving this would greatly improve the robustness of
S2S connectivity, which is a big strength of XMPP.
 
Jean-Louis
-----Original Message-----
Message: 9
Date: Thu, 26 Oct 2006 13:49:04 -0700
From: "JD Conley" <jd.conley at coversant.net>
Subject: RE: [Standards-JIG] RFC 3921 Better User	PresenceExperience
	(Implementation Detail)
To: "Jabber protocol discussion list" <standards-jig at jabber.org>
Message-ID:
	<97B71C0C860DEC40A993AB9F7F0D43357026EC at fattire.winfessor.com>
Content-Type: text/plain;	charset="utf-8"

> I think we should think about something like sending a <presence
> type="error"/> in that case. This would allow the entity that
> subscribed
> to the presence, to decide on how to react on this situation. E.g. a
> muc
> comonent could throw the user out of a room, while a client could mark
> the contact to have unknown state.

I do like that idea of using errors rather than unavailables. One bad thing
I can see about using errors is it wouldn't work with existing clients (I
can't think of any off the top of my head that show an error state for a
contact very well). However, with an error the client could make a much more
informed decision about how to display its contacts.

Regardless of how we notify the local clients, the local server still needs
to keep retrying to connect to the remote domain and when it does it still
needs to probe to make sure it has current presence. I'd still rather see
this probe be a single (small - not extended stanza addressing) stanza
rather than one for every entity that needs presence from the remote domain.

-JD






More information about the Standards mailing list