+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@xxxxxxxxxxxxx> wrote:
>> -----Original Message-----
>> From: Ned Freed [mailto:ned.freed@xxxxxxxxxxx]
>> Sent: Thursday, May 03, 2012 2:54 PM
>> To: Murray S. Kucherawy
>> Cc: ietf@xxxxxxxx
>> 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