Comments on 20030213 Part I

Phill,

Some comments on the latest draft.

   This version:
   http://www.w3c.org/2001/XKMS/Drafts/XKMS20030212/xkms-part-1.html
   XML Key Management Specification (XKMS 2.0) Part I: Schema
   W3C Editors Copy 13th February 2003

  1.2 Definition of Terms

   [16]The following terms are used within this document with the
   particular meaning indicated below:
   
I don't think it's ready yet, but the WS glossary might be of use in the 
future. (Or maybe we should point them at our own definitions?)
  http://www.w3.org/TR/2002/WD-ws-gloss-20021114/#webservice
  

   [39]The means by which the service specifies protocol options which it
   accepts is outside the scope of this document. If the policy mechanism
   uses URI based identifiers for this purpose the following identifiers
   SHOULD be used:

I wouldn't call this a "policy mechanism" but a "service description 
mechanism" since that seems to be the intent (for the URIs to be used with 
WSDL) and avoids the "policy URI" discussion.


   [41]XKMS supports two processing modes, synchronous processing and
   asynchronous processing.

I found these definitions confusing ("channel" is undefined) and proposed 
alternative text that I though you found acceptable but aren't included 
yet:
  http://lists.w3.org/Archives/Public/www-xkms/2002Dec/0085.html

  2.5 Compound Requests and Responses

I'm glad we have this section and think it is improving but I can't say I 
confidently understand the inter-relationship between the two-phase, 
asynchronous, and compound requests yet on the basis of the prose. Maybe a 
little table/diagram of some sort would be helpful...?

   [66]The <MessageExtension> element is an abstract element of the
   abstract type MessageExtensionAbstractType. Implementations may define
   subclasses of the MessageExtensionAbstractType to define message
   extension elements that may be applied to any XKMS message.

Editorial: in some places element type names are in <code/> elements, in 
others' they are not.

   [78] RespondWith values are specified as QNames, the following
   identifiers are defined:
   Identifier <ds:Keyinfo> Element Description
   xkms:KeyName <ds:KeyName> Key Name
   ...

The example in 3.1 still doesn't reflect if in fact that things are QNAMEs 
yet.

   [94]The following ResultMinor codes are defined:
   Code Possible Major Codes Description
   xkms:NoMatch No match was found for the search prototype provided.
   Success The result code Success.NoMatch indicates that the service is
   authoritative for the search prototype specified and that the service
   positively asserts that no matches exist.

I don't understand, are the ResultMinor Codes, QNAMEs? If so, are they 
expect to be composed with a ResultMajor code? If so, I wouldn't think the 
code is "Success.NoMatch" but a QNAME tuple (xkms:Success,xkms:NoMatch) or 
some composition "xkms:Success.NoMatch".

   [95]The <RequestSignatureValue> element provides a cryptographic
   linkage between the request and the response.

"RequestSignatureValue" can be mistakenly read as an actual request for a 
Signature from the service, instead of the SignatureValue corresponding to 
the Request. If we can't think of a less confusing name 
(<SignatureValueOfRequest>?) we should at least point out at the start that 
this is not a request.

   [140]A Key Binding asserts a binding between data elements that relate
   to a public key including the <ds:KeyName>, <ds:KeyValue> and
   <ds:X509Data> components contained in a <ds:KeyInfo> element.
   Furthermore, the Service represents to the client accessing the
   service and in the absence of specific undertakings to the contrary to
   that client alone that the binding between the data elements is valid
   under whatever trust policy the service offers to that client.

I don't know what "the absense of specific undertakings to the contrary" 
means and it sounds like legalize. Could we just remove that term?

   [211]The <UnverifiedKeyBinding> element is derived from the
   KeyBindingAbstractType. It describes a key binding but makes no
   assertion regarding the status of the key binding.

This is intended to be use only with Locate, right? If not, what does it 
mean in the context of a Validate request. (If so, perhaps we could add a 
sentence here to that effect.)

   [381]The section describes features and operations that XKMS
   applications whose support is either required or recommended to ensure
   interoperability of XKMS services.

"This section".

     * [384] sent by by another

"by"

     * [386]If support for a feature is specified as OPTIONAL, XKMS
       implementations SHOULD NOT send messages requiring support for a
       feature.

"support for that feature."
BTW: This OPTIONAL = SHOULD NOT was counteruntuitive at first but as I 
continue to test it in my reading of the specification it seems to make 
sense...

   [431]Two-Phase Request
   [433]RECOMMENDED+
   [434]Clients SHOULD support use of the two phase request protocol.

As you did in Asynchronous response, could you provide a small explaination 
of the dependency that makes this a '+'?

Received on Friday, 21 February 2003 15:29:44 UTC