Response to issues raised by Dipak Chopra

 
-----Original Message-----
From: Phill [mailto:phallam@comcast.net]
Sent: Wednesday, July 23, 2003 1:16 PM
To: 'Hallam-Baker, Phillip'; 'Socrates Gorilla (E-mail)'
Subject: RE: 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.   
 
The terms sender and reciever are defined in the SOAP protocol and refer to
messages and not protocols.
No Action.
 
 2 Section 2.4, paragraph 51, 52, "ResponseMechanism" should have "Pending"
instead of "Asynchronous".  
 
Fixed
 
 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?  
 
Fixed. 
The requestor may offer asynchronous processing, but the responder is not
obliged to honor this request.
 
 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?  
 
Fixed
If the service is not ready it simply returns pending again. This was
intentional to allow for polling as opposed to notification.
 
 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.  
 
Fixed
 
 6     Section 2.5.3.5, 'RequestID' value should be
'#I4294d3993de300c1ef54d49bd0903b2d".  
 
To do
 
 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.  
 
No, asynchronous processing is always an option. Fixed the text to make this
clearer
 
 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.  
 
It is open to implementors, the text has been fixed to make this clear.
 
 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?  
 
 Fixed
 
 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.  
 
Its a MAY, fixed
 
 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.  
 
Discuss.
 
 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.  
 
No. The constraint is correctly on the request, if there is no signature on
the request then there is no way to link it in the response. This is not the
same as no authentication which indicates a violation of the service
authentication policy. The lack of the signature in this case is simply a
logic error since the requestor is asking the service to return a data item
that was not provided.
 
 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.  
 
Fixed
 
 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. 
 
This would break existing applications without providing significant value.
No Change 
 
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. 
 
Discuss
 
 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.  
 
This is the SOAP spec.
 
 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? 
 
Fixed
 
Thanks,
Dipak Chopra 
Technology Architecture Group, 
SAP Labs, Palo Alto