[Standards-JIG] Re: Council decision on "Stanza Acking" proposal

Tijl Houtbeckers thoutbeckers at splendo.com
Fri Mar 25 22:14:30 UTC 2005

On Fri, 25 Mar 2005 22:16:08 +0100, Peter Saint-Andre <stpeter at jabber.org>  

> On Fri, Mar 25, 2005 at 04:54:31PM +0200, Stephen Marquard wrote:
>> It's hard to see how the problem can be called an "edge case" (with
>> increasing prevalence of wireless devices that go off the air without
>> notice, and notebooks that get hibernated).
> IMHO, devices that cannot maintain long-lived TCP connections should use
> a different stream binding (i.e., the HTTP binding defined in JEP-0124).
> And it seems to me that before a notebook computer switches to hibernate
> mode, it should be able to inform applications of that fact, so that a
> a Jabber client can end its session gracefully. Making modifications at
> the stream level in order to compensate for poorly written clients does
> not strike me as a good idea.
>> The council decision also seems to be a reversal of the practice of
>> establishing working protocols and then standardising them through IETF.
>> If everyone had waited for RFC3920 before writing any code, Jabber
>> wouldn't exist today.
> Actually, the true practice is working on some experimental code and
> then standardizing it through the appropriate means (either a JEP or an
> Internet-Draft). So feel free to experiment. :-)
> Finally, I really would be curious to know how serious a "problem" this
> is, as shown by hard numbers and actual statistics. So far, all we have
> is anecdotal evidence as far as I'm concerned.

What you're basically saying is that most clients can maintain "long  
lived" TCP connections and close them gracefully. This indeed seems to the  
assumption that RFC3920 is written. I'd say in practise however the  
situation where this is actually true is probably closer to 0% than to  
100%. Though most of the time you probably "can", there is no garantue. I  
think most of us on this list who've used jabber for a while or run a  
server know all about "ghost presence", users that appear to be online but  
are really not.

To combat this behaviour there are some tricks, for example keeping track  
of which bytes your TCP stack claims delivered. Apart from this not  
working in the case of many proxies (both transparant and not  
transparant), fairly common programming envoriment (eg Java) do not have  
this functionality. Both harldy edge cases..

Another "trick" is sending those ping "whitespaces". This is of course not  
official protocol either and it has it's own set of problems (eg. how do  
you know wether a space is a "ping" or a "pong"?). Then there's  
keep-alive. Again, bad behaviour with many types of proxies and not  
available in all programming enviroments.

The final trick (works best if it's available) is not caring or pretending  
it doesn't happen.

JEP-ACK standardizes these solutions. Not just for the TCP binding but for  
any binding, since it's at the XMPP level. It's 100% optional, so if you  
have a situation where you trust your IP enviroment, just don't care, or  
you have a binding where it's not needed, no need to use it.

For those of us that do care, it allows more fine grained control over the  
connection; you know which stanzas were delivered, unlike with hard time  
outs, whitespace pings or keepalive. It'll also be available to every  
programming enviroment that can do XMPP.

In the end, whether the number of clients (and servers) to benifit from  
this is relativly small or big, if it greatly enhances the end user  
experience even for that smaller group, I find that a good reason to have  
a standardized protocol. Counting the number of times the requests for  
something like this have come up though, and keeping an eye on how current  
implementations deal (or rather, do not deal) with this problem, I think  
it'd make more than a few developers and end users happy.

More information about the Standards mailing list