Subject: [urn] NSS encoding

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 24 Jul 2015 06:11:01 +0000

Hello, 

Keith said: 

"I'm concerned that telling implementors to use %-encoding of disallowed characters that appear in NSS might conflict with an existing URN namespace's encoding rule.  Also, %-encoding is a mess, because it's used by so many different layers of software without any clear guidance about which layers undo which portions of the encoding.  So I doubt that it's a good idea to specify a uniform rule for how every namespace should encode its native names to URN format; instead, I think that encoding considerations should be part of namespace-specific "canonicalization" rules."

My take on this is between the original text and Keith's point of view. Most standard identifiers I am familiar with consist of ASCII characters only and do not need encoding rules for disallowed characters at all. But in the other extreme there are cases when name space specific encoding rules are needed. For instance, if ARK (another persistent identifier system) registers a URN namespace, it is necessary to develop namespace specific guidelines for dealing with ARK specific r-components which are "?" for requesting from the resolver metadata about the resource and "??" for asking for preservation commitment of the institution which is holding the document. ? is a reserved character, and since URNs have specific uses for "?" and "??" normal URN resolver would not have any idea of what to do with unaccompanied "?" or "??" ARK has chosen to use. But %-encoding them would not make sense from ARK resolution point of view, so URN:ARK (if and when it is registered) must specify how to treat these ARK specific features. For instance, since "?" and "??" are not part of the ARK identifier, they can be deleted in order to just retrieve the identified resource. Or, they can be migrated into corresponding URN r-components.   

If we allow both %-encoding and namespace specific encoding of identifiers, the resulting text in RFC2142bis could be something like this: 

"Depending on the rules governing a namespace, names that are valid in a namespace might contain characters that are not allowed by the "pchar" production referenced above (e.g., characters outside the ASCII range or characters that are reserved in URIs, such as "?", and "#").  While such a string might be a valid name, it is not a valid URN until it has been translated into a conformant NSS.  If there are no namespace specific encoding requirements, translation may not be necessary at all, or it may be done by percent-encoding each disallowed character using the method defined in Section 2.1 of the generic URI specification [RFC3986]. If there are specific encoding requirements, translation of an identifier from its "native" format to URN format is accomplished by using the canonicalization and encoding methods defined for that URN namespace in that namespace's registration. Software that is not aware of those URN canonicalization and encoding rules for the namespace used MUST NOT construct URNs from such identifiers. Note also that the "%" character is allowed in the NSS only for the purpose of percent-encoding. "    

IMO we have already taken namespace specific character encoding into account, since  the syntax section of the namespace registration template enables the registrant to describe "Any special character encoding rules for assigned URNs (e.g., which character ought to always be used for quotes)."

There is also another aspect of URN encoding which we may need to mention in passing. It may happen that when an identifier is turned into NSS, changes go beyond simple %-encoding of characters, especially if the identifier as such does not support resolution requirements of the community. An example of this in ISBN in DOI. ISBN prefix element, registration group element and registrant element form DOI prefix and publication element and check digit become DOI suffix. So ISBN 978-952-222-272-5 becomes DOI 10.978952222/2725, which can be resolved by the publisher. There are various ways in which URN:ISBN resolution could be tweaked in the same way, and some of them would have an impact on how ISBNs are expressed as URNs.    
  
Best regards, 

Juha
--

Juha Hakala

 Senior advisor
 The National Library of Finland
 Library Network Services 
 P.O.Box 26 (Teollisuuskatu 23)
 FIN-00014 Helsinki University

 Gsm: +358 50 3827678
 email: [email-masked]