W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: ISSUE 8 : "Clarity and Safety"

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Mon, 22 Nov 2004 19:06:43 -0500
To: "David Orchard" <dorchard@bea.com>
Cc: Francisco Curbera <curbera@us.ibm.com>, "Glen Daniels" <gdaniels@sonicsoftware.com>, "Hugo Haas" <hugo@w3.org>, "Marc Hadley" <Marc.Hadley@Sun.COM>, "Martin Gudgin" <mgudgin@microsoft.com>, public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OFA0E07A3D.42CC4619-ON85256F55.0000005E-85256F55.00009DB2@us.ibm.com>


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

"Marc Hadley" <Marc.Hadley@Sun.COM>, "Hugo Haas" <hugo@w3.org>
Francisco Curbera/Watson/IBM@IBMUS, "Martin Gudgin" 
<mgudgin@microsoft.com>, <public-ws-addressing@w3.org>, "Glen Daniels" 
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


> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> 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;
> 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
> >> 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
> >> 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
> >> 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
> > 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
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:07 UTC