Subject: [apps-discuss] Review of draft-levine-application-gzip-01.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 10 Apr 2012 11:54:14 +0100

Hi John,
I am sorry I've missed this document earlier.

I am generally happy that you wrote this draft and support its 
publication. Having said that, I think it needs some changes:

In Section 1:

    Some applications have informally used the media type application/
    x-gzip.  The media types defined in this document should replace that
    media type in future applications.

Also I've seen application/x-gzip-compressed being mentioned on the web.

But I think it would be better to wait for 
draft-ietf-appsawg-media-type-regs-04 to be submitted to IESG (it is in 
the APPSAWG WGLC now). That document would relax restrictions on 
registering x-* media types. I think your document should register media 
types already in use, as changing existing implementations to use 
application/gzip is hopeless at this point, unless there is some 
evidence that application/gzip is also in use. In the latter case 
aliasing mechanism proposed in draft-ietf-appsawg-media-type-regs should 
be used.

3.1.  Regsistration Details

    Person and email address to contact for further information: see
    http://www.gzip.net/

I've just tried this URI and I am getting "this domain is for sale". It 
doesn't look like this is a good stable reference.

5. References

This Section should be named "Normative References".

Nit: spot typos in names of Sections 2.1 and 3.1.

---

From: John Levine <[email-masked]>
Date: Tue, 10 Apr 2012 13:24:00 +0000

I don't feel strongly about gzip vs. x-gzip but I also don't think
there is much x-gzip now. There is a good chance that DMARC will use
whichever it defines. Will look for a better ref than gzip.net
although the real refs are the RFCs of course.

r's from my Kindle
John

---

From: "John Levine" <[email-masked]>
Date: 13 Apr 2012 21:26:39 -0000

>although the real refs are the RFCs of course.

The right reference is www.gzip.org, which has been around for
15 years and seems unlikely to go away.

R's,
John

>_______________________________________________
>apps-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Ned Freed <[email-masked]>
Date: Fri, 13 Apr 2012 17:22:48 -0700 (PDT)

> Also I've seen application/x-gzip-compressed being mentioned on the web.

And application/gzip-compressed, application/gzipped, application/x-gunzip, and
probably a bunch of others.

> aliasing mechanism proposed in draft-ietf-appsawg-media-type-regs should

I'm ambivalent about this in this case. There are simply too many names for
this media type in use; no matter which one we pick is cannot possibly conform
to all existing usage.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 13 Apr 2012 23:34:55 -0400

--On Friday, April 13, 2012 17:22 -0700 Ned Freed
<[email-masked]> wrote:

>>     Some applications have informally used the media type
>>     application/ x-gzip.  The media types defined in this
>>     document should replace that media type in future
>>     applications.
> 
>> draft-ietf-appsawg-media-type-regs-04 to be submitted to IESG
>> (it is in the APPSAWG WGLC now). That document would relax
>> restrictions on registering x-* media types. I think your
>> document should register media types already in use, as
>> changing existing implementations to use application/gzip is
>> hopeless at this point, unless there is some evidence that
>> application/gzip is also in use. In the latter case aliasing
>> mechanism proposed in draft-ietf-appsawg-media-type-regs
>> should be used.
> 

And, of course, there is the separate issue that caused us to
reject various "zip" and related types years ago -- it is
basically a content-transfer-encoding (even if it also used
locally) and not a content/media type.

As with other things, the "horse have left the barn" principle
may argue for registering it anyway, but we (and I believe any
spec) should be aware that it breaks the model.

    john

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2012 14:17:41 -0000

>locally) and not a content/media type.

