Re: the four (rather one) last remaining open issue

Jose,

I'm in total agreement with you on this one.

Stephen.

(And sorry for not being around yesterday.)

Jose Kahan wrote:
> Matt, folks,
> 
> I started to make the change in p. 102 [1].
> 
> I slightly edited the text so that it says "Service", rather than
> "receiver", in conformance to the text below that paragraph. I also
> removed the first "encoded" as Rich suggested. There was a second
> "encoded" in:
> 
> <quote>
> ... The <RespondWith> element SHOULD be encoded in requests of type...
> </quote>
> 
> which I changed into "included".
> 
> I also noticed that p. 102 was duplicating parts of p. 103. I split them
> and completed p.103. Here's the latest version:
> 
> <quote>
> [102] The <RespondWith> element in a request specifies one or more URI
> values that SHOULD resolve to data elements provided in either the
> <ds:KeyInfo> element or private key information defined in the section
> Cryptographic Algorithm Specific Parameters below. The <RespondWith>
> element SHOULD be included in requests of type LocateRequest,
> ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest,
> RecoverRequest. The XML Signature elements are described here for
> convenience. The normative reference is the XML Digital Signature
> Specification [XML-SIG].
> 
> [103] The Service SHOULD return any data elements that are resolvable
> <RespondWith> URI values and that supported by the Service. The Service
> MAY return additional data elements not requested. In particular, the
> service MAY return data elements specified in the request with the
> response. If the Service cannot return any data elements, the Service MUST
> fault with [XKMS Bindings 3.4.2] (5). The XML Signature elements are
> described here for convenience.
> </quote>
> 
> I still have some questions in order to validate this change:
> 
> 1. Are people comfortable with my splitting it into two paragraphs (which
> is actually a small rewrite of both p.102 and p.103.
> 
> 2. Are people comfortable with the text? No objections? 
> 
> 3. Are people comfortable with the "MUST fault"? I'm not.
> 
> Where the changes proposed by Matt can be considered editorial ones on 
> p.102 and p.103, the "MUST fault" one seems to be one requesting a change
> in behaviour. Moreover, it doesn't take into account the HTTP bindings.
> Finally, the 3.4.1 (5) means that that the Server couldn't parse
> the XKMS message. This is not the case here. It could parse it, but
> couldn't find any pertinent information. It doesn't look like a good
> choice.
> 
> I think that Receiver.Failure defined in p. [127] already . Moreover, there
> are many other parts in part-1. that define the use of Receiver.Failure
> as such and none that mention "fault".
> 
> I'd prefer to remove all the "MOST fault" sentence. If Matt thinks
> it should still be there, I propsoe to change it as follows:
> 
> <quote>
> "If the service cannot return any pertinent data elements, the 
> Service MAY return the "Receive.Failure"  Result code."
> </quote>
> 
> I put MAY because I think that in some cases, the Service may return
> another error code if something else happens during the processing.
> "I couldn't return any results because I was busy" :) To avoid
> ambiguity the text in that sentence should be precise saying that it
> couldn't return any data elements, but otherwise the request processing
> was succesful. What I feel we would have needed is a different
> ResultMinor code for this case.
> 
> In all cases, I think it's better to not say anything and just remove
> this sentence.
> 
> Comments? (And please send them quickly or the [102, 103] change will 
> only be integrated in errata).
> 
> Thanks!
> 
> -jose

Received on Thursday, 23 June 2005 11:49:40 UTC