RE: new proposal for 7911

Yves will need to speak-up here but trying to channel him for a 
moment....the concern, as I understand it, is about situations where an 
implementation examines the soap envelope more than once and chooses a 
different algorithm each time it tries to determine the operation being 
invoked.  For example, at one point (say a firewall component) looks just 
at the wsa:Action and another component (say the dispatcher) examines the 
QName in the Body.  If its not consistent in its algorithms then it could 
lead to unexpected results - for example, an inconsistency between how 
these two component authorize the requests.

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog.



Ram Jeyaraman <Ram.Jeyaraman@microsoft.com> 
Sent by: public-ws-resource-access-request@w3.org
11/20/2009 06:18 PM

To
Doug Davis/Raleigh/IBM@IBMUS
cc
"public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
Subject
RE: new proposal for 7911






Hi Doug,
 
Ø  The Basic Profile defines an operation signature as a comination of the
[Action] 
property and the QName of the [Body] child.  An implementation that 
examines 
just one of those values, but at multiple points during the entire 
processing 
of the message, are advised to ensure that the values that are used each 
time 
are consistent.
 
Some implementations examine just the wsa:Action, some use the body 
wrapper, some use a combination of both (like Basic Profile does), and 
some others use various other techniques. Given the wide variance in how 
the messages are processed, there is no need to go into specific 
mechanisms used by implementations, since it is implementation detail. 
 
On the other hand, as long as a message conforms to the XML outline of an 
operation as defined by the specification, it should be possible for any 
implementation to further process the message. Hence, I suggest that we 
clarify [1] the receiver behavior in the case when a message does not 
conform to the XML outline of the operation it is targeted at. That 
should, in my opinion, address the concern surrounding the receiver 
behavior.
 
Do you think [1] would work?
 
Thanks.
 
[1]
 
A receiving SOAP Node is encouraged to generate a SOAP 1.1 Client or SOAP 
1.2 Sender fault, if a SOAP message targeted at an operation defined by 
this specification does not conform to the XML outline and description of 
the operation. 
 
From: public-ws-resource-access-request@w3.org 
[mailto:public-ws-resource-access-request@w3.org] On Behalf Of Doug Davis
Sent: Tuesday, November 17, 2009 12:02 PM
To: public-ws-resource-access@w3.org
Subject: new proposal for 7911
 

forwarding... 

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug@us.ibm.com
The more I'm around some people, the more I like my dog. 
----- Forwarded by Doug Davis/Raleigh/IBM on 11/17/2009 03:02 PM ----- 

bugzilla@wiggum.w3.org 
Sent by: public-ws-resource-access-notifications-request@w3.org 
11/17/2009 03:00 PM 


To
public-ws-resource-access-notifications@w3.org 
cc

Subject
[Bug 7911] mismatching action and body wrapper
 








http://www.w3.org/Bugs/Public/show_bug.cgi?id=7911





--- Comment #8 from Doug Davis <dug@us.ibm.com>  2009-11-17 20:00:51 ---
A new version of the text - making it a bit more generic:

The Basic Profile defines an operation signature as a comination of the
[Action] 
property and the QName of the [Body] child.  An implementation that 
examines 
just one of those values, but at multiple points during the entire 
processing 
of the message, are advised to ensure that the values that are used each 
time 
are consistent. 


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 20 November 2009 23:38:24 UTC