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

Matthias Wimmer m at tthias.eu
Fri Oct 27 23:31:30 UTC 2006


Justin Karneges schrieb:
> As I've read this thread, it seems to me that the idea doesn't require any new 
> protocol.  Developers that choose to implement better informing of errors to 
> their clients or better server reconnection simply have a better server.
> 
> Anyway, a "best practices" document couldn't hurt.

I think we still have to think about the following two things:

<presence type='error'/> can also be generated by the server if a
presence sent by the user could not be delivered to the addressee. The
difference here is, that the one error-presence means "could not
deliver" while the other error-presence means "we expect not being able
to receive". While in most cases this will be the same and a contact
will just get marked as "currently not reachable", it would still be
good if the two error cases are distinguishable.
I think about two ways that could be used to distinguish these cases:
Either we define that a expected problem in receiving presence updates
should be delivered to the bare JID (sent to all sessions of a user, but
not having the resource in the to attribute), while the problem
delivering a presence stanza would result in a bouncing presence to the
full JID of the sender.
Or we define, that if a Jabber entity wants to distinguish these two
cases, it should send presences with an id attribute (which that gets
bounced back), while a server generating an error-presence on its own
should not generate an id attribute.

While with dialback we normally had only fully brocken connections (i.e.
if one direction does not work, the other works neither), with SASL we
may have connections working in one direction, but not in the other.
This might be caused by A accepting the certificate of B, but B not
accepting the certificate of A. (This is a problem I already noticed to
happen on my own server. Currently it results to have one direction
working as a SASL connection, while the other direction is established
using dialback. But as I expect, that we discontinue supporting dialback
some time, the impact might get bigger.)
In that scenario (connections working only one-way) the proposed thing
of setting a contact into a special state if a connection to it could
not be established might get problematic. It might be, that we cannot
connect to a destination and set presences to be on error while we still
can receive and will receive presences.
It might be, that we just accept, that with the proposed new presence
handling, we still can get wrong presences being displayed. But in any
case we have to arrange for incoming presences in the algorithm, that
checks if a destination becomes available again.


Tot kijk
    Matthias

-- 
Matthias Wimmer      Fon +49-700 77 00 77 70
Züricher Str. 243    Fax +49-89 95 89 91 56
81476 München        http://ma.tthias.eu/



More information about the Standards mailing list