[jdev] Server responses to resource conflicts

[Will Thompson]

Hi,

<http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-14#section-7.6.2.2> 
specifies three legal server responses to a client trying to connect 
with an already-connected resource:

1. Assign the new client a fresh resource;
2. Boot the old connection, granting the resource to the new client;
3. Refuse the new connection.

It recommends 1, which is what (e.g.) Google Talk implements (well, they 
always randomize, but it's equivalent in this case ;-)). I was under the 
impression that no-one did 3, but I discovered that Openfire apparently 
does. <https://bugzilla.gnome.org/show_bug.cgi?id=629768>

I don't really think behaviour 3 is very useful. Maybe this is a 
function of being interested in mobile stuff, but I believe that the 
most common reason for trying to connect with an already-connected 
resource is recovering from a loss of connectivity. As the above-linked 
bug shows, behaviour 3 means you can't reconnect until the original 
connection times out.

So, I think the third behaviour should be strongly discouraged, with 
this rationale. (I suspect making it illegal is not going to fly now.) I 
guess the client can work around this behaviour by retrying with a 
different resource, but this doesn't have the nice property of cleaning 
up dead connections.

(Obviously the One True Way to recover from a loss in connectivity is 
XEP-0198, but deployed servers don't all implement this.)

Regards,
-- 
Will