W3C home > Mailing lists > Public > www-xkms@w3.org > September 2004

Re: Meeting reminder

From: Rich Salz <rsalz@datapower.com>
Date: Mon, 13 Sep 2004 15:14:09 -0400
Message-ID: <4145F181.9070006@datapower.com>
To: Shivaram Mysore <shivarammysore@yahoo.com>
CC: www-xkms@w3.org

Sorry for the delay; I tried to come back to work too soon.

I had an AI to propose spec changes that moved from qname's to anyURI.

The following places use qname:
        ResponseMechanism (sec 3.2.2)
        RespondWith (sec 3.2.3)
        ResultMajor (sec 3.3.1.1)
        ResultMinor (sec 3.3.1.1)
        KeyUsage (sec 5.1.2)
        KeyBindingStatus (or is it StatusValue or AssertionStatus?) (sec 
5.1.7)
        ValidReason, InvalidReason, IndeterminateReason (sec 5.1.8)

Of these, KeyUsage has the requirement that it cannot be an 
extensibility point, and that there is desire to enforce this through 
the schema definition.  The others are potential extensibility points, 
although the specification is inconsistent (perhaps deliberately so). 
That is, the following are defined as being of type xsd:QName, so that 
any legal qname is schema-valid
        ResponseMechanism
        RespondWith
        FaultMajor
        FaultMinor
        ValidReason, InvalidReason, IndeterminateReason
and the following are defined by a type derived by restriction from 
xsd:QName; that is, the allowed values are specified in the schema:
        KeyUsage
        KeyBindingStatus (StatusValue or AssertionStatus)

I propose that we replace all of the above QName types with anyURI. 
Since the URI's are only for identification, and need not be 
dereferencable, we can use the same URI that is used for the XKMS 
namespace; "http://www.w3.org/2003/03/xkms#" (yes, I know that will 
change when we go to CR).  We can define our qnames as URI fragments 
with the XKMS uri as the base.  That is, xkms:IssuerTrust becomes 
http://www.w3.org/2003/03/xkms#IssuserTrust

Second, for ResponseMechanism, RespondWith, FaultMajor, and FaultMinor, 
we add new type declarations that derive from anyURI and enumerate the 
values that are defined in the specification
       <simpleType name="ValidReasonType">
          <restriction base="anyURI">
            <enumeration value="http://www....xkms#IssuerTrust"/>
            <enumeration value="http://www....xkms#RevocationStatus"/>
            ...
            <enumeration value="http://www....xkms#Signature"/>
       </simpleType>

For items that we want to be extension points, we define the content as 
an XSD union of the new type and anyURI:
        <simpleType name="ValidReasonUnion">
          <union memberTypes="xkms:ValidReasonType anyURI"/>
        </simpleType>
        <element name="ValidReason" type="ValidReasonUnion"/>
For those that are not extension points, we don't define the union, and 
we make the type by xxxType.

Finally, we define that the behavior is undefined if any of the messages 
have a value that is not defined in the xxxType field.

Hoping this closes the (delayed) action item.
	/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
Received on Monday, 13 September 2004 19:11:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:22 GMT