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

Implicit Parsing and Serialization in New Processing Model

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Mon, 11 Sep 2000 18:55:05 -0400
Message-Id: <4.3.2.7.2.20000911185206.00b84188@rpcp.mit.edu>
To: "John Boyer" <jboyer@PureEdge.com>
Cc: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
John (and WG),

In your new processing model [a], some of the nodeset-to-octets and
octets-to-nodeset is implicit. However, what happens if these functions
change?

1. a new Canonical XML appears (nodeset-to-octets). If you want to make
sure that the old implicit method isn't used, you have to specify an
explicit transform? Will implementors have hard-wired the 1.0 such that
bugs will inevitably crop up?
2. a new XML appears (octets-to-nodeset). How will you signal that it
should be parse as XML2.0 and not XML1.0 . (This is mostly an argument
for symmetry as I expect the definitive answer will be in the instance's
declaration).

[a] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0419.html

The reason I ask this is I'm wondering if it's better to make the
following implicit transforms explicit and add a few characters but make
it clear in implementors mind that the signature spec is orthogonal to the C14N.

[1]  <Reference URI="foo.b64"> 
[2]    <Transforms>
[3]      <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64">
[4]      <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
[5]       <XPath xmlns:dsig="&dsig;">
[6]       not(ancestor-or-self::dsig:Signature)
[7]       </XPath>
[8]     </Transform>
[9]   </Transforms>

(Te following implicit/explicit relate to the line numbers above.)

[1] explicit:  octets (derference the URI)
[3] explicit: octets-to-octets (decode)
[4] implicit: octets-to-nodeset (parse)
[5] explicit: nodeset-to-nodeset (XPATH)
[5] implicit: nodeset-to-octets (serialize)

The version where all of the above is explicit designates both the XML parsing version
and canonicalization version follows:

[1]  <Reference URI="foo.b64"> 
[2]    <Transforms>
[3]      <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64">
[3A]    <Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-2e-20000814">
[4]      <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
[5]       <XPath xmlns:dsig="&dsig;">
[6]       not(ancestor-or-self::dsig:Signature)
[6A]     <Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000907">
[7]       </XPath>
[8]     </Transform>
[9]   </Transforms>

[3a] now explicit: Extensible Markup Language 2nd Edition
[6a] now explcit: Canonical XML 20000907

I'm not advocating this necessarily, just making sure we considered the
option. The only reason I raise this is I wanted the isse on the list and I'm slightly concerned about the potential of new versions or even errata being issued that affects no one but us and creating ambiguity in implementors' code. 

_________________________________________________________
Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Monday, 11 September 2000 18:55:08 GMT

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