Subject: RE: SOAP IANA considerations

From: "Larry Masinter" <[email-masked]>
Date: Thu, 6 Dec 2001 14:35:45 -0800

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.

The HTTP protocol specification RFC 2616 does create IANA
registries  (for content-coding and transfer-coding
value tokens) and makes reference to several others
(for charset, media type, and language tags). That there is
no registry for other protocol elements (headers and error codes)
is not an accident.

So I discourage you from trying to create a HTTP header
registry so that you could add "SOAPAction" to it.

Larry (as former HTTP WG chair)
-- 
http://larry.masinter.net

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Dec 2001 14:50:14 -0800

> to the HTTP protocol defined by the IETF.
[...]
> registry so that you could add "SOAPAction" to it.

That was the approach taken by the P3P WG. My motivation for asking
was that, at the time, there was no clear way to put a stake in the
ground and claim a header, from a W3C perspective. The default was to
use the HTTP extension framework.

We eventually got advice that it would probably be good enough to
publish an RFC, but it ate up a lot of time to get to that point. Of
course, we probably just didn't ask the right people. ;)

An index certainly would be a nice thing.

Thanks,

-- 
Mark Nottingham
http://www.mnot.net/

---

From: Jeffrey Mogul <[email-masked]>
Date: Thu, 06 Dec 2001 16:28:01 -0800

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Dec 2001 16:57:02 -0800

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,

-- 
Mark Nottingham
http://www.mnot.net/

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Fri, 7 Dec 2001 16:51:42 +0100

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:[email-masked]]
>Sent: Friday, 7 December 2001 1:28
>To: [email-masked]
>Cc: 'Mark Nottingham'; 'Graham Klyne'; 'Mark Baker'; [email-masked];
>[email-masked]; [email-masked]
>Subject: Re: SOAP IANA considerations
>
>

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 11 Dec 2001 11:29:01 -0800

After reading your message several times, I *think* you agree that
it would be a good idea to establish a registry, using the criterion
that "Values and their meaning must be documented in an RFC."

But you write:

    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.
    
My initial thought was that the requirement that the header name
be documented in an RFC was a high enough standard to meet; the IESG
has not been very generous about allowing Internet-Drafts to become
RFCs.  If a specification makes it to the RFC stage, then this
suggests it has had enough review to be "somewhat useful" rather
than "mostly useless."

I suppose that a case could be made that the requirement should
be stricter, e.g., "Values and their meaning must be documented in
*standards-track, historic, or informational* RFC".  That is, don't
let experimental RFCs add things to the registry.

I'm not sure about this, though.  We might be micro-managing.

-Jeff

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 12 Dec 2001 07:24:03 -0800

I think that the requirement is not merely that the header is
"useful" but that its interaction with the rest of HTTP has
been analyzed and documented. Lots of header extensions are
poorly considered and not interoperable as documented.

The original motivation -- to allow "SOAPAction" as a HTTP
header by putting it in a registry that would be established
by the XML protocol group -- is pretty suspect. They don't
need a "registry" to allow SOAPAction, they need to document
how SOAPAction is used, what it means, and how to implement
it interoperably. Is it end-to-end or hop-to-hop? Is it allowed
in trailers as well as headers? Is it only allowed with requests,
responses, only some methods or with all? How does it interact
with other parts of HTTP semantics?

So I think that "Values and their meaning must be documented
in a RFC" is not adequate for HTTP headers. "Values and their meaning
and interaction with the rest of HTTP must be reviewed in
a standards-track update or extension to HTTP".

Of course there are lots of headers and extensions that aren't
documented in standards-track RFCs, but then those headers and
extensions aren't standard.

Otherwise, you'll see "Safe:" and "Accept-Additions:" in the
header registry.

> Sent: Tuesday, December 11, 2001 11:29 AM
> To: Joris Dobbelsteen
> Cc: WWW WG (E-mail)

---

From: Mark Baker <[email-masked]>
Date: Wed, 12 Dec 2001 11:27:01 -0500 (EST)

I believe Mark is busy with other things right now, so I'll hazard
a response.

> with other parts of HTTP semantics?

Definitely.  IIRC, Mark's thinking was that we would do all that, *and*
establish a registry for others to use.  But I agree with the sentiment
here that we only really need an index, not a registry.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      [email-masked]
http://www.markbaker.ca   http://www.planetfred.com

---

From: "Joris Dobbelsteen" <[email-masked]>
Date: Thu, 13 Dec 2001 22:33:52 +0100

>From: Mark Baker [mailto:[email-masked]]
>Sent: Wednesday, 12 December 2001 17:27
>To: [email-masked]
>Cc: 'Jeffrey Mogul'; 'Joris Dobbelsteen'; [email-masked]

This points out that we should not use the word "useful", as it's exact
meaning is merely 'undescribed'.

What's the need of a registry is not to get conflicting headers and we want
to prevent headers that don't work well with the current HTTP standard, what
can be done more easily with RFCs.

>> it interoperably. Is it end-to-end or hop-to-hop? Is it allowed

If new headers are defined and they are hop-to-hop, do the current proxies
and gateways know about this? This is only in the case of extending
currently existing hop-to-hop headers (like connection header).

>here that we only really need an index, not a registry.

