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 <[email protected]> >>> 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/
smime.p7s
Description: S/MIME Cryptographic Signature
