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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 3 May 2012 21:51:22 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Thursday, May 03, 2012 2:21 PM
> To: IETF-Announce
> Subject: Last Call: <draft-levine-application-gzip-02.txt> (The application/zlib and application/gzip media types) to Informational RFC
> 
> The IESG has received a request from an individual submitter to
> consider the following document:
> - 'The application/zlib and application/gzip media types'
>   <draft-levine-application-gzip-02.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2012-05-31. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

Only two things:

1) Shouldn't this be Standards Track?

2) Should it mention the "xdash" draft, since it talks about "application/x-*" types?

-MSK

---

From: [email-masked]
Date: Thu, 03 May 2012 14:54:21 -0700 (PDT)

> 1) Shouldn't this be Standards Track?

Based on past practices, the answer to that seems to be "no". See, for example,
RFC 6208, RFC 6207, RFC 6129, RFC 5967, and so on.

The rule seems to that if the specification defines the format as well as
registering one or more media types, then it needs to be on the standards
track. But if the specification simply registers a bunch of types, then
it's informational.

And I think this makes sense. After all, how would one assess interoperability
or pretty much anything else of a registration? 

I suppose you could argue that in cases where the registration points at an
external specification (which is not the case here) that it could be a sort of
"hook" to allow such assessment, but I think we have enough problems performing
evaluations of our own work that we don't need to added fun of evaluating
externally defined formats.

> 2) Should it mention the "xdash" draft, since it talks about "application/x-*" types?

That specification is really focused on not using x- in newly defined
registries, not on how it's used in existing registries. And since x-gzip and
friends are only mentioned to say they shouldn't be used, I'd say that while
such a reference would not bother me, I don't think it's especially helpful.

				Ned

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 3 May 2012 22:14:15 +0000

> From: Ned Freed [mailto:[email-masked]]
> Sent: Thursday, May 03, 2012 2:54 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: RE: Last Call: <draft-levine-application-gzip-02.txt> (The application/zlib and application/gzip media types) to Informational RFC
> 
> Based on past practices, the answer to that seems to be "no". See, for
> example, RFC 6208, RFC 6207, RFC 6129, RFC 5967, and so on.
> 
> [...]
> 
> registries, not on how it's used in existing registries. And since x-
> gzip and friends are only mentioned to say they shouldn't be used, I'd
> say that while such a reference would not bother me, I don't think it's
> especially helpful.

Good enough, just thought I'd ask.

I support publication as-is.

-MSK

---

From: [email-masked]
Date: Thu, 03 May 2012 17:11:21 -0700 (PDT)

> I support publication as-is.

As do I.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 May 2012 14:02:11 -0400

+1 

I'm still a little concerned about the boundary between media
(content) -type and content-transfer-encoding, but I've become
convinced that we should not put the burden of that issue onto
this document.  

I do believe that, someday, someone should try to write up an
up-to-date description of the difference that recognizes the
fact that compressed files are in use as media types with
application/zip (in assorted spellings) and application/gzip
(from this spec and in assorted spellings) as examples.  But I
now believe it is a separate task that should not block this
document or registration.

    john

--On Thursday, May 03, 2012 22:14 +0000 "Murray S. Kucherawy"
<[email-masked]> wrote:

>> Subject: RE: Last Call:
>> <draft-levine-application-gzip-02.txt> (The application/zlib
>> and application/gzip media types) to Informational RFC
>> 
>> Based on past practices, the answer to that seems to be "no".
>> See, for example, RFC 6208, RFC 6207, RFC 6129, RFC 5967, and
>> so on.
>> 
>> [...]
>> 
>> That specification is really focused on not using x- in newly
>> defined registries, not on how it's used in existing
>> registries. And since x- gzip and friends are only mentioned
>> to say they shouldn't be used, I'd say that while such a
>> reference would not bother me, I don't think it's especially
>> helpful.
>

---

From: "John Levine" <[email-masked]>
Date: 4 May 2012 19:11:04 -0000

>document or registration.

I'll be happy to do that if I can ever find enough spare time to write
it.

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.

R's,
John

---

From: [email-masked]
Date: Fri, 04 May 2012 19:26:55 -0700 (PDT)

> >document or registration.

That pretty much sums up my view as well.

> 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.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 May 2012 23:15:39 -0400

--On Friday, May 04, 2012 19:26 -0700 Ned Freed
<[email-masked]> 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