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. Peter -- Peter Saint-Andre https://stpeter.im/
