Re: [urn] Benjamin Kaduk's Discuss on draft-hakala-urn-nbn-rfc3188bis-01: (with DISCUSS and COMMENT)

[Adam Roach <[e-mail]>]

On 6/7/18 3:02 PM, Peter Saint-Andre wrote:
> By "normalize" you mean perform equivalence matching of percent-decoded
> strings (of which Unicode normalization might be one step), right? Here
> again I think the answer is "don't do that" because it's equivalence
> matching is done on the percent-encoded strings.


I think the concern here is the translation between percent-encoded URNs 
on the wire and the display form that users enter into lookup forms. For 
example, imagine some alt-history version of a country that decided that 
its NBNs would take the form <author-last-name>-<serial>. Encoded as a 
URN, this might look like urn:nbn:dd:roach-157.

The issue, of course, is that "urn:nbn:dd:m%c3%bcller-127" doesn't match 
"urn:nbn:dd:mu%cc%88ller-127".

So the problem doesn't occur at the level you mention; it happens 
somewhere between the keyboard and the network card of a querying user. 
That's not really this document's problem per se, but it is definitely a 
dragon that needs flagging. I'm not sure whether "don't do that then" is 
the correct advice, unless we have reason to believe that national 
libraries are hyper-aware of URN considerations when designing their NBN 
schemes. What we probably need to say is "if your national library 
defines an NBN that can contain percent-encoded characters higher than 
U+007F, then that same body needs to carefully define the canonical 
transformation from NBNs into URNs, including normalization forms."

/a