Re: Defining extensions for the "Expect" header

Julian wrote:

    RFC2817 is really interesting, it states:
    
    "7.1 HTTP 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.  The initial
	values for this name space are those specified by:
    
	1.  Draft Standard for HTTP/1.1 [1]
	2.  Web Distributed Authoring and Versioning [4] [defines 420-424]
	3.  WebDAV Advanced Collections [5] (Work in Progress) [defines 425]
	4.  Section 6 [defines 426]
    
	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 the Draft Standard for
	HTTP/1.1 [1]."
    
    Note,
    
    - RFC2518 [4] defined 422-424 and 507, but not 420 and 421 (and was 
    published before RFC2817) 
    (<http://greenbytes.de/tech/webdav/rfc2518.html#status.code.extensions.to.http11>)
    
    - The only document that actually *does* update RFC2616 is RFC2817 :-)
    
    The WebDAV WG is indeed working on a document that defines new status 
    codes 
    (<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-10.html#additional.status.codes>): 
    should it indeed say that it updates RFC2616?

My opinion (which, no doubt, some people will violently disagree
with) is that the SHOULD-level requirement in 7.1 of RFC2817
(requiring documents to "update" RFC2616) is nonsensical.
Aside from the minor problem that nobody seems to be following
it, the real problem is that HTTP was designed for extensibility;
that is, there are plenty of extension that build on RFC2616
rather than redefining it.

RFC2616 section 6.1.1 spells this out:

   HTTP status codes are extensible. HTTP applications are not required
   to understand the meaning of all registered status codes, though such
   understanding is obviously desirable. However, applications MUST
   understand the class of any status code, as indicated by the first
   digit, and treat any unrecognized response as being equivalent to the
   x00 status code of that class, with the exception that an
   unrecognized response MUST NOT be cached. For example, if an
   unrecognized status code of 431 is received by the client, it can
   safely assume that there was something wrong with its request and
   treat the response as if it had received a 400 status code. In such
   cases, user agents SHOULD present to the user the entity returned
   with the response, since that entity is likely to include human-
   readable information which will explain the unusual status.

I think it would lead to unnecessarily complex trees of
"updates/obsoletes" pointers if we tried to enforce an
RFC2817-like rule for all HTTP-related IANA registries.
    
    Speaking of which: is there a registry for HTTP method names (almost all 
      specs produced by the WebDAV WG define new method names...)?
    
I do not believe such a registry has ever been formally
proposed.  It might be a good idea.  As you're probably
aware, HTTP/1.1 didn't do a perfect job at extensibility
in this space, though ... there's a paragraph at the front of
section 9 that says:

   The set of common methods for HTTP/1.1 is defined below. Although
   this set can be expanded, additional methods cannot be assumed to
   share the same semantics for separately extended clients and servers.

which, in retrospect, seems to mean "we don't know how to
make method names extensible without revising this spec."
An IANA registry would be a good first start towards
"shared semantics for separately extended clients and servers"!

-Jeff

Received on Friday, 11 February 2005 20:15:42 UTC