[Standards] XEP-0138 vs. TLS compression

Peter Saint-Andre stpeter at stpeter.im
Thu Aug 30 20:14:56 UTC 2007

Boyd Fletcher wrote:
> On 8/30/07 1:50 PM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:
>> 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? ;-)
> I don't have a problem with the registry. I just had a problem with XEP-138
> listing LZW and not EXI.

We did that back in 2005. We could always move it to a separate spec.

>>> 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.
> should that be numbered like XEP-138a or a totally new XEP.

"XEP-0138a" doesn't fit with our naming scheme. :)

I think we should leave ZLIB in XEP-0138 because after all it is
mandatory-to-implement, and move LZW to a different spec.

>>> 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
> probably a good idea, but I think that is different than how it can be used
> for stream compression.
>> to be added to the compression algorithms registry.
> +1 for adding to the registry but we should remove LZW from XEP-138 and move
> its description text to registry.

+1 to specifying the LZW usage in a separate spec, -1 to adding lots of
text to the registry.


Peter Saint-Andre

-------------- 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/c8a8cdc9/attachment.bin>

More information about the Standards mailing list