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

[Peter Saint-Andre <[e-mail]>]

On 6/7/18 2:40 PM, Adam Roach wrote:
> 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."

Text along those lines seems appropriate. We might also discourage
people from defining their own canonical transformation, but rather
re-use one that's already defined (say, a PRECIS profile such as
UsernameCaseMapped).

Peter