You're right, but these days you could make much the same argument
about application/pdf.  (Text? Images? Encrypted?  Forms to fill in?
Active content?  Whatever else they've addred to PDF lately?)

In view of Ned's comments, I'm inclined to leave it as
application/gzip.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Apr 2012 12:18:24 -0400

--On Saturday, April 14, 2012 14:17 +0000 John Levine
<[email-masked]> wrote:

> You're right, but these days you could make much the same
> argument about application/pdf.  (Text? Images? Encrypted?
> Forms to fill in? Active content?  Whatever else they've
> addred to PDF lately?)
> 

John,

I think there are two separate issues here.  One is what this
should be called given that we decide it is an application type.
I agree that application/gzip is a reasonable answer to that
question.   The other is whether we give up significant
functionality by abandoning the distinction between a media
(content) type and a content-[transfer-]encoding.   The latter
concerns me independent of the level of current practice, if
only because, once we "officially" start down that slope, I
don't see any model by which we stop.

In the latter regard, I don't see your analogy to PDF as
relevant.  It would be relevant had we defined text/pdf,
image/pdf, etc., but we didn't -- we defined it as an
application type from the beginning.  Independent of what goes
on inside a PDF document (even one that is a aggregate of
several kinds of things), it still meets the basic criteria for
an application/ subtype, namely "go off and find a competent PDF
processor and let it do its thing".  The problem with compressed
formats (or, worse, compressed aggregate ("archive") ones like
zip or tar.gz) is that the compressor/uncompressor are just
reversible transformation formats of something else -- where
that something else might be one or more objects of
substantially any media type.  

Now I don't think the original model works entirely well for the
compressor-aggregator case either, first because one might end
up needing
   content-transfer-encoding=SomeZip
encoded with, e.g., base64, and, if the compression form is also
an aggregating one, one could have 
   SomeZip (text-file, image-file, image-file,...)

There is no clear way to express that compressed aggregate in
Media-type language either.  At the same time, the binary data
problem notwithstanding, it has hard for me to understand why a
strict compression type shouldn't, in principle, be a CTE (and,
while the discussion has mostly focused on gzip, zlib, as a pure
stream compression format, seems like even more of a candidate
for a CTE.

Precisely because of the aggregation issue, "application/zip" is
a more complex case than "application/gzip" but we see a lot of
"application/x-zip" in the wild too.

The above is no surprise.  We were at least aware of the issue
when MIME was designed.  I'm just reluctant to give up on the
distinction without a more general and careful examination of
the model than one gets if one starts, as it appears to me that
your document appears to start, with "this is useful, there is a
lot of it out there (modulo details of the keyword chosen), so
let's standardize it".

Expressed a little differently, this spec, especially for zlib,
changes or ignores the distinction between content-type and
content-transfer-encoding of the base MIME specification.   As
such, it effectively updates that specification unless there is
a clear explanation of why the distinction doesn't apply to this
case.  So I believe that the document has some obligation to
either:

	(1) Explicitly update RFC 2045, especially the
	discussion in the last half of Section 6.4, to split
	whatever hairs need to be split to justify a stream
	compression method that can, in principle, be applied to
	media of any type as a media type rather than as a CTE.
	FWIW, updating 2045 probably requires a standards track
	spec, possibly a separate one.    Or
	
	(2) Explain why that discussion either isn't applicable
	or should be ignored because of the special
	circumstances of this case.

As a hypothetical question, if someone sat down now and wrote up
a spec for two new content-transfer-encodings, Zlib and ZlibB64,
explaining in those specs that, while application/x-zlib is in
use, it was a mistake and should be deprecated in favor of the
C-T-E form, what reaction would it get?  I'm not predicting that
such a spec would be written, but thinking about the possibility
may help in the discussion.

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2012 16:26:14 -0000

>In view of Ned's comments, I'm inclined to leave it as

A little Googlage found at least five other MIME types that people
have used to describe gzip data.  I just posted a new version that
mentions all of them and suggests that people use application/gzip or
application/zlib in the future, fixes the reference to gzip.org, and
a bunch of typos.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 14 Apr 2012 16:33:46 +0000

> "application/x-zip" in the wild too.

But "application/zip" is registered.  See RFC 2912, section 4.5 for a 
suggestion about how one might say what's inside the ZIP file in an 
application/zip MIME part, and RFCs 2007 and 6362 for other references. 
I agree that in a more ideal world, the compression type would be in with 
the encoding, but that horse bolted 20 years ago.

The reason I'm doing application/gzip is that the DMARC project is sending 
reports as application/zip for something where gzip would be more 
suitable, and when I asked why, the document author said that 
application/zip is registered and application/gzip isn't.  So I'm 
levelling the playing field.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Apr 2012 12:41:35 -0400

--On Saturday, April 14, 2012 16:33 +0000 "John R. Levine"
<[email-masked]> wrote:

>> Precisely because of the aggregation issue, "application/zip"
>> is a more complex case than "application/gzip" but we see a
>> lot of "application/x-zip" in the wild too.
> 
> But "application/zip" is registered.  See RFC 2912, section
> 4.5 for a suggestion about how one might say what's inside the
> ZIP file in an application/zip MIME part, and RFCs 2007 and
> 6362 for other references. I agree that in a more ideal world,
> the compression type would be in with the encoding, but that
> horse bolted 20 years ago.

Sorry.  Had lost track of application/zip.  Comments/objection
withdrawn -- this spec should not be victimized when we've
already made a worse mistake.   At some stage, we should rethink
the distinction that RFC 2045 tries to make, but I'm not
volunteering and am not going to hold my breath.

> The reason I'm doing application/gzip is that the DMARC
> project is sending reports as application/zip for something
> where gzip would be more suitable, and when I asked why, the
> document author said that application/zip is registered and
> application/gzip isn't.  So I'm levelling the playing field.

Seems reasonable.  
   john

---

From: Ned Freed <[email-masked]>
Date: Sun, 15 Apr 2012 14:09:09 -0700 (PDT)

It occurs to me that the new media types registration process allows a
registration to list deprecated type name aliases for the type. Seems to me
we might want to take advantage of that.

				Ned