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

RE: Comment about C14N last draft

From: John Cowan <cowan@locke.ccil.org>
Date: Tue, 6 Jun 2000 19:02:37 -0400 (EDT)
To: John Boyer <jboyer@PureEdge.com>
cc: David Blondeau <blondeau@intalio.com>, "Joseph M. Reagle Jr." <reagle@w3.org>, w3c-ietf-xmldsig@w3.org, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Message-ID: <Pine.BSI.3.95.1000606190002.27358A-100000@locke.ccil.org>
On Tue, 6 Jun 2000, John Boyer wrote:

>  This seems like a good idea since we really don't know what's coming
> in future versions of XML, so deciding how to canonicalize it now may not be
> appropriate.  For example, it could happen that neither infoset nor xpath
> have a data model that adequately captures the next version of XML.

I think this is exactly right.

> However, even if you want to preserve the XML version, the fact that c14n
> applies an xml processor to the input to produce a node-set does not change
> the fact that c14n *has* the input and can therefore recover the version,
> although an application function hook may be required to help with character
> encoding issues for non-UTF.  Also, the absense of a version should be
> construed as 1.0.

I don't think it's appropriate to plan a processing model for non-1.0
XML; we don't have any idea what parsers for it will look like, or
what styles of APIs they might expose.  Define Canonical XML for
XML 1.0 only, and generate a fixed XML declaration.
When XML is updated, time enough to update Canonical XML too.

> B) use a version of 1.0

Check.

-- 
John Cowan                                   cowan@ccil.org
	"You need a change: try Canada"  "You need a change: try China"
		--fortune cookies opened by a couple that I know
Received on Tuesday, 6 June 2000 18:44:45 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:09 GMT