Re: [dss] Core versus Extended Profile Handling

[Rich Salz <rsalz@datapower.com>]

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