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