> Right now the draft says: "All options must have some default value, so
> that a client may omit the <Options> element yet still get service from any
> DSS server."
Yeah, I was gonna ask about that. :) I understand the reasoning, but
it makes me feel a little uneasy. Suppose a server doesn't want to
sign without some kind of proof-of-posession kind of indicator. Can
the "service" it responds with be a Fault? Can we change that
MUST have a default to SHOULD?
> It depends on the previous issue, I think. My first choice is do all
> extensions as <Options>, and have them all (or at least mostly) be optional.
Perhaps we change the name to Specifiers or ProcessingOptions or
some such. But I don't think we need two containers: those that
have defaults and those that don't.
> I know making
> everything an Option limits what you can do as a profile designer - but if
> you can meet that constraint, the jobs of people using our stuff becomes
> much easier, cause they can count on a minimum of compatibility.
Exactly.
/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
