This page enumerates outstanding issues on the XML
Key Management Specification. The source of an issue need not be its first
instance; it also might reference a cogent description or WG poll. Also, this
document may not capture editorial tweaks and errors that were easily and
quickly remedied.
This page will contain two tables. Outstanding issues are recorded in
the first table. They are typed as either Editorial (including typos and
small clarifications), Clarification (where significant explanatory text
is required) or Major. In some cases, a volunteer has been
identified, but in case not, then implementation of the proposed resolution is
left to the specification editor(s). Once an issue has been resolved
(meaning that a resolution satisfactory to the group is agreed and has been
included in the latest version of the specification), the issue is moved to the
`Resolved Issues' table. The issue index number is maintained to allow for
consistent referencing.
New issues, and the resolution of issues should be reported to the XKMS
mailing list. Before doing so, ensure that the issue is not already covered
by an issue either in the "Outstanding Issues" table (in which case, a
new issue need not be entered) or in the "Resolved Issues" table (in
which case a new outstanding issue should be created, as opposed to moved from
resolved to outstanding). In addition, for newly discovered issues, the
discoverer should identify an related issues that may already be cited in either
table below.
Last Minute Issues
# |
Type & Source |
Specification Reference & Issue Description |
Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank) |
37 |
Editorial/ [ Sept 2002 F2F] |
[Part
I - 2002/08/01] [Part
II - 2002/08/01] The "Status of this Document" section needs to be brought up-to-date. |
Makes appropriate changes to this section at final draft (see also Issue 35). [ Sept 2002 F2F] |
39 |
Editorial/ [ Sept 2002 F2F] |
[Part
I - 2002/08/01] [Part
II - 2002/08/01] In paragraph [1], the glyphs for (C) and TM are missing. |
Add appropriate glyphs. [ Sept 2002 F2F] |
17 |
Clarification/ [ Sept 2002 F2F] |
[Part
I - 2002/08/01] [Part
II - 2002/08/01] The specification should be validated against the requirements [XKMS Requirements]. |
Ensure that this validation is performed
prior to moving through Working Group Last Call. [ Sept
2002 F2F]. Frederick Hirsch |
Examples Issues
# |
Type & Source |
Specification Reference & Issue Description |
Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank) |
47 |
Clarification/ [ Sept 2002 F2F] |
[Part
I - 2002/08/01] [Part
II - 2002/08/01] Some remaining issues with examples, in particular the canonicalization of the signature block may be incorrect, the certificates presented bear no relation to the public keys allegedly certified. |
Make changes/updates as described. Brian
LaMacchia will provide some code for X.509 examples.[ Sept
2002 F2F] Phill Hallam-Baker, Brian LaMacchia |
Additional Issues Just added, mostly clarification requests at specified paragraph
# |
Type & Source |
Specification Reference & Issue Description |
Proposed Resolution Details (incl Date)& Volunteer (Specification editor(s) if blank) |
200 | Shivram http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0022.html |
As a reminder: Line 522 needs contents. ISSUE - CREATE |
DONE |
201 | Shivram http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0022.html |
Line 90 /Section 4.6 still needs work | |
202 | Shivram http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0022.html |
Also add in a section on "Versions,
Namespaces URIs, and Identifiers" as in the dsig and xenc core specs. |
DONE |
203 | Reagle http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0027.html |
[41]XKMS supports two processing modes,
synchronous processing and asynchronous processing. |
|
204 | Reagle http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0027.html |
[78]
The example in 3.1 still doesn't reflect if in fact that things are QNAMEs yet. |
|
205 | Reagle http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0027.html |
[94] I don't understand, are the ResultMinor
Codes, QNAMEs? If so, are they expect to be composed with a ResultMajor code? If so, I wouldn't think the code is "Success.NoMatch" but a QNAME tuple (xkms:Success,xkms:NoMatch) or some composition "xkms:Success.NoMatch". |
?? Looks OK to me ?? explanation required, check consistency |
206 |
Frederick
|
[159][163] ISSUE [159],[163]
Why is SOAP role used for XKMS application? Shouldn't this be the XKMS
service URI for XKMS |
|
207 |
Frederick
|
190 presumably using UseKeyWith for policy will imply a different application URI/Identifier than those listed. |
DONE |
208 |
Frederick
|
448 in the compliance
table, is "no security" recommended for operations other |
DONE |
209 |
Frederick
|
103-106 [103] Sentence incomplete, probably
should say "is used to obtain the status of a pending request." |
|
210 | Frederick http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0024.html |
PT2 [90] ISSUE Compound
request example TBS - not sure it is needed given part 1 text. |
|
211 | Frederick http://lists.w3.org/Archives/Public/www-xkms/2003Feb/0025.html |
[Section 4]DISCUSS
Not a biggie, but I really would like to discuss it
before such a major change.
|
will do |
212 | Shivram http://lists.w3.org/Archives/Public/www-xkms/2003Mar/0008.html | [190,318]DISCUSS |