OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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
>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 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]