On Mon Oct 6 12:07:45 2008, Pedro Melo wrote:
On Oct 5, 2008, at 11:42 PM, Dave Cridland wrote:
On Sun Oct 5 10:33:46 2008, Jonathan Schleifer wrote:
How does replacing the resource work? I thought <conflict/> was
issued
if the resource was in use.
If you get a conflict, you can continue and replace the old
resource.
IIRC, with the current RFC, it's undefined what the server does
then, but most replace it. This should be clearified IMO so that
the RFC says it should be replaced then.
FWIW, we conflict. I have some ideas for how to do replacement
sensibly, but terminating a live client means risking the
ping-pong effect that server administrators hate.
Sure, but such client is broken if he does not respect the stream
error condition <conflict />.
A proper client, if he receives a <conflict /> stream error MUST
NOT reconnect.
Unfortunately MUST NOT does not reprogram existing implementations
and deployments. Would that it could. :-)
Instead, I think the solution is to, when a conflict case is found,
to ping the existing session, terminate it if it does not respond
quickly, and return a conflict to the new session if not.
Essentially, avoid terminating "real" sessions with a <conflict/>.
Presumably, the user is either in front of the new session, or else
doesn't care.
Luckily, all this is largely a QOI issue, and is orthogonal to
whether servers SHOULD NOT, MAY, or SHOULD respect a client
requesting a specific resource.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
