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

[Milojicic, Dejan S]

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
> 
>