Folks at the F2F, Attached is the proposed time table for tomorrow and minutes for today. We will start tomorrow's discussion with the review of the minutes. -Keisuke ======================================================================= ACS F2F DAY 1 ----------------------------------------------------------------------- Date and Time: Aug 1 9:00-18:30 EDT 2005 Location: IBM, Durham RTP. Participants: Keisuke Fukui (Fujitsu) Peter Ziu (Northrop) Thomas Studwell (IBM) Michael Behrens (R2AD) Sachiko Wada (ASCADE) - minutes ----------------------------------------------------------------------- * 9:15 Agenda bashing, role call, note taker & time keeper. * 9:30 AA Creation use case Material: (from Tom) There are two representations of AA: AA on the wire and AA in the repository. Both are logically equivalent. We agreed to call the former as AA Document and the latter as AA Instance. To create an AA Instance, the client sends an AA Document and optional administrative information to the repository. The administrative information is used to add or overwrite information in the AA Document. * 10:45 break * 11:00 AA Creation use case (continued) We discussed five scenarios. Z) Non-ACS IDE, which doesn't know about AA Document, sends administrative information and a collection of Application Content files to the repository in order to create a new AA Instance. 1) ACS IDE, which knows about AA Document, sends an AA Document and optional administrative information to the repository in order to create the corresponding AA Instance. 2) The client uploads files to the portal service, then the service sends an AA Document and optional administrative information on behalf of the client to the repository in order to create the corresponding AA Instance. This scenario is exactly the same as scenario 1 from ARI view. 3) The client uploads files to the repository in order to add or update Application Contents in an existing AA Instance. This is a scenario of AA Updating. 4) The repository (ACS service) sends an AA Document and optional administrative information to another repository to replicate the AA. This is a scenario of AA Replication. We agreed to drop off scenario Z. We agreed to call the operation for scenario 1 and 2 as "Create" instead of "Register". The detailed message exchange format for AA creation (scenario 1 and 2), AA Updating (scenario 3) and AA Replication (scenario 4) will be discussed tomorrow. * 11:45 Lunch * 13:20 Data Transport Material: (from Keisuke and Sachiko) ** Baseline discussion We agreed that ACS (ARI) exposes a list of supported protocols as resource properties. ** Discussion on slide 3: We discussed six scenarios for Create and GetContents operations. A) Create using SwA. B) Create using soap message but with out of band transport for a (part of) the AA document and the uri is provided by the ACS (the ACS acts as a file server). C) Create using soap message but with out of band transport for a (part of) the AA document and the uri is provided by the ACS (the ACS client acts as a file server). D) GetContents using SwA. E) GetContents using soap message but with out of band transport for the AA contents and the uri is provided by the ACS (the ACS acts as a file server). F) GetContents using soap message but with out of band transport for the AA contents and the uri is provided by the ACS client (the ACS client acts as a file server). We agreed that A and D should be supported by default. B: Pros - Client needs not prepare storage. Cons - Message exchange becomes complicated. (At least 3 stages are required to complete transaction) 'Put' is difficult in respect of access control. C: Pros - ACS can select whether ACS stores actual files or references. Message exchange is simple. On-demand expansion of the storage can be explored easier. Cons - The client needs prepare storage. E: Pros - Client needs not prepare storage. This is what we discussed with CDDLM-WG at GGF14. Cons - Message exchange becomes complicated. It may need 3 stages. F: Pros - The operation can be done in 1 stage. Cons - 'Put' is difficult in respect of access control. How do ACS put multiple contents? ** Conclusion Which pattern ACS supports is: Required - A, D Optional - B, C, E(recommended) Not supported - F * 15:10 break * 15:25 Security and signature on ACS Material: (prepared by Sachiko) Keisuke explained the material. We agreed that ACS may not specify what the other standards including OGSA basic profile cover as for the ARI, since they should be treated common to all OGSA services. We need to clarify to what extent OGSA and other standards specify, especially concerning with authorization. Mike will get comments from the OGSA AuthZ co-chair. Action: Mike to report the feedback of the OGSA meeting next Wednesday (US EDT). * 16:30 OGSA F2F presentation The presentation is for EMS team and other OGSA people who may not know much about ACS. The presentation should take less than 10 - 15 minutes. We review the proposed material in the regular teleconference next week. Action: Pete to make the draft presentation by coming Friday. * 17:00 break * 17:15 ACS use case for SDD TC and update ** Updates SDD TC is now collecting use cases and as an input to the TC. Those are available from the TC WWW site. Sun and IBM had already posted their use cases. ACS and CDDLM are requested to input grid related use cases. ** ACS use case Extracted requirements which are relevant to SDD from current ACS requirements. Action: Keisuke to send the ACS requirements document with highlits on those that may apply to the SDD (green: yes, yellow: possibly) to the ml. Action; All to review it and send comments if any. * 18:00 Warp up for day 1