We use IBB (for Jingle and SI) in an XMPP product that we use internally and
may release commercially soon. A different developer, on my team, handled the
IBB related tasking so I can't provide definitive information. I can tell you
that we can easily adjust to any change made at this point. From a quick
glance at the code, it looks like we are using block-size to control the amount
of bytes read from the buffer at a time. I would need to look at it further,
but as I mentioned, we can make adjustments if anything changes (and if I
determine we are not currently supporting it correctly).
I looked at the XEP as well and see how it can be interpreted as referring to
the encoded data rather than the raw data. I would have to make a slight
observation here that a statement in 2.2 ("stanza, MUST NOT be larger than the
'block-size'") says "MUST NOT be larger" which implies it can be equal to or
smaller. This leaves room for interpretation. I don't see anywhere that the
block-size definitively refers to the raw or encoded data. I would suggest the
wording be more explicit here so interpretation is limited. I would also say
that block-size should definitively refer to the encoded data since that is
what is stored in the "data" portion of the message.
Todd Herman
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Matthew Wild
Sent: Wednesday, May 23, 2012 2:34 PM
To: Peter Saint-Andre
Cc: XMPP Standards
Subject: Re: [Standards] Call for Experience: Advancement of XEP-0047 (In-Band
Bytestreams) to Final
On 23 May 2012 02:52, Peter Saint-Andre <[email protected]> wrote:
> On 5/22/12 4:13 PM, Matthew Wild wrote:
>> Old draft alert! I really thought I had sent this... sorry.
>>
>> On 31 January 2012 09:07, Sergey Dobrov <[email protected]> wrote:
>>> On 01/31/2012 05:54 AM, Peter Saint-Andre wrote:
>>>> At its meeting on December 20, 2011, the XMPP Council agreed to
>>>> issue a "Call for Experience" regarding XEP-0047 (In-Band
>>>> Bytestreams), in preparation for perhaps advancing this
>>>> specification from Draft to Final in the XSF's standards process.
>>>> To help the Council decide whether this XEP is ready to advance to
>>>> a status of Final, the Council would like to gather the following
>>>> information:
>>>>
>>>> 1. What software has implemented XEP-0047? Please note that the
>>>> protocol must be implemented in at least two separate codebases
>>>> (and preferably more).
>>>
>>> I have tested XEP-47 implementations in tkabber and Vacuum-IM. Also,
>>> I have my own implementation in my experimental library named "twilix"
>>> which is an high level wrapper on top of twisted library. This
>>> implementation is used now to pass attachments to my experimental
>>> microblogging platform implementation (named LiJ) which based on
>>> XEP-277. The source code of the implementation is placed here:
>>> https://github.com/xamvz/twilix/blob/master/twilix/bytestreams/ibb/b
>>> ase.py
>>>
>>>>
>>>> 2. Have developers experienced any problems with the protocol as
>>>> defined in XEP-0047? If so, please describe the problems and, if
>>>> possible, suggested solutions.
>>>
>>> The only problem I remember with the XEP is in this paragraph:
>>>
>>>> The base64-encoded data to be sent, prior to any wrapping in the <data/>
>>>> element and IQ or message stanza, MUST NOT be larger than the 'block-size'
>>>> determined in the bytestream negotiation.
>>>
>>> It's not clear for me when I have to check the length of the block:
>>> for raw data or for base64 encoded? In the last case it's hard to do
>>> such encoding. I implemented the last case for the first time but
>>> then I noticed that Vacuum-IM checks it for raw data and so my
>>> implementation said that Vacuum-IM sends inappropriate packets, so
>>> for now I am checking a raw data. Maybe it will be good to specify
>>> this thing more clearly.
>>>
>>
>> It seems overall pretty clear to me that the XEP says the block-size
>> limit applies to the data after base64-encoding. This does make it a
>> bit more awkward than it should be in my opinion, and I'm not
>> surprised clients interpret it differently.
>>
>> The maximum amount of data you can fit into X bytes of base64 is
>> 3*floor(X/4)... so for 4096 bytes of base64, 3072 bytes of data can
>> be sent. Not hard to figure out, but perhaps "too hard", and for the
>> sake of simplicity should be relaxed. If we do relax it (and make the
>> limit apply to pre-base64 length) then we should decrease the
>> recommended block size accordingly.
>
> It seems that at least an implementation note about that little
> calculation would be helpful. I don't particularly see a reason to
> change the spec on this point, but it's not a hill for me to die on.
My preference (and I would imagine the preference of all developers) would be
for the limit to apply to the input data. If people have already implemented
with the current text though then I agree it makes sense to leave it.
On the other hand from the (little) evidence we have that it's not entirely
clear what interpretation existing implementations have adopted. It wouldn't
surprise me at all if the majority are applying the limit to the pre-base64
data, and in that case I think the XEP should be amended accordingly.
But we need that data before making such a move. People with IBB
implementations, speak up!
Regards,
Matthew
