FW: Updated Proposal for changes to C14N11 related to XMLSec interop feedback

 

-----Original Message-----
From: Frederick Hirsch [mailto:frederick.hirsch@nokia.com] 
Sent: Tuesday, 2007 November 06 11:13
To: gmarcy@us.ibm.com
Cc: Grosso, Paul; ext Thomas Roessler; XML Canonicalization Comments;
XMLSec XMLSec; Frederick Hirsch
Subject: Updated Proposal for changes to C14N11 related to XMLSec
interop feedback

Glenn

Attached is a revised red-line of changes to C14N11, based on our  
discussion during the XML Core F2F meeting today (I also changed the  
order of bullets in 2.4 since knowledge of the changes to Remove Dot  
Segments is required to perform the RFC 5.2.2 processing).

I believe we agreed that these changes should be incorporated into an  
update to the C14N11 CR draft for review.

Thanks

regards, Frederick

Frederick Hirsch
Nokia



On Nov 5, 2007, at 7:52 PM, Frederick Hirsch wrote:

> resend with PDF
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
>
>
> On Nov 5, 2007, at 6:12 PM, Frederick Hirsch wrote:
>
>> Paul, Thomas
>>
>> I have put together a concrete proposed set of changes to C14N11 -  
>> this may help with our discussion tomorrow. This is a rough draft  
>> for discussion and has not been reviewed by the XMLSec WG.
>>
>> I  attach a PDF red-line that attempts to implement all of our  
>> feedback to C14N11 [1] on the C14N11 CR draft [2]. Line numbers  
>> refer to the PDF.
>>
>> The rationale of the changes is as follows:
>>
>> 1. Line 11, remove text to revert C14N11 to 1.0 wording, as agreed  
>> in first feedback item
>>
>> 2.  Line 37-60 attempt to address feedback on xml:base processing  
>> as follows
>>
>> 2a. Wrote new brief introduction to xml:base fixup processing.  
>> Remove redundant descriptions, as a result the text now only  
>> refers to removed  *elements* requiring fixup. Added parenthetical  
>> to emphasize need for contiguous missing elements, and to  
>> indicated how this applies to updated example.
>>
>> 2b renamed "join URI" to "join-URI-References"
>>
>> 2c Added explicit warning re removal of elements vs attributes  
>> (lines 61-64)
>>
>> 2c moved description of join-URI-References function to follow  
>> general xml:base fixup discussion. Minor editorial updates
>>
>> 2c) removed reference to Appendix A, I am suggesting that Appendix  
>> A be removed. Last bullet covers the key point at line 79-83
>>
>> 3. Updated example for 3.8 as suggested by XMLSec. (lines 92-96)
>>
>> regards, Frederick
>>
>> Frederick Hirsch
>> Nokia
>>
>> [1] http://lists.w3.org/Archives/Public/www-xml-canonicalization- 
>> comments/2007Oct/0000.html
>>
>> [2] http://www.w3.org/TR/2007/CR-xml-c14n11-20070621
>>
>>
>> On Oct 25, 2007, at 1:12 PM, ext Thomas Roessler wrote:
>>
>>>
>>> ----- Forwarded message from "Grosso, Paul" <pgrosso@ptc.com> -----
>>>
>>> From: "Grosso, Paul" <pgrosso@ptc.com>
>>> To: www-xml-canonicalization-comments@w3.org, Thomas Roessler  
>>> <tlr@w3.org>
>>> Date: Thu, 25 Oct 2007 12:59:02 -0400
>>> Subject: Re: Interop meeting report
>>> X-Spam-Level:
>>> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
>>>
>>> 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
>>>>
>>>
>>>
>>>
>>> ----- End forwarded message -----
>>>
>>
>> <c14n11-2-4-redline.doc>
>
> <c14n11-2-4-redline.pdf>