Subject: IANA Registration Requirements for Status Codes and Method Names

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Jun 2009 12:26:12 +0200

Hi,

in Part 2 we currently state for both:

"Any document registering new method names should be traceable through 
statuses of either 'Obsoletes' or 'Updates' to this document."

I think we inherited that from RFC2817, Section 7.1. 
(<http://tools.ietf.org/html/rfc2817#section-7.1>)

IMHO this doesn't make sense; the "updates" relation shouldn't be used 
just because a specification uses a well-defined extension point that 
already has a registry.

Proposal: remove the requirement from sections 2.1 (method names) and 
4.1 (status codes).

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Jun 2009 21:13:39 +1000

+1, I think.

AFAIK there isn't any advice to do this for documents that establish  
registries (e.g., in RFC5226).

On 03/06/2009, at 8:26 PM, Julian Reschke wrote:

> "Any document registering new method names should be traceable  
> through statuses of either 'Obsoletes' or 'Updates' to this document."
>
> I think we inherited that from RFC2817, Section 7.1. (<http://tools.ietf.org/html/rfc2817#section-7.1 
> >)
>
> IMHO this doesn't make sense; the "updates" relation shouldn't be  
> used just because a specification uses a well-defined extension  
> point that already has a registry.
>
> Proposal: remove the requirement from sections 2.1 (method names)  
> and 4.1 (status codes).
>
> BR, Julian
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 03 Jun 2009 13:36:07 +0200

Mark Nottingham wrote:
> ...

Now issue 170 (<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/170>).

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 4 Jun 2009 11:41:05 +1000

Anyone object to dropping this language?

On 03/06/2009, at 9:36 PM, Julian Reschke wrote:

> Mark Nottingham wrote:
>> +1, I think.
>> AFAIK there isn't any advice to do this for documents that  
>> establish registries (e.g., in RFC5226).
>> ...
>

---

From: Julian Reschke <[email-masked]>
Date: Thu, 04 Jun 2009 17:14:41 +0200

> Anyone object to dropping this language?

Proposed patch: 
<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/170/170.diff>

BR, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 04 Jun 2009 16:17:15 +0100

> <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/170/170.diff> 

No objection from me :-).

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 5 Jun 2009 10:30:52 +1000

OK, let's call that accepted (realising that the IESG may tell us  
something different down the road).

Milestone set to 07, Julian.

On 05/06/2009, at 1:17 AM, Alexey Melnikov wrote:

>> Proposed patch: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/170/170.diff 
>> >
>

---

From: Julian Reschke <[email-masked]>
Date: Fri, 05 Jun 2009 08:57:47 +0200

> Milestone set to 07, Julian.

Change applied with 
<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/591>.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 08 Jun 2009 15:07:51 +0200

Hi,

related to <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/170>, I'd 
like to propose that we submit an erratum to RFC 2817, related to the 
HTTP Status Code registry, as soon as the HTTPbis drafts containing 
"our" resolution to issue 170 are published.

The proposed erratum is:

"""
Section 4., paragraph 1:
OLD:

     Values to be added to this name space SHOULD be subject to review in
     the form of a standards track document within the IETF Applications
     Area.  Any such document SHOULD be traceable through statuses of
     either 'Obsoletes' or 'Updates' to the Draft Standard for HTTP/1.1
     [1].

NEW:

     Values to be added to this name space are subject to IETF review
     ([12], Section 4.1).

(where [12] would refer to RFC 5226 in the References Section)

Notes:

Since RFC 2817 was published, it has become harder to publish non-WG 
documents on the Standards Track. The "IETF review" policy is defined in 
RFC 5226 as:

       IETF Review - (Formerly called "IETF Consensus" in
             [IANA-CONSIDERATIONS]) New values are assigned only through
             RFCs that have been shepherded through the IESG as AD-
             Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
             intention is that the document and proposed assignment will
             be reviewed by the IESG and appropriate IETF WGs (or
             experts, if suitable working groups no longer exist) to
             ensure that the proposed assignment will not negatively
             impact interoperability or otherwise extend IETF protocols
             in an inappropriate or damaging manner.

             To ensure adequate community review, such documents are
             shepherded through the IESG as AD-sponsored (or WG)
             documents with an IETF Last Call.

which should address this nicely.

Furthermore, overloading the "Updates" relation for specifications that 
use a well-defined extension point plus an IANA registry is misleading.

"""

Feedback appreciated,

Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Jun 2009 12:57:34 +1000

Looks good to me.

On 08/06/2009, at 11:07 PM, Julian Reschke wrote:

> Hi,
>
> related to <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/170>,  
> I'd like to propose that we submit an erratum to RFC 2817, related  
> to the HTTP Status Code registry, as soon as the HTTPbis drafts  
> containing "our" resolution to issue 170 are published.
>
> The proposed erratum is:
>
> """
> Section 4., paragraph 1:
> OLD:
>
> documents on the Standards Track. The "IETF review" policy is  
> defined in RFC 5226 as:
>
> Furthermore, overloading the "Updates" relation for specifications  
> that use a well-defined extension point plus an IANA registry is  
> misleading.
>
> """
>
> Feedback appreciated,
>
> Julian
>
>