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?
Yes we do, because BEEP offers a number of services straight TCP lacks:
Multiplexing, various sorts of security services, and so on.
Did we even discuss that?
Yes we did.
Did we get some form of requirement from the WG defining
the XML protocol in the W3C?
Requirement no, but having just spoken with W3C people about this I can say
that they were interested in having a such a binding done and happy to have it
done in the IETF.
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?
It is axiomatic that a "potential requirement" cannot be addressed.
All I can tell you is that this wasn't a concern raised by the W3C.
What
is the relation with SOAP extensions to handle such forwarding, that are
currently debated in the W3C?
Any such extension would do well to consider the issues that arise from a wide
variety of transports.
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.
This is already taking place.
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.
I disagree, and think that the general issue of transporting BEEP, which
necessarily will encompass transports other than TCP/IP, is definitely
outside the scope of the IETF. This one piece is here because we're the
ones who know how to do it.
Ned