So setting up a registry must prevent 'poor headers' from appearing and
headers being used by more than once with different meanings. When using
RFCs, this is already ensured, but the two major complaints are that RFCs
take a long time to be published and we don't want a list of RFCs that just
handle HTTP extensions that are not meaningful to many applications (will
not be implemented in most products). Most companies don't take the time
needed to publish the RFC claiming there headers and giving a specification
of it.

So why a registry?
- Fast registration of headers
- No more (less?) conflicting headers (people register them)

But why RFCs?
- They will conform to the HTTP standard
- Others will know how it interacts with HTTP

I would like to (and will) end with note that using a registry doesn't mean
we should not require a description of the header any more, it can also mean
that we use the same procedure as RFCs, but that the 'registration time' is
dramatically shortened. This ensure 'good headers' to be registered.

Of course, already described headers cannot be overridden and must be kept.
Others should be prevented from registering headers with these names.

- Joris

---

From: Koen Holtman <[email-masked]>
Date: Sun, 16 Dec 2001 05:29:02 -0800 (PST)

OK, so we all want to promote interoperability, right?  But I am
seeing a lot of disagreement in this thread about what rules for a
HTTP header name registry would promote interoperability most.

As far as I am concerned it is crazy to try to use an IETF registry to
force some minimal level of documentation requirements on all HTTP
headers.  Implementing a new header is as simple as adding a line in a
CGI script, and many people who have the need and ability to implement
new headers will simply not care about getting formal IETF approval of
their documentation, if they intend to publish documentation at all.

It would be useful if somebody ran a service which helps everybody in
picking new header names that nobody else is using yet.  So in my
opinion, the only way to maximally promote interoperability here is to
have very low requirements for registration.  In principle the *only*
requirement for registering a header should be the honest intention to
start using this header in internet HTTP-type traffic.  Similar weak
requirements already apply to the vendor mime type registry and the
media feature tag registry.

Koen.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 16 Dec 2001 09:09:51 -0800

Hmm. I don't know if it's good/possible to maintain a registry of
*all* HTTP headers in use. The original intent was to assure
coordination between headers that were standardised (or Recommended,
etc.) by organisations like the IETF, W3C, OASIS, etc. to assure that
there are no collisions, and to clarify the process. Imposing the
requirement for these headers to be a reasonable fit into HTTP isn't
such a bad thing, IMHO.

Vendors, third parties, etc. would have three choices;
  1) meet the requirements by publishing an RFC
  2) use the HTTP Extension framework
  3) take their chances.

These are, of course, exactly the choices that they have today,
except that #1 isn't well-defined.

-- 
Mark Nottingham
http://www.mnot.net/

---

From: Jeffrey Mogul <[email-masked]>
Date: Tue, 18 Dec 2001 14:54:39 -0800

I don't think we are disagreeing in any unresolvable way.

Koen Holtman writes:

    OK, so we all want to promote interoperability, right?  But I am
    seeing a lot of disagreement in this thread about what rules for
    a HTTP header name registry would promote interoperability most.

That's a good point.  Promoting interoperability is certainly the
primary objective.  But I sense that a secondary objective (at least,
among some people) is a desire to provide differentiation between
"standard" and "non-standard" headers, since (as we saw in the
proliferation of HTML tags) the creation of new IDs is not without
potential negative consequences.  (Mostly lack of interoperability,
but sometimes more subtle than that.)

    As far as I am concerned it is crazy to try to use an IETF
    registry to force some minimal level of documentation
    requirements on all HTTP headers.  Implementing a new header is
    as simple as adding a line in a CGI script, and many people who
    have the need and ability to implement new headers will simply
    not care about getting formal IETF approval of their
    documentation, if they intend to publish documentation at all.

The value of having a registry that does require minimal
documentation is that (1) it encourages documentation, for people who
aren't entirely irresponsible, and (2) it allows us to define what
"interoperability" means with respect to a given header name.

Implementors who choose to add header names without going through
this process are thus (implicitly, at least) accepting the risk of
non-interoperability.  That is, they have only themselves to blame
if, later on, their software runs into interoperability bugs.

The catch here is that, if an implementor widely deploys a system
using a non-registered header, then this creates future problems for
standards-track extensions which inadvertently choose the same
header.  So, when Koen writes:

    It would be useful if somebody ran a service which helps
    everybody in picking new header names that nobody else is using
    yet.

I agree with him.

This suggests that the most effective approach (for maintaining
interoperability) is the creation of TWO lists.

    1. An IANA registry of "Standardized HTTP Headers" that only
    includes headers described in standards-track documents, or the
    equivalent.  (I would include "Best Current Practices" documents,
    since protocols such as HTTP/1.0 never entered the IETF Standards
    Track.)

    2. An IANA registry of "Known non-standardized HTTP Headers." The
    purpose of this list would simply be to publicize the use (or
    intended use) of header names, so as to avoid collisions.  As
    Koen wrote (my paraphrase), "to maximally promote
    interoperability [this index should] have very low requirements
    for registration.  In principle the *only* requirement for
    registering a header should be the honest intention to start
    using this header in internet HTTP-type traffic."  RFC2434
    explicitly allows this kind of FCFS registry.

I hope this two-pronged approach satisfies everyone, since we end up
with as much documentation as possible, without either unduly
burdening people trying experiments or application-specific
extensions, and without implying any approval of non-standards-track
extensions.

-Jeff