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

Daniele Ricci daniele.athome at gmail.com
Thu Aug 8 09:44:13 UTC 2013


Hi Dave,
thanks for your delightful answer. Actually I was going to reply with
pretty much the same arguments, I was looking for the time to write
that... you saved me from a long writing :-)

Anyway Dave has perfectly catched my needs. Although I ended up
defining my own extension, I really would like to standardize it or
(if possible) use an existing XEP.

p.s. the last paragraph came 3 times.


On Thu, Aug 8, 2013 at 11:37 AM, Dave Cridland <dave at cridland.net> wrote:
> 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.



-- 
Daniele



More information about the Standards mailing list