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