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

Bart van Bragt jabber at vanbragt.com
Fri Mar 25 22:05:28 UTC 2005

Peter Saint-Andre wrote:
> 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.
IMHO we're talking about an issue that shouldn't be downplayed so easily 
:\ Computers crash, Laptops get out of WiFi coverage, network cables get 
unplugged, servers die. Not once but thousands (millions?) of times each 
day. Or just take a look at the jabber.org server in the past month. It 
had quite a few outages where people appeared online but where messages 
never arrived for whatever reason.

If I send a message I either want this message to arrive or receive an 
error message that states that this message didn't arrive at the 
recipient. I had quite a few problems with this while I was still using 
a (fairly overloaded) public MSN/ICQ transport (yeah, yeah, transports 
are evil :D). I can tell you from experience that it's _extremely_ 
annoying to not know if your messages arrive intact. Didn't the person 
on the other side respond because he's away? Is he ignoring your remark? 
Is he just not interested into going into a specific topic that you 
mention? Was he offended? Is he too busy? Or did the message get lost in 
space somewhere?

Delivery notifications are a sort of stop gap solution that works fairly 
well as long as the other side supports them and if you're only 
interested in <message>-es. IMO it would be very, very nice if there 
would be some kind of protection against link breakages on a somewhat 
lower level.

Reverting to HTTP on a mobile device makes everything horribly 
inefficient because of the overhead and the fact that the mobile client 
has to poll for updates (and polling is extremely evil in my book :D). 
The nice thing about Jabber on a mobile device is that it costs close to 
nothing as long as you're not doing anything (and as long as you don't 
have a 500 user roster :D). IMO Jabber should just be able to handle a 
dropped connection gracefully, simple clients...

> 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. :-)
IMO the experiment then standardize process works pretty well for 
clients but it's horrible for servers. How can you test something like 
this when all you control is your client or your server? This needs 
cooperation of a conciderable amount of people/groups which in the end 
amounts to standardization :) At least to some extent... Experimenting 
with most client side code is easy because you control both ends of the 

> 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.
Well, what do we think is acceptable? 1 out of 100 messages getting 
dropped? 1 in 1000? 1 in a million? IMO 1 in a million is starting to 
get close and I wouldn't be surprised if the current drop rate would be 
on or two orders of magnitude higher than that. But, indeed, I don't 
have hard numbers. But there is also no evidence of this being 'just an 
edge case' either :)

I guess the only way to actually measure this is by using the delivery 
confirmation JEP. Which clients support that to this extent? IMO most 
clients only support this JEP for the typing notification part?


More information about the Standards mailing list