Exclusive XML Canonicalization, Version 1.0
draft-ietf-xmldsig-xc14n-02

[Note]: 'The revised draft includes the changes requested by Randy Bush.  It is back on the agenda to confirm that there are no further concerns.' added by Amy Vezza

[Note]: 'The revised draft includes the changes requested by Randy Bush.  It is back on the agenda to confirm that there are no further concerns.' added by Russ Housley

[Note]: 'The revised draft includes the changes requested by Randy Bush.  It is back on the agenda to confirm that there are no further concerns.' added by Russ Housley

Randy Bush and Russ Housley have provided comments on this document.  The IESG will not approve the document for publication until these comments have been addressed.

This draft is the result of the deal worked out between Jeff Schiller and Joseph Reagle of the W3C.  The W3C had always claimed it was going to do XML security standards, but nothing happened until work in the IETF TRADE working group showed the need and obvious void. Don Eastlake organized a BoF, which in turn woke up the W3C and caused them to schedule a workshop weeks after the BoF.  The workshop was at MIT and Jeff Schiller attended, resulting in the creation of a unique joint IETF/W3C XMLDSIG WG with its documents to become standards in both organizations.

How will follow-up work on XML encryption and canonicalization be handled? Now that the XMLDSIG effort has created critical mass within W3C, the compromise was that follow-on XML security work, at least encryption and canonicalization, would happen with W3C procedures but the W3C documents would also be published as informational in the IETF. The thought was that this was just a mechanical process to make them more easily accessible to the IETF community.

Section 1.3.1 demands non-imported namespaces be redeclared at apex nodes, or in the interpreting context.  Alternatively, but maybe not deeply interestingly, they might be declared at orphans which are ancestors of all uses.  This is a reasonable, though minor criticism.  However, given the prior understand that this is just an Informational reprint of the W3C Recommendation. How should the IETF proceed? Ignore the issue? Include an IESG Note? Or change it so that it can no longer be said to be equivalent to the W3C document.  This is really a political question.  The decision was not to pursue this potential improvement.

Section 3.1.3.4 is missing the verb clause.  It is likely that of 3.1.3.3, i.e., render a default namespace declaration, xmlns="".  This is a typo introduced in HTML to ASCII conversion.  It will be fixed.

The Security Considerations statements seem semantically correct and complete.  Is the restriction in 5.2, esoteric cases, deserve a special case? Shouldn't this only happen when dealing with non-well-formed XML. 

The Security Considerations are trying to characterize the XML objects that might encounter difficulties.  No change is anticipated here.