April 2006 - ogsa-wg - lists.ogf.org

#new-2 resolution should optionally return referral-EPR, RR or IRI/URI
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-2 resolution should optionally return referral-EPR, RR or IRI/URI Tracker: Naming Comments by Frank Description: In order to support global resolution names and services, the resolution service and renewableReference should optionally be able to return an EPR to another resolution service or other RenewableReference or alternative URI. This is the referral functionality that makes DNS/LSID/Handle do their global resolution. The client can distinguish the EPRs by porttype/interface, and when a new resolution service EPR is returned instead of an expected application-svc-EPR, then the resolution of the URI should be attempted with the new resolution svc instance. Similar for RR and URI. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#new-1 zero, one or more "abstract-names"
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #new-1 zero, one or more "abstract-names" Tracker: Naming Comments by Frank Description: There is no reason to assume that there will be only one very special "abstract-name", and thus the spec should cater for 0, 1, or many. Same is true for RenewableReferences and resolution service EPRs. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1746 epr-hint removal
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1746 epr-hint removal Tracker: Naming Comments by Frank Description: 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. Andrew Grimshaw (2006-03-16 13:47:33) I'd rather not remove it. In our experience with an earlier re-resolution scheme it is very useful to know which EPR the client has already tried ... because if they just tried an EPR and it did not work, why give them exactly the same one back? Instead, you want to give them another, "fresher" one if one is available. For example, suppose my resolution service is really a binding cache, binding abstratnames to EPR's - or if i am not using abstract names to id services, whatever i am using in the EPR to id services. Clients use the cache service to get bindings. If they don't pass in the binding they used - they may get the same one back. Frank: Please read my comment again... the epr-minter of the renewable reference EPR can embed information about the EPR in which it was embedded. Furthermore, as the client cannot compare the EPR that is returned with its cache of already used EPRs, and because the client doesn't know whether it deals with a "smart" or "dumb" resolution service, it can only just try and give up after a number of attempts if it doesn't work. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1745 resolve-abstract-name TO IRI-to-EPR
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1745 resolve-abstract-name TO IRI-to-EPR Tracker: Naming Comments by Frank Description: 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. Andrew Grimshaw (2006-03-16 13:00:50) I disagree most strongly. The whole point of that porttype WS_Name resolveAbstractName(AbstractName) is to work with abstract names that are explicitly comparable without having to resort to using RefParameters. If someone wants to do as suggested - then they should use the other resolution port EPR resolve([EPR]) and pass in the EPR. Frank: Please read my comment again... It states that the interface should be useful for any URI/IRI, not "just" the abstract-name. In other words, "your" abstract name is just one possible URI to identify the resource and there maybe many, many more, and of those, there could be one or more that can be used to resolve. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1744 Resolver Port Type Rename
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1744 Resolver Port Type Rename Tracker: Naming Comments by Frank Description: 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 Andrew Grimshaw (2006-03-16 12:57:52) I'm not sure I understand the question - though I believe the spec as modified reflects the desire - i.e., that the two resolution porttypes explicitly have different "types" - one returns a WS-Name, the other a vanilla EPR. Frank: So we differentiate by return type... isn't the operation name a more intuitive way to address semantical meaning? -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

#1742 WS-Name vs. Abstract Name
by Frank Siebenlist 28 Apr '06

28 Apr '06

Summary: #1742 WS-Name vs. Abstract Name Tracker: Naming Comments by Frank Description: 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" Andrew Grimshaw (2006-03-16 10:54:35) I disagree. The term "WS-Name" implies an EPR with an AbstractName. Whereas a RenewableReference implies an EPR with a Resolver EPR. Frank: Please read my comment again as this has nothing to do with renewable references... A "name" is not a "EPR"... it's use as one only confuses. Furthermore, there is nothing "abstract" about the "abstract-name"... also causes confusion -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

[Fwd: [ogsa-naming-wg] Call in number for tomorrow morning]
by Frank Siebenlist 28 Apr '06

28 Apr '06

FYI - Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Naming requirements document
by Andrew Grimshaw 28 Apr '06

28 Apr '06

All, Recall that back at the January face-to-face Frank and Dave took an action to write up their take on the requirements for (low-level) naming. Attached is their draft. A few comments of mine based on my read and discussions of the document with Dave. 1) This is not intended as a replacement for the existing work. 2) It is requirements - not specifications. Rather, it is a call for specifications that address the requirements. 3) Several of the requirements are met by the existing WS-Naming draft specification, though some are not. 4) Two of the proposed "specifications", 5.2 and 5.4 are covered by the existing WS-Name specification. A variant of 5.3 is covered in the WS-Name spec. The variant specified a technique that could be used to ensure that identifying information would be sent with the headers - specifically embed names in the reference parameters. Personally I fell that 5.3 is a fine replacement for that if desired. 5.1 is not covered at all, and I must confess that it seems so obvious that I had implicitly assumed it true. Dave says it is not - so having a spec that says it must be true seems ok to me. 5) I think that with a small amount of work on this document and the WS-Name spec we can make them dovetail quite nicely. GGF is a scant two weeks away. I'd like to schedule a teleconference with the following agenda on Friday April 28th, at 10 AM eastern. (Dial in information as soon as I find a dial in number we can use.) If you plan on attending, PLEASE read both the existing draft WS-Name spec and this document before the call. Proposed Agenda: Max time Subject 5 minutes Agenda bashing 30 minutes Discuss draft requirements document including vis a vis existing draft WS-Name document 30 minutes Discuss approval of DRAFT WS-Names document to send to GFSG for GFSG approval. Note we will prepare a version that does not include the language that overlaps 5.3. 25 minutes Attempt to come to closure on working group consensus regarding WS-Directory, RNS, or failing that, at least what the issues are. Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

3 2

no authz SoW yet...
by Frank Siebenlist 27 Apr '06

27 Apr '06

Sorry, it requires a little more homework on my part... -Frank. -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

URLs for 4/27 OGSA call (info model item)
by Ellen Stokes 26 Apr '06

26 Apr '06

A document has been added: "BES and JSDL": https://forge.gridforum.org/docman2/ViewProperties.php?group_id=42&category… Note: the one thing I left off the next steps slide above is a work item to provide a concrete simple diagram and xml example to demonstrate the approach "updated JSDL 1.0 to CIM spreadsheet": https://forge.gridforum.org/docman2/ViewProperties.php?group_id=42&category… Ellen

1 0