- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 7 Mar 2012 15:06:46 +1100
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
I think that makes sense. On 07/03/2012, at 8:24 AM, Julian Reschke wrote: > So... > > +1 on making them all the same (except for header fields being defined elsewhere). > > This means we switch these three: > > > 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-upgradetokens.xml > > > > p3 > > * Content Codings - Specification Required > > http://www.iana.org/assignments/http-parameters/http-parameters.xml > > to IETF Review, which I believe makes a lot of sense for these anyway. > > I'm not convinced yet on the part about "reserved" and would like to get more feedback, or optimally guidance from the happiana activity. > > Proposal: just do the "make-them-consistent" part for now; will provide a proposed patch. > > Feedback appreciated, Julian > > > On 2012-03-05 05:17, Mark Nottingham wrote: >> Proposal: >> >> Make all of our registries IETF Review (except for headers, which are governed by RFC3864). >> >> Add a 'status' field to each registry, with the following possible values: >> >> Standard / Reserved / Obsolete >> >> ... with the notion that if there are commonly-used values that haven't gone through IETF Review, they can be written up in a quick I-D and registered as Reserved. >> >> Because the rate of change for all of these is pretty slow, excepting headers (which as per above aren't included), and the set of folks extending these is pretty limited, I think it's OK. The only thing that makes me a bit nervous is cache directives, but they still don't move that fast (and it seems like the most direct impact would be on myself ;). >> >> Thoughts? I'm open to alternative approaches, just want to keep things rolling. If we keep things as they are, we need to identify a bunch of expert reviewers and document procedures for them. >> >> Cheers, >> >> P.S. this is related to<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/247>. >> >> >> >> On 01/03/2012, at 5:05 PM, Mark Nottingham wrote: >> >>> 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/ >>> >>> >>> >>> >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> >> > -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 7 March 2012 04:07:11 UTC