RE: Sorting of DOM input to c14n 2.0

> From the complexity point of view I think it is better to put in on
> signing side than on the c14n side, because I think a simple
> implementation will use an off the shelf Xpath engine on the signing
> side, and write custom code for the c14n side.  If we put the sorting on
> the signing side then they would need to write some custom code on the
> signing side too.

I think your first sentence is backwards, no? You're saying to leave it on
the c14n side?

That's fine, I just advocate the processing rules being less
implementation-specific about sorting and more declarative (the subsets must
be processed in order).

> Another fact is that c14n 1.x implementation is
> already required to document order sorting, so it is probably not too
> much to expect a c14n 2.x to do so too.  A full blown c14n 2.0
> implementaion with all prefix rewriting and pruning and sorting will
> turn out to be more complicated than a c14n 1.x implementation
> (especially when implemented in Ruby)  but we can profile it down to the
> n=1 case.

Well, this is why I'm not an advocate of prefix-rewriting, and I don't think
it should be MTI.
 
-- Scott

Received on Tuesday, 13 April 2010 19:46:03 UTC