Re: [IANA #1275238] URN:NAN registration request

Hi John,

Thanks for engaging in this discussion.

You know this, but I write the following paragraph for the benefit of 
the registrants:

Because the place of the expert review team is to provide feedback only 
for the purpose of adding namespaces to the IANA registry, we cannot 
recommend or insist upon publication of an informational RFC. (However, 
in an individual capacity I and other expert review team members have 
assisted registrants in pursuing publication via the Independent 
Stream.) Therefore, I suggest that at this time we work with the 
registrants to make the appropriate changes to their request so that the 
namespace can be added to the registry. If the registrants wish to 
pursue the RFC route, we are happy to make the proper introductions.

With that in mind, we look forward to an updated registration template 
from the registrants that addresses the feedback provided on list.

Peter

On 6/27/23 9:38 AM, John C Klensin wrote:
> Hi.
> After under a minutes's thought, I agree with Juha -- the
> information I've been thinking about in terms of the
> registration request belongs in an Informational RFC.
> 
>     john
> 
> 
> --On Tuesday, 27 June, 2023 06:02 +0000 "Hakala, Juha E"
> <[email protected]> wrote:
> 
>> Hello,
>>
>> although The National Archive of Finland is the registrant of
>> URN:NAN namespace, administration of the system will be
>> delegated to the national level. So it is up to the
>> Bundesarchiv to decide which archives in Germany will get
>> URN:NAN subdomains. But before that the archive needs to make
>> the decision to start using urn:nan:de, and if there are any
>> questions about this process, Bundesarchiv can contact its
>> Finnish peer.
>>
>> I agree with John that additional guidance on URN:NAN
>> namespace would be useful, especially if more countries than
>> just Finland adopt it (we have a pretty good idea of what do
>> with these URNs already). But instead of adding such
>> information to the registration request, it might be better to
>> publish an informational RFC. This is what we did with
>> URN:NBN; RFC 8458 was written because there is no other
>> publication which provides an overview of NBN identifier
>> systems. But URN:NAN RFC does not need to be in place before
>> the namespace registration, and IMO we should leave it to the
>> archival community to decide whether such document is needed.
>>
>> As an aside, archives have a common exchange format for
>> metadata, EAD  (https://www.loc.gov/ead/), and detailed
>> specifications for digital archiving
>> (https://digital-strategy.ec.europa.eu/en/activities/earchivin
>> g-specifications). Some kind of Achilles' heel in this is that
>> long term preservation requires persistent identifiers, but
>> there is no shared approach to what PID system to use, and PID
>> adoption rate may be low compared to e.g., libraries. Even in
>> France, where ARK is popular in libraries and museums,
>> archives have been less keen. URN:NAN will be the first
>> persistent identifier for archives only, and time will tell if
>> it becomes popular.
>>
>> Possibly the main obstacle for potential URN:NBN and URN:NAN
>> implementers is the lack of open source resolver application.
>> (Of course there is no such problem in URN:DOI.) The National
>> Library of Finland intends to alleviate the problem; we plan
>> to make our resolver available in GitHub this summer. The new
>> version of the resolver has been in production for quite a
>> while now and we believe it is stable enough.
>>
>> Currently the resolver supports just one R component (URN to
>> multiple URLs), but we intend to enrich the resolver with
>> additional services. There is a need to establish a registry
>> of URN resolution services using R component, and I hope IANA
>> can take the responsibility of it. We have discussed this
>> issue in the past, but back then our resolver did not support
>> R component yet, so the issue was still a bit theoretical. Not
>> anymore.
>>
>> Lars: German National Library has an API for harvesting data
>> from the resolver. Do you think that the API is generic enough
>> so that it can be used by any URN resolver? In FAIRCORE4EOSC
>> project NLF is involved in the development of meta resolver,
>> and APIs are part of that work.
>>
>> Best regards,
>>
>> Juha

<snip/>