- From: Rich Salz <rsalz@zolera.com>
- Date: Wed, 18 Jul 2001 20:14:09 -0400
- To: Mark Baker <distobj@acm.org>
- CC: xml-dist-app@w3.org
> But it isn't, it's a > protocol that extends application protocols. Some would disagree. I view the bindings more as a "tunneling" mechanism, a way of carrying new traffic in old bottles. > So when the work is done to bind it to an application protocol, the > semantics of that application protocol have to be reused. Buy the premise, buy the flick. I don't buy the premise. This is one of those elegant theories that fails in the real world. You cannot get identical semantics across different network layers. > HTTP has an existing semantic for specifying that an > unexpected error has occurred that prevents the response from being provided at this > time, the 500 response code. Except that the HTTP/1.1 RFC says "User agents SHOULD display an included entity to the user" (sec 10.5). Display to user doesn't match "deliver to soap engine." In particular, it allows for the entity to be dropped (it's a SHOULD not a MUST, so caches and proxies could drop and/or rewrite it, e.g) or otherwise modified. When SOAP has something to communicate to a SOAP peer, it should use the underlying protocol mechanisms to say "here is data for you." /r$ -- Zolera Systems, Securing web services (XML, SOAP, Signatures, Encryption) http://www.zolera.com
Received on Wednesday, 18 July 2001 20:13:06 UTC