[Standards-JIG] NEW: XEP-0198 (Stanza Acknowledgements)

Dave Cridland dave at cridland.net
Fri Nov 24 11:57:02 UTC 2006

On Fri Nov 24 11:02:48 2006, Mickaël Rémond wrote:
> The business case is the following:
> - We need to be sure that we will not lose messages
> - We need to detect as soon as possible that a client or server is 
> no  more reachable / connected.
[Caveat - I have not read all the referenced XEPs in detail - in 
particular I'm unfamiliar with XEP-0022 and XEP-0085, and haven't 
considered XEP-0184 or XEP-0079 WRT implementation]

I'd put it differently.

1) We need to ensure that the stanza has been received by the peer.
2) We need to ensure that the message has been acknowledged by the 
3) We need to test end-to-end connectivity, and sometimes measure 

If you think of the overall network as something like:

Alice <-1-> AliceClient <-2-> AliceServer <-3-> BobServer <-4-> 
BobClient <-5-> Bob

Where hops 2,3,4 are XMPP streams, and hops 1,2 are screen/keyboard:

XEP-0198 operates on any of hops 2,3,4. It's purely hop-by-hop, and 
makes these hops more resilient to failure, and makes it easier to 
detect failures of the lower levels. It's addressing (1). It doesn't 
help (3) or (1) directly, but it allows both to function more 

XEP-0199 operates on any of 2, 2-3, 2-4, 3, 3-4, 4. There's some 
overlap with XEP-0198, but note that it can operate across a number 
of hops. It's addressing (3), but can be used for limited (1) as 
well, by its nature. There's also a certain degree of (2) involved - 
one might assume that if someone's client is responding to a ping, 
it's very likely they received the message you sent them. It benefits 
from (1) when used across multiple hops.

XEP-0184 (which is based on XEP-0079) operates on 1-5 - it's human to 
human. A receipt from Bob to Alice asserts something about hop 5 for 
a message Alice sent through hop 1. It's solely addressing (2), which 
relies on (1), and also provides some of the information of (3) in 
some cases - you know that if someone's read your message, they're 
connected, but you couldn't use it as a latency measurement.

So yes, I agree there's overlap, but I think the majority of the 
overlap you describe is a by-product of the nature of what these 
different use-cases are about.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list