Re: i59

Julian Reschke wrote:
> ...
>> An "IETF review" excludes informational or experimental RFCs in
>> the "independent" (RFC-editor) stream, and it also excludes all
>> other non-IETF streams.  Both proposals exclude W3C standards.
> 
> I think that comes close to that RFC2817 intended to say, so I would 
> propose to use that language for now. (If people feel that it should be 
> easier to register new status codes we should treat that as a separate 
> issue.)
> ...

OK,

here's a new proposed patch: 
<http://www3.tools.ietf.org/wg/httpbis/trac/attachment/ticket/59/i59.2.diff>.

As ab-diff:

Section 6., paragraph 0:
OLD:

  6.  Response Header Fields

NEW:

  5.1.  Status Code Registry

    The HTTP Status Code Registry defines the name space for the Status-
    Code token in the Status line of an HTTP response.

    Values to be added to this name space are subject to IETF review.
    Any document registering new status codes should be traceable through
    statuses of either 'Obsoletes' or 'Updates' to this document.

    The registry itself is maintained at
    <http://www.iana.org/assignments/http-status-codes>.

  6.  Response Header Fields

Section 11.1., paragraph 1:
OLD:

    The HTTP Status Code Registry located at
    <http://www.iana.org/assignments/http-status-codes> should be updated
    with the registrations below (see [RFC2817], Section 7.1).

NEW:

    The registration procedure for HTTP Status Codes -- previously
    defined in Section 7.1 of [RFC2817] -- is now defined by Section 5.1
    of this document.

    The HTTP Status Code Registry located at
    <http://www.iana.org/assignments/http-status-codes> should be updated
    with the registrations below:


Section 7., paragraph 5:
OLD:

    Clarify definition of POST.  (Section 8.5)

NEW:

    This document takes over the Status Code Registry, previously defined
    in Section 7.1 of [RFC2817].  (Section 5.1)

    Clarify definition of POST.  (Section 8.5)


BR, Julian

Received on Tuesday, 10 June 2008 14:02:58 UTC