[Standards] XEP-0047: IBB

Fabio Forno fabio.forno at gmail.com
Sat Feb 13 21:00:23 UTC 2010


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

> 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: ff at jabber.bluendo.com



More information about the Standards mailing list