W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Typos and implications in WD-xml-c14n-20000613

From: Doug Bunting <Doug@ariba.com>
Date: Sun, 2 Jul 2000 16:48:08 -0400 (EDT)
Message-ID: <BD93B9BF6CDBD3119494009027F43CB4F5E273@us-mtvmail1.ariba.com>
To: "'jboyer@PureEdge.com'" <jboyer@PureEdge.com>
Cc: "'w3c-ietf-xmldsig@w3.org'" <w3c-ietf-xmldsig@w3.org>
I noticed the following in the latest Canonical XML draft:

*	In the Status of this Document section, the parenthetical comment in
the second paragraph should read "(and any other issues)" not "(any any
other issues)".
*	In Section 2, the paragraph reading "An element has attribute nodes
to represent the non-namespace attribute declarations appearing in its start
tag as well as nodes to represent default attributes that were not specified
and not declared as #implied." implies the legality of an attribute
declaration such as <!ATTLIST form method CDATA #IMPLIED "POST">.  This is
not legal according to section 3.3.2 of the XML Recommendation.  "Default
attributes" must be either declared as #FIXED or simply with an attribute
*	The following paragraph would read better as "... retain sufficient
information ..." instead of "... retain the sufficient information ..."
*	In Section 5, the second-to-last paragraph contains an extraneous
*	In A.2, both Proof paragraphs are followed by "[]" which seem

Of slightly greater importance, the distinction between serialising an XML
document in consistent character encodings and avoiding character encoding
normalization isn't made clear by this document.  When creating a file or
character stream containing the serialization of a Canonical XML document,
the draft implies but does not explicitly state that UTF-8 should be used.
It may assist those not using an XPath processor when creating Canonical XML
documents if you made clear some implications of your chosen system.  For
example, entities (including character entities other than &#9, &#A and &#D)
would not appear in a Canonical XML document.
Leaving the inclusion of comment nodes up to implementators leads to two
possible Canonical forms of the same document.  Either recommend one or the
other, remove the ambiguity or define a processing instruction (or other
method) such that the source of a signed document could let the recipient
know which approach was chosen when generating the signature.  The default
exclusion is not sufficiently constrained (it implies comments could be
included by "flipping a switch").  A potentially sufficient improvement
would be to state "In the absence of an explicit XPath which includes
comment nodes, comments are not included in the Canonical form."
Doug Bunting
cXML Standards Manager
Ariba, Inc.
Received on Wednesday, 5 July 2000 10:29:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:34 UTC