[Standards] Application-level delivery notification between server and client

Dave Cridland dave at cridland.net
Thu Aug 8 09:37:26 UTC 2013


I know this thread is going to sleep, but I'd like to stick my oar in. :-)

On Tue, Aug 6, 2013 at 9:15 PM, Daniele Ricci <daniele.athome at gmail.com>wrote:

> Please correct me if I'm wrong at any point, just to be sure I
> understand XEP 198 and how I can use it in the right way.
>
>
XEP-0198 is designed to make a stream:
 - Reliable: You know what has definitely been received by the peer.
 - Recoverable: You can have a stream span TCP connections, in effect,
without duplication or loss.

But note this *only* has an effect for streams; "chat sessions" span
multiple streams - unless you're talking to a server, or using XEP-0174
(Serverless messaging, in case I've got the number wrong) - and so all this
is doing is making each leg of the journey reliable. That's important, but
not sufficient.


> In my case, I can only use the 'h' attribute to store the server-side
> message ID. Which I can't do according to the spec.
>
>
Right - h is purely a count. Because it's only one stream, rather than
end-to-end, we can do this, and it's sufficient. We could have had <a/> and
<r/> contain random guids or something, but then people would have expected
to be able to insert semantic meaning into them, and they don't need that.
<a/> is the conversational equivalent of saying "Right?" at the end of a
sentence, and <r/> is the equivalent of saying "Uh-huh" and nodding
politely. You don't need to figure out which sentences have been received,
because it's just "everything up until this point".

But just like a conversation where one side is just grunting and nodding,
while you know they've heard, you don't know if there was anything more.


> But the biggest and main issue is: a receipt is actually part of a
> message. It's not stream management; it means Alice will receive a
> delivery receipt when message has been delivered (and acknowledged) by
> Bob. I can't just throw off <r/> at any time for this purpose - it
> would not be stream management any more. That's why I think I need
> something half XEP 198 and half XEP 194.
>
>
And you're right - except you don't want half '198 and half '184, you
actually want all of both.

Whilst XEP-0198 makes streams reliable, to make chat sessions reliable to
need XEP-0184, which will then mean you can reliably send a message - and
reliably get a receipt back when it's delivered.

The reason you need both, despite them looking superficially similar, is
that without any XEP-0198 in place you can't actually tell if it was the
message that was lost or the XEP-0184 receipt, and so while the safe thing
to do is warn the user and possibly resend, that may be very irritating for
the recipient.

The reason you need both, despite them looking superficially similar, is
that without any XEP-0198 in place you can't actually tell if it was the
message that was lost or the XEP-0184 receipt, and so while the safe thing
to do is warn the user and possibly resend, that may be very irritating for
the recipient.

The reason you need both, despite them looking superficially similar, is
that without any XEP-0198 in place you can't actually tell if it was the
message that was lost or the XEP-0184 receipt, and so while the safe thing
to do is warn the user and possibly resend, that may be very irritating for
the recipient.

I hope that makes things clearer,

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130808/02e9a5f0/attachment.html>


More information about the Standards mailing list