RE: SOAP IANA considerations

This is IMHO rather about the fear that we get a HTTP Header Registry with
numberous of useless headers, obstructing the creation of new useful
headers. Using RFCs or a registry provides some advantages and
disadvantages.

The use of RFCs means that headers are generated with a useful description
how they operate. It takes a lot of time for new headers to be documented,
but I think this might be worth the effort, but only in some cases.

On the other hand, creating a registry makes it possible to get a long list
of mostly useless headers, you don't know where to use them for. If you want
to set up a registry, ensure that you make some good RULES for adding
headers to the list. Make sure the list doesn't get poluted: all the useless
names.

A domain name registries (e.g. the .nl domain) runs out of name-space,
resulting in strange, stupid and funnie names. Even sentences without spaces
are registered.

Most companies just use there own headers for there products and I don't
think they conflict with others. A registry ensures this doesn't happen.
Some examples could be:

- header names are reviewed. They must be supplied with a name and
(generalized) description (of working). If agreed to the header, it's put on
the list.
- naming rules: add e.g. company or product name in the header

General purpose headers must be published in RFCs, so others can use them.
These don't follow the restrictions for the registry. I suppose you could
combine both, in order to benefit from the little time needed to register a
header on the registry and RFCs for general purpose headers, usable for
multiple applications. This combines both strengths, but requires a
registration policy...


- Joris


>-----Original Message-----
>From: Jeffrey Mogul [mailto:mogul@pa.dec.com]
>Sent: Friday, 7 December 2001 1:28
>To: LMM@acm.org
>Cc: 'Mark Nottingham'; 'Graham Klyne'; 'Mark Baker'; mogul@pa.dec.com;
>http-wg@hplb.hpl.hp.com; xml-dist-app@w3.org
>Subject: 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 Friday, 7 December 2001 15:54:26 UTC