RE: [dss] RE: ProcessingOptions example and discussion

[Trevor Perrin <trevp@trevp.net>]

At 10:07 AM 9/4/2003 -0400, Edward Shallow wrote:

>Not all of them. I agree with Trevor that 3) and 4) are more workable. 1)
>and 2) are out of the question.
>
>In general, how a DSS implementation processes internally should be kept
>from the user as much as possible. I believe 4) does this best. One is
>typically performing a basic operation say "sign" ... applying a timestamp
>is an adjunct activity. The primary verb is the sign, the request to have it
>timestamped is a "ProcessingOption" or an "Options" sub-category as
>suggested by Juan-Carlos.
>
>I guess I am agreeing with Trevor in that we should not hold up compound
>operations as a notion deserving of it's own construct. It is simply the
>impact of a particular "ProcessingOption". I believe we should allow
>anything in the "ProcessingOptions" enumeration that makes sense from a
>requester's standpoint. Simple booleans which fall into "Options" categories
>will do the job.

I agree with the above, at least wrt Sign-then-Timestamp: this can be done 
through the Signing protocol, as a boolean option or as part of a server's 
default behavior.



>Please review my schema snippet.
>
>I really only like 4) if 3) means things like SignAndTimeStamp, or
>VerifyAndUpdate, etc ...
>
>I can't see any example where the prime objective of the request does not
>fall into one of our core protocol operations.

What about VerifyAndUpdate?  Aka 
"VerifyThen[Sign/Timestamp/Refresh/whatever]".  Does it fall into the 
"Sign" or "Verify" core protocol, or is it a fusion of both?  To me, this 
is the big question..

I would be happy to table this question until we've fleshed out the Signing 
and Verifying protocols.

Are there other Compound Operations we need to consider?  Or would you 
agree that all compound operations are "adjunct activities" to the Signing 
and Verifying Protocols, except for Updating, which we're not sure about yet?


Trevor