Re: Last Call: <draft-levine-application-gzip-02.txt> (The application/zlib and application/gzip media types) to Informational RFC

[John C Klensin <[e-mail]>]

--On Friday, May 04, 2012 19:26 -0700 Ned Freed
<[e-mail]> wrote:

>> You're right, it would be nice if there were some way to
>> distinguish containers from content in MIME types.  But given
>> the existing historical mess, and that some kinds of
>> compression are just a different way to encode a bunch of
>> bits (zlib) whereas others are more like a small filesystem
>> (zip and tgz), even if we could start with a clean sheet it's
>> not obvious to me what would be the best thing to do.
> 
> This is further complicated by the fact that there are now a
> number of types defined that are actually zip with specific
> semantics attached to the content. There are also types
> defined for use only within such containers.

With the wonderful advantage of hindsight, it might have been
better to define compound Content-Types/Media Types or a
universal encoding parameter rather than trying to separate
C-T-E out.   The first might have given us, e.g.,
application/foo+base64 and 'application/bar+xml+gzip' or
'application/bar+xml+gzip+base64'; the second something like
application/foo; encoding="base64" and 'application/bar+xml;
encoding=gzip+base64'.  Obviously a little late now :-(

And, again, not a blocking issue for this document, one way or
the other.

   john