Subject: Re: Final (?) procedural question.

From: Jeffrey Mogul <[email-masked]>
Date: Mon, 01 Dec 2003 11:30:47 -0800

Jim wrote:

> As I think I mentioned before, the IETF revised policies on us
> in RFC 2434, in the time between when we submitted the draft
> standard and its approval.  No one noticed this change at the time.
>
> In sections 3.5 and 3.6 of we define content and transfer coding
> values that require registration.
>
> RFC 2435 requires us to specify whether new values need to
> be reviewed, for what purpose and/or if they need approval.
> We are silent on the approval process.

It might also be a good idea to point out (in the revised version
of RFC2616) that there is a <soon-to-be?> BCP

	"Registration procedures for message header fields"
	Klyne, Nottingham, Mogul
	http://www.ietf.org/internet-drafts/draft-klyne-msghdr-registry-07.txt

According to the IETF ID Tracker, the IESG has approved an earlier
draft as a BCP (back in May) but there are some minor revisions
that require "AD followup".  I think it would be safe to add a
non-normative reference, given that this ID is far enough through
the IESG process that it should have an RFC number long before
the Full Standard for HTTP/1.1 could be an RFC.  (Yes, it might
be naive to trust the IESG process this much.)

I would suggest putting something in 4.2 (Message Headers)
along the lines of:

	All HTTP header field-names SHOULD be registered
	according to the procedure in [draft-klyne-msghdr-registry-07].

I believe that one of my co-authors on this I-D has already
prepared an initial list of field-names including fields from
all extant HTTP-related RFCs.

-Jeff

---

From: Jim Gettys <[email-masked]>
Date: Tue, 02 Dec 2003 11:03:46 -0500

Of course, I'm fighting with Word to generate the ascii....  Sigh...
Never again....

I note that if the reference is non-normative, we can't say SHOULD.
                              - Jim

-- 
Jim Gettys <[email-masked]>
HP Labs, Cambridge Research Laboratory

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 02 Dec 2003 10:34:17 -0800

You wrote:

    Unless there are complaints, I plan to revise [3.5] to say:
    
    "New content-coding value tokens SHOULD be registered; to allow
    interoperability between clients and servers, specifications of the
    content coding algorithms needed to implement a new value SHOULD be
    publicly available and adequate for independent implementation, and
    conform to the purpose of content coding defined in this section. New
    registrations are reviewed and approved by the IESG according to these
    criteria."

> all extant HTTP-related RFCs.

You wrote:

First of all, I'm not really sure if a reference to a BCP must
be non-normative.  What's the IETF rule about this?  I did a
quick skim of RFC2026 (especially section 5.1) but I couldn't
figure this out.  Note that RFC2026 is itself a BCP but people
seem to treat it as normative :-)

More important, if you look at the language you proposed for 3.5,
you have a normative (SHOULD) requirement for registration, but a
non-normative (passive-verb) statement about how this
registration will take place.  That seems odd -- requiring
registration but not requiring people to follow a specific
registration procedure? -- but perhaps this is the best we can
do.  If so, I'll change my suggestion for 4.2 to mirror your
language for 3.5:

	All HTTP header field-names SHOULD be registered; header
	field-names are registered according to the procedure in
	[draft-klyne-msghdr-registry-07].

Still, on the whole I would prefer to find a way to make both
of these statements "normative all the way down."

-Jeff

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 2 Dec 2003 13:43:54 -0500 (EST)

> Of course, I'm fighting with Word to generate the ascii....  Sigh...

If you can save it as XML using a recent version of Word (maybe
someone at MS can help there) and send it to me, I will convert
it to XML RFC form.

....Roy

---

From: Jim Gettys <[email-masked]>
Date: Tue, 02 Dec 2003 15:12:11 -0500

Certainly, I have no copy of word so recent.

Donations of XML greatly appreciated :-).

Anyone who can do so I'd be happy (relieved) to send the Word file
to...
                  - Jim