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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> > -----Original Message-----
> > From: ietf-announce-bounces@xxxxxxxx [mailto:ietf-announce-bounces@xxxxxxxx] 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@xxxxxxxx mailing lists by 2012-05-31. Exceptionally, comments may
> > be sent to iesg@xxxxxxxx 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


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]