[Standards-JIG] In order delivery for xep-0047 ?

[Mridul]

Justin Karneges wrote:
> On Thursday 07 December 2006 8:19 am, Mridul wrote:
>   
>> Matthias Wimmer wrote:
>>     
>>> If you are binding a XMPP stream on a transport protocol, that does
>>> not guarantee in-order delivery by itself, your binding would have to
>>> ensure the reordering.
>>>       
>> I think the assumption here is that in order processing will immediately
>> result in in order delivery - which is a simplistic scenario.
>> Anyway, the point is - since xmpp does not mandate in order delivery : I
>> am not sure why 47 is trying to mandate it - especially since seq number
>> can be used for message re-ordering in case of out of sync delivery.
>>     
>
> Except that XMPP *does* mandate in-order delivery.

The spec does not.

>   If it is unclear in the 
> RFC, then it needs to be fixed, since I believe this was always the intent of 
> the protocol.  I think the only reason the document doesn't explicitly 
> say "in-order delivery" is because this would be redundant in the context of 
> a single TCP stream.  Now that we realize we might have non-TCP bindings, or 
> multiple TCP streams (s2s), some additional clarification is needed.  
> However, I don't see in-order delivery between each jid pair to be a threat 
> to parallelism.
>
> Regarding IBB: XMPP guarantees stanza order, but it does not guarantee stanza 
> delivery to occur.

I am not sure of this - if you are in the middle of a transfer, why 
would a stanza not get delivered ?
And if a stanza does not get delivered, the sender will be notified with 
an error - which can be used by it to close the stream.

Regards,
Mridul

>   Therefore, a sequence number is needed to detect a hole 
> in the transfer (missing packet).  The sequence number is not used for any 
> kind of reordering.
>
> -Justin
>