RE: SOAP IANA considerations

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.

> -----Original Message-----
> From: Jeffrey Mogul [mailto:mogul@pa.dec.com] 
> Sent: Tuesday, December 11, 2001 11:29 AM
> To: Joris Dobbelsteen
> Cc: WWW WG (E-mail)
> Subject: Re: SOAP IANA considerations 
> 
> 
> 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
>

Received on Wednesday, 12 December 2001 15:26:54 UTC