RE: ISSUE 8 : "Clarity and Safety"

Just to add my 2c to Jonathan's point. The assumption seems to be that a
requester will decide arbitrarily to add SOAP headers to its message
regardless of what is the contract with the endpoint. If a requester
decides to add a new transaction context ignoring the fact there is already
one in use (received from someone else), then the interaction is probably
going to break because s/he broke the contract - as specified by the Tx
protocol in use. If s/he decides to add a header that the endpoint is
already requiring as a ref. property, the requester is breaking the
contract as well (unless the semantics of that header allows multiple
copies). That is how contracts work, the limit your ability to do whatever
you like; it is not in any way an exclusive feature of reference
properties.

Paco




                                                                                                                                               
                      "Jonathan Marsh"                                                                                                         
                      <jmarsh@microsoft.com>          To:       "Glen Daniels" <gdaniels@sonicsoftware.com>, <public-ws-addressing@w3.org>     
                      Sent by:                        cc:                                                                                      
                      public-ws-addressing-req        Subject:  RE: ISSUE 8 : "Clarity and Safety"                                             
                      uest@w3.org                                                                                                              
                                                                                                                                               
                                                                                                                                               
                      11/17/2004 03:39 PM                                                                                                      
                                                                                                                                               





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 Monday, 22 November 2004 17:53:50 UTC