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-03 17:07:37
-----Original Message-----
From: ietf-announce-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-announce-bounces(_at_)ietf(_dot_)org] 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
ietf(_at_)ietf(_dot_)org mailing lists by 2012-05-31. Exceptionally, 
comments may
be sent to iesg(_at_)ietf(_dot_)org 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?

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