On Sat, Feb 13, 2010 at 3:26 AM, Peter Saint-Andre <[email protected]> wrote: > A few comments on XEP-0047... > > First, it might be useful if the error for "block size too big" provided > more detailed information, because right now the recipient can't tell > the sender what block size would be acceptable (e.g., if the sender > proposes a block size of 4096 and the recipient returns an error, the > initiator might then try a block size of 2048 but the receiver might > still return an error; that seems to require too many round trips). I > propose that we add an application-specific error condition that > specifies the preferred block size: > > <iq from='[email protected]/balcony' > id='jn3h8g65' > to='[email protected]/orchard' > type='error'/> > <error type='modify'> > <resource-constraint xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> > <pref xmlns='http://jabber.org/protocol/ibb' > block-size='1024'/> > </error> > </iq>
Just noticed that the block size is not really negotiated. When possible I'm always keen to handle feature negotiation without using errors, since code remains simpler. So I'd prefer to allow the responder sending back a smaller block size in the answer and not in the error. In that way the initiator can start sending blocks with the received block size, without needing to restart the stream > 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. -- Fabio Forno, Ooros srl jabber id: [email protected]
