- From: Marc Hadley <Marc.Hadley@Sun.COM>
- Date: Mon, 22 Nov 2004 14:51:40 -0500
- To: Martin Gudgin <mgudgin@microsoft.com>
- Cc: Francisco Curbera <curbera@us.ibm.com>, public-ws-addressing@w3.org, Hugo Haas <hugo@w3.org>, Glen Daniels <gdaniels@sonicsoftware.com>
On Nov 22, 2004, at 2:24 PM, Martin Gudgin wrote: >>> 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 you'd better understand what the properties mean when they become headers so you don't inadvertently break your message by including additional headers that don't compose with the ones derived from the ref params. You can call that opaque if you like, but I don't think it would fit most peoples definition of that word. > 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. > Hey, its early days... Marc. --- Marc Hadley <marc.hadley at sun.com> Web Technologies and Standards, Sun Microsystems.
Received on Monday, 22 November 2004 19:51:46 UTC