RE: SOAP IANA considerations

>-----Original Message-----
>From: Mark Baker [mailto:distobj@acm.org]
>Sent: Wednesday, 12 December 2001 17:27
>To: LMM@acm.org
>Cc: 'Jeffrey Mogul'; 'Joris Dobbelsteen'; http-wg@hplb.hpl.hp.com
>Subject: Re: SOAP IANA considerations
>
>
>I believe Mark is busy with other things right now, so I'll hazard
>a response.
>
>> 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.

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.

>>
>> 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

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).

>> 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?
>
>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.

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

Received on Friday, 14 December 2001 12:25:55 UTC