Re: Canonical XML revision

Hi Rich,

Fair enough.  For the record, though, it sounds like you have the 
perspective of a dsig 
implementer rather than an XML document author.

In other words, the underbelly of the philosophical point is a set of 
technical problems.

Granted a new algorithm does mean that old software will fail to validate 
new signatures 
because the new c14n is unavailable, rather than failing to validate 
because an
xml:id was inherited during signing with an old engine but not during 
validation with 
a new engine.  The other cases are similar.

But the bottom line is that it is still a failure that will require the 
dsig implementer to solve
the impedance mismatch between sign and validate software *regardless* of 
which
approach we take.

It might be easier to detect and fix this particular IT problem, but it is 
more expensive
to XML document authors who will still be faced with "why doesn't my 
signature work"
problems because they keep forgetting to add the hack that fixes the fact 
that dsig 
doesn't really play nice with xml:id.

Point is, this isn't really a technical debate at all because both 
solutions fix the 
technical problem, so it seems prudent to pick a fix that causes the least 
pain. 
If sign and validate don't have the same algorithms available, you're 
going to 
get a signature failure of some kind in either case, so we can either fix 
the problem 
so that you get a failure AND document authors have to learn new 
techniques that 
have obscure reasons for being required (the new algorithm approach) or we 
can 
fix the problem so that no changes to document author collateral is 
required.

Cheers,
John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/





Rich Salz <rsalz@datapower.com> 
01/03/2006 12:07 PM

To
w3c-ietf-xmldsig@w3.org
cc
John Boyer/CanWest/IBM@IBMCA, Joseph Reagle <reagle@mit.edu>
Subject
Re: Canonical XML revision






John and I agree to disagree on this...

The arguments for issuing an errata and not a new xmlns seem 
philosophical: it follows the original intent.

The arguments for going the other way (creating a new algorithm) seem 
technical:  it will make interop problems easier to find and solve.

I cast my lot with Joseph. :)

                 /r$

-- 
SOA Appliance Group
IBM Application Integration Middleware
* This address is going away; please use rsalz@us.ibm.com *