[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] RE: ProcessingOptions example and discussion
Colleagues - OK. Let's get a list of compound operations before we decide how to deal with them. If there are three primitives (V,S & T) and if it is not valid to repeat an operation and if it makes no sense to do V anywhere but as the first operation, then there are four possible dual-operations and two possible triple-operations (see below). I don't think it makes sense for us to say which of these are invalid: someone may one day want to do any one of them. We should simply provide the framework in which one could do any one of them. All the best. Tim. Here they are ... VS, VT, ST, TS, VST, VTS. This list omits archival (and other things) because they are outside the scope of our charter. -----Original Message----- From: Trevor Perrin [mailto:trevp@trevp.net] Sent: Tuesday, September 02, 2003 1:51 PM To: Tim Moses; 'Nick Pope'; OASIS DSS TC Cc: Ed Shallow Subject: RE: [dss] RE: ProcessingOptions example and discussion At 10:39 AM 9/2/2003 -0400, Tim Moses wrote: >Colleagues - Forgive me if I have missed a step in this discussion. But, for >my part, I would like to see an enumeration of all anticipated compound >operations, That would be a big step forward. The compound operations I see are: - sign-with-timestamp - verify-then-sign (i.e. "update" or "refresh") Do we want to support others? There was a little talk at the f2f of doing multiple signatures or verifications in a single request/response, but I think we decided against that. >an enumeration of the technical options for supporting compound >operations and a discussion of the pros and cons of each approach. > >Without giving it too much thought, it seems to me that there are at least >four possible approaches ... > >1. All operations are atomic. Compound operations are built by clients >making multiple calls to different services. Some technique for linking the >output of one operation to the input of the next would have to be defined. > >2. Request messages can be concatenated, with an option to indicate that the >input token in one request is to be the output token from the previous >request. > >3. All operations (including compound ones) are identified by their own >request type identifier. We would define a few useful ones. Others could >define their own in profiles. Each compound-operation message should be >derived from the general message syntax defined in the core document. > >4. Compound operations are variants of our existing sign, timestamp and >verify request types. All variations in syntax would have to be captured in >the basic syntax. That's a good list. I'd like to first understand what compound operations are in scope, and then return to the list in deciding what mechanisms are needed. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]