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 19:13:31 -0500
Message-Id: <200201260013.TAA05295@tux.w3.org>
To: "John Boyer" <JBoyer@PureEdge.com>, "merlin" <merlin@baltimore.ie>
Cc: <w3c-ietf-xmldsig@w3.org>
On Friday 25 January 2002 14:50, John Boyer wrote:
> The fact
> that the near-REC hasn't changed in a while has no bearing on this, and
> I think we're obliged to fix things that we notice (albeit belatedly)
> are broken using our implementations (otherwise why require
> implementation?).

The xmldsig namespace is set; it  *cannot* substantively change by 
definition of having entered CR, so any  change you would introduce would 
need a new namespace anyway. 

However, I'm still encouraging folks to think about and discuss performance 
issues. Aand while we've waited out process lag we've also had perfectly 
agreeable suggestions come in that we couldn't take on for fear of kicking 
off another lag. (And of course, if you wait around for 4 months for 
something to happen, someone is going to make another reasonable 
suggestion, darn it! <smile/>)

So since the spec/namesace calcified a while ago we are now in the natural 
state where people are beginning to think, "hrmm... this syntax is a bit 
silly here, this feature doesn't work in the way I had hoped, could this 
bit be speeded up, and wouldn't it be nice if we had schema data  typing, 
why isn't this based on Infoset?" This is natural and good, people are 
using the spec.

Since xmldsig is so extensible, I expect to see new transforms (like 
xml-exc) that improve on performance and/or meet requirements in the 
scenarios people end up using it in. In my head, an xmldsig 1.1 would be a 
mushing of all of those together but changing the key words. (This syntax 
is tweaked, this transform is deprecated and this new one is now required). 
An xmldsig 2.0 would take on some more fundamental rethinking and perhaps 
based on XPath 2.0 (which is infoset based and supports schema 
validation!). But that's much further out and I'd want to understand how 
xmldsig and xenc work together with lots of deployment/operational 
experience in hand.

We need to finish this thing off, let folks get more experience with 
it in their application contexts, specify new transforms if/as the need 
arise, and focus on xenc, particularly when it comes to xenc+xmldsig. 


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 19:13:46 UTC

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