- From: Jeffrey Mogul <Jeff.Mogul@hp.com>
- Date: Fri, 21 Jan 2005 11:38:11 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: ietf-http-wg@w3.org
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