[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Core versus Extended Profile Handling
> Yes exactly. I had thought of that casually, but dismissed the concern > based on the assertion that if things start getting shared across > profiles, they belong in the core. This eliminates the multiple inheritance anomaly. Which requires the core to be uprev'd, complicating the existing deployments. <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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]