Re: Defining extensions for the "Expect" header

    RFC2616, section 3.20 
    (<http://greenbytes.de/tech/webdav/rfc2616.html#header.expect>) defines 
    the "Expect" header with extensibility in mind, but doesn't mention any 
    registration process.
    
    Is this an oversight? Who can legitimately define new extensions (did 
    this happen so far?)? I'd assume that an IETF standards track document 
    can do this (in the same way as it already occurs for method names and 
    request/response headers).
    
I believe it was an oversight.  It certainly wasn't the only
such oversight, as evidenced by subsequent efforts that were
required to create IANA registries for HTTP status codes (RFC2817)
and message headers (RFC 3864).

It certainly would be nice if someone could write up an
Internet-Draft for an "HTTP expectation code registration procedure".
>From our experience with RFC3864, I can't say that this will
be a simple process; the IESG is not currently noted for
its speed at blessing things.

Note that RFC2817, which defined the status code registry,
was titled "Upgrading to TLS Within HTTP/1.1".  I think it
is generally a mistake to define a generic registry within
the specification of a specific protocol ... maybe someone
thought it would be easier to get one RFC blessed than two,
but if the IESG doesn't like the specific protocol, then
the registry definition could be held hostage until they are
happy about the protocol.

Also, it's hard to remember which RFC defined the registry
if it's hidden under an unrelated title.  Case in point:
the IANA listing of Protocol Parameters:
	http://www.iana.org/numbers.html#H
currently says that the HTTP Status Code registry is defined
by RFC3293 ... which is entirely unrelated!  I suspect this
mistake would have been harder to make if the title of the
RFC were simply "HTTP Status Code registration procedure" :-)
(I'll inform IANA of this bug).

-Jeff

Received on Friday, 21 January 2005 19:38:19 UTC