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

Stephen Marquard scm at marquard.net
Fri Mar 25 14:54:31 UTC 2005

Tijl Houtbeckers wrote:
> On Thu, 3 Mar 2005 13:25:27 -0600, Peter Saint-Andre 
> <stpeter at jabber.org>  wrote:
>> In its meeting earlier today [1], the Jabber Council discussed whether
>> to accept as a JEP the proposal for a "Stanza Acking" specification
>> submitted by Justin Karneges. [2]
>> The consensus of the Council is threefold:
>> 1. It is not clear what real-world use cases this proposal addresses, in
>>    the sense of solving pressing problems (rather than edge cases) with
>>    the XMPP protocols and network as they exist today (e.g., problems
>>    that cannot be solved by using the existing practice of "whitespace
>>    pings" over the stream, setting TCP timeouts to lower values, and the
>>    like).
> There has been quite some discussion about this on the list. There are  
> lot's of programming enviroments that experience the black hole effect.  
> Apart from that there were many real world examples given where even  
> having the perfect TCP stack would not help you (proxies, gateways, 
> etc).  Because of the large number of situations I do no think the term 
> "edge  cases" would be justified for them.
> Options such as lower time outs (if even available to the programmer) 
> do  not solve this.
> As for whitespace pings, this is a very unofficial feature. It's even 
> less  functional than the "ping" part of JEP-ACK, doesn't have 
> negotiation etc.  so it's not a real alternative for anything either.
>> 2. If there is a problem, it probably exists at the TCP layer, not the
>>    XML streaming layer (e.g., it would not apply to other bindings of
>>    XMPP, such as the HTTP Binding).
>> 3. If there is a problem at the level of the binding of XMPP to TCP, then
>>    it needs addressed during the process of revising RFC 3920 within the
>>    IETF, not by means of a JEP.

I must say I'm disappointed about the Council's rejection of this JEP, 
and I agree with Tijl's comments.

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).

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.

Are any client authors interested in implementing JEP-ACK as-is (for 
example if there was a patch for jabberd2 to support some or all of it)?


More information about the Standards mailing list