RE: ISSUE 8 : "Clarity and Safety"

Glen wrote:
> 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)

I don't understand this.  You want to protect against getting an error,
presumably by generating a pre-emptive error.  The benefits of the
pre-emptive error aren't clear.  In my mind there are two cases, where
you have established trust in the EPR, and where you haven't.

It would be very helpful if you could be clearer about the (autological)
"potentially unclear" ways that a _trusted_ EPR can screw with your SOAP
node.  The only thing I can think of is that there might be namespace
clashes which might be a general problem with SOAP headers (e.g. I
insert my:header to mean one thing and you insert my:header to mean
something else, though presumably only one of us has authority to use
the namespace bound to 'my'.)

I don't believe anyone is forced to use an EPR that they receive if they
can't establish trust.  If you want to implement some process for
validating your EPRs using a NetNanny-type filter or heuristics such as
you outline above, that's outside the scope of the spec and therefore
perfectly fine.  WS-A only talks about what the endpoint expects you to
do once you decide to use the EPR to construct and send a message.

Received on Wednesday, 17 November 2004 20:42:17 UTC