[Standards] XEP-0138 vs. TLS compression

Peter Saint-Andre stpeter at stpeter.im
Thu Aug 30 17:50:57 UTC 2007

Boyd Fletcher wrote:
> I strongly disagree. I think that sends a confusing message to developers.

How so? We have a registry. Refer to the registry. Do you think the XMPP
Registrar creates these things for fun? ;-)

> Perhaps, we should remove all the compression algorithm references XEP-138
> and have it only specify the core approach. Then create new XEPs for
> specific implementations: ZLIB, LZW, EXI, etc.... That is analogous to how
> the IETF does it - look at how they handled RTP and the different packet
> formats.

Right. I have no objections to that. But ZLIB is mandatory to implement.

> Or, we make XEP-138 obsolete and create a new one that adds EXI. IETF also
> does this approach.

That seems unnecessary.

> But having a separate XEP for just EXI for stream compression would I think
> be sending a confusing message to developers.

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070830/7ff309cb/attachment.bin>

More information about the Standards mailing list