Re: Moving exc-c14n forward: your response is needed!

Hi Joseph,

1. #default is in the examples, so yes. Performance is
marginally better than regular c14n, depending on the
input.

2. We've used it informally in SOAP-based situtations
and it solves lots of problems; particularly helps in
the separation of some application layers.

3. I've tried Gregor's examples and, with one exception
(example 4, regular c14n, GrandChild, xml:fool should
not be there?), I think everything works. For other folks'
convenience I attach a signature that represents these
examples (hope you don't mind, Gregor), along with the
raw c14n output. I know you want non-signature-based
examples but, for the sake of this thread, it's a lot
easier to run a signature verify than to check these by
hand.

Merlin

r/reagle@w3.org/2002.04.17/17:08:48
>
>As mentioned in [1] and expected in [2] I'd like to move this document 
>forward. If I request Proposed REC I might be able to make a case for 
>advancement on the basis of [0], but the more documentation I have, the 
>better. In particular I'd like to:
>1. Fill in the row for the "#default" token and adequate performance for 
>the empty cells.
>2. Have a report that someone tested it (even informally) in some 
>application context (e.g., SOAP) and it did what they needed it to do.
>3. Have someone else try Gregor's examples.
>
>If you can contribute on any of these fronts, please do so -- if you can't 
>immediately but hope to do so soon, feel free to email me off list. Also, 
>if you know you have concerns or problems with exc-c14n, speak now or 
>forever hold your peace! <smile/>
>
>
>[0 http://www.w3.org/Signature/2002/02/01-exc-c14n-interop
>
>[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/0043
>2. Exclusive Canonicalization
>I feel like the work on this specification is done and we're pretty much 
>ready to move forward. I'd like to hear a few more people report success 
>with Gregor's tests [1] and that you're satisfied with its operation in an 
>application context. (Even if you've already sent in a report, if your 
>column isn't complete or haven't interop'd with Gregor's tests, please do 
>so.) If I get this feedback soon, I'll stage it for publication as a 
>Proposed REC at the end of this month!
>
>[2] http://www.w3.org/TR/2002/CR-xml-exc-c14n-20020212
>We expect to meet all requirements of
>   that report within the two month Candidate Recommendation period
>   (closing April 16). Specific areas where we would appreciate further
>   implementation experience are:
>    1. Speed of canonicalziation relative to Canonical XML; [23]it should
>       be no slower, is it faster?
>    2. Use in application contexts. Does the specified behaviour meet
>       application requirements for flexibly canonicalizing document
>       subsets if they are moved out of their context? For example,
>       [24]does your application scenario lead to any difficulties in
>       which a subset (e.g., payload) require the use of an ancestor base
>       that is not easily remedied by including xml:base in the apex of
>       the subset?
>
>-- 
>
>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/
>


-----------------------------------------------------------------------------
The information contained in this message is confidential and is intended
for the addressee(s) only.  If you have received this message in error or
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from alteration
of the contents of this message by a third party or as a result of any 
virus being passed on.

This footnote confirms that this email message has been swept for Content
Security threats, including computer viruses.
http://www.baltimore.com