[jdev] Server responses to resource conflicts

[Peter Saint-Andre]

Will, you make some good points. I will add some stronger wording to
rfc3920bis on this point after IETF Last Call.

On 9/16/10 2:38 AM, Will Thompson wrote:
> 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,