- From: Konrad Lanz <Konrad.Lanz@iaik.tugraz.at>
- Date: Mon, 25 Jun 2007 22:42:57 +0200
- 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
- Message-ID: <468028D1.1010400@iaik.tugraz.at>
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
Attachments
- text/html attachment: Apendix_20060625.html
Received on Monday, 25 June 2007 20:43:50 UTC