Subject: Status of IANA Considerations (registrations and registries) -- issues 40, 59, 72, 79

From: Julian Reschke <[email-masked]>
Date: Tue, 03 Jun 2008 18:31:47 +0200

Hi,

over the last weekend I spent some time working on IANA considerations. 
There are four related open issues, and some questions left...

A. Message headers: <http://www.tools.ietf.org/wg/httpbis/trac/ticket/40>

I have added those throughout, but I wonder...:

1) What's the standards status of Content-Disposition?

- it's defined in RFC2616, but it says: "Content-Disposition is not part 
of the HTTP standard, but since it is widely implemented, we are 
documenting its use and risks for implementors." (in the Security 
Considerations)

- the initial registry (RFC4229) says "standard" 
(<http://tools.ietf.org/html/rfc4229#section-2.1.22>)

- however the actual registry 
(<http://www.iana.org/assignments/message-headers/perm-headers.html>) 
doesn't mention a status

-> I'm tempted to leave it as defined in registry, so with no entry for 
the standard status

2) Should we include more information, such as whether the header 
accepts list syntax? Can we, without changing the registration procedure?

B. Status Codes: <http://www.tools.ietf.org/wg/httpbis/trac/ticket/40>

I have added instructions to update the status code registry in P2.

Question:

3) The current status code registration procedure is hiding in a really 
obscure place (<http://tools.ietf.org/html/rfc2817#section-7.1>), should 
Part 2 take over (me thinks yes). Should we keep the registration 
requirements (IETF standards track)?

C. Request Method registry: 
<http://www.tools.ietf.org/wg/httpbis/trac/ticket/72>

That registry currently doesn't exist, but I believe it should, and 
belongs into Part 2. So:

4) Should we add a registration procedure similar to the one used for 
status codes?

D. Media types: <http://www.tools.ietf.org/wg/httpbis/trac/ticket/97>

This seems to be just a reminder that the media types defined in P1 and 
P3 need to be mentioned in the IANA Considerations (TBD).

Feedback appreciated,

Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 4 Jun 2008 11:58:28 +0200

> 1) What's the standards status of Content-Disposition?

It's whatever you say in 2616bis :-)

> (<http://www.iana.org/assignments/message-headers/perm-headers.html>) 

Yeah, IANA didn't bother to "decompose" the documents with
the initial registries into proper registry entries, leaving
that task to the authors of updates.  2822upd does this for
many "4021" entries, RFC.ietf-usefor-usefor did it for many
"news" entries, and 2616bis will do this for "4229" entries
covered by 2616.

> -> I'm tempted to leave it as defined in registry, so with
> no entry for the standard status

That's cheating, and might not pass.  Just pick something
that fits, "standard" or "obsoleted" or "deprecated", same
idea as for the RFC.ietf-usefor-usefor entries.  From what
you wrote my vague impression is that "Content-Disposition"
in HTTP is a case like "Lines" for NNTP => "deprecated".

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Jun 2008 12:05:01 +0200

> in HTTP is a case like "Lines" for NNTP => "deprecated".

I don't think we can deprecate it. After all, it's in wide use, and 
widely implemented, and there's no replacement.

So, saying "informational" probably would make sense.

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 4 Jun 2008 13:55:16 +0200

> I don't think we can deprecate it. After all, it's in wide use,
> and widely implemented, and there's no replacement.

Then you could say "standard", IMO the purpose of the registry 
is (1) to avoid collisions and (2) offer pointers for folks
looking for the specification.   

> So, saying "informational" probably would make sense.

Reading it again, RFC 3864 from start to end tries to explain
why *redefining* MIME Content-* header fields in individual
protocols can be a seriously flawed idea.  And it says that
the "status" for a permanent entry is set according to the
primary document defining it.  

IMO for a standards track RFC the default should be "standard".
Obviously it can be "deprecated" when the standard(s) say so,
e.g., "Lines".  Maybe a standard can also say "informational",
but I think it's not the intention of RFC 3834:

Forwarding to the message header list, Graham would know what
RFC 3864 wanted, and if a minor twist is okay or confusing.

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Wed, 04 Jun 2008 14:00:27 +0200

Frank Ellermann wrote:
> ...
> ...

Thanks.

I just want to make sure that there is consistency; and RFC2616 
currently makes it clear that although it contains documentation about 
C-D, it's not to be considered part of the HTTP standard.

BR, Julian

---

From: J Ross Nicoll <[email-masked]>
Date: Thu, 05 Jun 2008 15:10:23 +0000

On 3 Jun 2008, at 17:31, Julian Reschke wrote:

> - it's defined in RFC2616, but it says: "Content-Disposition is not  
> part of the HTTP standard, but since it is widely implemented, we  
> are documenting its use and risks for implementors." (in the  
> Security Considerations)
>
> - the initial registry (RFC4229) says "standard" (<http://tools.ietf.org/html/rfc4229#section-2.1.22 
> >)
>
> - however the actual registry (<http://www.iana.org/assignments/message-headers/perm-headers.html 
> >) doesn't mention a status
>
> -> I'm tempted to leave it as defined in registry, so with no entry  
> for the standard status

