[Standards] XEP-0047: IBB

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 17 03:25:44 UTC 2010


On 2/16/10 7:31 PM, Peter Saint-Andre wrote:
> On 2/14/10 8:14 PM, Peter Saint-Andre wrote:
>> On 2/13/10 2:00 PM, Fabio Forno wrote:
>>> On Sat, Feb 13, 2010 at 3:26 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>
>>>> Second, if the recipient detects an error with a data packet, the spec
>>>> says that it SHOULD (not MUST) return an error and is silent about the
>>>> number of retries that are appropriate, whether the recipient needs to
>>>> close the session at some point, etc. One option would be to say that
>>>> the recipient MUST return an error and close the session if it detects a
>>>> problem with a data packet. Another would be to more carefully specify
>>>> the retry logic. Do folks on this list have a preference?
>>>
>>> What about specifying that the recipient MUST return an error with an
>>> appropriate type? In that way it can specify whether to retry or
>>> close.
>>> Especially with IQs I don't have many use cases for allowing retries,
>>> but I think they could be useful for encrypted ibb with a low traffic.
>>> When reopening a S2S connection it could happen that some IQs are lost
>>> (noticed the problem with some servers) and still being able to retry
>>> could be useful.
>>
>> That's a more relevant scenario than file transfer.
>>
>> I'll look at the spec again tomorrow to see how we can modify it along
>> the lines you've suggested.
> 
> I still need to look at this.

I now see what you mean about error processing here. I think the text
needs to be updated a bit. Right now it says:

***

It is also possible that the recipient might detect an error with the
data packet, e.g. because the session ID is unknown, because the
sequence number has already been used, or because the data is not
formatted in accordance with Section 4 of RFC 4648. In this case the
recipient shall return an appropriate XMPP stanza error, such as
<item-not-found/>, <unexpected-request/> or <bad-request/>. Upon
receiving notice that a data packet cannot be processed by the
recipient, the sender SHOULD close the bytestream as described under
Closing the Bytestream but MAY attempt to correct the error and re-send
the offending data packet using the same sequence number (the recipient
MUST NOT consider a sequence number to have been used until the data
packet has been successfully processed).

***

I think it needs to be more specific about the error types, as you
suggest. So something like this:

***

It is also possible that the recipient might detect an error with the
data packet, e.g. because the session ID is unknown, because the
sequence number has already been used, or because the data is not
formatted in accordance with Section 4 of RFC 4648. In this case the
recipient shall return an appropriate XMPP stanza error, such as
<item-not-found/> with a type of 'cancel' or 'modify',
<unexpected-request/> with a type of 'cancel' or 'modify', or
<bad-request/> with a type of 'cancel' or 'modify'. If the stanza error
is of type 'auth' or 'cancel', the sender MUST close the bytestream as
described under Closing the Bytestream; if the stanza error is of type
'continue', 'modify', or 'wait' the sender SHOULD attempt to correct the
error and re-send the offending data packet using the same sequence
number. The recipient MUST NOT consider a sequence number to have been
used until the data packet has been successfully processed; however, the
recipient MAY close the bytestream if the sender attempts to send the
same data packet too many times (in which case the stanza error
condition MUST be <policy-violation/> with a type of 'cancel').

***

However, I don't think that text is quite complete, because we might say
more about how a client recovers from these errors. For example, how
could the recipient handle the situation in which the session ID is
unknown? Perhaps there's no good reason to expect that a client could
recover from such errors. Feedback from implementers would be appreciated.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100216/0b893db7/attachment.bin>


More information about the Standards mailing list