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

Tijl Houtbeckers thoutbeckers at splendo.com
Thu Mar 3 20:55:02 UTC 2005


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.

The problem is not with TCP. The problem is XMPP does not have a way of  
knowing yours stanzas were delivered hop to hop. In the perfect enviroment  
and with the perfect TCP library that's not a problem. However in practise  
that combination can be rather hard to find. Only in a controlled  
enviroment (like a corportate enviroment perhaps) can you even be sure of  
this. (There is no way of detecting whether your connection is free of  
those nasty proxies, for example)

If you bind XMPP to another transport layer that makes no garantuees about  
how safe it is, you'll run into the same problem. Thus, a solution on the  
XMPP layer is needed. Eg. if you'd implement JEP 124 as a standalone proxy  
you'll run into it.

Yes, there is the alternative of doing things e2e. However, that leads to  
much more complexity and some cases will be hard to solve (eg. presence).  
IMHO a too heavy requirment for client and servers who just want to know  
whether the stanzas they send arrived.

I know this is just a rehash of things that have been said many times on  
the list, however, none of them seem to have come back in the council  
discussion!

I suppose one could argue this should be solved in RFC 3920. However in  
the introduction (or any further text that I know of) of XMPP CORE there  
is no mention of what reliability of stanza delivery (and processing,  
something this JEP does not address either) it is aiming for. Changing  
that might be a good idea, on the other hand I see no reason (looking at  
the current RFC) why such reliability enhancements could not be an add-on.

Keep in mind that JEP-ACK does not prentend to make 100% garantuees about  
delivery of your stanza, let alone end to end delivery. It's just an easy  
way of greatly reducing the current problems in sending your stanzas down  
to a more managable level (to what I *would* call edge cases: such as  
server crashes or errounous implementations). That's fine for lot's of  
applications (like "consumer" IM, if you ask me). Some other applications  
might require more rigid but complexer implementations (that would make  
using JEP-ACK unnecisary), which COULD be a reason NOT to include it in  
XMPP CORE or XMPP IM (let whatever uses that decide what mechanism is best  
for it).



More information about the Standards mailing list