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

Peter Saint-Andre <> Thu, 29 June 2023 19:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D6B0C15107D for <>; Thu, 29 Jun 2023 12:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b="eq4c/y6x"; dkim=pass (2048-bit key) header.b="O2zVjYK/"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SjrTFbx-riIP for <>; Thu, 29 Jun 2023 12:58:01 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BA1FC14CF13 for <>; Thu, 29 Jun 2023 12:58:01 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 77DB53200912; Thu, 29 Jun 2023 15:58:00 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute2.internal (MEProxy); Thu, 29 Jun 2023 15:58:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1688068680; x=1688155080; bh=CAaMFqQxdTb+XulOayHvM+x3pi9uKqMAM08 aGfOFgTw=; b=eq4c/y6xQOZQuCCGJERRK1P0mtSmAep3pw3FvyYldyn4nzv3PS+ RzAzG7WT5WjIHCvhS2/2dKeZu7HUQoN9mQe/hKUyEpFdbck3GAK8BBx/bAvzTAC4 n5vYbvT7FR/GwAdNqQ4HB7vAlVPrK22fiAq6Wo5gAX3p1/cgvvTPIOjPZazM51Lz ozz22MSNtNdWPNQEDkWcqRqMWylzNcqs+7v5MH2PGRf+V8O0PxsWYWYxodgSDaP5 9q3y2RPmBUUNYoKRwfz9bBq4Vs4Ff8vTJ53Gu7z+ZkBKg6a19eK0ndZDOvTWzBJw 6yloI2XSr2IY4S0SqE/bX+vgGiVJAeDEO9g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1688068680; x=1688155080; bh=CAaMFqQxdTb+XulOayHvM+x3pi9uKqMAM08 aGfOFgTw=; b=O2zVjYK//4Kg4/VD1ktJ73o9mUDtbn+ZPyusDAC2BRZe1Fi/L/B 1iD3rUeWHyxZqLZbNuv28QBYIk5fhfDERWpJoGMSFngD6PxFr384lbrQMkReIen3 AMN3oIcLHmlXTPfnXY/yuGceDZ3YMyznsOa0cjqWXKKonmWMJYJEUo5l3/JfSIQz 84wNIANF3naeiDN72CcrA6fYjjCA1L3PkW/6B52oQ3cZpebaP2EEYnEF/WFFsdE9 MDIZSM3N04lcNetBbPs8o4891j3Z7UFgw4R2gJmGsTAtqCvWWWKKXu58A0/lPy/x D/dRS1iD/7yUlmH5+PstQK17Ez3Tc1ecF0w==
X-ME-Sender: <xms:R-KdZPLQh1XWOc2qO7CK7IP6qUu11haI6Ho-ShLsMuN6e1pd101kzQ> <xme:R-KdZDJ_mzM460WiZmCG2d-x9gfy3Nd4EW4U4yzx_VSt85aIiS3urjkMoWzTfW7S9 fBv3tdSCcJvTAIAAQ>
X-ME-Received: <xmr:R-KdZHts9EJoYwe1_Wc3tENMqJAOxGL0nyXTNWQAAPvw4-sJIvUzuzcONGMw-qB7>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrtdeggddugeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnegfrhhlucfvnfffucdlqdehmdenucfj ughrpefkffggfgfvvehfhffujggtgfesthejredttdefjeenucfhrhhomheprfgvthgvrh cuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqnecu ggftrfgrthhtvghrnhepffejgeekffelueelgeduveegjeehjeeftdffffeukeduteefve ehtddviedtueegnecuffhomhgrihhnpehlohgtrdhgohhvpdgvuhhrohhprgdrvghunecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvth gvrhesshhtphgvthgvrhdrihhm
X-ME-Proxy: <xmx:R-KdZIYe0AsQ13OavUYob1Vzj9CAorRWOBKhwjYZoSOwOBEr4w24Jg> <xmx:R-KdZGYn1ZZcjk3ZLJ6sJmupDLOYLuUjmHlXQOiuMo6J7QZVABXGEw> <xmx:R-KdZMAGFgGTiQqvyo3TrhP6pk5SUaCCp-j0LDu2-WSZoH5HivvL3w> <xmx:SOKdZNUi1-MO88mKJcPJTTaCdBHqOmhjo58CU9SM7ViNs9NCkdfG-w>
Feedback-ID: i24394279:Fastmail
Received: by (Postfix) with ESMTPA; Thu, 29 Jun 2023 15:57:58 -0400 (EDT)
Message-ID: <>
Date: Thu, 29 Jun 2023 13:57:57 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.11.2
Content-Language: en-US
To: John C Klensin <>, "Hakala, Juha E" <>, "Lars G. Svensson" <>,
References: <> <AS8P250MB0911A579297B901351E97A2EE85DA@AS8P250MB0911.EURP250.PROD.OUTLOOK.COM> <> <> <01a701d9a83c$8b5ecbd0$a21c6370$> <159E19456429B89285CAEA61@PSB> <> <>
From: Peter Saint-Andre <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [urn] [IANA #1275238] URN:NAN registration request
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jun 2023 19:58:06 -0000

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.


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"
> <> 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  ( and detailed
>> specifications for digital archiving
>> (
>> 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