Old thread alert!

On 1/31/12 2:07 AM, Sergey Dobrov 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

Thanks for letting us know!

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

Well, the spec says that the length restriction applies to the
base64-encoded data, so I think we meant that this does *not* apply to
the raw data. However, you seem to be saying that this might be
difficult to implement. Have other folks experienced this problem?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


Reply via email to