=======================================================================
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 Wrap up for day 1