[Standards] XEP-0047: IBB

Peter Saint-Andre stpeter at stpeter.im
Mon Feb 15 03:14:35 UTC 2010

On 2/13/10 2:00 PM, Fabio Forno wrote:
> On Sat, Feb 13, 2010 at 3:26 AM, Peter Saint-Andre <stpeter at stpeter.im> 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='juliet at capulet.com/balcony'
>>    id='jn3h8g65'
>>    to='romeo at montague.net/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 Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100214/f1a8629e/attachment.bin>

More information about the Standards mailing list