Re: ISSUE 8 : "Clarity and Safety"

+1 for the wsa:wrapper for the refPs

Glen Daniels wrote:

>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/2004Nov/0008.ht
>ml
>
>  
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Tuesday, 9 November 2004 15:37:14 UTC