[Standards-JIG] Council decision on "Stanza Acking" proposal
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>
> In its meeting earlier today , the Jabber Council discussed whether
> to accept as a JEP the proposal for a "Stanza Acking" specification
> submitted by Justin Karneges. 
> 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
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
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
More information about the Standards