Subject: Re: Defining extensions for the "Expect" header

From: Julian Reschke <[email-masked]>
Date: Thu, 10 Feb 2005 23:58:02 +0100

Jeffrey Mogul wrote:
> ...
> 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.
> ...

Jeffrey, thanks for the feedback.

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?

Speaking of which: is there a registry for HTTP method names (almost all 
  specs produced by the WebDAV WG define new method names...)?

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: Jeffrey Mogul <[email-masked]>
Date: Fri, 11 Feb 2005 12:15:37 -0800

Julian wrote:

    

    
    Note,

    

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.

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