[Standards] XEP-0047: IBB

Peter Saint-Andre stpeter at stpeter.im
Wed Feb 17 02:31:36 UTC 2010

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 <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.

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 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/20100216/6b5b933b/attachment.bin>

More information about the Standards mailing list