Re: [media-types] Request for review of Media Type application/lzip

[Antonio Diaz Diaz <[e-mail]>]

Dear media types experts,

As I said in my first message in this thread, I'm trying to publish 
draft-diaz-lzip[1] as a RFC so that I can register at IANA (among other 
things) the media type 'application/lzip'.

[1] https://datatracker.ietf.org/doc/draft-diaz-lzip/

Until now all the reviews (here and at [e-mail]) have been favorable. 
But at [e-mail] some questions have been raised regarding the 
registration of compressed formats as media types:

https://mailarchive.ietf.org/arch/msg/art/o6NV_hwWIrHYU877SrKc_iv_1_c/
"But I agree with John, it doesn't seem quite right to have a compression 
scheme to be itself a media type.  It's probably worth looking at the 
discussions around the RFC that registered gzip, RFC 6713."

I think that some compressed formats are actual media formats worth being 
registered. They save storage space and add integrity checking to the data 
they contain. They also may increase the survivability of the data; multiple 
compressed copies may have a better chance of surviving intact than one 
uncompressed copy using the same amount of storage space.

I think that lossless compressed non-archiving formats are well suited as 
structured syntax suffixes because they have been used for a similar role 
for decades (tar.gz files, for example). I even maintain a set of tools 
(zutils) designed to take care of a compression layer on top of any base 
media type, usually what would correspond to 'text/plain+gzip'.

Maybe the confusion comes from the fact that compressed formats can also be 
seen as persistent content transfer encodings. Compressed files are usually 
stored in the server, transferred to the client, and stored in the client 
without decompressing them not for a moment.

Moreover, I agree with Dale R. Worley and John C Klensin in that compression 
schemes not intended to be saved in files and lacking a properly designed 
file format should perhaps not be registered as media types. This is the 
case of 'application/zlib' (RFC 6713), which does not define proper magic 
bytes nor any file extensions.

I need the help of the experts in this list to confirm the validity of the 
arguments above, and maybe find new arguments that will convince the IETF 
that it makes sense to register lossless compressed non-archiving formats 
with a properly designed file format (like gzip) as media types, and in 
particular that registering 'application/lzip' as a media type is not likely 
to cause any trouble. After all, lzip is basically gzip with higher 
compression ratio, correct size calculation, and more accurate integrity 
checking.

Thanks,
Antonio.