Re: [urn] URN:DOI namespace registration request

Paul Jessop <> Fri, 15 January 2021 11:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFEDB3A0BF2 for <>; Fri, 15 Jan 2021 03:24:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.616
X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mxOiN8tpugrC for <>; Fri, 15 Jan 2021 03:24:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1AB573A0BFF for <>; Fri, 15 Jan 2021 03:24:43 -0800 (PST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id 63BD86044B for <>; Fri, 15 Jan 2021 11:24:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aN1-1GcU-DwE for <>; Fri, 15 Jan 2021 11:24:40 +0000 (GMT)
Received: from (unknown []) by (Postfix) with ESMTPS id B2CEF60453 for <>; Fri, 15 Jan 2021 11:24:40 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 15 Jan 2021 12:24:39 +0100
Received: from ([fe80::516d:9387:664a:7563]) by ([fe80::516d:9387:664a:7563%13]) with mapi id 15.00.1497.010; Fri, 15 Jan 2021 12:24:39 +0100
From: Paul Jessop <>
To: "Hakala, Juha E" <>, "" <>
CC: "" <>, Jonathan Clark <>
Thread-Topic: [urn] URN:DOI namespace registration request
Thread-Index: AdaYd1sv+4pAeRQ7TuGRkNNI8T4mdRSJRYSAABr1KWAACBauAA==
Date: Fri, 15 Jan 2021 11:24:39 +0000
Message-ID: <>
References: <> <trinity-3f828d18-723e-46eb-a4fe-1f69faf504d0-1610646069243@3c-app-webde-bap09> <>
In-Reply-To: <>
Accept-Language: en-GB, de-DE, en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/16.44.20121301
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
x-1and1-spam-score: 1/100
x-1and1-spam-level: None
x-1and1-expurgate-category: clean
x-provags-id: V02::YJ3aC8K/pd7a6rU+P8OtzXNJcLZUwB0Onv3XHfP4yFEiO szOsUxdy4z/+9oTrr7FpVWGuF43Gtq4OJlQuxhoGvW8kgxnGGp M7f+NuvXub3ZfR4nKlsJg6t+ftm9M8dqN+EJPn7xfB4jYxqyPI 9OyAfo5KC1sF5QOrV3lFsSFhW5uLA/it7bu65Pgs2YpOkiI
Content-Type: multipart/alternative; boundary="_000_E3EF8D81ECB94EB09DB3F59886FB897Acountyanalyticscom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [urn] URN:DOI namespace registration request
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Jan 2021 11:28:35 -0000

Thanks all for these helpful and thoughtful comments. I will study and get back to you shortly.

Best regards,

Paul Jessop
Technology Advisor, The DOI Foundation

Paul Jessop              county analytics ltd 


rights - technology - markets - music - media 

---------------------------------------------<>      +44 7850 685378

From: "Hakala, Juha E" <>
Date: Friday, 15 January 2021 at 07:31
To: "" <>
Cc: "" <>, Paul Jessop <>, Jonathan Clark <>
Subject: VS: [urn] URN:DOI namespace registration request

Dear Lars,

thank you for this feedback! Some comments inline below.

Lähettäjä: <>
Lähetetty: torstai 14. tammikuuta 2021 19.41
Vastaanottaja: Hakala, Juha E <>
Aihe: Aw: [urn] URN:DOI namespace registration request

Dear Juha,

My apologies for not acting on this earlier.

I have some issues with the current registration template.

Relation to doi URI scheme

As Julian already noted, the document lacks information on how the urn:doi namespace relates to the doi URI scheme. This is particularly imporant since the registration claims that "no scheme registration for DOI has yet been made by the DOI Foundation". This is clearly an error, since the IANA registry of URI schemes includes "doi:" (even if it's only a provisional registration) [1].

Actually, the claim in the URN:DOI namespace registration is correct. Paul Jessop told me that:

“The registration of a provisional scheme for DOI was made without the knowledge or consent of the DOI Foundation and we found out about it only once it had been done. We are not currently supporting it and remain sceptical that the ambitions of the group that has done this will result (as they hope) in the identifiers they have selected becoming resolvable in browsers.

It seems that the provisional registration with our name on it has the effect of blocking anyone else using the string "doi" as a URI scheme for a different purpose and it will not go forward without our consent - so it is not in general harmful at the moment. We are tracking progress in case this group is able to do now what many failed to deliver in the past: create a table of schemes and action rules for use in browsers and get the competing applications to use it. This would not be a stupid thing to do as it would (for instance) have allowed the migration from to to happen by pushing a revised rule to browsers rather than changing the presentation rules in every DOI system handbook.

But the focus of The DOI Foundation is on the registration of a URN namespace to allow DOI to be recognised as a technology independent identifier alongside NBN and the other namespaces that are used operationally.”

Since the International DOI Foundation has had nothing to do with the provisional registration of the DOI URI scheme, I am not sure how it should be taken into account in the URN namespace registration. We could, for instance, add a note acknowledging the existence of provisional DOI URI scheme registration, but pointing out that the registration was made without the knowledge or consent of the International DOI Foundation and that the foundation has currently no plans to support it.

As an aside: I do not know if people who register URI schemes should have a mandate for what they are doing. The company behind the DOI URI scheme registration, Igalia, is a Spanish IT consultancy. I assume there is no malicious intent, but as far as I can tell, Igalia has never been involved with DOI standardization or any other identifier related standardization work in ISO TC 46 or in IETF URNbis WG. When a URI scheme is registered for an international standard such as DOI, IANA should perhaps check that that the organization responsible of the standard is aware of the registration and endorses it, especially if this organization is mentioned in the request.

Lexical Equivalence

The part on urn comparison lacks information on how to compare percent-encoded characters, e. g. if %7f and %7F are considered equivalent. If they should be -- which I think is correct -- this can easliy be solved by a statement at the beginning of the section stating that "in addition to the equivalence rules defined in RFC 8141 the following rules for lexical equivalence apply:". I also think that you should future-proof this section with regard to the doi:... syntax: Since there are obviously plans to register doi: as a fully-fashioned URI scheme, you must ensure that the URI doi: syntax remains compatible with the urn:doi namespace when it comes to lexical equivalence.

I am fine with clarifying the equivalence of percent-encoded characters. But given the shaky status of the doi URI scheme registration, I would not say anything about doi: syntax yet.

Character Set

In the section on character set, you write that

URI percent encoding (see RFC 3986, section 2.1) is required for characters in a DOI that are:
(a) outside the ASCII printable character set, or
(b) reserved in the URI syntax (see RFC 3986, section 2.2).
The same rule is applied in creating a URN.

RFC 3986 does not speak of printable ASCII characters but uses the term "unreserved characters" [2]. In order to ensure that the doi:urn rules for percent-encoding are equivalent to those of URIs in general, I would suggest to phrase (a) as "characters that are not URI unreserved characters (see RFC 3986, section 2.3), or"



The syntax section says that the doi NSS contains of prefix, slash and suffix, where the prefix consists of directory indicator, full stop and registrant  code. It the goes on to say that there are plans to remove the requirement that the directory indicator be "10" and to allow DOIs without a registrant code. I cannot see how this is compatible with the specified syntax and think it would be helpful if you provided an example for this.

I’ll discuss with Paul Jessop about this. There are at least two options: remove the reference to alternative syntax which may be established in the next edition of the DOI standard, or explain the new option more clearly, with an example.

DOI Assignment

The document says that the DOI Registration Agencies manage the registration process. It is, however, silent on how it is ensured that DOIs are not duplicated (i. e. only one referent for each DOI). The linked DOI handbook says in §2.3.5 that "Each DOI name shall specify one and only one referent in the DOI system. While a referent can be specified by more than one DOI name, it is recommended that each referent has only one DOI name." It does not say how this is achieved, so some text clarifying this or a link to external documentation would be helpful.



In the introduction the use of the R-component is mentioned, but there is no information on that in the section on resolving.

As far as I know, the DOI community has not discussed yet how the R-component may be used in the future. I’ll see if some information can nevertheless be provided.

All the best,




Gesendet: Freitag, 02. Oktober 2020 um 06:26 Uhr
Von: "Hakala, Juha E" <<>>
An: "<>" <<>>
Cc: "Larry Lannom" <<>>, "John C Klensin" <<>>, "Paul Jessop" <<>>, "Jonathan Clark" <<>>
Betreff: [urn] URN:DOI namespace registration request
Hello all,

please find attached a URN namespace registration request for DOI, Digital Object Identifier. I have assisted Paul Jessop in writing the request and therefore shall exempt myself from evaluating the request. Any questions should be sent to Paul and Jonathan Clark.

Handle.Net resolver ( already supports URN representation of DOIs (<doi<>>) so every DOI is actionable also as URN. The resolver does not support URN R- or Q-components, but such functionality may be added to a future version.

Handles may be presented and resolved as URNs as well, with the NID HANDLE. I do not know if DONA Foundation ( intends to request a URN namespace for Handles. However, NID “HANDLE” should not be granted to some other community.

All the best,


PS. The National Library of Finland has rebuilt its URN resolver. Following a beta test last summer, we are currently in the process of taking the new resolver into production. As far as I know, it is the first one supporting R component. The first service implemented was linking of a single URN to multiple URLs.

Once the resolver is “battle proven” and there is basic documentation available in English, the resolver will be made freely available in GitHub.

Juha Hakala
Senior advisor
Library Network Services, The National Library of Finland
P.O.Box 15 (Yliopistonkatu 1), 00014 Helsingin yliopisto

_______________________________________________ urn mailing list<>