[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]

Dave Cridland dave at cridland.net
Tue May 29 13:43:14 UTC 2007


On Tue May 29 12:17:52 2007, Ian Paterson wrote:
> IMHO this can been seen as a server implementation issue. Although 
> using the same resource would fix the specific scenario you 
> describe, it does not address the fundamental problem. The server 
> should realise that the TCP connection to the high priority 
> resource is down (i.e. that the resource is offline) when it fails 
> to deliver the message (XEP-0198 may be necessary if proxies are 
> involved). It should then try delivering the message to another 
> resource instead.
> 
> 
Momentary aside - the server will only find out the resource is 
offline for certain some time *after* the delivery attempt, and the 
time can be anywhere from a millisecond or two (to recieve a FIN or 
RST across LAN) up to a TCP timeout. Given we're dealing with actual 
human messages, that's a very significant delay, so it's not just 
proxies and the like that need XEP-0198.

Luckily, in Adam's scenario, if the client also uses XEP-0198, then 
not only does the server notice the disconnect, but since he 
describes reconnecting presumably with the same client, his client 
can restore the session, maintaining the resource et al quite easily, 
and not missing any messages.

So this isn't a good reason for human-defined resource names; it's a 
good reason for XEP-0198. But... fixed resource names certainly 
reduce the problem, and are deployable now - indeed, are very well 
deployed now.

And besides, I personally like them - dwd at jabber.org/Office always 
goes to my desktop computer, and I like it that way. I see no 
technical advantage in changing that to a random string, and I 
believe it would be a change in deployed semantics at this point. By 
all means provide better methods of accomplishing everything that 
user-defined fixed resource strings can do, but don't get rid of them.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list