> [Pieter Kasselman] There is also discovery - a client may need to
> know what implicit choices were made (e.g. to determine why the result is
> different from separate servers/services).
I don't think it is very common that a client is going to connect, make a
request, and then say "how/why did you do that?" I think this can be put
into a "management protocol" that is not part of the core.
> [Pieter Kasselman] By providing a mechanism for parameter
> selection/parameter inspection we do not have to focus on which parameters
> are implicit or explicit or worry that for a certain type of service in a
> certain jurisdiction we are failing to communicate a vital parameter because
> we can not explicitly communicate that parameter. We may still allow certain
> parameters to be set explicitly elsewhere in the protocol, but we have a
> flexible mechanism for specifying additional parameters. WS-Policy, is just
> one way to express this, and we may simply opt for a URN or a similar
> pointer.
Yes. That is why (a) I proposed a general container framework with a
mustUnderstand attribute, and (b) I made everything either explicit or
set-by-server.
/r$
Make it --
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
