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: >> 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
Yes, that is better. >> 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. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
