[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Core versus Extended Profile Handling
Rich, I'm not sure I see the "feature-mixing" problem. Sorry. Perhaps an example would help. If an additional option in a new profile requires an additional request type and an additonal response type ... no problem. If a profile requires several new features, presumably driven by new options on our primitives, then either existing, extensions on existing, or entirely new type structures must be introduced to support the new features. Each profile extends only the core. The problem with choice and any structures is that we just scratch the surface with a handful of hopefully useful constructs. Implementors are still left with the challenge of extending the schema in some other way. XMLDSIG is not faced with that dilemna, as it tends to simply gets used rather than extended. Witness the way it itself is leveraged (not really extended) by things like ETSI (which looks more like the combo approach I described in "C") and WS-Security. Ed -----Original Message----- From: Rich Salz [mailto:rsalz@datapower.com] Sent: November 5, 2003 9:57 PM To: Edward Shallow Cc: dss@lists.oasis-open.org Subject: Re: [dss] Core versus Extended Profile Handling Q1: Extensibility The problem I see with A (extend base class) is that it does not allow for feature-mixing: how can I write a profile C that uses features A and B? It also makes fallback and error diagnosis hard; a DSS server that is sent a profile it doesn't understand will just see some random uri/element combination, and can't respond with a useful fault "I don't understand foo:bar option" I like B because it is what XML DSIG uses. Since we are defining a "remote access" or something that generates DSIG (yes, and perhaps more), it seems like a no-brainer to follow their style. C has the same problems as A, but is done in a implementation style. Q2: Should core define some things that might be useful but are optional (Did I summarize that right?) I'm neutral. DSIG defined things that folks might find useful, but they haven't gotten widespread use. If there's something completely obvious, then I would feel most comfortable putting it in a non-normative appendix. Q3: How define conformance The trend seems to be to follow the IETF MUST/MAY/SHOULD model (see http://www.ietf.org/rfc/rfc2119.txt). I can't see any reason not to follow that model. As for branding, testing, etc., I think we should either have a separate conformance TC (as with XSLT, for example), or hope we're useful enough that WS-I does it. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]