OGSA Interim Meeting 12 - Naming ================================ Location: Fujitsu Labs America, Sunnyvale, US Date: 17 August 2005 (Day 3), morning Attendees --------- Hiro Kishimoto (Fujitsu) Steve Tuecke (Univa) Tom Maguire (IBM) Andreas Savva (Fujitsu) Takura Mori (NEC) Steven Newhouse (UoS) Michel Drescher (Fujitsu) Mark Morgan (UVa) Allen Luniewski (IBM) Donal Fellows (UoM) Steve McGough (IC) Fred Maciel (Hitachi) Andrew Grimshaw (UVa) Manuel Pereira (IBM) Michael Behrens (R2AD, LLC) Jem Treadwell (HP) Pete Ziu (Northrop Grumman) Soonwook Hwang (NAREGI) Ellen Stokes (IBM) Jay Unger (IBM) Fred Brisard (CA) Phone Bridge: Marvin Theimer (MS) Minutes: Mark Morgan Naming ------ * Frank's two issues - Renewable Reference functionallity folded into WS-Naming - Time to get the document out is a no op -- the doc is almost ready to go now. * Layers issues -- if we don't need abstract naming but only renewability, then why have the abstract name * We may need to have a fault returned from the resolve methods if only the same WS-Name can be returned. * Returning an EPR is different from returning a WS-Name * What about taking the first resolve (WS-Name resolve([WS-Name])), and changing the return and parameter types to EPRs. -- Well, you would possibly need to have a different fault type saying, "I don't know how to resolve without a WS-Name." * The ability to be able to renew an endpoint reference is seperate from being able to compare them. * Two things - One is renew -- you have an old address that isn't valid -- get a new one - The other is turning an abstract name into an addressable endpoint. * Let's change the renew to take and return EPRs instead of WS-Names. They could be WS-Names, but they don't have to be. * We are not saying anything about how to build trust domains. * There is only one normative way to get a resolver -- out of the WS-Name * You are making a statement when you put a resolver into the EPR -- that resolver is the resolver to use. * We need to have faults * In the renew, do we put restrictions on whether or not you can have EPR -> WS-Name or WS-Name -> EPR mappings? - Let's say that we recommend that you don't demote or promote the nature of the the hint to the result, but we won't require it. * What is the bottom layer (of the three layer naming scheme)? - Well, we had to collapes the two lowest layers together. * Going through the document - Do we want URI or IRI? - IRI has international characters - URI's have a case-insensitivity which could get in the way - We'll use IRI * We need to put in faults and Mark and Andrew will do this and send them around. * SOAP 1.2 is not valid -- use SOAP 1.1 * Add GGF Copyright statement in the schema and the WSDL - Normative use of schema includes - Change the namespaces RNS --- * Review of the RNS document. * Can this be simplified further? * The basic thing is to map a string to some thing, but RNS does that to several different things. But, can we collapse a few things - For example, there are junctions that refer to another repository, but there are also things that are sort of like soft links in the same repository, and then there are just EPRs - The model is that you have these repositories which have some tree inside of them...leaf nodes in these trees can point to root nodes in other repositories - It seems that we could do this by just having them point to EPRs - Well, the entries within a tree ARE EPRs, so that's OK - Two types of junctions - Junction and Referral - Why two types - Behavior - There is the question of determining the "Type" of something. - The client can resolve one name segment at a time - The client can get a message back saying, I resolved some, but not all of it * As a group, OGSA has agreed to recommend to GFS that they go with Andrew's individually addressable directory port type model. * Proposal that GFS and Data get together and talk about consolidating the iterator port type. As we move to implementing specifications, one of the things that we want to be able to do is to have some implementations and an experiences document. There are two methods. What happens inside of that is impl. dependent. Interoperability boils down to, "can my client deal with your resolution service", and vice versa. Microsoft now has internal policies about what they can sign up to do for things that have WS in the name. - Marvin to explain that. Andrew would very much like the output of this group to include Microsoft on board. * What is required to get Microsoft on board. - Two things - Still have to take the spec to the WS team in MS. -- Showed some stuff early on, but haven't talked since then - Assuming that the various parties in MS that have the ability to say yay or nay, there is the following thing -- Any spec that MS is party to, it has to go through the interop. workshops that they have been using for things like WS-Security -- There is a formal workshop and interop procedure involved to make sure that the interested parties do an impl. and have a formal interop workshop. -- There is also a feedback procedure - Is there a process document that we could get ahold of that describes this? - Probably. Marvin to talk to Andrew Layman and ask him for a formal description of this. Once this is done, UVa will do an implementation. Is anyone else intending a WS-Naming interface? - Microsoft would if they were interested in the spec. - IBM would have some people interested in doing an implementation - Does RNS have interest in doing an implementation of the resolve. Next Actions - Get latest version of doc. out and come to closure on that. - Once it gets into that state, we'll start an impl. at UVa. Maybe premature to start talking about an interop. event. We want to keep that on the planning horizon.