[Standards] LAST CALL: XEP-0198 (Stream Management)

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Jun 17 20:42:19 UTC 2009

On Wednesday 17 June 2009 12:47:49 Philipp Hancke wrote:
> Justin Karneges wrote:
> > Are you suggesting that we should not have s2s session resumption, but
> > you're okay with s2s acking?
> I just don't see yet what exactly session resumption means in the s2s
> context. s2s acking might help, although I think that s2s connections
> are already far more reliable than it is rumored. The main problem there
> is imo overly aggressive use of stream errors.

True, s2s is generally more reliable than c2s.  Most c2s problems have to do 
with wi-fi or other dodgy internet connections, or roaming clients.  In 
contrast, servers usually stay put and have good network connections.

I would imagine that most s2s problems are due to server 
upgrades/modifications or failures: someone changes their DNS, reboots their 
server, power goes out, etc.  I'll admit that session resumption after a 
power failure may be a lot to ask for, but it's surely not impossible for 
those that want to try.

There's also the race condition of a server closing down an idle s2s 
connection just as the peer sends it a stanza.  So at least this could be 
solved by session resumption, though it's probably a rare problem to begin 

> > Just keep the state, whatever it is.
> The 'whatever' is the problem. Actually, I think it is just the list of
> domains authorized to send/receive for the stream.

It just might be that simple, hopefully. :)  I think XEP-198 should be kept in 
mind when designing the multiplexing stuff, and we can talk about this again 
if it turns out to be really difficult.


More information about the Standards mailing list