On 2/17/10 3:21 PM, Peter Saint-Andre wrote: > On 2/17/10 9:51 AM, Fabio Forno wrote: >> On Wed, Feb 17, 2010 at 4:25 AM, Peter Saint-Andre <[email protected]> >> wrote: >>> *** >>> >>> 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. >> >> In fact I'm mumbling over the possible errors: >> - in real cases the most common error is an <iq/> lost for which we >> receive an error from our server (e.g. the case of a S2S connection >> taking too much time to reopen), and in this case the recipient is not >> involved at all in the process and the sender can try to recover by >> re-sending the stanza > > Yes, that seems to be the most common error. > >> - IDs out of sequence o packets with bad data are something which is >> very uncommon on an xmlstream and when it happens the only sane >> recovery is restarting the stream > > Agreed. > >> - No recovery at all if the SID is missing > > Agreed. > >> After this I'm stepping back on the option of always closing the >> stream when some error is detected by the recipient. > > By "stepping back on" do you mean "I think that the sender MUST close > the stream if it receives an error from the recipient related to a data > packet"? I'd be fine with that, but I wanted to check with people on > this list before recommending that behavior. All the errors I could > think of were fatal.
If I understand your comment correctly, I would change the text as follows: *** The sender of a data chunk need not wait for these acknowledgements before sending further stanzas. However, it is RECOMMENDED that the sender does wait in order to minimize the potential for rate-limiting penalties or throttling. It is possible that delivery of the stanza might fail, in which case the sender's or recipient's server shall return an appropriate error: 1. Because the recipient has gone offline, the recipient's server returns a <recipient-unavailable/> error with a type of 'wait'. 2. Because a server-to-server link has gone down, the sender's server returns a <remote-server-timeout/> error with a type of 'wait'. Upon receiving an error related to delivery, the sender SHOULD temporarily suspend the stream but retry sending at a later time. It is also possible that there is a problem with the data packet itself, in which case the recipient shall return an appropriate error: 1. Because the session ID is unknown, the recipient returns an <item-not-found/> error with a type of 'cancel'. 2. Because the sequence number has already been used, the recipient returns an <unexpected-request/> error with a type of 'cancel'. 3. Because the data is not formatted in accordance with Section 4 of RFC 4648, the recipient returns a <bad-request/> error with a type of 'cancel'. Upon receiving an error related to the data packet, the sender MUST close the bytestream as described under Closing the Bytestream. *** Because the changes are starting to become more significant, I've posted an interim build here: http://xmpp.org/extensions/tmp/xep-0047-1.3.html Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
