- From: John Boyer <jboyer@PureEdge.com>
- Date: Tue, 6 Jun 2000 15:05:50 -0700
- To: "John Cowan" <cowan@locke.ccil.org>, "David Blondeau" <blondeau@intalio.com>
- Cc: "Joseph M. Reagle Jr." <reagle@w3.org>, <w3c-ietf-xmldsig@w3.org>, "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Actually, the limitations of the XPath model should not necessarily be a limitation of c14n, especially in such a simple case. For starters, the current goal is to have a consistent way of writing XML 1.0, so for this version we could simply render the root node as <?xml version="1.0"?>#xA rather than producing nothing as the result of the root node. 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. 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. This seeming need for a character encoding function hook actually leads one to a solution that might be more appropriate for something like DSig. We need c14n to do things like canonicalize SignedInfo. If the SignedInfo is coming from an XML document with version > 1.0, we would like to know that, but the canonicalizer will only receive the SignedInfo text. Somehow, the version info either needs to be prepended to the SignedInfo, or the surrounding document's version must simply be known by "implementation-specific" means and provided to the canonicalizer as an additional parameter (we already provide the input and an optional XPath expression as parameters, so one more won't hurt). So, if c14n received a version string of "anything", it could render the following text for the root node of the node-set (if it is in the output node-set): <xml version="anything"?> Finally, as you can see, there are lots of options for solving this problem, and using XPath as a basis is not really causing a problem. In fact the only problem I do have is that the c14n issues list has not been provided to me, so the current version has not accounted for things like this because I didn't know about them. With respect to the issue above, what do people think is the best choice: A) ignore version B) use a version of 1.0 C) recover version from input document (kind of hard) D) parameterize version, with default of 1.0 Obviously I like the last one best, and thanks David for bringing this up again. John Boyer Software Development Manager PureEdge Solutions Inc. (formerly UWI.Com) Creating Binding E-Commerce jboyer@PureEdge.com -----Original Message----- From: John Cowan [mailto:cowan@locke.ccil.org] Sent: Tuesday, June 06, 2000 2:48 PM To: David Blondeau Cc: Joseph M. Reagle Jr.; w3c-ietf-xmldsig@w3.org; Donald E. Eastlake 3rd; John Boyer Subject: Re: Comment about C14N last draft On Tue, 6 Jun 2000, David Blondeau wrote: > The new draft specify that there is no XML declaration like the last c14n > draft of the Core WG (01/19). Naturally, since the new draft uses the XPath model, which has no place for the XML version. > Should a canonical XML document considered as an XML document and have an > XML declaration? Maybe, M Cowan could explain the position of the XML Core WG when they decided this? We basically felt it was a good idea with little cost. No explicit rationale for including the XML version number in Canonical XML was ever given, except in the public announcement: By encoding the XML version number in Canonical XML, we ensure that no confusion can result between documents that differ only in XML version number, and therefore potentially in significance. We wanted to make sure that two documents in different versions of XML could not be canonicalized to the same byte-for-byte representation, as their original forms might have had different interpretations. -- 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:06:05 UTC