W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Registry policies

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 1 Mar 2012 17:05:32 +1100
Message-Id: <E4D519F3-D93C-4276-9546-36CD9FDD3458@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
I've been reviewing the various registries we have in bis, and their associated policies (for reference: <http://tools.ietf.org/html/rfc5226#section-4.1>). 

Right now, we have:

p1
* Transfer-codings - Specification Required
   http://www.iana.org/assignments/http-parameters/http-parameters.xml

* Upgrade tokens - First Come First Served   
   http://www.iana.org/assignments/http-upgrade-tokens/http-upgrade-tokens.xml

p2
* Methods - IETF Review

* Status Codes - IETF Review
   http://www.iana.org/assignments/http-status-codes/http-status-codes.xml

* Headers - Specification Required

p3
* Content Codings - Specification Required
   http://www.iana.org/assignments/http-parameters/http-parameters.xml

p5
* Range Specifiers - IETF Review

p6
* Cache Directives - IETF Review

* Warn-codes - IETF Review

p7
* Authentication Schemes - IETF Review


A few thoughts:

I'm having a hard time believing that Cache Directives, Range Specifiers and Warn-codes should be IETF review. How do people feel about making them Specification Required?

Does FCFS really make sense for upgrade tokens? It seems like this should be Specification Required, at a minimum. Yes, I know that it's historically been FCFS, but we have the latitude to review registration policies.

Finally, all of the Specification Required registries (including any we decide to convert) imply use of an expert reviewer; we should make sure that we give reviewers advice.

Cheers,



--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 1 March 2012 06:06:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT