Re: FW: Extensibility Sentence

[Trevor Perrin <trevp@trevp.net>]

At 04:47 PM 8/13/2003 -0400, Edward Shallow wrote:

>Hi Trevor,
>
>     As part of the process of closing off the requirements document, it was
>noted in the conference call of Aug 11th that the requirement on the subject
>of general extensibility and specifically "compound" or "stacked" operations
>be included in the text of the document so it may be closed.
>
>     Please refer to the suggested verbage below which I sent you and Nick
>last month. The invitation to tweak the sentence still stands.


I think the suggested text bears on several different parts of the 
Requirements Document.  I think some things are already covered in the 
document, and I'll suggest a few other things we could put in.


>     "Support for additional service options characterized by scenarios like
>Verify and TimeStamp should be provided for more generally as part of an
>overall "extensibility framework".

Protocol Extensibility is mentioned in 3.1.2, 3.11, and 3.11.1.  I'm not 
sure what the term "extensibility framework" means.  As long as you can add 
new elements to the requests and responses when profiling them, is that 
good enough?


>As such the introduction of various
>options or directives on core DSS service operations can be extended to
>support profile-specific requirements.

Does the discussion of profiles in 3.11 and 3.11.1 already cover this?


>  This "extensibility framework" should
>be designed to support the notion of compound or stacked operations typified
>by the Verify and TimeStamp scenario as well as the more common notions of

I assume you're talking about requesting the server to Sign *and* 
TimeStamp, or Verify *and* Update?  This is a little confusing, because 
both Verify and TimeStamp are request/response protocols in their own 
right, they don't necessarily have to be stacked with other operations.

As far as the Sign and TimeStamp case, I like the idea of the client 
requesting a timestamp in the same fashion that the client requests other 
Signature Properties, i.e through SignatureOptions/UnsignedProperties in 
the current schema.  I could add a note in 3.5.6 to the effect that one 
type of signature property you can request is a timestamp.

As far as the Verify and Update case, this is mentioned briefly in 
3.9.  But it seems like we're not yet sure how to handle this, so I'm 
hesitant to say much else about it, like calling it a "compound" or 
"stacked" operation when it may just turn out to be a single operation.  I 
vaguely recall you were going to post some further discussion of this to 
the list?


>"selection of response elements"

what exactly is a response element?


>or "specification of signing attributes".

I think we cover this in 3.5.6.


Trevor