W3C home > Mailing lists > Public > public-iri@w3.org > December 2009

Re: Percent encoding normalization v. mapping URIs to IRIs

From: Martin J. Dürst <duerst@it.aoyama.ac.jp>
Date: Wed, 02 Dec 2009 20:04:11 +0900
Message-ID: <4B1649AB.8090806@it.aoyama.ac.jp>
To: Geoffrey Sneddon <gsneddon@opera.com>
CC: public-iri@w3.org
Hello Geoffrey,

Many thanks for your comment.

I think intent of saying that percent encoding normalization MUST only 
be done locally was to protect against changes that would lead to 
problems for uses such as XML Namespaces and RDF, where equality is 
defined character-by-character on the surface representation (i.e. '%' 
equals '%',...).

However, I agree that this seems to be too strong, and in some way out 
of place, because such a provision would have to be in each and every 
subsection of the comparison ladder. I think it is better to only talk 
about this point in Simple String Comparison (currently 

Regards,    Martin.

On 2009/12/02 18:07, Geoffrey Sneddon wrote:
> Given something that is both a URI and an IRI that contains a
> pct-encoded unreserved character, such as http://example.com/%41, you
> may apply percent-encoding normalization to end up with
> http://example.com/A, however, this MUST only be used for local
> comparison (currently section and not passed along anywhere
> else. However, if you follow the steps for converting the URI to an IRI
> you will likewise end up with http://example.com/A, but with no such
> restriction on use of the converted string.
> As far as I can tell, this is an effective contradiction in the spec, as
> either converting pct-encoded unreserved characters matters or it does
> not. If I really wanted to circumvent the restriction on pct-encoding
> normalization, I could just convert the URI to an IRI and back again, a
> procedure that would effectively do the same.

#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp
Received on Wednesday, 2 December 2009 11:05:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:40 UTC