- From: Mark Baker <mbaker@markbaker.ca>
- Date: Sat, 21 Jul 2001 01:58:27 -0400 (EDT)
- To: xml-dist-app@w3.org
All, It seems there's a large disconnect between the two different uses of SOAP-over-HTTP that I've discussed. Unless this disconnect is resolved by defining a binding that addresses both needs (*), I believe that the WG should seriously consider defining two HTTP bindings. I would not be happy about that, because I don't believe the typical developer would know enough to choose the right one in most cases. But I don't see an alternative. In the hopes that this can further help explain my position and the difference between the two uses of SOAP/HTTP, I've written down a high level view of what features I believe each binding should include; Tunnel binding; - Content-Type; (**) - TCP port; not 80 - URI scheme; doesn't matter - HTTP method; any that carries a body - HTTP response codes; doesn't matter - SOAPAction; (**) Application protocol semantics preserving binding (ack, that really needs a better name); - Content-Type; application/soap+xml - TCP port; 80 - URI scheme; HTTP - HTTP method; POST - HTTP response codes; whichever makes sense for the POST based transfer of each SOAP message; 200 for normal responses, 400 for mustUnderstand or other client faults, and 500 for version or server faults. - SOAPAction; unnecessary because of the SOAP-specific Content-Type (assuming the Content-Type includes a parameter that specifies the value of the SOAP 1.1 SOAPAction header). (*) As I previously stated, I believe that the binding for the non-tunnelling view of SOAP-on-an-application-protocol is the generic case and should be sufficient for both uses. (**) A tunnel binding only requires a single bit of SOAP-identifying information on an inbound message in order to unambigously identify to a receiving implementation that a tunnel needs to be established. This could be done with either the Content-Type or SOAPAction headers. However, if both bindings are defined (or at least if the tunnel binding is defined and doesn't want to preclude the definition of other bindings in the future), then the tunnel binding should include some tunnel- specific identifier; a Content-Type of application/soap-tunnel+xml, "SOAPActor: tunnel", or something else. MB
Received on Monday, 23 July 2001 04:54:18 UTC