- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 1 Mar 2012 17:05:32 +1100
- 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 UTC