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

i0016: Distinguishing RefProperty headers

From: Glen Daniels <gdaniels@sonicsoftware.com>
Date: Mon, 15 Nov 2004 14:32:51 -0500
Message-ID: <80A43FC052CE3949A327527DCD5D6B27A214CE@MAIL01.bedford.progress.com>
To: <public-ws-addressing@w3.org>


Marc Hadley asks "What is the relationship between SOAP headers that are
generated from ReferenceProperties and those that are from WSDL?".  I
would expand this (per some of the conversation I recall from the F2F)
to "what is the relationship between refp SOAP headers and SOAP headers
generated in any other way?".

As far as the message itself goes, I believe there is currently no
called-out relationship at all between the two - in other words, there
is no way for a receiver without out-of-band knowledge to distinguish
referencep's from any other headers that might have been inserted by
non-addressing portions of the message path/stack.

There are (at least) two ways to look at this - first, "this is a good
thing".  Making refp's into regular old headers allows them to be used
to trigger functionality that does not necessarily require deep
knowledge of WS-Addressing.  Second, that this is an issue for anyone
(intermediaries, WS-Addressing stacks built in certain ways, people
looking at wire traces) needing to distinguish the two.  This can
compound if refp's from a couple of different EPRs are in the same
message (as might occur in the case of intermediaries).

Do people feel like this is a problem, or is it in fact fine for
intermediaries and receiving SOAP nodes to require out-of-band knowledge
of which headers are refp's and which are not?

If indeed it is a problem, we could resolve it in a number of ways,

* (you've heard this one before) introduce some kind of container
element to clearly distinguish refp's from regular headers.  See issue
0008 and 0018.

* Put some kind of marker on the headers to indicate that they were
generated as refp's.

Received on Monday, 15 November 2004 19:32:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:21 UTC