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

Re: ISSUE 8 : "Clarity and Safety"

From: Marc Hadley <Marc.Hadley@Sun.COM>
Date: Mon, 22 Nov 2004 14:05:00 -0500
To: Hugo Haas <hugo@w3.org>
Cc: Francisco Curbera <curbera@us.ibm.com>, Martin Gudgin <mgudgin@microsoft.com>, public-ws-addressing@w3.org, Glen Daniels <gdaniels@sonicsoftware.com>
Message-id: <684C1D92-3CB9-11D9-B7E8-000A95BC8D92@Sun.COM>

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 Monday, 22 November 2004 19:05:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT