[Issue 344-ml] Use of terms, RFC[2110], clarity in Sec. 3.2.3[102]

Hi Matt,

This is just a confirmation message for closing the decision cycle.

The comments you reported[1] were assigned issue id  344-ml[1].
Your suggestion was taken into account and the following changes
were added to the Editor's draft[2]:

<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 are 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.
</quote>

The "MUST fault" change was not taken into account as it is 
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.

Also note that Receiver.Failure defined in p. [127] already serves
this purpose. Moreover, there are many other parts in part-1. that
define the use of Receiver.Failure as such and none that mention
"fault".

Your "MUST fault if none" proposal will be documented in a To-Do list (in
addition to the issues list) so that it can be taken into account in
future revisions of the XKMS specification.

Please reply to this message if you have any objections.

[1] http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html#344-ml
[2]
http://www.w3.org/2001/XKMS/Drafts/XKMS-REC-DRAFT/REC-DRAFT-xkms-part-1.html

Thanks,

-jose

On Tue, Jun 21, 2005 at 07:04:01PM -0000, Matt Long wrote:
>  The following proposed text takes into account previous discussions.
> In general the semantics state:
> (1) Send one or more <RespondWith> with 'these' request types.
> (2) Receivers return what they can resolve and may add additional unrequested
> elements.
> (3) If the receiver cannot resolve any URI values and cannot return any
> additional unrequested elements, then fault the request.
> 
> I believe this is conforms to existing implementations.
> 
> 
> Proposed Text
> [102] The <RespondWith> element encoded in a request specifies one or more
> URI values that SHOULD resolve to data elements provided in either the
> [XML-SIG] <ds:KeyInfo> element or private key information defined in the
> section Cryptographic Algorithm Specific Parameters below. The
> <RespondWith> element SHOULD be encoded in requests of type LocateRequest,
> ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest,
> RecoverRequest.  The receiver SHOULD return any data elements that are
> resolvable <RespondWith> URI values and supported by the receiver and
> MAY return additional data elements not requested.  If the reciever
> cannot return any data elements the receiver MUST fault with
> [XKMS Bindings 3.4.2] (5).  The XML Signature elements are described
> here for convenience. The normative reference is the specification [XML-SIG].