Re: Final (?) procedural question.

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."
    
I wrote:

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

You wrote:

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

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

Received on Tuesday, 2 December 2003 13:34:19 UTC