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] Finalizing core spec


AdditionalProfiles as an OptionalInput is fine by me.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 14 April 2004 19:52
> To: Nick Pope; dss@lists.oasis-open.org
> Subject: RE: [dss] Finalizing core spec
>
>
> At 09:45 AM 4/14/2004 +0100, Nick Pope wrote:
> >[...]
> >This is a useful way of signalling the addition of horizontal functions.
> >For example, code signing with policy wise, or code signing with
> asynch, or
> >code signing with asynch and policy wise.  Clearly there will be some
> >combinations that do not make sense.  However, if someone wanted to do
> >something I think is stupid then I have no problem allowing him
> to do it (it
> >may even turn out to be not so stupid).  When defining a concrete profile
> >the other profiles that make sense to be used in combination can be
> >identified.  If it is not an "approved" combination then the
> "caveat emptor"
> >rule can apply.
> >
> >I suggest that we put in a warning in the Core that the results may be
> >unpredictable if there are conflicts between the profiles selected.
> >
> >It may make more sense to have "Profile" and "AdditionalProfile"
> as Elements
> >of the SignedRequest rather than attributes.
>
> Could we leave the 'Profile' attribute as-is, and add <AdditionalProfile>
> to '2.8 Common Optional Inputs'?
>
> This way, the "main profile" can choose whether it supports additional
> profiling?
>
>
>
> >BTW I noted an error that 2.8.1 refers to a ServiceProfile
> attribute whereas
> >3.1 and 4.1 use the attribute Profile.
>
> Yup.
>
>
> Trevor
>
>
>




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