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

Mickaël Rémond mickael.remond at process-one.net
Fri Nov 24 17:05:26 UTC 2006


Hello,

Le 24 nov. 06 à 12:57, Dave Cridland a écrit :
> 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 reliably.
>
> 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.

If a peer answer to a ping, yes, we can assume that he has received  
the previous messages, but the reverse is not true. Not answering to  
a ping does not make it possible to know which message has not been  
received.
If you want to established retry policy that's not sufficient: You do  
not know which message might have been lost on the wire ...

> 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.

My opinion is that there is no need to acknowledge from 1-5 if you  
know that all subtransfers are reliable.
The most important XEP for servers is thus probably XEP 184, as it is  
a necessary component, at the "transport" level.
My feeling about end to end ack is that it should take place at the  
application level and only at this level. If your XMPP application  
needs end to end ack, you need to implement it over existing xmpp  
mechanism.

It is good to make that standard for most common cases, for client  
developers, but why should it require server-side implementation ?  
Maybe it is a sign that it is not positionned at the right level (I  
am talking about AMP, XEP-184 and XEP-79). I now agree with you that  
in this context, XEP-0199 makes senses, as it is purely transparent  
on top of XMPP.
In this regard, I feel that XEP-0079 and XEP-0184 are trying to  
achieve too much in a single mechanism.

-- 
Mickaël Rémond
  http://www.process-one.net/


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061124/4180629b/attachment.html>


More information about the Standards mailing list