For SleekXMPP, I applied the limit to the pre-base64 data because I apparently didn't read the XEP closely enough.
I'll fix that shortly though using the 3*floor(X/4) formula. - Lance On May 23, 2012, at 11:34 AM, Matthew Wild wrote: > On 23 May 2012 02:52, Peter Saint-Andre <stpe...@stpeter.im> 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 <bin...@jrudevels.org> 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
smime.p7s
Description: S/MIME cryptographic signature
