[ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profil e, AbstractName is meaningless ...

[Maguire_Tom at emc.com]

So we have had this discussion several times now.  I suggest that when the
WS-Addressing 1.0 WSDL Binding becomes a recommendation that the wsa:Address
will not be treated by the tooling as a URL.  Further the fact that current
tooling gets it wrong is not surprising given that there is no normative
profile for WS-Addressing.  While I understand the tooling issues I would be
extremely hesitant to base an architectural decision on vagaries of tooling.
Let me be very clear about this an EPR does not have a 1 to 1 correspondence
with a protocol and binding address.  It MUST be true that an EPR can
support multiple protocols and their associated addresses.  With that as a
base understanding is there any argument, other than URL tooling, that you
can articulate against using the wsa:Address IRI field as a unique resource
identifier?

Tom

-----Original Message-----
From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of Mark
Morgan
Sent: Tuesday, November 15, 2005 11:11 AM
To: 'Steve Loughran'
Cc: ogsa-naming-wg at ggf.org; ogsa-wg at ggf.org
Subject: RE: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address profile,
AbstractName is meaningless ...

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 at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf 
> Of Steve Loughran
> Sent: Monday, November 14, 2005 12:16 PM
> Cc: ogsa-naming-wg at ggf.org; ogsa-wg at ggf.org
> Subject: Re: [ogsa-wg] Re: [ogsa-naming-wg] ... without wsa:Address 
> profile, AbstractName is meaningless ...
> 
> 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: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
>