The last thing that HTTP needs is yet another tag with which to
de-multiplex incoming traffic. Adding application-specific
request or response headers just increases the problems that
already exist due to a lack of clean layering in HTTP. So I'd
strongly recommend against defining any new SOAP-specific headers.
As for demultiplexing, my recommendation would be to do whatever
SOAP-specific demultiplexing either entirely within the URL of the
request, or entirely within the HTTP payload. (and SOAP should
choose one of these, not make it a per-service option). If the
latter is chosen, the separation between the SOAP payload and the
tag used for demultiplexing could be done either using XML framing
or with MIME multipart/something. This ensures the maximum
compatibility with existing servers, server-side APIs, proxies,
and client APIs. It also keeps HTTP servers from having to know
specifically whether a particular URI corresponds with a SOAP
request (in which case it might have to look at the SOAPAction header
in order to know how to handle it) or not (in which case the SOAPAction
header should be ignored).
The name of the SOAP service should *not* be inferred from the XML
namespace used to describe the request. This would make it impossible
to have multiple services that accept identically formatted requests.
Keith