SOAP is going to see widespread use no matter what. The other
application
transport for SOAP is HTTP. Use of HTTP for things it isn't well
suited for is
something we want to discourage. So doing this correctly is of
considerable
concern to the application layer.
It is true that HTTP is the only transport defined in the SOAP
specification, but SOAP can be mapped to a variety of transports,
including direct mapping over TCP or UDP. Do we really believe that
carrying SOAP over BEEP is better than carrying it over TCP? Did we even
discuss that? Did we get some form of requirement from the WG defining
the XML protocol in the W3C? How can we define a mapping to BEEP
channels without even considering the potential requirements for
multi-step forwarding of SOAP messages across various transports? What
is the relation with SOAP extensions to handle such forwarding, that are
currently debated in the W3C?
I don't think it is a good idea for the IETF to issue a proposed
standard on how to transport SOAP over the Internet without first having
an organized discussion of what the transport should be, and without a
well defined cooperation with the W3C -- unless indeed our intent is to
maximize confusion. An individual draft such as draft-etal-beep-soap-04
should not be published as an RFC, let alone a proposed standard,
without first chartering a working group on the general issue of
transporting SOAP.
-- Christian Huitema