[cddlm] In preparation for the CDDLM/ACS joint session at GGF14

Wed Jun 22 18:05:42 CDT 2005

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: owner-cddlm-wg at ggf.org [mailto:owner-cddlm-wg at ggf.org] 
>>On Behalf Of Steve Loughran
>>Sent: Wednesday, June 22, 2005 4:47 AM
>>To: Keisuke Fukui
>>Cc: 'cddlm-wg at ggf.org'
>>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
>>
>>

-------------- next part --------------
An embedded message was scrubbed...
From: Keisuke Fukui <kfukui at labs.fujitsu.com>
Subject: [acs-wg] Agenda for the Call on Jun 22 Mon 20:00 EDT/Jun 23 Tue 9:00 JST
Date: Wed, 22 Jun 2005 18:21:47 +0900
Size: 6638
Url: http://www.ogf.org/pipermail/cddlm-wg/attachments/20050623/86a32b8d/attachment.mht 