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 

> [...] 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 

The changes proposed by in Juan Carlos in 
have been incorporated.

The comments by Sean 
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 
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 .
> [...]


Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520

Certificate chain (including the EuroPKI root certificate):

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:38 UTC