RE: [dss] Finalizing core spec

[Paul Madsen <p.madsen@entrust.com>]

Hi Trevor

1) core 18 refers to both 'ServiceProfile' (line 463) and 'Profile'
attributes

2) Wrt to keeping the Profile attribute and using an <AdditionalProfile>
element for any profile designators beyond that, I would prefer a
symmetrical mechanism. Using an attribute for one profile and an element (in
another location) for others might suggest an unintended semantic to DSS
Servers, i.e. 'the value in the Profile attribute is the real profile and I
can probably ignore the others'. 

Separate but perhaps related, as far as I know, we discount the potential
for the DSS Server being able to indicate profile(s) on its Response. Is the
client simply expected to remember under what profile(s) the request was
sent and correlate the response approriately? Perhaps this is only relevant
for asynchronous interactions?

Thoughts?

Paul

>-----Original Message-----
>From: Trevor Perrin [mailto:trevp@trevp.net]
>Sent: Wednesday, April 14, 2004 2:52 PM
>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 
>
>
>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.