[Standards] XEP-0138 vs. TLS compression

[Jonathan Chayce Dickinson]

Peter Saint-Andre wrote:
> Boyd Fletcher wrote:
>> *SNIP*
> 
> As far as I understand it, Efficient XML is more than just a compression
> algorithm. In order to prevent developer confusion, I think it might be
> helpful to write a XEP that describes how Efficient XML is to be used in
> the context of XMPP applications. That XEP could also register an item
> to be added to the compression algorithms registry.
> 
> /psa
> 

I like EXI, I really do, but how well will it work with streaming? EXI, 
in full, looks like it's designed for transactional requests, like SOAP, 
where the entire message is encoded at once. Maybe there should be a 
'fixed' event tree for Jabber gathered from statistics from a popular 
server (j.o seems like a good place to start).

Only sending the header at the stream start seems like a good idea, but 
I would be tempted to send it with every stanza if it's not stated 
clearly (it would probably be the default behaviour for most EXI 
libraries). I really think EXI is a good idea, but it's open to so many 
ambiguities.

EXI is pretty open to including custom options like this. Because it's 
binary I think the XEP will have to be really clear about ambiguities: 
textual XML is harder to mess up. Binary stuff can go nuts.

I think we were lucky as far as XML libraries go (e.g. expat). They were 
not designed for XMPP, but they could be used for it anyway. I think we 
are going to have a harder time finding EXI libraries that can handle 
streaming data.

Maybe a stanza boundary needs to be included? So that a client can send 
complete XMPP stanzas to the parser. That would open up more options for 
developers and would result in quicker adoptions as soon as the first 
EXI libraries come out (which probably won't support streaming).

Regards,
  Jonathan Dickinson

-- 
jonathan chayce dickinson
ruby/c# developer

email:  chayce.za at gmail.com
jabber: moitoi at inflecto.org

<some profound piece of wisdom>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6974 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070830/3d957f3d/attachment.bin