|
|
|
Andrew Grimshaw: 08/24/2006 12:33 PM EDT
|
| |
Action: |
Update
Closed set to 08/24/2006
Status changed from Resolved to Closed
|
|
|
David Snelling: 06/29/2006 11:33 AM EDT
|
| |
Comment: |
Some discussion points:
1) It's a safe bet that JSDL would not want this as a defined element.
2) Agreement: If this element exists it is not part of the JSDL document.
a) In some job wrapper.
b) As an operand.
3) Requirements:
a) Id is unique enough to allow the service to prevent multiple executions of the same request.
b) The service advertises how long it maintains a list of used ids.
c) The service supporting this function will only execute the request once for each id it maintains.
d) This is an optional published capability.
|
| |
Action: |
Update
Status changed from Open to Resolved
|
|
|
David Snelling: 05/02/2006 9:44 AM EDT
|
| |
Comment: |
From Marvin:
One thing to keep in mind about "unique job ids" is that they involve assumptions about who must ensure their uniqueness and who may include one in a
request message. As mentioned in the use case document, you have to ensure that a buggy or malicious client can't submit a job id that "belongs" to
someone else and hence prevent them from submitting their job(s). That implies assumptions about the security infrastructure that is present and
about the scope of issuers of unique job ids (e.g. is uniqueness relative to a client as represented by some authentication credential or relative
to an administrative domain or relative to all of time and space?). That's the reason why I treat at-most once semantics as a common case, but not
the base case.
|
| |
Action: |
Update
|
|
|
David Snelling: 04/28/2006 6:44 AM EDT
|
| |
Action: |
Update
Priority changed from - to 1
|
|
|
David Snelling: 04/28/2006 6:05 AM EDT
|
| |
Comment: |
From the above, I read the agreement as follows:
1) Include a unique (as defined in ESI) Job Id in the create activity message.
2) This element of the message is optional.
3) This id SHOUL also apprear in the JSDL JobName.
Note: A new issues is needed wrt temporal uniqueness. I will do this.
|
| |
Action: |
Update
|
|
|
David Snelling: 04/28/2006 6:01 AM EDT
|
| |
Comment: |
On 2006-04-19:
-- Decision (OK)
Optional with the characteristics that if it exists then it must be unique as specified in the ESI
document. Temporal uniqueness? Over what time period does an implementation need to keep
historical information about the activity to help determine uniqueness. The JSDL document JobName
element should contain the unique ID. At most once semantics for the Unique ID.
|
| |
Action: |
Update
|
|
|
|
