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: >>> 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.
I don't see a good way to do that in XEP-0047, but it's easy enough in XEP-0261 using Jingle session-accept or transport-info. >>> 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. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
