W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > January to March 2002

Re: History: Question on C14N list of nodes instead of subtrees

From: Joseph Reagle <reagle@w3.org>
Date: Fri, 25 Jan 2002 13:16:40 -0500
Message-Id: <200201251816.NAA13493@tux.w3.org>
To: "John Boyer" <JBoyer@PureEdge.com>, "merlin" <merlin@baltimore.ie>
Cc: <w3c-ietf-xmldsig@w3.org>
On Friday 25 January 2002 11:44, John Boyer wrote:
> Joseph, do you have any opinion on the ability to tolerate a change at
> this point?

The question is a change in what? Canonical XML is already a REC and can't 
be changed. xmldsig will be a REC in a couple of weeks but that's been 
stable for so long it can't change either. My goal has been that exc-c14n 
be faster for subtree processing.

As an aside, Don and I had a exc-c14n -> CR review meeting yesterday and I 
still run into problems of people less familiar with the work assuming that 
there is such a thing as a one-and-only-one form of Canonical XML -- 
perhaps we should've call them serializations 1 2 and 3 <smile/>. 
Regardless, my goal is for exc-c14n to be faster with some implementation 
optimizations. (We've actually made this an exit criteria of the CR [1] -- 
and it reference Merlin's earliest speed tests on exc-c14n [2]).

For example, originally the python c14n *only* worked over a DOM node so 
that was good for sub-tree processing and we then worked on extending it to 
support XPath expression. If there is an XPath expression you have a hit on 
performing the XPath expression and walking the whole dom tree, checking 
each node (and building ancestor context) against the subset to see if it 
should be omitted. However, if you only passed it a single DOM element 
node (representing a sub-tree) it serializes that subtree and walks up its 
ancestors looking for xml:* attributes. My expectation/goal in exc-c14n is 
that you don't have to even walk up your ancestors since you don't care 
about that context. (Our implementation would fail at this -- I think -- 
because we don't have a proper XPath nodeset with namespace axis with the 
necessary ancestor context; they are treated as attributes. But an 
implementation with a proper namespace axis node need only serialize the 
subtree (doesn't care about ancestor xml:*, and if the namespace is 
utilized then the prefix/value is right there in that elements namespace 
axis node -- it need not look at ancestors at all!) So I think we're likely 
to end up with decent subtree c14n with exc-c14n.

It doesn't solve any performance problems with respect to arbitrary xpath 
filtering and I'm not sure if anything proposed in this thread would fix 
that ...? (I might've missed it, did you agree that Merlin's intersection 
expression would be better?) So it's to say hard to say how that would 
affect existing specs beyond, again, xmldsig is extensible so it could be 
done if necessary.

[1] http://www.w3.org/Signature/Drafts/xml-exc-c14n.html 
(see greyed out status)
[2] 
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2001JulSep/0108.html

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/
Received on Friday, 25 January 2002 13:16:49 GMT

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