RE: [dss] Groups - oasis-dss-1.0-profiles-codesigning-spec-wd-01. doc uploaded

[Trevor Perrin <trevp@trevp.net>]

I agree.  I'll add "TryAgainLater" to the next draft, unless anyone wants 
to discuss more.

Trevor


At 07:31 PM 3/22/2004 +0000, Nick Pope wrote:

>This looks like a reasonable way ahead.
>
>Nick
>>-----Original Message-----
>>From: Pieter Kasselman [mailto:PKasselman@betrusted.com]
>>Sent: 22 March 2004 08:50
>>To: 'Trevor Perrin'; Pieter Kasselman; Pieter Kasselman; 
>>dss@lists.oasis-open.org
>>Subject: RE: [dss] Groups - 
>>oasis-dss-1.0-profiles-codesigning-spec-wd-01. doc uploaded
>>
>>Hi Trevor, we can keep the async behaviour in the profile, but I would 
>>prefer to have the TryAgainLater in the core (there are other reasons why 
>>the server may ask the client to try again later - i.e. it may be very 
>>busy). The TryagainLater can then be further qualified through a 
>>ResultMinor error code (ServerBusy etc). It is small enough and I doubt 
>>if it influences anything else. Using the ResponderError when there is no 
>>error is as abusive as responding with Success when there is no signature.
>>
>>We can also allow profiles to define their own <Result> codes, in which 
>>case everything goes into the profile, although I would prefer the option 
>>where it is kept in the
>>
>>-----Original Message-----
>>From: Trevor Perrin [<mailto:trevp@trevp.net>mailto:trevp@trevp.net]
>>Sent: 19 March 2004 23:12
>>To: Pieter Kasselman; Pieter Kasselman; dss@lists.oasis-open.org
>>Subject: RE: [dss] Groups -
>>oasis-dss-1.0-profiles-codesigning-spec-wd-01. doc uploaded
>>
>>At 05:13 AM 3/19/2004 -0500, Pieter Kasselman wrote:
>>
>> >Thanks Trevor, in general I like the idea of fitting as much as possible
>> >into the exisiting framework. I guess a key question is if the
>> >code-signing profile is the only profile that will require asynchronous
>> >support, or if there are other profiles that require this as well?
>>
>>At the F2F we decided this wouldn't be a V1 requirement, and I don't recall
>>much objection, so I suspect there isn't a strong immediate demand for
>>this.  But I could be wrong.
>>
>>I like Nick's idea of experimenting with this in the code-signing profile,
>>and moving it to the core later if the demand arises.
>>
>> >So I still like re-submission, since it accomplishes much of
>> >the  functionality of <RequestReference> at less cost.
>> >
>> >[Pieter Kasselman]  Maybe from an implementation perspective, but the
>> >server has to do more work and more bandwidth is consumed. Looking at the
>> >proposed benefits in detail:   - "allows the server to quickly track the
>> >status of the request" - it  seems not too hard for the server to
>> >canonicalize and hash the request, and  use that as a "request reference".
>> >
>> >[Pieter Kasselman]  This is still more work than taking a reference and
>> >checking it. On a busy server this will add up.
>>I still weigh simplicity/reusability of client code as more important, but
>>I see your point.
>>
>> >   - "conserve bandwidth" - Bandwidth can be reduced by using
>> > <DocumentHash>  input documents.  If it's important for the server to
>> > have the whole  application to review, you could use <Document> for the
>> > 1st request, and  <DocumentHash> for the 2nd.
>> >
>> >[Pieter Kasselman]  OK, in this model the request reference is fixed as
>> >the hash of the document, which precludes other types of request
>> >references that may include additional information (e.g. authorization
>> >assertions etc). Granted these can also be found by indexing of the hash
>> >value. If we take this approach, can we include some kind of an
>> ><OptionalInput> element to indicate that this is a retrieval request
>> >rather than a new request?
>>We could also let the server infer it (it would check if the request
>>matches any pending request).  Either way seems doable.
>>
>>[...]
>> >[Pieter Kasselman]  OK, so lets go for the small token (such as using the
>> >DocumentHash) and see how we can fit it into the exisiting framework :).
>>
>>Sure.  My 2 objections were to:
>>   - signature "successes" that don't return a signature
>>   - sending requests with no input documents
>>
>>So using a special failure value ("TryAgainLater" or something) instead of
>>"Success", and using a re-submitted <DocumentHash> instead of
>><RequestReference>, eliminates those issues.
>>
>>I guess we should discuss whether the "TryAgainLater" value should be
>>defined in the core document or not.  It seems okay to put it in the core
>>now, since it's fairly generic.  Though maybe we don't want to tweak the
>>core at this late date.    In which case we could do it as a ResultMinor
>>code for ResultMajor=ResponderError, or something.
>>
>>Trevor