W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > June 2007

C14N 1.1 Appendix Updated

From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
Date: Mon, 25 Jun 2007 22:42:57 +0200
Message-ID: <468028D1.1010400@iaik.tugraz.at>
To: "Grosso, Paul" <pgrosso@ptc.com>, Frederick Hirsch <frederick.hirsch@nokia.com>
CC: public-xml-core-wg <public-xml-core-wg@w3.org>, public-xmlsec-maintwg@w3.org
Hi Frederick, Paul and all,

Frederick wrote:
> Are we at a point where the needed changes are clear?
I'd presume so. Nevertheless challenging test cases from other 
participants/implementors are highly appreciated.

Konrad Lanz wrote in 
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007May/0044.html: 

> [...] preparations for C14n1.1 interoperability test and created two 
> test implementations (taking different approaches) for the modified 
> remove_dot_segments function and identified several problems. (If 
> someone is interested in detail one can try the test cases in the 
> attached HTML file).
>
> [...] please find a reworded version of the c14n11 Appendix including 
> several test cases in the attachment.

Attached please find an updated version of the c14n11 Appendix updated 
according to 
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0031.html 
.

The changes proposed by in Juan Carlos in 
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0041.html 
have been incorporated.

The comments by Sean 
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0065.html 
have not yet been considered as the consensus in the XML Core WG was to 
stay as close as possible to the original text (Section 5.2.4 
http://www.ietf.org/rfc/rfc3986.txt), which is also indicated by the 
diff notation(coloring) in the Appendix .

However I agree that a complete rewording might simplify the processing 
as I have informally mentioned already in 
http://lists.w3.org/Archives/Public/public-xmlsec-maintwg/2007Jun/0031.html 
.
I'm unsure about the process if we'd really like to change this and 
hence I sticked as "close" as possible to RFC 3986.

I would also appreciate other people's opinion about the following:
> Further in the concourse of these initial tests I also found a 
> potential ambiguity in the merge_path function in rfc3986
> http://tools.ietf.org/html/rfc3986#section-5.2.3
>
> Which says: " i.e., excluding any characters after the right-most "/" 
> in the base URI path"
>
> However I don't think this applies if a base URI has two trailing dots 
> (assuming the optional normalization mentioned in the second paragraph 
> of http://tools.ietf.org/html/rfc3986#section-5.2.1 was not performed).
>
> So I'm unsure what would happen to an inherited xml:base URI reference 
> of the form "../.." to be joined with a URI reference of the form 
> "..". For the least surprising output I would bet on "../../../" as an 
> output and I think this would also deserve a mention in section 2.4 of 
> C14n 1.1 .
>
> [...]
regards

Konrad

-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
https://www.iaik.tugraz.at/aboutus/people/lanz
http://jce.iaik.tugraz.at

Certificate chain (including the EuroPKI root certificate):
https://europki.iaik.at/ca/europki-at/cert_download.htm




Received on Monday, 25 June 2007 20:43:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:35 GMT