RE: [dss] Core versus Extended Profile Handling

[<Frederick.Hirsch@nokia.com>]

Am I correct that DSS will not define an API but wire formats and processing rules?

regards, Frederick
 
Frederick Hirsch
Nokia Mobile Phones




> -----Original Message-----
> From: ext jmessing [mailto:jmessing@law-on-line.com]
> Sent: Saturday, November 08, 2003 12:12 PM
> To: Edward Shallow; 'Rich Salz'; Nick Pope
> Cc: dss@lists.oasis-open.org
> Subject: RE: [dss] Core versus Extended Profile Handling
> 
> 
> It seems from the descriptions that the DSS standard will be 
> an API that is divided by agreement into what is standardized 
> as core and thus not likely to be appropriated as claimed 
> proprietary patent or trade secret technology, and the 
> remainder which is not subject to that restriction as 
> profile, which can be open or not.
> 
> If that distinction is correct, then the inheritance 
> described by Nick between profiles could inadvertently create 
> a licensing requirement between A and B in order for the 
> inheritance to occur legally. Is that the kind of practical 
> consideration we want to factor into the work of the TC? 
> 
> ---------- Original Message ----------------------------------
> From: "Nick Pope" <pope@secstan.com>
> Date:  Sat, 8 Nov 2003 15:39:17 -0000
> 
> >Ed, Rich, Trevor,
> >
> >Catching up on this thread, there is one point that I would 
> like to add:
> >
> >If we find option/output elements that are common, or likely 
> to be common,
> >to several profiles before the DSS core is published, I 
> would suggest that
> >the schema definition of those option elements is placed 
> within the core
> >specification thereby maximising commonality.  I agree, 
> however, this should
> >not be mandated, and there will be situations where one 
> profile may inherit
> >an element from another profile's namespace.
> >
> >Nick
> >
> >...
> >
> >
> >
> ><ed>They don't get complicated until the implementation 
> decides it now wants
> >to be compliant with the uprev, which it is not obliged to do. </ed>
> >
> >Also, I don't believe that just because 'n' profiles want 
> the same element,
> >that the core must be changed.
> >
> ><ed>I agree, they can stay within the comfort of the profile
> >indefinitely.</ed>
> >
> >> Until then, the profiles can unofficially respect the 
> other published
> >> profiles as much and to the extent they can.
> >
> >If A wants to use B's profile, then A must define its own element and
> >include the set of (B-core) in A.
> >
> ><ed> And so ? If a B profile's features and capabilities are 
> so attractive,
> >they should be scoped into DSS from the beginning. If not, 
> they are simply
> >good examples of how to do things.</ed>
> >
> >It fits what X509 does, DSIG does, etc.
> >
> ><ed>Not a fair comparison, as I said earlier, DSS is a 
> request/response
> >protocol wedged in between a slew of existing 
> well-established content and
> >binding standards (i.e. XMLDSIG, PKCS7/CMS, SOAP) not to 
> mention all the
> >others we are treading so close to. Let's face it DSS is a 
> lot closer to the
> >implementation and consumption side of the spectrum than 
> something like a
> >signature layout standard. Staying nebulous will not help 
> with its take-up
> >and acceptance, which is really fundamentally addressing a 
> "How do I ask for
> >a signature ?" question and hence a "rubber meets the road" 
> challenge.</ed>
> >
> >
> >> My real motives for expressing things for explictly (and less
> >> nebulously) stems from a desire to reduce implementation 
> complexities for
> >our clients.
> >
> >Seems that having a single request, where additional 
> elements get stuffed is
> >a lot simpler than having to know about (several) different 
> namespaces for
> >different requests.
> >
> ><ed>It is not obligatory to know or follow or emulate 
> anything that stays in
> >the recesses of a profile.</ed>
> >
> >I understand your desire in making it simple to map this into native
> >object-model RPC.
> >
> ><ed>That is because that is all DSS is !!! A signature creation and
> >verification request mechanism.</ed>
> >
> >I don't share the desire.  Or rather, I see that as less 
> important than
> >getting a real extensible protocol specified.
> >
> ><ed>The thinness and therefore value of what is left is 
> scary to me.</ed>
> >
> >And implementations that want to do this can always write a 
> "custom" WSDL
> >that fills in some of the spaces in the Options element.
> >
> ><ed>I thought this was exactly what we were trying to make 
> easy ?</ed>
> >
> >I'll try to be productive in closing ...
> >
> >I believe DSS implementors must see value in what is 
> produced and shouldn't
> >be too constrained in how they salute and extend the spec.
> >I therefore vote for extensibility option "C", totally 
> separate schemas
> >which import and ref from the base dss schema and extend as 
> they chose.
> >Clearly there will be less divergence the more one "specifies" in a
> >non-nebulous way the details of the core.
> >Perhaps one can look at this as a compromise.
> >
> >Ed
> >
> >
> >
> >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/leav
e_workgroup.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_workgroup.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_workgroup.php.