ietf
[Top] [All Lists]

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

2012-05-04 14:02:50
+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"
<msk(_at_)cloudmark(_dot_)com> wrote:

-----Original Message-----
From: Ned Freed [mailto:ned(_dot_)freed(_at_)mrochek(_dot_)com]
Sent: Thursday, May 03, 2012 2:54 PM
To: Murray S. Kucherawy
Cc: ietf(_at_)ietf(_dot_)org
Subject: RE: Last Call:
<draft-levine-application-gzip-02.txt> (The application/zlib
and application/gzip media types) to Informational RFC

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.

[...]

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.

Good enough, just thought I'd ask.

I support publication as-is.

-MSK