Re: [urn] URN:DOI namespace registration request

[Paul Jessop <[e-mail]>]

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 

--------------------------------------------- 

[e-mail]<mailto:[e-mail]>      [phone]




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

Dear Lars,

thank you for this feedback! Some comments inline below.

Lähettäjä: [e-mail] <[e-mail]>
Lähetetty: torstai 14. tammikuuta 2021 19.41
Vastaanottaja: Hakala, Juha E <[e-mail]>
Kopio: [e-mail]
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 dx.doi.org to doi.org 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"

OK.

Syntax

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.

OK.

Resolving

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,

Juha

[1] https://www.iana.org/assignments/uri-schemes/prov/doi
[2] https://tools.ietf.org/html/rfc3986#section-2.3
[3] https://www.doi.org/doi_handbook/2_Numbering.html#2.3.5

Best,

Lars
Gesendet: Freitag, 02. Oktober 2020 um 06:26 Uhr
Von: "Hakala, Juha E" <[e-mail]<mailto:[e-mail]>>
An: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "Larry Lannom" <[e-mail]<mailto:[e-mail]>>, "John C Klensin" <[e-mail]<mailto:[e-mail]>>, "Paul Jessop" <[e-mail]<mailto:[e-mail]>>, "Jonathan Clark" <[e-mail]<mailto:[e-mail]>>
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 (http://www.handle.net/download_hnr.html) already supports URN representation of DOIs (https://doi.org/urn:doi:<doi<https://doi.org/urn:doi:%3cdoi>>) 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 (https://www.dona.net/) intends to request a URN namespace for Handles. However, NID “HANDLE” should not be granted to some other community.

All the best,

Juha

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
email [e-mail]<mailto:[e-mail]>

_______________________________________________ urn mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/urn