Present: Steven Newhouse Glenn Wasson Vesselin Novov Gabor Roczei Marty Humphrey (at end) Agenda 1. OGF IPR Notice 2. SC07 PM * Good from an implementation perspective - especially from client configuration * Pushed forward on specifications and proposed extensions * Big issues on establishing SSL configurations * UVa may still have issue accepting NorduGrid connections * Overall good experience Action: Continue updating interop matrix on wiki 3. Experience Document * Update from Glenn... last draft on 1st Nov. Action: All to review and make contributions 4. Data Staging & Activity Credential Revision * Discussion on SJN's email and Glenn's response * FileStaging element in JSDL optional - we may Fault if present or silently ignore * Use xsd:any within the Credential element * Define a list of minimally supported authentication tokens and protocols that an implementation MUST support (e.g. username/password and ftp, others...) * The credential for job initiation to not go in the file staging spec. Perhaps as an optional extension to the basic profile specification? Action: Glenn currently revising document. Will circulate next few days 5. Activity Filter Action: All to read & comment 6. OGF Article * Glenn thought it read OK. Make it clear that extensions are separate - not part of the specification. 7. AOB 8. Next Meeting - Thursday 6th December 2007 - 9.30 PACIFIC
Steven Newhouse wrote:
4. Data Staging & Activity Credential Revision * FileStaging element in JSDL optional - we may Fault if present or silently ignore
The correct "JSDL way" of handling something is to throw a fault (with meaning "I don't/won't do that") if a unsupported feature is used.
* Define a list of minimally supported authentication tokens and protocols that an implementation MUST support (e.g. username/password and ftp, others...)
I'd be a bit concerned about requiring support for a specific token type/protocol. Recommending is OK though, and requiring some mechanism for discovery of what is supported would be good. Donal.
4. Data Staging & Activity Credential Revision * FileStaging element in JSDL optional - we may Fault if present or silently ignore
The correct "JSDL way" of handling something is to throw a fault (with meaning "I don't/won't do that") if a unsupported feature is used.
Yeah. But the JSDL model having xsd:any everywhere makes it tricky for implementers to define what is explicitly out of bounds.
* Define a list of minimally supported authentication tokens and protocols that an implementation MUST support (e.g. username/password and ftp, others...)
I'd be a bit concerned about requiring support for a specific token type/protocol. Recommending is OK though, and requiring some mechanism for discovery of what is supported would be good.
To get interoperability we need a minimal core supportable set. People can (& will) go beyond that - that's fine. Steven
Steven Newhouse wrote:
4. Data Staging & Activity Credential Revision * FileStaging element in JSDL optional - we may Fault if present or silently ignore The correct "JSDL way" of handling something is to throw a fault (with meaning "I don't/won't do that") if a unsupported feature is used.
Yeah. But the JSDL model having xsd:any everywhere makes it tricky for implementers to define what is explicitly out of bounds.
I think the problem of advertising what features one supports is different from 'doing the right thing' when one gets a document that includes features one does not support. I had a look at the draft Glenn sent out and I suppose 'FileStaging' refers to the FileSystem element in DataStaging. If a value for FileSystem in a DataStaging element is given and an implementation ignores it the file will be put in the wrong place. The "JSDL way" (as Donal put it) does not allow implementations to ignore anything in a JSDL document because if a 'user' put something in then it must be needed and it's not up to an implementation to do something different. Marking parts of a JSDL document as optional is one of the features we have in mind for future versions. -- Andreas Savva Fujitsu Laboratories Ltd
I think the problem of advertising what features one supports is different from 'doing the right thing' when one gets a document that includes features one does not support.
OK. When a FileSystem element appears in a JSDL document for this specification we WILL throw an UnsupportedFeatureFault... I think we have one of those kicking around already. Steven
Steven Newhouse wrote:
4. Data Staging & Activity Credential Revision * FileStaging element in JSDL optional - we may Fault if present or silently ignore The correct "JSDL way" of handling something is to throw a fault (with meaning "I don't/won't do that") if a unsupported feature is used.
Yeah. But the JSDL model having xsd:any everywhere makes it tricky for implementers to define what is explicitly out of bounds.
Understood. My point is that the standard way of handling the element is to either accept it (and process it correctly) or to reject it noisily. Silently ignoring it is (currently, as Andreas notes) unacceptable.
* Define a list of minimally supported authentication tokens and protocols that an implementation MUST support (e.g. username/password and ftp, others...) I'd be a bit concerned about requiring support for a specific token type/protocol. Recommending is OK though, and requiring some mechanism for discovery of what is supported would be good.
To get interoperability we need a minimal core supportable set. People can (& will) go beyond that - that's fine.
Thinking about it a bit more (and in context) it's acceptable from my perspective to require support for username/password for FTP transfers. After all, the FTP URI protocol already says how to do it. ftp://user:pass@host.example.org/some/path/to/file.data I was getting mixed up with the job submission side. Donal.
participants (3)
-
Andreas Savva -
Donal K. Fellows -
Steven Newhouse