RE: ISSUE 8 : "Clarity and Safety"

+1

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
blog: http://webpages.charter.net/chrisfer/blog.html
phone: +1 508 377 9295



"David Orchard" <dorchard@bea.com> 
Sent by: public-ws-addressing-request@w3.org
11/22/2004 05:04 PM

To
"Marc Hadley" <Marc.Hadley@Sun.COM>, "Hugo Haas" <hugo@w3.org>
cc
Francisco Curbera/Watson/IBM@IBMUS, "Martin Gudgin" 
<mgudgin@microsoft.com>, <public-ws-addressing@w3.org>, "Glen Daniels" 
<gdaniels@sonicsoftware.com>
Subject
RE: ISSUE 8 : "Clarity and Safety"







Is your concern that an EPR recipient might decide to send a message
with some SOAP header that conflicts with the RefPs?  The scenario might
be: EPR contains an RM header block and the sender decides to use RM
which conflicts? 

The sender would only be able to use RM if the receiver wanted to allow
it right? 

The receiver will have defined their contract AND they will own the EPR
space.  Seems to me it's up the contract designer to ensure that their
EPRs don't conflict with their soap extensions, and the client doesn't
have to do anything.  The burden is on the EPR minter to manage their
interface. 

Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Marc Hadley
> Sent: Monday, November 22, 2004 11:05 AM
> To: Hugo Haas
> Cc: Francisco Curbera; Martin Gudgin; public-ws-addressing@w3.org;
Glen
> Daniels
> Subject: Re: ISSUE 8 : "Clarity and Safety"
> 
> 
> On Nov 22, 2004, at 1:07 PM, Hugo Haas wrote:
> >> The fact that some XML can be assumed to be opaque does not
preclude
> >> someone from making decisions based on aspects of that XML. People
> >> have
> >> posited that they might have reasons for not wanting to use certain
> >> reference property/parameter elements. If this is the case, then
they
> >> need to *not* treat the data as opaque and rather use whatever
> >> criteria
> >> they choose to deterimine whether the data does or does not fit
those
> >> criteria.
> >
> > I think that it's weird to define them as opaque and then, in the
> > yet-to-be-written security portion of our spec, advice people not to
> > treat those as opaque, especially as this XML could really be
> > anything.
> >
> Also as Paco said:
> 
> > 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).
> 
> So, in reality, the refps aren't opaque at all, you have to understand
> their semantics to see if they compose with the rest of the message
you
> intend to send.
> 
> Marc.
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
>

Received on Tuesday, 23 November 2004 00:06:50 UTC