RE: [dss] Finalizing core spec

["Nick Pope" <pope@secstan.com>]

I suggest that we eventually produce a "roadmap" which describes the
different profiles and how they may be used together.

Nick

> -----Original Message-----
> From: Paul Madsen [mailto:p.madsen@entrust.com]
> Sent: 15 April 2004 13:22
> To: 'Nick Pope'; Trevor Perrin; dss@lists.oasis-open.org
> Subject: RE: [dss] Finalizing core spec
>
>
> Then I think we need to provide guidance that the two diffrent mechanisms
> should be used in this manner.
>
> Paul
>
> >-----Original Message-----
> >From: Nick Pope [mailto:pope@secstan.com]
> >Sent: Thursday, April 15, 2004 6:40 AM
> >To: Trevor Perrin; Paul Madsen; dss@lists.oasis-open.org
> >Subject: RE: [dss] Finalizing core spec
> >
> >
> >I agree with Trevor that they do not need to be symmetric.  I
> >would expect
> >there to be one profile which is tagetted at a verical
> >application, with
> >other horizonal additions to the core.
> >
> >Nick
> >
> >> -----Original Message-----
> >> From: Trevor Perrin [mailto:trevp@trevp.net]
> >> Sent: 14 April 2004 21:10
> >> To: Paul Madsen; dss@lists.oasis-open.org
> >> Subject: RE: [dss] Finalizing core spec
> >>
> >>
> >> At 03:19 PM 4/14/2004 -0400, Paul Madsen wrote:
> >> >Hi Trevor
> >> >
> >> >1) core 18 refers to both 'ServiceProfile' (line 463) and 'Profile'
> >> >attributes
> >>
> >> It'll be changed to 'Profile'.
> >>
> >>
> >> >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'.
> >>
> >> What I like about having a "main profile" is that it can guide the
> >> interpretation of the "additional profiles".
> >>
> >> For example, the main profile can say:
> >>   - no additional profiles are allowed
> >>   - these 3 addititional profiles are allowed: X, Y, Z, and
> >when they're
> >> active, this is how the combined profile should be interpreted
> >>
> >> Otherwise, if they're all symmetric, there's no ultimate
> >authority to say
> >> what the combined profile means.  Well, maybe that's the idea.
> >>
> >> I think it's still an open issue how exactly all this should work:
> >>   - Is there a main profile, or are they all equal?
> >>   - Should these be "optional inputs", or mandatory parts of the
> >> core protocol?
> >>
> >>
> >> >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?
> >>
> >> I guess we've been assuming the client can remember it.
> >Another argument
> >> for putting the 'Profile' in the response is that the client
> >may not have
> >> indicated a profile at all, or the server may have used a particular
> >> sub-profile of the indicated profile.
> >>
> >> It would be easy to add a 'Profile' attribute to the response,
> >> and probably
> >> a good idea.  Of course, if we do multiple-profiling, like
> >above, that'll
> >> affect this.
> >>
> >> 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_wor
> >kgroup.php.
> >
> >
> >
> >
>
> 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_wor
> kgroup.php.
>
>
>