> a) several of the application profiles will use the same set of elements.
I would like to understand why this is a problem.
> b) We will get a multitude of documents.
See below.
> c) There several different places in which we would want to add extensions
I don't believe this is true.
> Is there a way that we can collect together some generally useful elements
> that we do not expect all implimentations to support but are applicable to
> several applications profiles into one or very few documents.
Yes. We could issue a "common extensions" document that defined a
handful of dss:Parameter elements for various things. The spec could
say if you support this element, then it must be with the semantics
defined here. You could then make an easy interop matrix that listed
the URI's of all the elements, and vendors and customers (and interop
testing) could make a check-list of the URI's that are supported.
> I am not sure what you mean by "standards profile" as apposed to application
> profile and how this relates to use of extensions
I mean things like the way WS-I says "only use doc/literal not
rpc/encoded for SOAP." Or the way IETF PKIX says how to use X.509.
It's where one document defines a "subset" (not strictly in the PKIX
case, perhaps) of another. That's a standards profile.
An application profile would be a URI embedded in each request that
indicates to the DSS server what behavior(s) the client wants. For
example, "urn:tpu.int:timestamp:1.0" could be the URI that clients send
if they want a postal-service timestamp.
Is that a better explanation?
/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
