OGSA-DMI Telcon - 8 August 2008
===============================

Present:
	Mario Antonioletti, EPCC
	Steven Newhouse, Microsoft
	Michel Drescher, Fujitsu
	Allen Luniewski, IBM

Agenda:

    - Implementations and Interop progress
    - Rendering documents
    - Open Tracker Artefacts
      http://tinyurl.com/6g448w

+---

- Implementations and Interop progress

Both Steve and Michel now have running implementations. Had some
slightly different interpretation of stuff in the spec but that is the
point of this exercise. All that remains is to test whether an
unsupported state fault is thrown but no problem is expected for this.

Tests are passing for both implementations - remaining problems are
implementation bugs rather than interpretation of the specs. We are in
a good shape in validating the WSDL and the spec.

Have covered all messages and have tested the start operation - which
is a template for all the other state transitions. Expect the other
state transitions to work in the same way. Just need to test the
faults.

The wiki pages are kept up to date with the tests and results:

http://forge.gridforum.org/sf/wiki/do/viewPage/projects.ogsa-dmi-wg/wiki/PlainWSInterop

There are some corner cases that might may need investigation but from
an OGF perspective we are done though it would be nice to have a third
implementation.

Some discussion followed regarding other groups that might be
contacted to provide another implementation: Globus, Unicore at FZJ,
etc.

- Rendering documents

Now have the WSDL finalised and capture messages to see what is
required and what is not required. Michel will try to put this
in a document.


- Open Tracker Artefacts (http://tinyurl.com/6g448w)

Had 13 artefact but 10 of these have been retrofitted and closed -
there are 3 remaining ones.

o artf6261 obsoletes the "Activate()" operation?

  Clarifying the ambiguities described in artf6261 makes things much
  clearer. However, this opens the question whether the "activate()"
  operation is still necessary.

It is worth keeping the state in but the operation is redundant. There
is no manual mechanism that makes sense for changing from the
scheduled to the transferring state.

Can invoke the start operation to start a transfer but the
implementation is not obliged to start the transfer when requested
through the invocation of this operation.

It was agreed to remove the Activate() operation.

o Stop()" operation definition hole

   However, there is a definition hole in conjunction with
   "EndNoLaterThan" and more than one attempt to transfer the data:

   The status "transferring" is defined as having bytes moving on the
   wire. That means that the state of the DTI must be a different one
   when a transfer attempt failed (but the maxAttempts requirement has
   not been reached) and the next one is in the process of being set
   up. In that phase, the transfer is not stoppable as it is not (yet)
   in state "Transferring" or "Suspended".

   I propose to expand the notion of stopping a transfer regardless in
   which state it currently is. The effect of the stop operation will
   be nil if the state is either "Done", "Failed" or one of the
   substates of "Failed".

There was unanimous agreement for this proposal as well.

o Time skew support

  Should we add a facility to the DTF (and possibly the DTI?) for time
  skew detection, i.e. have both support a "local time" attribute of
  type xs:dateTime?

Skew times in clocks caused problems in scheduling transfers in the
interop testing. Can leverage of other solutions to solve this -
e.g. WSRF Lifetime, could add the local server times to one of the
elements - useful to know the time.

It was agreed that time skew is out of scope for the specification but
not for the implementation.

Adding an extra element with the server time would complicate matters
(WSRF has mechanisms - would end up with one more than one mechanism
to do the same thing - not nice). No server time element to be added.

DONM when new people come on line or things need to be
reported/discussed.