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

Re: #247 and Registry policies

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 06 Mar 2012 22:24:51 +0100
Message-ID: <4F5680A3.2090003@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>
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/
>
>
>
>
>
Received on Tuesday, 6 March 2012 21:25:22 GMT

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