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. Regards, Matthew
