the four (rather one) last remaining open issue

Hi,

After going thru the issues document, we have four open ones than can be
folded to a single one: changing the part-1 [102] paragraph.

Matt proposed a new text. We need to have consensus on the wording and on
making the change. Could I have your feedback ASAP? If there's no
consensus, I will then propose to postpone this change and solve it thru
errata after further discussion unless someone objects. 
It would be better to do it without errata.

The hurry is that we need to close those issues, get the Director's
decision and, if all is OK, we'll have a publication as a rec. soon.

You'll find here below a summary of the discussion.

Useful links:

Editor's draft for the XKMS spec:

 http://www.w3.org/2001/XKMS/Drafts/XKMS-REC-DRAFT/REC-DRAFT-xkms-part-1.html
 http://www.w3.org/2001/XKMS/Drafts/XKMS-REC-DRAFT/REC-DRAFT-xkms-part-2.html

PR issues with links to the discussion threads:

 http://www.w3.org/2001/XKMS/Drafts/pr-issues/issues.html

Thanks!

-jose

-----------------
1. XKMS Schema changes:

341-ml: Inconsistent definition of RespondWith element usage with
RequestAbstractType
343-ml: RequestAbstractType and optional "RespondWith" elements

(343-ml seems to be an extension of 341-ml)

The proposed action here is to just document the schema changes in the
issues list (as it's too late for them right now) and go thru a text 
change in [102] (here below in 2.).

Matt's proposal:

<quote>
(1)  Remove the RespondWith element from RequestAbstractType.

(2) Define a new abstract type RequestWithAbstractType that extends
the RequestAbstractType and add the RespondWith element as
(one unbounded) to extended type. (schema changes proposed in 341-ml)

(3) Extend the following request types by RequestWithAbstractType
LocateRequest, ValidateRequest, RegisterRequest, ReissueRequest,
RevokeRequest, RecoverRequest (no schema changes proposal in 343-ml) 

Justification:

(1) Clearly defines which request types encode and require RespondWith
elements and which request types do not.

(2) Removes the optional RespondWith element from request types that
must not encode RespondWith elements.
(3) Defines request types that must encode RespondWith elements must
use one or more.
(4) Should not break any current implementations.
(5) Allows the specification clearly state processing rules concerning
RespondWith by not having to deal with the optional issue in the
current schema.

</quote>

2. Rewriting of part-1 p. [102] 
340-ml: Namespaces inclusions
344-ml: Use of terms, RFC[2110], clarity in Sec. 3.2.3[102]

It seems that changing the text was OK, but there was no agreement yet
on whether to use MUST or SHOULD or MAY in 
  
<quote>
  <RespondWith> element MUST be ...
</quote>

and

<quote>
  ... MUST fault ...
</quote>

Original text:
<quote>
The <RespondWith> element in the request specifies one or more strings
included in the request that specify data elements to be provided in
the <ds:Keyinfo> element of the response. Each string is a single
identifier corresponding to a sub-element of the XML Signature
Specification [XML-SIG] <ds:Keyinfo> element; or the private key
information defined in the section Cryptographic Algorithm
Specific Parameters below. The XML Signature elements are described
here for convenience. The normative reference is the specification
[XML-SIG].  
</quote>

Matt's latest proposal:

(Matt,  what does (5). mean there)?

<quote>
[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].
</quote>