Content-Disposition is defined in RFC 2183 ( http://www.ietf.org/rfc/rfc2183.txt 
  ), or am I missing something subtle?

The University of St Andrews is a charity registered in Scotland : No  
SC013532

---

From: Julian Reschke <[email-masked]>
Date: Fri, 06 Jun 2008 14:20:43 +0200

J Ross Nicoll wrote:
> ...
> Content-Disposition is defined in RFC 2183 ( 
> http://www.ietf.org/rfc/rfc2183.txt ), or am I missing something subtle?
 > ...

That's correct, but it's the definition for MIME, not for http.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 9 Jun 2008 23:08:28 +1000

On 04/06/2008, at 2:31 AM, Julian Reschke wrote:

> A. Message headers: <http://www.tools.ietf.org/wg/httpbis/trac/ticket/40 
> >
>

I vaguely remember struggling with this when we put the registry  
together. It doesn't fit well, but one can look at its use in HTTP as  
being defined in 2616 -- which is a standards-track document -- even  
if 2616 goes out of its way to say that C-D isn't part of the standard.

In actuality, though, this is an artefact of the use of Semantic Web  
technology to put together the registry. *shrug*

> accepts list syntax? Can we, without changing the registration  

This is what 'related information' is for.

> 3) The current status code registration procedure is hiding in a  
> really obscure place (<http://tools.ietf.org/html/ 
> rfc2817#section-7.1>), should Part 2 take over (me thinks yes).  
> Should we keep the registration requirements (IETF standards track)?

Yes and yes.

> C. Request Method registry: <http://www.tools.ietf.org/wg/httpbis/trac/ticket/72 
> >
>
> 4) Should we add a registration procedure similar to the one used  
> for status codes?

Yes.

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jun 2008 15:37:14 +0200

Mark Nottingham wrote:
>> part of the HTTP standard, but since it is widely implemented, we are 
> being defined in 2616 -- which is a standards-track document -- even if 
> 2616 goes out of its way to say that C-D isn't part of the standard.
> 

OK.

So for the headers defined by "us", we'd add that as "related 
information", but will not attempt any changes to the registration 
procedure...

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jun 2008 18:32:33 +0200

Mark Nottingham wrote:
>> really obscure place 
>> (<http://tools.ietf.org/html/rfc2817#section-7.1>), should Part 2 take 
>> over (me thinks yes). Should we keep the registration requirements 
>> (IETF standards track)?
> 
> Yes and yes.
>  ...

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

This copies RFC2817's reg. procedure into P2, Section 5 ("Status Code 
and Reason Phrase"), and updates the IANA Considerations and the Change 
Log accordingly.

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 9 Jun 2008 20:03:11 +0200

Julian Reschke wrote:
 
> and Reason Phrase"), and updates the IANA Considerations and the 
> Change Log accordingly.

RFC 2817 says "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".

I've problems with 2119 key words in IANA considerations.  What is a
good enough excuse to violate these SHOULDs, and how can IANA decide
that it really is good enough ?  

Why on earth does RFC 2817 talk about a specific IETF area ?  What is
"review in the form of a standards track document" supposed to mean ?
As *any* standards track document or BCP always has IETF review I try
to figure out what this says, does it try to rule out BCP ?  What is
wrong with say experimental IETF RFC registrations ?  

Let's try to translate the obsolete RFC 2234 language to new RFC 5226
terms, e.g., "IETF review" + "RFC required" *OR* "standards action".

Please post the new "IANA considerations" as text/plain when you have
them, I'm not sure what the XML diff in the tracker really means.

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Mon, 09 Jun 2008 20:09:44 +0200

> I've problems with 2119 key words in IANA considerations.  What is a

Actually, it's not in the IANA Considerations, but in the Registration 
Procedure.

But besides that, I agree with you on that :-)

