- From: Henrik Frystyk Nielsen <frystyk@microsoft.com>
- Date: Wed, 7 Feb 2001 09:05:52 -0800
- To: "Mark Nottingham" <mnot@akamai.com>
- Cc: "XML Distributed Applications List" <xml-dist-app@w3.org>
>>> SOAP doesn't have a firm conception of a protocol binding or >>> the requirments placed upon it - HTTP is assumed. >> >> I am not sure what you mean by "assume" - the SOAP spec refers several >> places to text indicating that HTTP is not assumed. An example is >> section 1.3 where it refers to example 1 [1]: >[snip] > >I missed those the first time around. I'm still a bit uncomfortable >that SOAP doesn't place explicit requirements on future protocol >bindings, though. In fact it is interesting to see what these requirements are - the only one I can really think of is that the underlying protocol must be able to transfer a complete SOAP message from the SOAP sender to the SOAP receiver. >>> * R811 - "... must define and accommodate processing intermediaries." >>> >>> SOAP accommodates processing intermediaries, but does not >>> define them. See also R806 and R808. >> >> I believe it does talk about intermediaries in the sense that it defines >> them as being SOAP processors like any other SOAP processor and defines >> a processing model for all SOAP processors. Is this what you are >> referring to? > >I couldn't find a definition for something equivalent to 'processing >intermediary'. Yes but although it doesn't distinguish between processing intermediaries and processing ultimate recipients it does define a single processing model that fits both in that the actor model is part of the processing model for any SOAP processor. Is there anything that is special in that regard to a processing intermediary? Henrik
Received on Wednesday, 7 February 2001 12:06:24 UTC