Re: SOAP IANA considerations

    I don't think that a "registry" of HTTP headers is appropriate,
    Rather, additional HTTP headers should be documented in IETF
    standards-track documents, if they are to be considered extensions
    to the HTTP protocol defined by the IETF.
    
    It is useful to have an index of headers for implementers
    to know where various headers are defined (as, say, an update
    to RFC 2076), but such an index is not a registry.
    
I'm confused.  First of all, about where the original message in this
thread appeared (apparently not on HTTP-WG, but then I don't know how
to find the original message).

More particularly: I don't understand the conflict between the desire
(on the part of at least one of you, apparently) to have an IANA "HTTP
Headers Registry", and Larry's desire to see HTTP headers documented in
IETF standards-track documents.

As far as I can tell from reading RFC 2434, there is no conflict; the
document that creates an IANA registry normally specifies some sort
of review mechanism, and one "suggested" wording is:

      Specification Required - Values and their meaning must be
      documented in an RFC or other permanent and readily available
      reference, in sufficient detail so that interoperability
      between independent implementations is possible.

I agree that it would be Darned Good Idea to have an HTTP Headers
Registry administered by IANA, because otherwise I suspect we will
end up with a chaotic situation as more RFCs generate more header
names.

So I think it would be appropriate to create an "IANA Considerations"
section (logically part of the HTTP specification, but presumably in
a separate document) that says something like:

    IANA Considerations

    The Internet Assigned Numbers Authority (IANA) administers the
    name space for HTTP header field-name values.  Values and their
    meaning must be documented in an RFC, in sufficient detail
    so that interoperability between independent implementations is
    possible.  Subject to these constraints, name assignments are
    First Come, First Served (see RFC2434).

    This registry initially consists of those header field-name
    values specified in RFC 2616, RFC 2617, [other RFCs TBD].

    Future RFCs that add values to this registry MUST provide an
    explicit list of such values in an "IANA Considerations" section,
    for the convenience of IANA in maintaining the registry.

The list of "other RFCs" could be potentially fairly large, since
there are a bunch of Experimental, Informational, or Proposed
Standard RFCs listed on the HTTP-WG home page (in addition to the
small set of Draft Standard RFCs).

And, I suppose, some poor soul(s) would have to volunteer to help
IANA glean the list of header names from all of these RFCs.  But we
might as well start now, rather than later.

One more thing: I infer from the Subject line of this thread of
messages that the intent is to create this registry as a section of
the SOAP document.  This is insane; it couples progress on
establishing the registry to the progress of a much more complex
technical design, and it hides the registry specification behind a
title that most people would never suspect.  (OK, how many people
could guess the name of the RFC that defines the HTTP Status Code
Registry, and no fair peeking at www.iana.org to find the
back-pointer?)

I'd suggest that we create a separate document called

	IANA Header Field-name Registry for HTTP

that contains just the text above (and other necessary boilerplate)
and be done with it.

-Jeff

Received on Thursday, 6 December 2001 19:28:38 UTC