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

Received on Tuesday, 9 November 2004 06:45:58 UTC