> Why on earth does RFC 2817 talk about a specific IETF area ?  What is

Dunno.

> terms, e.g., "IETF review" + "RFC required" *OR* "standards action".

Please make a proposal.

> them, I'm not sure what the XML diff in the tracker really means.

The IANA Considerations did not really change much, what's new would be:

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 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 this document.

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

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 9 Jun 2008 22:18:30 +0200

Julian Reschke wrote:

>> Why on earth does RFC 2817 talk about a specific IETF area ?
> Dunno.

Then let's remove it, I don't want "updates 2026" in 2616bis :-)

>> e.g., "IETF review" + "RFC required" *OR* "standards action".
> Please make a proposal.

Those are two proposals, I try to explain the main differences:

A "standards action" means that an experimental RFC cannot add
new status codes to the status code registry.

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.

For obscure status codes of an IETF protocol excluding the W3C 
is no issue, but I'd worry if we try that also for say new HTTP
header fields:  Let's not update RFC 3864 unless we really must.

 Frank

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 9 Jun 2008 13:38:24 -0700

> other non-IETF streams.  Both proposals exclude W3C standards.

Some (most?) Informational documents do go for IETF Review.  But I  
agree it would exclude independent and other non-IETF streams.

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 9 Jun 2008 23:14:24 +0200

> Some (most?) Informational documents do go for IETF Review.

AFAIK the IESG can still approve a "document action" without prior
IETF Last Call (= IETF review) for informational and experimental
RFCs, that was a stunt openSPF proponents weren't aware of when it
happened with four controversial letters in RFC 4406 vs. RFC 4408.  

http://www.ietf.org/IESG/STATEMENTS/iesg-statement-01-15-2007.txt
is "for selected draft Informational and Experimental documents".

How about adding this to a "known traps and pitfalls" page in the
IESG wiki, my crystal ball says that there will be a case when an
IESG forgets to "select" an I-D running into a "gotcha" appeal ;-)

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Jun 2008 15:23:17 +0200

> Then let's remove it, I don't want "updates 2026" in 2616bis :-)

Yes. it doesn't make sense.

> new status codes to the status code registry.

The registry contains several status codes defined in Experimental RFCs 
(RFC2295 and RFC2774). Of course that doesn't tell us that the intent of 
the authors of RFC2817 was...

> 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.)

> header fields:  Let's not update RFC 3864 unless we really must.

No, there's (AFAIK) no intent to change the header registration.

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Jun 2008 16:02:14 +0200

> easier to register new status codes we should treat that as a separate 

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:

    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.

  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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 10 Jun 2008 17:09:54 +0200

>   5.1.  Status Code Registry
[...]
> Values to be added to this name space are subject to IETF review.

+1

> Any document registering new status codes should be traceable
> through statuses of either 'Obsoletes' or 'Updates' to this
> document.

Okay, I guess we can ignore the loophole of an "IETF review"
without a document or standards "action" (IOW without RFC),
that is IETF magic not covered in Brian's marauder's map. :-) 

 Frank

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2008 12:03:16 +0200

>> Values to be added to this name space are subject to IETF review.

OK, I have applied the patch (+ a reference to 
<http://tools.ietf.org/html/rfc5226#section-4.1>, pointing to the IANA 
policies) with <http://tools.ietf.org/wg/httpbis/trac/changeset/262>.

Note: the registration procedure (hopefully) is what the authors of 
RFC2817 had in mind. If we want to *change* it though, we should treat 
that as a separate issue.

BR, Julian

