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

i0001: EPRs as identifiers - alternative proposal

From: Francisco Curbera <curbera@us.ibm.com>
Date: Wed, 1 Dec 2004 13:00:27 -0500
To: public-ws-addressing@w3.org
Message-ID: <OF129D3AFB.57179590-ON85256F5D.00554558-85256F5D.0062EADC@us.ibm.com>

Following up on my action Item from last week, here is my proposal for how
to deal with issue 1- and why.

Rationale
=======

EPRs are not identifiers, only addresses. Let me explain.

What is required from an identifier?
------------------------------------------

An identifier to be useful must allow meaningful comparison for identity or
"sameness". This requires them to overall unique and unambiguous, otherwise
no meaningful comparison is possible.  Moreover one could argue that to be
really useful identifiers should not be reused  once they've been made
invalid.

Are EPRs identifiers?
--------------------------

No, in view of the above and the use cases EPRs are intended to support.

First, multiple EPRs may be issued for accessing the same resource. This is
the case when multiple protocols are available to access a resource (note
that allowing multiprotocol EPRs does not imply that every EPR is
multiprotocol, so single protocol EPRs must be assumed to exist even in
multiprotocol environments). When considering long living stateful
resources this is particularly clear: resources may move and EPRs may
become stale and need to be refreshed while accessing the same stateful
resource. No meaningful comparison can be carried out in these cases.

Also, the spec clearly states the opaqueness principle: only the issuer
understands the actual runtime meaning of the EPR contents (stuff other
than metadata). This is so to allow the server the side to freely manage
those EPRs, generating aliases if required or virtualizing the meaning of
EPRs. This freedom is fundamental for effectively managing resources, but
is incompatible with the notion that the EPR identifies the resource.

Finally, looking at the information inside an EPRs and to the actual usage
of that information (as specified by the spec itself) it is clear that
there is not indication of identifier related operational semantics in the
spec: none of the two operations on EPRs that the spec recognizes
(comparison and serialization) are compatible with identifier semantics but
with those of addresses (more below). The language used in certain
paragraphs is another matter, and that is what I am proposing that we fix.

So what are EPRs then?
-----------------------------

EPRs are a particular form of an address, XML based and with specific
operational semantics attached to it. EPRs encapsulate in XML the
information that a message needs to carry so it can reach the destination.
It is associated with specific operational semantics that state how that
information needs to be used to ensure that a message is delivered to the
right address. I think everyone will agree that this is the core meaning of
an EPR.

Note that there are no equivalent semantics to explain how they can be used
as identities. The EPR comparison rules in Section 2.3 clearly disallow any
conclusion regarding the identity of the resource being addressed. In fact,
the only conclusion that it allows is completely consistent with the
address interpretation, since they exclusively refer to endpoint metadata,
i.e. what a requester needs to do to successfully send a message to the
endpoint.

Discussion
=========

>From the arguments above I conclude that the text in certain paragraphs of
the specification is inconsistent with its actual semantics. This is the
reason that has lead many people (and issue 1 as well) to mis-characterize
of EPRs as identifiers. This should be fixed by clarifying the text.

One remaining question is whether EPR (as addresses) should be URIs but I
think this should be opened as a separate issue. The question I guess is
whether we believe them to be "Web addresses". For me the answer is clearly
no, in the same way as other methods of addressing are not considered to be
necessarily Web addresses, for example the use of URLs with HTTP cookies.
This however, is a different debate (issue) that we should have once issue
1 is clarified with respect to the identity problem.


Proposed resolution
===============

Editorial changes to be introduced in the core specification to eliminate
any implication that EPRs identify resources. In particular replace
"identify" by "address" as appropriate in the following sections:

Abstract:
-----------
"to identify Web service endpoints and to secure end-to-end identification
of endpoints in messages." -> "to address Web service endpoints and to
secure end-to-end delivery of messages to endpoints."

Section 1:
------------
(2nd para): "Endpoint references convey the information needed to
identify/reference a Web service endpoint" -> "Endpoint references convey
the information needed to address messages to a Web service endpoint".

Section 2:
------------
 (2nd bullet): "Identification and description of specific service
instances that are created as the result of stateful interactions." ->
"Addressing and description of specific service instances that are created
as the result of stateful interactions."

Section 2.1:
--------------
[address] property (even the use of "identify" is ambiguous here) "An
address URI that identifies the endpoint. This may be a network address or
a logical address." -> "A network or a logical URI address for the
endpoint".
[ref. props]: "identify" -> "address", remove additional "identification".

Section 2.2:
--------------
/wsa:EndpointReference/wsa:Address: change accoding to Section 2.2.

Section 3:
-----------
"identification and location" -> "addressing"
[reply endpoint], [fault endpoint]: "endpoint reference that identifies the
intended receiver" -> "an endpoint reference for the intended receiver".
Received on Wednesday, 1 December 2004 18:01:04 GMT

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