Subject: Re: [cddlm] In preparation for the CDDLM/ACS joint session at GGF14
From: Keisuke Fukui <[email-masked]>
To: "Milojicic, Dejan S" <[email-masked]>
Cc: Steve Loughran <[email-masked]>, [email-masked]
Date: Thu, 23 Jun 2005 08:05:42 +0900

Hi Dejan and et al,

# This is a resend. I forgot the attachement ;-p
Thanks for your offer. Unfortunately, I missed the call.
FYI, we have acs-wg regular call soon today. You can join
acs-wg one if you like. Attached is an info.
We can start with CDDLM changing the order of the topics in the agenda.

  -Keisuke
Milojicic, Dejan S wrote:
> Hi,
> 
> We can also start this discussion at our last regular CDDLM phone
> conference before GGF, which will  start in about half an hour.
> 
> Thanks,
> 
> Dejan.
> 
> 
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] 
>>On Behalf Of Steve Loughran
>>Sent: Wednesday, June 22, 2005 4:47 AM
>>To: Keisuke Fukui
>>Cc: [email-masked]'
>>Subject: Re: [cddlm] In preparation for the CDDLM/ACS joint 
>>session at GGF14
>>
>>Keisuke Fukui wrote:
>>
>>>Folks in the cddlm-wg,
>>>
>>>As you know we will have a joint session at GGF14 between 
>>
>>CDDLM and ACS.
>>
>>>This is in preparation for the session from acs-wg.
>>>After the GGF13 inside the acs-wg, we studied and discussed 
>>
>>about the 
>>
>>>possible interactions between CDDLM and ACS, especially in terms of 
>>>"File upload" section and AddFile() in the deployment API document.
>>>Sequence diagrams in the attachment describe our 
>>
>>interpretation about 
>>
>>>how CDDLM works, and our proposal for the possible 
>>
>>interactions in the 
>>
>>>case that the ACS co-exists in the system. We believe our proposal 
>>>goes along with what the current set of CDDLM specifications define 
>>>and doesn't require change in the original definitions.
>>>
>>>We are looking forward to discuss about this at the joint 
>>
>>session for 
>>
>>>CDDLM/ACS at GGF14. It is very much appreciated if we get responses 
>>>before the joint session at GGF14 in case that important 
>>
>>overlook in 
>>
>>>our understanding is found. Please feel free to make 
>>
>>comments or questions.
>>
>>>FYI,
>>>At GGF14 joint session, we'd like to start our discussion with this 
>>>diagram and if we don't find critical issues, we may go down to the 
>>>detail of the interface and/or advanced interaction. We'd 
>>
>>also like to 
>>
>>>hear requirements on ACS in terms of the event notification and 
>>>asynchronous invocation of the interfaces, if the time permitting.
>>>
>>>Thanks in advance for you efforts on this!
>>>
>>>Best Regards,
>>>Keisuke Fukui
>>>ACS-WG
>>>
>>
>>thank you, I will comment briefly.
>>
>>-The File upload stuff was very much written to be a 
>>transient/interim solution in the absence of a real 
>>repository, which is why it is so minimal and barely 
>>functional. I didnt want to be dependent upon anything not 
>>yet designed, but didn't want to do a repository myself
>>
>>-the current revision allows the sender to declare the URL 
>>schema to use. That could be file: for a shared filesystem 
>>and http: or https for HTTP access. It could also be fancy 
>>custom stuff; there is some java project whose name escapes 
>>me that provides a multicast URL resolution system, the file 
>>could be stored across multiple machines without ever having 
>>to give them a hostname, which is very good for fault-tolerance.
>>
>>-There is also support for adding metadata to a request, but 
>>nothing to do searches, retrieval, or even introspection on 
>>what stuff is supported. I've left that for implementations.
>>
>>-There is the perennial problem of how to get files up over 
>>SOAP. SwA is only available in java distrubutions, and then 
>>not consistently, DIME is in .NET WSE and Axis 1,x, but even 
>>more unpopular. As for MTOM, well, who implements that yet?
>>
>>As a workaround I've put in stuff for having the endpoint 
>>actually retrieve the files themselves, but this is a bit 
>>unsatisfactory, because it requires the files to be broadly 
>>visible on the 'net, and introduces race conditions. 
>>Otherwise, data goes inline in base-64 encoded form, 
>>unless/until MTOM lets you pretend that the file attached to 
>>the message is really inline base 64.
>>
>>
>>here are two example mesages and responses from the 
>>XSD-validation tests
>>
>>
>>
>>     <api:addFileRequest>
>>       <api:name>urn://45</api:name>
>>       <api:mimetype>application/x-pdf</api:mimetype>
>>       <api:schema>file</api:schema>
>>       <api:uri>http://example.org/files/source.pdf</api:uri>
>>     </api:addFileRequest>
>>   </t:test>
>>
>>     <api:addFileResponse>
>>       <item>file://nas1/temp/source.pdf</item>
>>       <item>file://nas2/4fgdbb.tmp</item>
>>     </api:addFileResponse>
>>
>>
>>
>>     <api:addFileRequest>
>>       <api:name>urn://46</api:name>
>>       <api:mimetype>application/x-ssh-key</api:mimetype>
>>       <api:schema>http</api:schema>
>>       <api:data>
>>       AAAAB3NzaC1yc2EAAAABIwAAAIEAwVmUkPzXdWEyJZ8nCR8GvdrDtO00RI4Z
>>       Bg3Gyviuz5IrWj2C6b2BdcKn+S/swDV1fiEFY4+ewYHUfmg+UKm2T8Lfksjn
>>       Hinks0GoVvkwy3bF48U5yVk1akAzR5YbSLJa6Naj8XS9681xVzWpbjxrV3KR
>>       QNWvEqI0MqRE34MzT4M=
>>       </api:data>
>>       <api:metadata>
>>         <x:expires date="2005-07-18" 
>>xmlns:x="http://example.org/expiry" />
>>       </api:metadata>
>>     </api:addFileRequest>
>>     <api:addFileResponse>
>>       <item>http://server/job5/files/1</item>
>>     </api:addFileResponse>
>>
>>
>>On a related note, I see that Fujitsu are listed as one of 
>>the interested parties in JSR 277, the java 
>>modules/repository proposal. Are you involved in that?
>>
>>-steve
>>
>>

