Comments on XKMS Last Call Draft

Hello Phill,
 
Here are some comments on XKMS docs
 
 Main Document

1.	Section 2, paragraph 43, two codes "Sender" and "Receiver" may make more sense if changed to "Requester" and "Responder". In any request/response protocol, where you have two messages, Receiver and Sender do not indicate the appropriate system entities. Requester and Responder make more sense. 
2.	Section 2.4, paragraph 51, 52, "ResponseMechanism" should have "Pending" instead of "Asynchronous".
3.	Section 2.4.1, "RespondWith values Represent and/or Asynchronous MAY be specified'. It should be ResponseMechanism and even then how can ResponseMechanism be set to Asynchronous in synchronous processing?
4.	Section 2.5, PendingRequest is sent after the arrival of Notification. But if the requester sends PendingRequest even if Notification has not arrived, what should be the response?
5.	Section 2.5.1, "RespondWith value Asynchronous MUST be specified" should be changed to "ResponseMechanism value Pending MUST be specified". Same should be reflected in Section 2.5.3.1 example.
6.	Section 2.5.3.5, 'RequestID' value should be '#I4294d3993de300c1ef54d49bd0903b2d".
7.	Section 2.6, in the differences between asynchronous processing and two phase request protocol, it is not pointed out clearly that while asynchronous processing is mandatory (once it is specified by request RespondWith) whereas two phase request protocol usage is the discretion of responder.
8.	Section 2.6.2, document specifies one method of nonce construction. Is it mandatory to use this method? Paragraph 68 does not suggest that.
9.	Section 2.8, paragraph 76, "Web Service" mention is unclear here. Till now, all the services are XKMS services. Does it mean that only web services can handle compound requests?
10.	Section 3.2.4, for Mechanism attribute, "A URI that specifies the protocol by which the notification is made". <PendingNotification> is a part of <RequestAbstractType> so it is going to be used by requester. And requester is not using Mechanism attribute, it is merely specifying it. In my opinion, "A URI that specifies the protocol by which the notification CAN BE made" seems more appropriate.
11.	OriginalRequestId (RequestAbstractType), RespondID (PendingRequest) , RequestId (ResultType) should be of type "xsd:NCName" as they are referring to "xsd:ID" type elements in other XML docs.
12.	Section 3.3.2, paragraph 124, "The corresponding request was not authenticated, or..." does it mean that ResultMajor.ResultMinor is Sender.NoAuthentication? If yes, then this probably is more concrete wording.
13.	Section 3.4.1, CompoundRequest can have multiple requests of the same type. Although this is clear from the schema definition, it would be better if some text can be provided to indicate that. Besides that there is no clear reasoning given for that.
14.	Section 5.1.3, paragraph 178. UseKeyWith specifies subject identifier and application identifier but the corresponding attributes (Identifier and Application) do not seem consistent. Probably attributes like Subject and Application; or SubjectIdentifier and ApplicationIdentifier seem more appropriate.

Bindings Document

1.	Section 3.1, can we have some other XML elements besides XKMS content inside Body element? Document does not say anything about that.
2.	In the SOAP Faults section, error codes are "env:Receiver" and "env:Sender". In any request/response protocol, where you have two messages, Receiver and Sender do not indicate the appropriate system entities. Requester and Responder make more sense. So probably "env:Requester" and "env:Responder" seem little bit better.
3.	Section 4, "This specification describes three principal security bindings...". I can see two, Payload Authentication Binding and SSL/TLS Security Binding. Where is the third one?

Thanks,
Dipak Chopra 
Technology Architecture Group, 
SAP Labs, Palo Alto