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

Re: Error in merlin-iaikTests-two.tar.gz?

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 23 May 2002 17:39:47 -0400
To: merlin <merlin@baltimore.ie>, Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: Gregor Karlinger <gregor.karlinger@iaik.at>, w3c-ietf-xmldsig@w3.org, jboyer@PureEdge.com
Message-Id: <20020523213948.67E58859F4@aeon.w3.org>
On Thursday 23 May 2002 10:23, merlin wrote:
> I believe you're right. I think it's just a small oversight in
> the spec that we'll have to live with. Exclusive c14n doesn't
> seem to have this feature.

Right, I think this is the same bug (the spec is clear, just 
counter-intuitive so implemented incorrectly) I had to correct last month. 

However, I also discovered a bug from Gregor's example 1 [a]. Presently,
c14n.py does the following:
1. takes any xml_attrs (e.g., xml:lang) from previous recursions not
rendered and adds them to local xml_attrs.
2. if the element we are processing is in the subset, it renders the
accumulated xml_attrs as part of that element and and resets xml_attrs=[]
3. it recurses. 

This has the effect of rendering all XML attributes that are "in affect" 
since the last ancestor was rendered. Sounds sensible, but it's not correct 
according to the the spec [b]. To fix this, I think we'd have to test 
whether the immediate parent was in the nodeset and keep a dictionary 
(instead of a list) of *all* ancestors' xml:foo attributes (not just since 
the nearest rendered one), with the *nearest* value. (Moving from a list to 
a dictionary is akin to what I did for the namespace bug.) This bug exists 
in c14n, not exc-c14n.
Received on Thursday, 23 May 2002 17:40:23 UTC

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