RE: ISSUE 8 : "Clarity and Safety"

Great description of problem. Issue of "other" headers overlapping
reference properties has been bothering us too :) On another hand this
weakness can be a strength in some cases.

One nice aspect of wrapper-less processing rules is that you can
instruct sender to provide headers for intermediary that knows nothing
about WS-Addressing. As a consequence you can to some degree compose use
of other specifications with WS-Addressing without adding spec-level
dependancy.


> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Glen Daniels
> Sent: Monday, November 08, 2004 10:46 PM
> To: public-ws-addressing@w3.org
> Subject: ISSUE 8 : "Clarity and Safety"
> 
> 
> 
> Here's a start at issue 8, and a clarification of some stuff 
> I wrote about issue 11.  Upon another read of [1], I think 
> that was a pretty good summary, actually.  However, I'll 
> endeavor to go a little further here.  I'll split these out 
> into separate emails for easier discussion.
> This one is about "Clarity and Safety".
> 
> Let's consider a refP as follows (namespace mappings are assumed in
> examples):
> 
>   <epr>
>    <refps>
>     <wsse:Security>
>       ...
>     </wsse:Security>
>    </refps>
>   </epr>
> 
> This would result in a static wsse:Security header appearing 
> in a message to this endpoint, as a result of following the 
> rules for refp's as they stand.  This header might be a) 
> wrong with respect to the rest of the message, or b) a 
> duplicate.  Another example:
> 
>   <epr>
>    <refps>
>     <admin:ShutDown/>
>    </refps>
>   </epr>
> 
> The thrust of thes particular cases involves an error (either 
> happenstance or malicious) on the part of someone supplying 
> an EPR, and of course we cannot protect against all such 
> situations.  However, the current design forces such errors 
> (bad refps) to happen at the SOAP infrastructure layer, as 
> opposed to inside the WSA module of an implementation.  This 
> has a few implications.
> 
> First, a layering problem - if I am to protect against such 
> errors, my infrastructure should probably scan all my refp's 
> to make sure they don't step on the toes of some "real" SOAP 
> extension.  One might argue that this isn't necessary, and 
> that you should just "trust the source of the EPR", but I 
> disagree - one could make the same argument against checking 
> for nulls/bad data in methods on a C# or Java object.  If you 
> provide a way for data (EPRs) that affects your SOAP 
> processor to be supplied by the outside world, you open 
> yourself up to errors in that data affecting your SOAP node 
> in potentially unclear ways - especially since refp's lose 
> their "refp-ness" once they get "header-ized". (this is the 
> "safety" part)
> 
> Second, if some node (either an intermediary who has no 
> knowledge of the EPR in question or maybe even the endpoint) 
> has a problem with one of these refps, it becomes harder to 
> debug what's going on when you account for the fact that any 
> of the headers might have been inserted due to processing an 
> EPR instead of due to actually following some extension's 
> contract.  In many (most?) modern SOAP processing systems, 
> there are going to be code modules which are responsible for 
> processing extensions.  In general each of these modules is 
> going to be directly responsible for a small subset of 
> headers.  Having a WSA module be required to insert an 
> arbitrary number of arbitrary headers may make it much less 
> clear where things are coming from, and which code to examine 
> when there is a problem. (this is the "clarity" part)
> 
> I would put forth that the SOAP processing model actually has 
> two sides to it.  The first is the one we're all familiar 
> with, i.e. what nodes must do when processing a message 
> containing headers.  The other side, though, is that the 
> *originator* of a given message actually inserted some SOAP 
> headers, and therefore by virtue of that fact, they agreed to 
> the semantics of those headers.  If WSA allows, or rather 
> forces, us to insert arbitrary headers which are explicitly 
> opaque, we change that part of the SOAP contract in what I 
> believe are at least confusing, and possibly dangerous, ways.
> 
> Proposal:
> 
> I would like to have the group consider the ramifications of 
> sending the refp's inside another element, whether that be 
> <wsa:To> or a separate <wsa:RefPs> header.  In either case, 
> the same exact information would be available to the SOAP 
> node (I am intentionally not saying "the application" to 
> avoid implementation-specific layering assumptions) as in the 
> case where each refp was a separate header, except there 
> would be a well defined semantic that <wsa:RefPs> (or 
> whatever name) contains a bag of data that is meant to go 
> along with each message sent to this endpoint.  This would 
> solve the problems I mention above (and others - see other 
> threads), and as far as I can tell would not lose us anything.
> 
> Thanks,
> --Glen
> 
> [1]
> http://lists.w3.org/Archives/Public/public-ws-addressing/2004N
> ov/0008.ht
> ml


------------------------------------------------------------------------------
This e-mail message is for the sole use of the intended recipient(s) and contains confidential and/or privileged information belonging to Siebel Systems, Inc. or its customers or partners.  Any unauthorized review, use, copying, disclosure or distribution of this message is strictly prohibited.  If you are not an intended recipient of this message, please contact the sender by reply e-mail and destroy all soft and hard copies of the message and any attachments.  Thank you for your cooperation.
====================================================

Received on Wednesday, 10 November 2004 01:18:20 UTC