Hi Folx, the sessions scheduled for GGF17 are: Wednesday, May 10 1:45 pm - 3:15 pm, room G-408 Wednesday, May 10 3:45 pm - 5:15 pm, room G-408 Thursday, May 11 3:45 pm - 5:15 pm, room G-408 Friday, May 12 11:00 am - 12:30 pm, room G-408 The agendas we originally proposed are somewhat out of sync with the status of the group work, so we would like to propose the following agendas. Feedback is appreciated. We intent to publish the agenda on the GGF web pages on Sunday morning. It is recommended to read both the SAGA Requirement Document and the SAGA API specification prior to the sessions. That is not to scare people away if they don't read the docs, but efficiency of the meetings will certainly improve with familarity with the work done in the group so far. The agendas below also imply that reading of other GGF specs and drafts (JSDL, BES, DRMAA) would be very beneficial. Cheers, Andre. Session 1 (RG): --------------- The new SAGA-RG incarnation will discuss administrativa, and plan collaboration with other GGF groups (RPC, CPR, SAGA-CORE, ...). A short overview presentation of the current SAGA API is included for bypassers. Agenda: - administrativa - SAGA overview for the crowd (3 slides), announce other sessions etc - evaluate the SAGA REQ document, and derive RG scope out of that - sync with RPC and CPR, finalize on design teams Session 2 (RG): --------------- The SAGA-RG will flesh out the work of the RPC and CPR design teams, and work on synchronization with other GGF groups in general. Agenda: - plan for real req. document for these design teams - work on SAGA-RPC draft - work on SAGA-CPR draft (if available) - synchronize with (and plan for future) new specs in GGF (GFS, BES, JSDL, ...) (we should READ them before GGF) - considerations about a SAGA look-&-feel spec (based on the look-&-feel parts of the core spec) Session 3 (WG): --------------- - discuss parts of API which should be moved into the RG look-&-feel document (object, task, ...) - update on issue list, try to close remaining items - define timeline/responsibilities for finalization (editing, proof reading, consistency checks) - define timeline/editors for cook-book Session 4 (WG): --------------- - continue on open issues if needed - define editors and format for language bindings - update on implementations - discuss bulk optimizations -- "So much time, so little to do..." -- Garfield
Andre, Here is a quick [and easily resolved?] issue for your list. Several attributes are defined in the spec as "time/date", for example: 'Created' - The time stamp of the job creation in the resource manager (i.e. the submission time). Date/time. 'Started' - The time stamp indicating when the job started running. Date/time. 'Finished' - The time stamp indicating when the job completed. Date/time. Because attributes are handled as strings it would be good to specify a format for the timestamps; for example 'yyyy-mm-dd HH:MM:SS'. This would allow them to be handled predictably by the client code. Graeme
Does anybody have a pointer to the relevant ISO standard? We could also use seconds since the epoch..... ;-) On 05/5/06 07:44, "G.E.POUND@soton.ac.uk" <G.E.POUND@soton.ac.uk> wrote:
Andre,
Here is a quick [and easily resolved?] issue for your list.
Several attributes are defined in the spec as "time/date", for example:
'Created' - The time stamp of the job creation in the resource manager (i.e. the submission time). Date/time.
'Started' - The time stamp indicating when the job started running. Date/time.
'Finished' - The time stamp indicating when the job completed. Date/time.
Because attributes are handled as strings it would be good to specify a format for the timestamps; for example 'yyyy-mm-dd HH:MM:SS'. This would allow them to be handled predictably by the client code.
Graeme
Quoting [Christopher Smith] (May 05 2006):
Does anybody have a pointer to the relevant ISO standard?
Is there an ISO standard for that?
We could also use seconds since the epoch..... ;-)
Would make it easier for C programmers, but I am not sure if others could handle them as easily. I would hesitate to leave that to the language bindings though (although that is possible I guess...). Posix knows about ctime, which basically gives the output of "asctime (localtime (t))". That format "Wed Jun 30 21:49:08 1993\n" would be a good candidate to agree on I think. my 2 cent, Andre.
On 05/5/06 07:44, "G.E.POUND@soton.ac.uk" <G.E.POUND@soton.ac.uk> wrote:
Andre,
Here is a quick [and easily resolved?] issue for your list.
Several attributes are defined in the spec as "time/date", for example:
'Created' - The time stamp of the job creation in the resource manager (i.e. the submission time). Date/time.
'Started' - The time stamp indicating when the job started running. Date/time.
'Finished' - The time stamp indicating when the job completed. Date/time.
Because attributes are handled as strings it would be good to specify a format for the timestamps; for example 'yyyy-mm-dd HH:MM:SS'. This would allow them to be handled predictably by the client code.
Graeme
-- "So much time, so little to do..." -- Garfield
On 17/5/06 07:45, "Andre Merzky" <andre@merzky.net> wrote:
Quoting [Christopher Smith] (May 05 2006):
Does anybody have a pointer to the relevant ISO standard?
Is there an ISO standard for that?
I found this link: http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html but I haven't read it in any detail. -- Chris
The W3C has a profile of ISO 8601 which simplifies life: http://www.w3.org/TR/NOTE-datetime Also IETF have a RFC "Date and Time on the Internet: Timestamps": http://www.faqs.org/rfcs/rfc3339.html Other Relevent standards that specify dates are: RFC 822 and RFC 1123 The HTTP protocol accepts dates in a number of formats, from section 3.3.1: "HTTP applications have historically allowed three different formats for the representation of date/time stamps: Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format" Hope this helps Mark
Quoting [Christopher Smith] (May 05 2006):
Does anybody have a pointer to the relevant ISO standard?
Is there an ISO standard for that?
I found this link:
http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html
but I haven't read it in any detail.
-- Chris
Wow! you are thorough! :-) Thanks! Seems that w3 has a similar convention as the ISO standard Chris referred to. Well, what was that famous quote again: "The nice thing about standards is that there are so many to choose from" ;-) Do you, or Chris, or others, have any opinion which version we should use? I personally think that the ISO and W3 one are not looking particularily beautiful, with T (!) as a delimiter, but they are surely simple enough to parse... On the other we try to stay close to POSIX in many places, so sticking with ctime, or even seconds since epoch, would also be well justified... Cheers, Andre. Quoting [Mark.McKeown@manchester.ac.uk] (May 17 2006):
The W3C has a profile of ISO 8601 which simplifies life:
http://www.w3.org/TR/NOTE-datetime
Also IETF have a RFC "Date and Time on the Internet: Timestamps":
http://www.faqs.org/rfcs/rfc3339.html
Other Relevent standards that specify dates are:
RFC 822 and RFC 1123
The HTTP protocol accepts dates in a number of formats, from section 3.3.1:
"HTTP applications have historically allowed three different formats for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format"
Hope this helps Mark
Quoting [Christopher Smith] (May 05 2006):
Does anybody have a pointer to the relevant ISO standard?
Is there an ISO standard for that?
I found this link:
http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html
but I haven't read it in any detail.
-- Chris
-- "So much time, so little to do..." -- Garfield
Hello,
I personally think that the ISO and W3 one are not looking particularily beautiful, with T (!) as a delimiter, but they are surely simple enough to parse...
Right! But at least it is a text based human readable format.
On the other we try to stay close to POSIX in many places, so sticking with ctime, or even seconds since epoch, would also be well justified...
The epoch format can be written down in text, all language that I know of supports this format and have formatting functions included. This would be a no brainer to use and let the different platform and system do the formatting. English, French or Japanese have all a different formats but they all come down to use epoch time.
Cheers, Andre.
Quoting [Mark.McKeown@manchester.ac.uk] (May 17 2006):
The W3C has a profile of ISO 8601 which simplifies life:
http://www.w3.org/TR/NOTE-datetime
Also IETF have a RFC "Date and Time on the Internet: Timestamps":
http://www.faqs.org/rfcs/rfc3339.html
Other Relevent standards that specify dates are:
RFC 822 and RFC 1123
The HTTP protocol accepts dates in a number of formats, from section 3.3.1:
"HTTP applications have historically allowed three different formats for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format"
Hope this helps Mark
Quoting [Christopher Smith] (May 05 2006):
Does anybody have a pointer to the relevant ISO standard? Is there an ISO standard for that?
I found this link:
http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html
but I haven't read it in any detail.
-- Chris
-- Best regards, Pascal Kleijer ---------------------------------------------------------------- HPC Marketing Promotion Division, NEC Corporation 1-10, Nisshin-cho, Fuchu, Tokyo, 183-8501, Japan. Tel: +81-(0)42/333.6389 Fax: +81-(0)42/333.6382
Hi, Quoting [Pascal Kleijer] (May 18 2006):
Hello,
I personally think that the ISO and W3 one are not looking particularily beautiful, with T (!) as a delimiter, but they are surely simple enough to parse...
Right! But at least it is a text based human readable format.
Right.
On the other we try to stay close to POSIX in many places, so sticking with ctime, or even seconds since epoch, would also be well justified...
The epoch format can be written down in text, all language that I know of supports this format and have formatting functions included. This would be a no brainer to use and let the different platform and system do the formatting. English, French or Japanese have all a different formats but they all come down to use epoch time.
I agree, good points. We are of course also free to agree on "either SSE or ctime" or such. Cheers, Andre. (SSE == seconds since epoch ;-)
Cheers, Andre.
Quoting [Mark.McKeown@manchester.ac.uk] (May 17 2006):
The W3C has a profile of ISO 8601 which simplifies life:
http://www.w3.org/TR/NOTE-datetime
Also IETF have a RFC "Date and Time on the Internet: Timestamps":
http://www.faqs.org/rfcs/rfc3339.html
Other Relevent standards that specify dates are:
RFC 822 and RFC 1123
The HTTP protocol accepts dates in a number of formats, from section 3.3.1:
"HTTP applications have historically allowed three different formats for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format"
Hope this helps Mark
Quoting [Christopher Smith] (May 05 2006):
Does anybody have a pointer to the relevant ISO standard? Is there an ISO standard for that?
I found this link:
http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html
but I haven't read it in any detail.
-- Chris
-- "So much time, so little to do..." -- Garfield
Hi Andre
Wow! you are thorough! :-) Thanks!
Unfortuntely I wasn't thorough enough, I didn't include xsd:DateTime which is what much of the underlying middleware will be using. For a description of the issues related to timestamps and standards check out the following thread on the Atom mailing list: http://www.imc.org/atom-syntax/mail-archive/msg13103.html I think the solution that the Atom people came up with is a good compromise as it is complient with xsd:DateTime, ISO 8601, RFC 3339 and the W3C profile of ISO 8601:
3.3. Date Constructs A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset. atomDateConstruct = atomCommonAttributes, xsd:dateTime Such date values happen to be compatible with the following specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827], and [W3C.REC-xmlschema-2-20041028]. Example Date constructs: <updated>2003-12-13T18:30:02Z</updated> <updated>2003-12-13T18:30:02.25Z</updated> <updated>2003-12-13T18:30:02+01:00</updated> <updated>2003-12-13T18:30:02.25+01:00</updated> Date values SHOULD be as accurate as possible. For example, it would be generally inappropriate for a publishing system to apply the same timestamp to several entries that were published during the course of a single day. <<< The above is from RFC 4287, http://www.ietf.org/rfc/rfc4287.txt I am not fully clued up on what SAGA is doing but you could include a helper function that would convert the above DateTime into seconds from the epoch. cheers Mark
Seems that w3 has a similar convention as the ISO standard Chris referred to.
Well, what was that famous quote again: "The nice thing about standards is that there are so many to choose from" ;-)
Do you, or Chris, or others, have any opinion which version we should use?
I personally think that the ISO and W3 one are not looking particularily beautiful, with T (!) as a delimiter, but they are surely simple enough to parse...
On the other we try to stay close to POSIX in many places, so sticking with ctime, or even seconds since epoch, would also be well justified...
Cheers, Andre.
Quoting [Mark.McKeown@manchester.ac.uk] (May 17 2006):
The W3C has a profile of ISO 8601 which simplifies life:
http://www.w3.org/TR/NOTE-datetime
Also IETF have a RFC "Date and Time on the Internet: Timestamps":
http://www.faqs.org/rfcs/rfc3339.html
Other Relevent standards that specify dates are:
RFC 822 and RFC 1123
The HTTP protocol accepts dates in a number of formats, from section 3.3.1:
"HTTP applications have historically allowed three different formats for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format"
Hope this helps Mark
Quoting [Christopher Smith] (May 05 2006):
Does anybody have a pointer to the relevant ISO standard?
Is there an ISO standard for that?
I found this link:
http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html
but I haven't read it in any detail.
-- Chris
Hi Mark, Pascal, I think what the underlying MW is using does not matter too much, as mapping is straight forward, and the API should use what is most comfortable to the developer/user, not for the implementor of the API. Having said that, the scheme you list below looks just as nice as the others you listed earlier :-) Proposal: - allow time from epoch (as that is easy to obtain/use on programming level in most languages/OSs) - allow the proposed constructs, as below 2003-12-13T18:30:02Z 2003-12-13T18:30:02.25Z 2003-12-13T18:30:02+01:00 2003-12-13T18:30:02.25+01:00 but allow to add spaces, and to replace the T with a space, like: 2003-12-13 18:30:02 Z 2003-12-13 18:30:02.25 Z 2003-12-13 18:30:02 +01:00 2003-12-13 18:30:02.25 +01:00 An implementation can easily map that to the standard forms, with $date =~ s/ (\S{10}) \s+ (.+) / $1T$2 / x; $date =~ s/ (\S{19,22}) \s+ (.+) / $1 $2 / x; That would pose small overhead to the implementation (conversion is well defined, and straight forward), stays human readable, allows to use the standard representations, and allows the epoch, as thta is widely used. Does that make sense, or would that be too loosely defined? Cheers, Andre. Quoting [Mark Mc Keown] (Jun 12 2006):
Hi Andre
Wow! you are thorough! :-) Thanks!
Unfortuntely I wasn't thorough enough, I didn't include xsd:DateTime which is what much of the underlying middleware will be using.
For a description of the issues related to timestamps and standards check out the following thread on the Atom mailing list:
http://www.imc.org/atom-syntax/mail-archive/msg13103.html
I think the solution that the Atom people came up with is a good compromise as it is complient with xsd:DateTime, ISO 8601, RFC 3339 and the W3C profile of ISO 8601:
3.3. Date Constructs
A Date construct is an element whose content MUST conform to the "date-time" production in [RFC3339]. In addition, an uppercase "T" character MUST be used to separate date and time, and an uppercase "Z" character MUST be present in the absence of a numeric time zone offset.
atomDateConstruct = atomCommonAttributes, xsd:dateTime
Such date values happen to be compatible with the following specifications: [ISO.8601.1988], [W3C.NOTE-datetime-19980827], and [W3C.REC-xmlschema-2-20041028].
Example Date constructs:
<updated>2003-12-13T18:30:02Z</updated> <updated>2003-12-13T18:30:02.25Z</updated> <updated>2003-12-13T18:30:02+01:00</updated> <updated>2003-12-13T18:30:02.25+01:00</updated>
Date values SHOULD be as accurate as possible. For example, it would be generally inappropriate for a publishing system to apply the same timestamp to several entries that were published during the course of a single day.
<<<
The above is from RFC 4287, http://www.ietf.org/rfc/rfc4287.txt
I am not fully clued up on what SAGA is doing but you could include a helper function that would convert the above DateTime into seconds from the epoch.
cheers Mark
Seems that w3 has a similar convention as the ISO standard Chris referred to.
Well, what was that famous quote again: "The nice thing about standards is that there are so many to choose from" ;-)
Do you, or Chris, or others, have any opinion which version we should use?
I personally think that the ISO and W3 one are not looking particularily beautiful, with T (!) as a delimiter, but they are surely simple enough to parse...
On the other we try to stay close to POSIX in many places, so sticking with ctime, or even seconds since epoch, would also be well justified...
Cheers, Andre.
Quoting [Mark.McKeown@manchester.ac.uk] (May 17 2006):
The W3C has a profile of ISO 8601 which simplifies life:
http://www.w3.org/TR/NOTE-datetime
Also IETF have a RFC "Date and Time on the Internet: Timestamps":
http://www.faqs.org/rfcs/rfc3339.html
Other Relevent standards that specify dates are:
RFC 822 and RFC 1123
The HTTP protocol accepts dates in a number of formats, from section 3.3.1:
"HTTP applications have historically allowed three different formats for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123 Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format"
Hope this helps Mark
Quoting [Christopher Smith] (May 05 2006):
Does anybody have a pointer to the relevant ISO standard?
Is there an ISO standard for that?
I found this link:
http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html
but I haven't read it in any detail.
-- Chris
-- "So much time, so little to do..." -- Garfield
Good points - I am all for that. Andre. Quoting [G.E.POUND@soton.ac.uk] (May 05 2006):
Date: Fri, 5 May 2006 15:44:39 +0100 From: G.E.POUND@soton.ac.uk To: Andre Merzky <andre@merzky.net> Cc: SAGA RG <saga-rg@ggf.org> Subject: Timestamp issue
Andre,
Here is a quick [and easily resolved?] issue for your list.
Several attributes are defined in the spec as "time/date", for example:
'Created' - The time stamp of the job creation in the resource manager (i.e. the submission time). Date/time.
'Started' - The time stamp indicating when the job started running. Date/time.
'Finished' - The time stamp indicating when the job completed. Date/time.
Because attributes are handled as strings it would be good to specify a format for the timestamps; for example 'yyyy-mm-dd HH:MM:SS'. This would allow them to be handled predictably by the client code.
Graeme
-- "So much time, so little to do..." -- Garfield
Andre, There is an inaccuracy in the contexts described by the strawman. The context type 'X509' describes proxy certificates. These are not standard X509 certificates, therefore this type should be renamed GSI. Graeme
X509 proxy certificates are described by RFC 3820, which has the status of proposed standard. 3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile. S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. June 2004. (Format: TXT=86374 bytes) (Status: PROPOSED STANDARD) "standard X509 certificates" are described by RFC 3280, which has the same status. 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. R. Housley, W. Polk, W. Ford, D. Solo. April 2002. (Format: TXT=295556 bytes) (Obsoletes RFC2459) (Updated by RFC4325) (Status: PROPOSED STANDARD) So I don't agree that proxies aren't standard. However, I do agree that X509 isn't a good label for a security context based on Globus certificates. There are other X509-based security models, e.g. the one employed by UNICORE. Stephen PS Do I have to resort to CVS to get the current draft of the strawman?
-----Original Message----- From: owner-saga-rg@ggf.org [mailto:owner-saga-rg@ggf.org] On Behalf Of G.E.POUND@soton.ac.uk Sent: 05 May 2006 16:09 To: Andre Merzky Cc: SAGA RG Subject: [saga-rg] Context inaccuracy
Andre,
There is an inaccuracy in the contexts described by the strawman. The context type 'X509' describes proxy certificates. These are not standard X509 certificates, therefore this type should be renamed GSI.
Graeme
Hi, Quoting [Stephen M Pickles] (May 07 2006):
X509 proxy certificates are described by RFC 3820, which has the status of proposed standard.
3820 Internet X.509 Public Key Infrastructure (PKI) Proxy Certificate Profile. S. Tuecke, V. Welch, D. Engert, L. Pearlman, M. Thompson. June 2004. (Format: TXT=86374 bytes) (Status: PROPOSED STANDARD)
"standard X509 certificates" are described by RFC 3280, which has the same status.
3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. R. Housley, W. Polk, W. Ford, D. Solo. April 2002. (Format: TXT=295556 bytes) (Obsoletes RFC2459) (Updated by RFC4325) (Status: PROPOSED STANDARD)
So I don't agree that proxies aren't standard.
However, I do agree that X509 isn't a good label for a security context based on Globus certificates. There are other X509-based security models, e.g. the one employed by UNICORE.
I also think that GSI (or even GlobusCert) is a more appropriate name - even if X509 was less general in definition and usage.
Stephen
PS Do I have to resort to CVS to get the current draft of the strawman?
The other way is to ask nicely on this list :-D I attach the current version. It is in editing, and parts are currently in tex, others in plain text. Sorry for that. In general though: yes, CVS is the preferred method. Cheers, Andre.
-----Original Message----- From: owner-saga-rg@ggf.org [mailto:owner-saga-rg@ggf.org] On Behalf Of G.E.POUND@soton.ac.uk Sent: 05 May 2006 16:09 To: Andre Merzky Cc: SAGA RG Subject: [saga-rg] Context inaccuracy
Andre,
There is an inaccuracy in the contexts described by the strawman. The context type 'X509' describes proxy certificates. These are not standard X509 certificates, therefore this type should be renamed GSI.
Graeme
-- "So much time, so little to do..." -- Garfield
participants (7)
-
Andre Merzky -
Christopher Smith -
G.E.POUND＠soton.ac.uk -
Mark Mc Keown -
Mark.McKeown＠manchester.ac.uk -
Pascal Kleijer -
Stephen M Pickles