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

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