- From: Mark Baker <distobj@acm.org>
- Date: Fri, 08 Jun 2001 11:27:34 -0400
- To: dkgunter@lbl.gov
- CC: xml-dist-app@w3.org
Dan, Dan Gunter wrote: > From what I understand, SOAP is _not_ an extension of HTTP, instead > it is a protocol with an HTTP binding. I really hope that other > bindings remain possible. It is both. The binding is an *extension* binding, not a layered binding. More below. If it were not for mustUnderstand, actor, and SOAP versioning (with which to reason about compatibility changes with the previous two features), SOAP would simply be a XML based syntactical framework for extending HTTP (and other application protocols). What would normally be done with a new HTTP header could be done with a SOAP header. mustUnderstand, actor, and SOAP versioning are what make SOAP a protocol and not *just* a new extension syntax (obviously it's also that). They are also generic features that apply to other application protocols (specifically transfer protocols). In order for protocol A to be a layer on top of protocol B, the interface to developers (i.e. a library) should expose only protocol A semantics. With using SOAP over HTTP, you as a developer are using HTTP semantics (specifically POST). They are exposed to you. Contrast this with HTTP over TCP - do you as an HTTP developer know or care when an IP packet arrives out of order? You don't, because HTTP *is* a layer on top of TCP. SOAP is not a layer on top of HTTP. > Pushing SOAP status information up into HTTP seems to me like a hack > that's going to cause no end of headaches for other bindings (what > happens when an intermediary needs to translate from HTTP<->UDP? does > it have to parse all the messages going back HTTP-side so it can stick > in the right error code? ugh..). Also, it complicates the spec. HTTP<->UDP? I'm not sure what that means. Those are different layers in the stack. > I like the XML-RPC take on the issue: "Unless there's a lower-level > error, always return 200 OK.". It's simple, for sure. But it doesn't let existing web applications or intermediaries know what's going on, and that's a bad thing. Luckily, it is a requirement of the XML Protocol working group that XMLP not interfere with the proper operation of "transport" (meaning "transfer") intermediaries; http://www.w3.org/TR/2000/WD-xp-reqs-20001219/#N1137 MB
Received on Friday, 8 June 2001 11:28:03 UTC