- From: Doug Davis <dug@us.ibm.com>
- Date: Fri, 20 Nov 2009 18:37:47 -0500
- To: Ram Jeyaraman <Ram.Jeyaraman@microsoft.com>
- Cc: "public-ws-resource-access@w3.org" <public-ws-resource-access@w3.org>
- Message-ID: <OF072ACAF5.414F5445-ON85257674.008055B5-85257674.0081CF6A@us.ibm.com>
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