Subject: [acs-wg] Agenda for the Call on Jun 22 Mon 20:00 EDT/Jun 23 Tue 9:00 JST
From: Keisuke Fukui <[email-masked]>
To: [email-masked]
Date: Wed, 22 Jun 2005 18:21:47 +0900

Folks,

Here is an agenda for the call tomorrow. See you there!

### Proposed Agenda
1. Agenda bashing, role call, note taker & time keeper. (5 min)
2. Review of the minutes for the last call. (5 min)
    Goal: Reconfirm our understanding for GGF14.
3. Draft writing schedule by GGF14. (20 min)
    We'd like to add contents to the current draft so that we can progress
    our discussion at GGF14 sessions. Possible candidates are show below
    (names are proposed drivers for each topic):
    - Glossary definition refinement. (KF) - Posted.
    - Security/Signature discussion for ACS (Mike/Pete)
    - Repository interface detail, (KF) - Posted.
      including portTypes, fault types, synchronous and asynchronous
      interface, event notification.
    - CDDLM interface (Sachiko) - Posted.
    - AAF/SDD refactor (Tom)
    - Data transport/event notification (TBA)
    I'd like the meeting materials merge into the draft spec. to
    facilitate the discussion effectively.
    Goal: Make consensus on the agenda.
4. Updates (10 min)
     Review the action items list and issues status on tracker.
     Updates on CDDLM, security, etc, if any..
5. Wrap up, Next meeting(5 min)

### Logistics for the call
Date & Time:               Jun 22 Mon 20:00 EDT/Jun 23 Tue 9:00 JST
Dial-in Number:            1-831-600-1000 (Santa Cruz, California)
Participant Access Code:   7771111

   -Keisuke