Philippe (and others),

A few comments on this thread.

First, keep in mind that we had a set of use cases and requirements that
WS-Addressing alone did not satisfy. Thus, we used the WS-Addressing
extensibility elements.

Second, a "must" requirement for us was that our solution must not break
existing tooling, i.e., an EPR that used WS-Naming extensions must be usable
"as-is" by tools that do not understand the protocol. Given that 
most (all?) current tooling assumes the address field is an http - if you
put some other type of URI in the wsa:address field the tooling will choke
and die.

Third, let's be clear about semantics. Addresses and identities (names) are
two different things. An address tells you how to talk to some thing - not
what the thing is. A named (identified) thing may have many addresses over
time - or in fact many at any given time. This is classic distributed
systems - see all of the projects in the 80's and 90's, Sprite,
Eden/Emerald, Clouds, ..... and so on.  The wsa:address is just that - an
address - not an identifier. We wanted identifiers (abstract names, whatever
you want to call them.) 

Fourth, we wanted to be able to compare two EPR's. Given that the
WS-Addressing specification explicitly states that there is no way to
compare EPR's based on a canonical representation, we embedded meta data
that can be used by WS-Naming aware clients to see if two EPR's refer to the
same entity. Note that in section 2.3 of the WS-Addressing spec,
"This specification provides no concept of endpoint identity and therefore
does not provide any mechanism to determine equality or inequality of EPRs
and does not specify the consequences of their equality or inequality.
However, note that it is possible for other specifications to provide a
comparison function that is applicable within a limited scope." 

We need to determine if two EPR's refer to the same logical endpoint so that
a client can make reasonable decisions regarding caching, whether the "same"
entity was involved in an action, etc.


This is EXACTLY what we have done.

Similarly, also from section 2,
"Flexible and dynamic exchange of endpoint information in tightly coupled
environments where communicating parties share a set of common assumptions
about specific policies or protocols that are used during the interaction."

Fifth. Because one cannot assume that metadata is sent in SOAP headers EPR
minters may choose to duplicate EPI information elsewhere, e.g., in the
reference parameters - or in the wsa:address field itself. 


Note: there is no section 2.6 in 
http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ws-addr-core.pdf
which is the version of the specification that (a) comes up when I google
WS-Addressing, and (b) was current when we had our last round of discussions
on this.

Andrew