![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> 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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.