RE: [dss] Core versus Extended Profile Handling

["Edward Shallow" <ed.shallow@rogers.com>]

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