W3C home > Mailing lists > Public > www-xml-canonicalization-comments@w3.org > October 2007

Re: Interop meeting report

From: Grosso, Paul <pgrosso@ptc.com>
Date: Thu, 25 Oct 2007 12:59:02 -0400
Message-ID: <CF83BAA719FD2C439D25CBB1C9D1D302092FA691@HQ-MAIL4.ptcnet.ptc.com>
To: <www-xml-canonicalization-comments@w3.org>, "Thomas Roessler" <tlr@w3.org>

Thomas,

I wanted to archive this email, and I can't post directly
to the XMLSEC list, so please forward this message to 
public-xmlsec-maintwg@w3.org.

paul

---

> The XML Security Specifications Maintenance Working Group
> held an interoperability testing meeting for the
> XML Digital Signatures and Canonical XML 1.1 specifications
> in Mountain View, California, on 27 September 2007. 

The XML Core WG is very appreciative of these efforts 
and this feedback.

> The following three issues with the Canonical XML 1.1
> specification were identified.
> 
> 1. The change back to language from C14N 1.0 that is
> suggested in [1] should be applied, as it matches
> implementation behavior.

Agreed, we will revert to 1.0 wording.

> 
> 2. The fix-up for the xml:base attribute that is specified in
> section 2.4 [2] was not implemented interoperably.
>   
> A single implementation was found to have implemented the
> specification's normative text correctly.  Four implementations 
> were found to be consistent with the example in section 3.8 [3]. 
> The example in section 3.8 was found to be inconsistent with the
> normative text.
> 
> After discussion, there was consensus that the normative text is
> correct (but in need of clarification), and that the example
> provided in the specification is indeed incorrect.  

Thank you for your clear explanation and examples.  We agree
with your feedback, and we have directed the editor to correct
the examples and come up with improved wording.

Once we have a new draft of this section, we will share it
with you for your comments.

> 
> 3. Appendix A was found to be complex to the point of being
> unimplementable.

> We recommend to rewrite Appendix A in a clear and simple
> fashion. Where the (commendable!) aim of staying close to
> RFC 3986's language gets into the way of clarity or
> simplicity, the latter should be given priority.

Being complex to the point of being unimplementable is
certainly an unfortunate situation.

However, RFC 3986 is very complicated.  People have been
arguing about what 2386 and 3986 really say for years, and
it's unlikely to stop.  It's been said that, if you think
you understand this stuff and you aren't Roy Fielding, you 
are misleading yourself.

Given that, we are very loath to attempt to include wording 
that is not based on 3986 as there would be almost no 
guarantee that it would be correct.

If there are errors in the description in Appendix A in
the C14N 1.1 CR, we certainly need to correct them.  If
there is a minor wording change that we can all agree 
maintains the correct meaning and improves its clarity,
we are all for that.

But unless we can get Roy Fielding to approve it, we are
very loath to replace Appendix A with a completely
different algorithm.

paul
for the XML Core WG


> 
> 1. http://lists.w3.org/Archives/Public/public-xml-core-wg/2007Aug/0018
> 2. http://www.w3.org/TR/xml-c14n11/#DocSubsets
> 3. http://www.w3.org/TR/xml-c14n11/#Example-DocSubsetsXMLAttrs
> 
Received on Thursday, 25 October 2007 16:59:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 25 October 2007 16:59:41 GMT