RE: ISSUE 8 : "Clarity and Safety"

 

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
> Sent: 22 November 2004 19:05
> 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.

No, in reality the reference properties are opaque. As a user of an EPR
you can choose to inspect them, and such inspection may or may not
provide information that is useful to you. But if you want to address
messages to the endpoint that the EPR refers to, you'd better put the
right address in the message or it's not going to get there. And that's
what EPRs are for; providing addresses which you then put into a
message.

FWIW, I've not yet encountered a collision between reference
properties/parameters and 'specified' SOAP headers in deployed systems.

Gudge

> 
> Marc.
> 
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
> 
>

Received on Monday, 22 November 2004 19:25:10 UTC