- From: Mark Baker <distobj@acm.org>
- Date: Thu, 1 Aug 2002 15:18:42 -0400
- To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
- Cc: www-ws-arch@w3.org
On Thu, Aug 01, 2002 at 03:04:35PM -0400, Champion, Mike wrote: > > For sure, there's all sorts of new extensions we can > > identify, including many that people have been talking about > > all along; transactions, > > conversations, reliability, routing, etc... > > Dare I hope that you would find the SOAP 1.2 header extension mechanism a > Web-friendly means of communicating the state of transactions, > conversations, reliability, etc.? Mostly friendly, yes. 8-) The processing model is actually *more* Web friendly than HTTP! Just so you know I'm not anti-SOAP, just anti SOAP-as-its-used-today. > GET's are obviously going to be a bit of a problem, For example, how does > one communicate the security information that one might put in a SOAP header > on a GET operation? I guess the URI could encode the header, maybe hashing > or otherwise compressing things like namespace URIs that tend to be long > .... > > Thoughts? Exactly, GET is the big issue. URIs would be a very poor kludge, IMO. One less kludgy approach is to consider defining a similar HTTP header if a SOAP header can be used with GET. Or, if we want a more general solution, we could identify the need for an RFC 822 serialization of SOAP and an HTTP binding that would seemlessly merge SOAP headers into HTTP headers. This would also require the use of an HTTP extension like RFC 2774, and a mapping from SOAP features to 2774 features, e.g. namespaces, mU. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com
Received on Thursday, 1 August 2002 15:18:45 UTC