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] Core versus Extended Profile Handling


At 05:26 PM 11/5/2003 -0500, Edward Shallow wrote:

>As per minutes of Nov 3rd, here are the questions to kick off the thread on
>core versus extended profile handling.

my votes -



>Question 1
>**********
>
>There are 3 (perhaps more) general approaches to handling extensibility on
>the core. They are roughly described as follows.

I'm happy with having <Options> be a sequence of <xs:any>, and then using 
normative text in profiles to say which options are allowed.

But we could also do stricter schema-typing, if people want.



>Question 2
>**********
>
>As it pertains to core versus extended, should the core endevor to define
>optional elements that can or might be (re)used by extended profiles, or
>should this element definition be left to the profile implementor ? If yes,
>should the core also define any optional elements that would also be
>required (e.g. additional outputs).

yes - the core should define common options/outputs that multiple profiles 
might find useful (like the current <KeySelector>, <IntendedAudience>, 
<ClaimedIdentity>, <SignatureTimestamp>/<ContentTimestamp>, etc..).


>Question 3
>**********
>
>Should DSS implementors be obliged to support all core operations and
>options designated as mandatory, or should DSS conformance be more loosely
>defined, if at all ? Should there be any "branding" or PlugTests to receive
>such an "OASIS DSS-compliant" branding or "seal of conformance" ?


I think every DSS server should accept <InputDocument>s and return a 
<Signature> for signing, similarly accept a <Signature> and return a 
<Result> for verifying.  Aside from that basic functionality, it should be 
left up to profiles to determine which <Options>/<Outputs> are supported.

So as far as a "seal of conformance" goes, I think that would be for 
conformance to a profile, not to DSS itself.  However, profiles would have 
a lot of commonality, hopefully - so that a client implementation of the 
DSS core should be easy to make conformant with a lot of different profiles.



Trevor








>
>
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster of 
>the OASIS TC), go to 
>http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php.



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