On Mon, Jun 2, 2008 at 9:41 PM, Mike Edwards < [EMAIL PROTECTED]> wrote:
> Simon Laws wrote: > >> >> Should we really be restricting the behavior of the service side SOAP >> stack? >> If your intent is to support 1_2 does that mean we outlaw 1_1 if the SOAP >> stack happens to be able to make sense of it? >> >> Simon >> >> Simon, > > This all depends on what you think is meant when the intent "SOAP.1_2" is > applied to either a service or to a reference. > > The way it was designed is that it says "This service/reference must use > SOAP encoding at the 1.2 level of the spec". > > It does not mean "Use SOAP.1_2 if you can but SOAP.1_1 will do as well". > > So strictly, the current Tuscany implementation is in error. It will use > SOAP 1.1 encoding even when it has been told to use 1.2. > > Take an example (not a good one for SCA, it must be admitted) where the > server messes with SOAP Headers only defined in SOAP 1.2. It would > naturally mark itself as requiring "SOAP.1_2". If SOAP 1.1 were used > instead, those extra headers would not be legal SOAP 1.1. > > If you want to require SOAP encoding but you don't care about the level, > just specify "SOAP" as the intent - this permits any level of SOAP encoding. > > > Yours, Mike. > Hi Mike Sticking a pin in the specs it does say what you are saying. I was thinking "must support" as opposed to "must use" on the service side. Within an SCA domain in Tuscany I believe that the binding matching code will fail to match soap.1_1 and soap.1_2 intents. Crossing the domain boundary what would be the intended action if a soap 1.1 message arrived at a service that is marked as soap 1.2. A response indicating that the message is not understood? Simon
