Re: [dss] FW: ProcessingOptions example and discussion

[Trevor Perrin <trevp@trevp.net>]

Hi Ed, Nick, all -

I just got back from vacation, I'll be responding to old messages for a 
while...

At 05:47 PM 8/18/2003 +0100, Nick Pope wrote:

>Forwarding on behalf of Ed:
>
>
>
>   Based partly on Trevor's feedback on the timestamp types post, as well as
>the need to start getting down to examples, here is a mock-up of how to take
>advantage of the ProcessingOptions request structure. I will follow this up
>(soon I hope) with some response structure samples that get impacted.
>Additonally I have shown how it might be extended for the EPM profile.
>Please treat as a sample for now, and not an official EPM profile
>submission.

The things in EPMProcessingOptionsType could be generally useful.  Do you 
or anyone else think they should go in core, or are you happy with leaving 
them as extensions that would go in an EPM "protocol profile"?

For your core suggestion -

><xs:element name="ProcessingOptions" type="ProcessingOptionsType"
>minOccurs="1"/>
>
><!-- This is the base type upon which core is built -->
>
><xs:complexType name="ProcessingOptionsType">
>   <xs:sequence>
>
>         <xs:element name="UtilizeDefaults" type="xs:boolean" minOccurs="0"/>
><!-- explicitly stated, mutually exclusive with all other options -->
>
>         <xs:element name="IncludeContentTimeStamp" type="xs:boolean"
>minOccurs="0"/>    <!-- PKCS7/CMS and XML -->
>         <xs:element name="IncludeSignatureTimeStamp" type="xs:boolean"
>minOccurs="0"/>  <!-- XML only, essentially an XAdES-T -->
>           ...  <!-- could be more, TBD -->
>   <xs:sequence
></xs:complexType>

Could we leave out "UtilizeDefaults", and say that an empty 
"ProcessingOptions" implies it?

As for IncludeContentTimeStamp / IncludeSignatureTimeStamp, are your 
comments correct? - in RFC 3126 section 4.1.1, which is based on ETSI TS 
101 733, you can have a PKCS7 signature time-stamp.  So I think your 2 
types of time-stamps would apply to both CMS and XML.

I earlier suggested that whether a timestamp was included, and what type, 
could be part of the Application Profile, or an Implicit Parameter of the 
server.  I still prefer implicitness to explicitness here.

One criteria for when to be explict vs. implicit is: if client would use 
the same parameter value in every request they issue to a particular 
server, the parameter should be made implicit.  This is like loop 
optimization: you hoist invariants out of the loop and only leave things 
that are going to change each iteration.  I tend to think a client would 
either always want a time-stamp, or always not want one, and wouldn't 
change on a per-request basis.

Another criteria is: implicit = less work, and it's easier to add things in 
once it becomes apparent they're needed, then take them away.  So we should 
be sparing in what we put in.

But if we do want clients to request timestamps, could we just have a 
single "IncludeTimeStamp", with the type of the time-stamp implicitly 
determined?


Trevor