PS and reminder: I have diffs of the TXT versions at 
<http://greenbytes.de/tech/webdav/>, for instance in this case 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-latest-from-previous.diff.html>.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2008 15:46:41 +0200

>> 4) Should we add a registration procedure similar to the one used for 

Note: if we define a new registry we will also have to supply the 
initial content for the registry, which in turn means we need to 
reference all applicable RFCs defining new methods.

I don't have a problem with that, but thought I should mention it before 
adding references to RFC4918, RFC3253 etc..

The alternative would be to move the HTTP Method Name Registry into a 
separate document.

BR, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Jun 2008 23:48:10 +1000

I think a separate document to populate the registry is a good idea.

Cheers,

On 12/06/2008, at 11:46 PM, Julian Reschke wrote:

>>> That registry currently doesn't exist, but I believe it should,  
>>> and belongs into Part 2. So:
>>>
> I don't have a problem with that, but thought I should mention it  
> before adding references to RFC4918, RFC3253 etc..
>
> The alternative would be to move the HTTP Method Name Registry into  
> a separate document.
>
> BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 12 Jun 2008 15:53:38 +0200

OK,

so the current proposal would be to have:

- the method registry inside Part2, modeled similarly to the status code 
registry (-> IETF review required),

- the registration for methods defined in Part 2 inside Part 2 (IANA 
Considerations)

- an additional document, referencing Part 2, and making the 
registrations for all other methods

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jun 2008 15:28:27 +0200

> registry (-> IETF review required),

Done with <http://www3.tools.ietf.org/wg/httpbis/trac/changeset/270>, 
please review:

3.1.  Method Registry

    The HTTP Method Registry defines the name space for the Method token
    in the Request line of an HTTP request.

    Values to be added to this name space are subject to IETF review
    ([RFC5226], Section 4.1).  Any document registering new method names
    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-methods>.

> - the registration for methods defined in Part 2 inside Part 2 (IANA 

11.1.  Method Registry

    The registration procedure for HTTP Methods is defined by Section 3.1
    of this document.

    The HTTP Method Registry located at
    <http://www.iana.org/assignments/http-methods> should be populated
    with the registrations below:

    +---------+-------------+
    | Method  | Reference   |
    +---------+-------------+
    | CONNECT | Section 8.9 |
    | DELETE  | Section 8.7 |
    | GET     | Section 8.3 |
    | HEAD    | Section 8.4 |
    | OPTIONS | Section 8.2 |
    | POST    | Section 8.5 |
    | PUT     | Section 8.6 |
    | TRACE   | Section 8.8 |
    +---------+-------------+

> registrations for all other methods

I can work on that, but we probably should discuss whether this is 
supposed to become a WG work item.

Also, we may want to consider adding more information to the registry 
(safeness?), and possibly add text about the pros and cons of defining 
new methods.

BR, Julian

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 26 Jun 2008 09:47:49 -0700

If a separate document, doesn't it opens the possibility of collect methods
already defined in other standards-track documents like WebDAV... otherwise,
how would they get registered?

(Standards track leaving out HTCPCP BREW, I suppose.)

Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julian Reschke
Sent: Thursday, June 26, 2008 6:28 AM
To: Mark Nottingham
Cc: HTTP Working Group
Subject: Re: Issue 72, was: Status of IANA Considerations (registrations and
registries) -- issues 40, 59, 72, 79

3.1.  Method Registry

11.1.  Method Registry

BR, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 26 Jun 2008 19:04:33 +0200

> how would they get registered?

Yes, that was the plan. Sorry, may have been obvious to me being a 
former WebDAV guy ;-)

As a matter of fact I already have all that data collected, the question 
is where to put it.

> (Standards track leaving out HTCPCP BREW, I suppose.)

I considered that one as well :-)

BR, Julian

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 26 Jun 2008 21:12:43 +0200

Let's add RFC&rfc.number; in the "reference" column of all rows,
with an editorial note somewhere stating that RFC&rfc.number;
has to be fixed on publication - automatically, but after IANA
created the registry; some readers might not know how it works.

> possibly add text about the pros and cons of defining new
> methods.

IMHO obvious, getting deployment would require a miracle, but
it happens.

 Frank