latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)

[Frank Siebenlist]

Hi Andrew,

I'd like to suggest the following changes/additions to your current 
ws-naming spec:

* add use cases about how names/identifiers will be used, specifically 
use cases that show that "names" are also used in policy and audit 
besides EPR-resolution.

* include a profile for the use of the Address and ReferenceParameters 
that ensure the proper uniqueness property in time and space of the 
reference. Tom Maguire suggested to use the wsdl binding of the address 
which sounded very promising.

* include a recipe for generation of a single IRI from the Address and 
ReferenceParameters that can function as an identifier of the resource. 
Mark Mc Keown pointed at the W3C Web Architecture description of the use 
of URIs which we could borrow from.

* provide some examples/best-practices of how to ensure the uniqueness 
of the Address. Personally, I liked the suggestion of adding a UUID into 
the Address value, which would make it easier to ensure the global 
uniqueness than to rely solely on the ip-names plus some serial number 
or such (not sure who suggested this...)

* remove and do not use the "WS-Name" definition as it has no more 
special meaning when the Address can also be viewed as an "abstract-name"

* use a different portType/Interface for the resolve and 
resolve-abstract-name, as the first one refers to a service and the 
latter to an implied resource

* change the portType name to indicate that this is a resolution to 
EPRs, like EprResolverInterface and EprRenewableReference, because there 
are many possible resolutions/resolvers and the porttype-name "Name" 
doesn't tell you much

* the IRI passed to the "resolve-abstract-name" should not be specific 
to an "AbstractName", but should be defined for generic "IRI-to-EPR" 
resolution. The IRI might alternatively be derived from the 
Address+RefParameters, or may have been communicated through many 
different ways that are different from EPR embedding.

* remove the optional parameter "epr-hint" for the renewable reference 
because its use and associated semantics is very confusing and doesn't 
add functionality.
If the resolver can make use of additional information in the original 
EPR, then the renewable reference minter can add that to the RR-EPR's 
Address and/or ReferenceParameters. In other words, there is no point in 
putting the burden on the client to "guess" whether it makes sense to 
communicate the original EPR or not, because the minter can do it much 
better. Furthermore, the burden is still on the client to verify whether 
the reply is a new EPR or not.

* need for additional error/fault messages, which should be discussed in 
the text and properly defined. Right now, the schema only includes one 
undefined element "UnknownResourceFault". You probably would like to 
distinguish "NoNewEprAvailable", "NoEprAvailable", 
"UnknownAbstractName", which may or may not be returned depending on policy.

* explain why we cannot reuse WSDM ResourceID for the AbstractName 
element. Steve Loughran mentioned that recently, while other have asked 
the same in the past.

* ???

---

Personally, I would actually prefer to have three different specs for:

* the unique Address+RefParameter profile and recipe
* AbstractName definition
* EprResolver Service and RenewableReference

All these specs would be useful by itself: the first spec shows when we 
can use the Address+RefParams as an identifier/name, which could be used 
for policy/audit and EPR-resolution. The second one relies on the first 
and gives you the ability to define a more stable name and bind it 
through EPR-embedding - again useful for policy/audit/resolution. 
Finally, the last one specifies services and interface for 
EPR-resolution through two standard patterns.

---

Lastly, I would truly like to add policy/audit/resolution functionality 
to our Globus Toolkit based on the notions of identifiers/names and 
resolver services that should come out of this working group, but there 
is some urgency here if we want to incorporate this in our next major 
release.

Please realize that a number of us are very willing to help with the 
writing of the associated specs...
Regards, Frank.

----------------------

Andrew Grimshaw wrote:
> One more thing,
> The latest draft is on gridforge.
>  
> Andrew Grimshaw
> Professor of Computer Science
> University of Virginia
> 434-982-2204
> grimshaw at cs.virginia.edu
>  

-- 
Frank Siebenlist franks at mcs.anl.gov
The Globus Alliance - Argonne National Laboratory