Jeff,
The thread started here:
http://lists.w3.org/Archives/Public/xml-dist-app/2001Dec/0109.html
I've been meaning to do this for some time. If there's support, I'll
be glad to be the poor soul. I agree that it shouldn't be coupled
with SOAP's other registrations (as it appears to make people in that
WG equally nervous).
Larry, would you mind expanding upon this:
> That there is no registry for other protocol elements (headers and
> error codes) is not an accident.
Cheers,
On Thu, Dec 06, 2001 at 04:28:01PM -0800, Jeffrey Mogul wrote:
> 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
--
Mark Nottingham
http://www.mnot.net/