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

Re: #247 and Registry policies

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 7 Mar 2012 15:06:46 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <13536752-E238-4DD4-882D-1336B8DD09C7@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>
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 GMT

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