[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]