... without wsa:Address profile, AbstractName is meaningless ...
Without the proper uniqueness guarantees for the wsa:Address, the use of ws-naming's AbstractName is meaningless. The EPR with an embedded AbstractName essentially describes a binding between the Address and the AbstractName. One could argue that this binding is a bit of a flaky assertion without any way to specify time-validity or issuer. As a result, one can not see from an EPR alone when it was issued or whether it is still valid or not. An EPR-minter can decide to create a new EPR for a resource and reuse an Address that was used for an other resource before. This would yield the undesirable situation that you would have two EPRs with identical Addresses and two different AbstractNames associated with different resources, and the client would have no way to see which one of the EPRs is valid... For example, if I have two EPRs with the same Address, where one EPR includes an AbstractName that identifies MyBankAccount and the other includes an AbstractName identifying YourBankAccount, then one of us will not be happy with that situation... In order to avoid this ambiguity, we need the guarantee from the EPR-minter that Address values will not be reused for different resources: for all times, the Address should either refer to that one and only resource, or it should be invalid (and it is allowed to change between those two states). Furthermore, the EPR-minters should ensure that globally unique Addresses are used for a resource such that different EPR-minters do not (accidentally) use the same Address for different resources. The described uniqueness properties of the Address constitutes a required EPR-minter profile for the use of AbstractNames. --- This has been reiterated in a number of emails, but i wanted to call it out separately to facilitate the discussion whether the observation holds water and if so, whether such a EPR-minter Address-profile should become part of the ws-naming spec. Again, I would especially welcome comments/reactions/acknowledgments from the ws-naming authors... Regards, Frank. PS. Note that everywhere I wrote "Address" above, it should probably be substituted by "Address+ReferenceParameters", but this simplification doesn't change the observation. -- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Frank Siebenlist wrote:
Without the proper uniqueness guarantees for the wsa:Address, the use of ws-naming's AbstractName is meaningless.
The EPR with an embedded AbstractName essentially describes a binding between the Address and the AbstractName. One could argue that this binding is a bit of a flaky assertion without any way to specify time-validity or issuer. As a result, one can not see from an EPR alone when it was issued or whether it is still valid or not.
An EPR-minter can decide to create a new EPR for a resource and reuse an Address that was used for an other resource before. This would yield the undesirable situation that you would have two EPRs with identical Addresses and two different AbstractNames associated with different resources, and the client would have no way to see which one of the EPRs is valid...
For example, if I have two EPRs with the same Address, where one EPR includes an AbstractName that identifies MyBankAccount and the other includes an AbstractName identifying YourBankAccount, then one of us will not be happy with that situation...
In order to avoid this ambiguity, we need the guarantee from the EPR-minter that Address values will not be reused for different resources: for all times, the Address should either refer to that one and only resource, or it should be invalid (and it is allowed to change between those two states). Furthermore, the EPR-minters should ensure that globally unique Addresses are used for a resource such that different EPR-minters do not (accidentally) use the same Address for different resources. The described uniqueness properties of the Address constitutes a required EPR-minter profile for the use of AbstractNames.
---
This has been reiterated in a number of emails, but i wanted to call it out separately to facilitate the discussion whether the observation holds water and if so, whether such a EPR-minter Address-profile should become part of the ws-naming spec.
One thing to remember is that WSDM defines every resource as having a ResourceId, and says that that ResID must be unique. So in the CDDLM deploy API we have -a resource ID that is used to uniquely identify a created System. -an operation on a portal that maps from a resource ID to an address The latter effectively allows multiple portals to manage the same cluster by giving you a more robust means to access things inside it. However, once you have an entity that can be accessed by >1 Address, you have to consider how WS Resource Lifetime interacts. Does the resource at address A have the same lifetime as address B: if I go A:<Destroy> does that destroy B too? And if the lease to B expires, does A go away too? Or do you have to model the thing at the end of every address not as the resource with which you are interacting with, but as a transient view of the resource, a view with its own lifetime. -steve
PS. Note that everywhere I wrote "Address" above, it should probably be substituted by "Address+ReferenceParameters", but this simplification doesn't change the observation.
that depends on how you implement WSRF. Mine only uses the address, and so should in theory interop better with other WS-A implementations. But I do use generated GUIDs in that address, as it is the best way to guarantee uniqueness.
Hi Frank, The Web Architecture (http://www.w3.org/TR/webarch/#identification) discusses and provides guidance on the issues you describe of IRI collision, IRI aliases etc. Does this document not address the issues of the profile work you are suggesting? When you advocate using the wsa:Address for the AbstractName are you saying that there is no need for adding the AbstractName element from WS-Naming into the EPR or are you saying that the wsa:Address (or some combination of the wsa:Address+wsa:ReferenceParameters) should be used in the AbstractName element. eg. <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/03/addressing" xmlns:name="http://ggf.org/name"> <wsa:Address>http://ggf.org/example/B944388</wsa:Address> <name:AbstractName>http://ggf.org/example/B944388</name:AbstractName> </wsa:EndpointReference> cheers Mark ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Mc Keown RSS Mark.McKeown@man.ac.uk Manchester Computing +44 161 275 0601 University of Manchester ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ On Thu, 10 Nov 2005, Frank Siebenlist wrote:
Without the proper uniqueness guarantees for the wsa:Address, the use of ws-naming's AbstractName is meaningless.
The EPR with an embedded AbstractName essentially describes a binding between the Address and the AbstractName. One could argue that this binding is a bit of a flaky assertion without any way to specify time-validity or issuer. As a result, one can not see from an EPR alone when it was issued or whether it is still valid or not.
An EPR-minter can decide to create a new EPR for a resource and reuse an Address that was used for an other resource before. This would yield the undesirable situation that you would have two EPRs with identical Addresses and two different AbstractNames associated with different resources, and the client would have no way to see which one of the EPRs is valid...
For example, if I have two EPRs with the same Address, where one EPR includes an AbstractName that identifies MyBankAccount and the other includes an AbstractName identifying YourBankAccount, then one of us will not be happy with that situation...
In order to avoid this ambiguity, we need the guarantee from the EPR-minter that Address values will not be reused for different resources: for all times, the Address should either refer to that one and only resource, or it should be invalid (and it is allowed to change between those two states). Furthermore, the EPR-minters should ensure that globally unique Addresses are used for a resource such that different EPR-minters do not (accidentally) use the same Address for different resources. The described uniqueness properties of the Address constitutes a required EPR-minter profile for the use of AbstractNames.
---
This has been reiterated in a number of emails, but i wanted to call it out separately to facilitate the discussion whether the observation holds water and if so, whether such a EPR-minter Address-profile should become part of the ws-naming spec.
Again, I would especially welcome comments/reactions/acknowledgments from the ws-naming authors...
Regards, Frank.
PS. Note that everywhere I wrote "Address" above, it should probably be substituted by "Address+ReferenceParameters", but this simplification doesn't change the observation.
-- Frank Siebenlist franks@mcs.anl.gov The Globus Alliance - Argonne National Laboratory
Mark McKeown wrote:
Hi Frank, The Web Architecture (http://www.w3.org/TR/webarch/#identification) discusses and provides guidance on the issues you describe of IRI collision, IRI aliases etc. Does this document not address the issues of the profile work you are suggesting?
When you advocate using the wsa:Address for the AbstractName are you saying that there is no need for adding the AbstractName element from WS-Naming into the EPR or are you saying that the wsa:Address (or some combination of the wsa:Address+wsa:ReferenceParameters) should be used in the AbstractName element.
eg. <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/03/addressing" xmlns:name="http://ggf.org/name"> <wsa:Address>http://ggf.org/example/B944388</wsa:Address> <name:AbstractName>http://ggf.org/example/B944388</name:AbstractName> </wsa:EndpointReference>
And if so, is everyone expected to (a) have read and understood section 3.2.3. on the subject of URI equivalence(below), or (b) to explicitly require case-sensitive-string-matching as the comparison. In the case above, are the following abstract names equivalent? <name:AbstractName>http://GGF.ORG/example/B944388</name:AbstractName> <name:AbstractName>http://GGF.ORG:80/example/B944388</name:AbstractName> <name:AbstractName>http://ggf.org:/example/B944388</name:AbstractName> <name:AbstractName>HTTP://ggf.org/%65xample/B944388</name:AbstractName> I ask, as for the test document for CDDLM, I need to define equivalence of things. And as EPR equivalence is so troublesome I am looking at WSDM ResourceIDs, but even there you have to specify what equivalence logic you will be using. -steve --------------------- RFC2616 on comparisons. Note that java.net does not implement this logic: 3.2.3 URI Comparison When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of "/". Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html
I'm concerned that by saying that we will start using the Address field for uniqueness and comparison reasons that that is going to place a MUCH heavier burden on the tooling, programers, and users then the abstract name does currently. All of my web services right now have URLs in the Address field because that's what the tooling supports and clearly the URL is not unique for all resource endpoints (I in fact have thousands of resource endpoints residing on my machine right now at exactly one URL). Using IRIs or URIs in the address field of the EPR is great on paper, but I don't know of any tooling that in fact supports that.
-----Original Message----- From: owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Steve Loughran Sent: Monday, November 14, 2005 12:16 PM Cc: ogsa-naming-wg@ggf.org; ogsa-wg@ggf.org Subject: Re: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profile, AbstractName is meaningless ...
Hi Frank, The Web Architecture (http://www.w3.org/TR/webarch/#identification) discusses and provides guidance on the issues you describe of IRI collision, IRI aliases etc. Does this document not address
Mark McKeown wrote: the issues
of the profile work you are suggesting?
When you advocate using the wsa:Address for the AbstractName are you saying that there is no need for adding the AbstractName element from WS-Naming into the EPR or are you saying that the wsa:Address (or some combination of the wsa:Address+wsa:ReferenceParameters) should be used in the AbstractName element.
eg. <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/03/addressing" xmlns:name="http://ggf.org/name"> <wsa:Address>http://ggf.org/example/B944388</wsa:Address>
<name:AbstractName>http://ggf.org/example/B944388</name:AbstractName>
</wsa:EndpointReference>
And if so, is everyone expected to (a) have read and understood section 3.2.3. on the subject of URI equivalence(below), or (b) to explicitly require case-sensitive-string-matching as the comparison.
In the case above, are the following abstract names equivalent?
<name:AbstractName>http://GGF.ORG/example/B944388</name:AbstractName> <name:AbstractName>http://GGF.ORG:80/example/B944388</name:Abs tractName> <name:AbstractName>http://ggf.org:/example/B944388</name:AbstractName> <name:AbstractName>HTTP://ggf.org/%65xample/B944388</name:Abst ractName>
I ask, as for the test document for CDDLM, I need to define equivalence of things. And as EPR equivalence is so troublesome I am looking at WSDM ResourceIDs, but even there you have to specify what equivalence logic you will be using.
-steve
--------------------- RFC2616 on comparisons. Note that java.net does not implement this logic:
3.2.3 URI Comparison
When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
- A port that is empty or not given is equivalent to the default port for that URI-reference;
- Comparisons of host names MUST be case-insensitive;
- Comparisons of scheme names MUST be case-insensitive;
- An empty abs_path is equivalent to an abs_path of "/".
Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
For example, the following three URIs are equivalent:
http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html
participants (4)
-
Frank Siebenlist -
Mark McKeown -
Mark Morgan -
Steve Loughran