Attached. Gridforge https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050223/en/1 -- Andreas Savva OGSA Teleconference - 23 February 2005 ====================================== * Participants Dave Berry (NeSC) Ian Foster (ANL) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Mark Morgan (UVa) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * Data (ByteIO BoF) Review of basic proposal; simple data access interface. Dave B has sent the revised charter to Stacey (and the list). Malcolm's comments are taken care. (1) WG will produce informative usecase document (2) WG will define API including WSDL (i.e., a WS interface, not java binding) Dave B will also send 7 Q&A to Stacey and Data Area ADs (Malcolm and Dave Martin) (It is probably not required at this point and in any case one purpose of the BoF is to review and draft the final answers.) - Proposed Milestones - Draft document and implementation by June - Draft experience document by GGF15 - Is there no other similar or related WS standard? WS-Enumeration was mentioned but it deals with XML streams rather than bytestreams. * WS-Naming A number of documents were sent out prior to the call. 1. A presentation for review in this call 2. A document describing the proposal 3. A draft Naming profile that was split off from Basic profile - There is one more (earlier) document that discusses motivation, use cases, etc. - GGF13 Plans - A union of these documents will be presented at GGF13 - Everything except the 'resolve' can be a profile. So one spec and one profile - The reason for the alternative document (2) is also to present to people who may not have an interest in the wider OGSA picture. The Profile is based on extending WS-Addressing EPRs with additional information. These extended EPRs can be used as normal EPRs by existing clients with no changes. This is an important requirement that is neeed to help initial adoption. Two elements are added: 1. Abstract name: A string, globally unique, only equality comparison allowed - Anything in profile should be testable; so how can global uniqueness be tested? - Probably not testable though there could be an argument that they are. No good answer at this point. - Strings are already comparable; why re-state this? - To emphasize that lexicographic ordering is not meangingful. Only equality is defined. - Why not use a URI? - No need to constrain the Abstract Name further at this point - Interesting points on whether it might have structure, and whether it can be reasoned about to some extent. - Scheme presented as 3-levels; but actually there can be many more levels than that. - Three levels capture requirements of many systems. It's not the intention to constrain it to (at most) 3 levels. This should be made clearer. 2. Resolver - Optional: it may appear and if it does its usage is optional - Singleton or list? - Currently saying that this is at-most-one - Leaving this as an issue for the WG that will define this. - If a list then there is additional complexity with whether you get the same answer from all resolvers or not, which one to use, and so on. - The resolver is a WS with an EPR and a portType with the operation 'resolve' that receives an epr and returns an (equivalent) updated one. - Could there also be a WSRF binding that casts the resolver as a WS-Resource with just the operation 'resolve' (no arguments; the resource is 'pointing' to what needs to be resolved.) - If necessary, it could be defined as a separate profile. - EPR examples slide - Case with "No resolver," "Simple," and "Resolver with resolver" - Resolver with resolver can be stateful or close to the WSRF rendering of a resolver mentioned before. - Exactly one abstract name or is it possible to include different names or aliases in the same EPR? - Is it inevitable or not? (Perhaps) - Sameness issues? - Might be better to constrain it at this level and at this point in time. - Properties on resolver, e.g., to distinguish them? - It is out of band - Extensible scheme for Names so that people can introduce names that are unique for that authority or not? (context) - Names are defined as globally unique but there is nothing stopping an organization to produce them in such a way that they can be interpreted differently within a context or domain (and those domains do not overlap) - For example, IP addresses are globally unique but many organizations use certain spaces (10.*) internally. - Issue of addressability from other places - Can generate a unique name/id, but someone else could re-use it later. Can't stop people from doing that. - No guarantee. Need to be careful when saying 'globally unique.' Might need to look at making this statement in a better or more descriptive manner. - Andrew and Mark are working to bring Tom's document (Naming profile draft) and this document together. - OGSA Naming session will probably be used as BoF for these activities. * OGSA-BES update - Not ready for a detailed review yet. Will continue on a separate teleconference to discuss logistics and come back to the main call. - Haven't completed the 7 questions yet - The draft reviewed at the F2F is not updated yet. Refinement of that document is not the focus at the moment. * Basic security profile - Frank is not available before GGF13. Probably discuss this at that time.