[Standards-JIG] NEW: XEP-0198 (Stanza Acknowledgements)
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
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards