[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] FW: ProcessingOptions example and discussion
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]