OGSA DMI Telcon 05/12/07
========================

Attendees:
	Mario Antonioletti, EPCC
	Allen Luniewski, IBM
	Steven Newhouse, Microsoft
	Michel Drescher, Fujitsu
	Ravi Madduri, ANL

Agenda:

1.       IPR Notice
2.       Previous Minutes and Action Review
3.       Agenda Bashing
4.       Issues Arising
5.       Spec Progress
6.       AOB

+---

Start off by looking at Ravi's proposals - Ravi likes and is in
agreement with the comments that were made.

Dealing with aggregations:

RFT originally started with one file transfers but this needed to be
changed for staging where more than one file had to be transferred at
a time.

Having separate DEPRs for every file that needs to be transferred in
the proposal was seen as being somewhat worrying. Should have a
logical representation for the files in a single DEPR. 

Issue then moved on to whether multiple files can or should be
represented in a DEPR - should there be the notion of an aggregate in
the DEPR? A counter argument was proposed that DEPRs are opaque things
- not XML containers that have associated semantics - produced by the
source and sink and, other than the stuff that DMI define, the
contents should not interpreted by the DTF/DTI. Having a DEPR
representing multiple files may cause problems and introduces ugly
protocol dependencies. A DEPR is an abstract thing that is only
interpreted at the source and sink. However, the DTF is made aware of
the contents through negotiation with the source and sink. Within this
model an aggregate is represented by the source and sink and out of
scope for DMI.

So, if you wanted to transfer a directory the source/sink would
specify a URL that gridFTP understands, a / at the end of the URL,
which is the interpreted as a directory. This could be done using
existing attributes in DMI. This information would be encoded in the
URL by the source/sink. Aggregation becomes an implementation detail.

Consensus reached: aggregation can already be addressed with the
current spec.

Ravi is to modify his existing proposal to take this discussion into
account and it will be discussed at the next call.

On Transfer Retries:

Should there be another state for transfer retries or could a
retry counter attribute be used instead? 

Consensus reached: go from the existing states failed -> scheduled ->
active - no new state and have a transfer retries counter attribute in
the DTI.

Ravi to modify his proposal to reflect this and discuss at the next
call.

Michel's proposal - communicating a transfer failure from the DTI.
Could have a fault bound to Start or Activate operations or if the
client sets a scheduled data transfer - communicate it back through
the state - client can poll to find this out if the data transfer
could not be instantiated.

It was thought that the fault bound model was a bit restrictive and
that the state bound model was more general. Putting it in a failed
state and putting information as to why it failed would be a good thing
as it would make it easier to implement. Have a single point of
contact for the client - service has gone into the failed state and
discover what went wrong. Could find out whether it was a syntactical
problem or a protocol problem, etc.

Consensus reached: drop the fault based communication to have a state
based communication instead. Michel to modify his proposal accordingly
and move this text into the spec. Michel gets the write token on the
spec until this is completed.

Steven and Ravi have made modifications to the spec - there were no
major objections.

DONM: 12/12/07, 9am (Pacific) 11am (CENTRAL) 5pm (UK).