Subject: [urn] Finding the end of the URN string

From: [email-masked]
Date: Thu, 01 Sep 2011 08:57:49 +0300

Hello all,

RFC2141 has this to say about parsing URN strings embedded in plain text:

"In textual context, a URN ends when an octet/character from the
excluded character set (<excluded>) is encountered.  The character
from the excluded character set is NOT part of the URN."

Although URNs will usually be incorporated in Dublin Core and other  
kind of metadata records where the encoding makes the data machine  
understandable, it may be useful or even necessary to discuss the  
issue of URN parsing in plain text in more detail in RFC 2141bis. And  
unlike back in 1997 we know a lot how URNs are used in textual context.

The problem with the current statement is that there is no guarantee  
that the first character after the URN string is from the excluded  
character set. For instance, International Standard Name Identifier

urn:isni:1111222233334444

could be followed by the telephone number of the person / organization  
to whom the ISNI belongs to. This information would not be part of the  
ISNI, but RFC 2141 would fail in making this clear.

In order to be able to parse URNs in plain text in reliable manner,  
applications must be aware of the syntax of the identifier system. For  
instance, there are 16 digits in ISNI, which makes it easy to find the  
end of the NSS.

ISBNs assigned since 2007 consist of 13 digits, like this:

urn:isbn:978-0-07-166346-5

(As an aside, Principles of Digital Audio, 6th ed., to which this ISBN  
belongs to, contains a chapter which explains the structure of ISBN. I  
was a little bit surprised.)

Applications parsing urn:isbn's based on the new ISBN standard must  
know that the NSS should consist of 13 digits. Therefore, if somebody  
builds URNs like these:

urn:isbn:<isbn-string>.<foo> (where "." is a local fragment separator)

or

urn:isbn:<isbn-string>#<foo>

or

urn:isbn:<isbn-string>?<foo>

the ISBN parsing algorithms should either ignore everything that comes  
after the 13th digit, or conclude that the NSS string in this  
particular URN is incorrect. A sophisticated algorithm should always  
do the former when the thing added to the URN is <query>. To my  
knowledge, no such algorithms exist yet.

There are namespaces such as urn:nbn where no generic rules for the  
NSS parsing exist. It may be that such parsing rules can be developed  
sub-sections of these namespaces (for instance: to the NBNs generated  
in the National Library of Finland). In these cases, a last resort  
parsing rule can be used, which is that the first character which is  
not allowed in that particular namespace indicates the end of the URN.  
And if the namespace does not have any rules that go beyond the URN  
syntax specification as regards the allowed characters, RFC 2141 can  
be used as the basis for parsing the URN.

To sum up, the short text section quoted above could be edited to this  
form in the next version of RFC2141bis in order to reflect the reality  
more closely:

URNs will often be embedded in metadata records or in structured text.  
There the encoding will make it clear where the NSS ends, and  
therefore this method of incorporating URNs is recommended. A special  
case of this is the use of URNs as HTTP URIs to make them resolvable  
in the present Internet.

When URNs are incorporated in plain text, reliable parsing of  
namespace specific strings is possible only if the identifier system  
has a well formed syntax (which specifies e.g. the length of the  
string) and the parser is familiar with it. For instance, ISBN numbers  
are either 10 or 13 digits long depending on the version of the ISBN  
standard, and the parser must be able to recognize which type of ISBN  
is being processed, and behave accordingly.

If NSS contains a <query>, parsing algorithms MUST ignore it. If NSS  
contains a <fragment> or a local add-on, parsing algorithms SHOULD  
behave in different ways depending on the namespace. In the ISBN  
namespace the algorithms SHALL ignore anything that comes after the  
ISBN itself, and MAY label the ISBN as erroneous. Some other  
namespaces (and possibly even future versions of ISBN) may allow the  
user of <fragment> or local add-ons for identification of fragments of  
resources, in which case the parsing algorithms will know how to deal  
with them.

If the identifier does not have a specified syntax, but its character  
set is more limited than that allowed by the URN syntax, a URN has  
certainly ended when an octet/character from the character set  
excluded in that namespace is encountered. This method is not  
reliable; NSS may have ended earlier if the characters following the  
NSS and not excluded.

If the namespace does not have any limitations concerning the  
character set, a URN has certainly ended when an octet/character from  
the excluded character set (<excluded>) is encountered.This method is  
not reliable: NSS may have ended earlier.

Please note that the character from the excluded character set is NOT  
part of the URN.

Best regards,

Juha