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

"Hakala, Juha E" <juha.hakala@helsinki.fi> Tue, 27 June 2023 06:03 UTC

Return-Path: <juha.hakala@helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A12AC1524A3 for <urn@ietfa.amsl.com>; Mon, 26 Jun 2023 23:03:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=helsinkifi.onmicrosoft.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wN6XGp7o3HPN for <urn@ietfa.amsl.com>; Mon, 26 Jun 2023 23:03:03 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2115.outbound.protection.outlook.com [40.107.20.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D5C8C151076 for <urn@ietf.org>; Mon, 26 Jun 2023 23:03:01 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JERS7c3IFdi+Klh8MoRylwr+IzolcHXfYxhERg2OeTn1WTJ/Pb6dqfqHtR7D+nCB4A4CeTe6zCafS/qV1OXZLhOLpiINS+a8smHGV2pft3T+0eL9uhwL91ojiQBaI7i9cKBopBNNU2N/a7hbBb0ac4qcoMqtkBcPTOW0dqFfhrKRcIx2uddNQhV+yoC7BQ5DygB1o7BaKq2i21s3jEoBgUbCNM8yQ87xTOlgDDP28QZIo1tsH2j0TMqODB3J0pP94a/8JjgH6KAJIVM/x7NvReZGz5GBvoRyEZKwU3t3y5P11bSywl24Gf4LSaBz5wIYkBtgGI8nl5veqTOOOMjMhQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZJYC38LnK25AxCe6KurhyogS6N8QGmPgqC6XoALrkfM=; b=Pt3bDIfNfUT9ffsfC5Lwx9/ibPRxI7Dkwebl/pQ6twPTYkoUH49JyK55D6xJq1Ybv/8+2Dh60LPGHLrl6ph5+KNsjY2LYnPUH/0NO3WOsU6pQ+OMSolltIy91T8Y98QkD0uQbFe/pmZHhh/2667l72KihzLnawkwcDQB4EqnTf4nvNcGxyiAyxxM1GeGtJ+Sodc0ELGwQ7wPpOlGDRn1PouxNq3fIrPwO15llGiA1QnsfVoz4utJGd3dkRGDLWHIC47ePAYywCB30q0Uv429rOORQ6DC4qDvyROpxoutqXwUJbzWw9wfBRUmY9WTHhWaQy8LNSJG9Eq4jUnLZCeh6g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=helsinki.fi; dmarc=pass action=none header.from=helsinki.fi; dkim=pass header.d=helsinki.fi; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=HelsinkiFI.onmicrosoft.com; s=selector1-HelsinkiFI-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZJYC38LnK25AxCe6KurhyogS6N8QGmPgqC6XoALrkfM=; b=vqVSb9Z8jOtzd9fIg4gB+u/okvA+z9eLqgElxHPQ55BniEibfj0CaApTnk+Y5sXxV6Qolq4KADL35TynUeZqEbEFJXGCyUtz45l65W/6w0tdeZ2Ye7mZ0KVO7ZocZLgfpDthjzgMEI68k7WA5h9Ph2lbZxKwSHkypLu4w+VhLUE=
Received: from HE1PR07MB3196.eurprd07.prod.outlook.com (2603:10a6:7:2e::17) by AS8PR07MB8944.eurprd07.prod.outlook.com (2603:10a6:20b:53c::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6521.26; Tue, 27 Jun 2023 06:02:58 +0000
Received: from HE1PR07MB3196.eurprd07.prod.outlook.com ([fe80::87fc:c70d:eb0c:57ed]) by HE1PR07MB3196.eurprd07.prod.outlook.com ([fe80::87fc:c70d:eb0c:57ed%7]) with mapi id 15.20.6521.026; Tue, 27 Jun 2023 06:02:57 +0000
From: "Hakala, Juha E" <juha.hakala@helsinki.fi>
To: John C Klensin <john-ietf@jck.com>, "Lars G. Svensson" <lars.svensson@web.de>, "urn@ietf.org" <urn@ietf.org>
CC: "urn.nan@kansallisarkisto.fi" <urn.nan@kansallisarkisto.fi>
Thread-Topic: [urn] [IANA #1275238] URN:NAN registration request
Thread-Index: AQHZpVywqFt5MEecDkWK+Df5gFUhGq+Xs5QAgAV6xwCAACjxAIAAyhHA
Date: Tue, 27 Jun 2023 06:02:57 +0000
Message-ID: <HE1PR07MB3196DB2AA5E8C03810CE9923FA27A@HE1PR07MB3196.eurprd07.prod.outlook.com>
References: <RT-Ticket-1275238@icann.org> <AS8P250MB0911A579297B901351E97A2EE85DA@AS8P250MB0911.EURP250.PROD.OUTLOOK.COM> <rt-5.0.3-167080-1687474526-316.1275238-9-0@icann.org> <262314ce-10f2-25ef-42a8-659722e9d9ac@stpeter.im> <01a701d9a83c$8b5ecbd0$a21c6370$@web.de> <159E19456429B89285CAEA61@PSB>
In-Reply-To: <159E19456429B89285CAEA61@PSB>
Accept-Language: en-GB, en-US
Content-Language: fi-FI
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=helsinki.fi;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: HE1PR07MB3196:EE_|AS8PR07MB8944:EE_
x-ms-office365-filtering-correlation-id: fa6ec053-6ea3-4a97-895f-08db76d427e6
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: LkWrp+of16uGvJIVsxIkPmxtfvjMOOdGeGhwVv9zcYYPa7JDZHquzRxHWq1KfFHCx6EQaKWznYXTXFbrWps24nZcLvlMeE7Nd0vp358vst/WyfYM3Nc3IEGyuoeXgN0lbCbPVnK7TvYY5AgwqB1MGCYzqIN0kR8+tCAzRGtGbnzLv5z7FAoQ7pSVCoiFN9JYFnWM4w8Dbbn08uPY53ihv+nDhYohK3g2kCZazhYM1uTaR4BZSeAmWdTYch0d6z02PWPx4BL1Wu3Aw5JzdqvolP+gXb+b35fXchOcCST8jRlb1d5SHf0IfJGGigCHuBijgF7DX2W6kARxeYQAqTSUqr8SZYMWuAblP/yoaPIZnmNdZeF6UK9+apXg3fpSGJgzN5oqWPGqAPI5qaCyBkOzsk8b044CHughg7XHrLjT3zsB05yvf2K9zHsoWxNs5x1Smc5PvotRqZM8vj5IFVChmAZTgNdo1kPct4JFNRYZEV0NXFT7qUi0/R3kRcFjIAawFp7K2Fw8iwJtzmDoJnZCMLlH7aZpvUBZwDyeRuGBRE0Xs4x4sjVUrNxEV+PxjJVEtBkS3xJeL2UZGHF95UESKjTUTYJ7Fly6r+HRDLq06uHvu5x7iXQ/KWURpqSfHUskNxNpWrUWNByoQT5ctxUdCg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3196.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(376002)(366004)(136003)(39860400002)(346002)(396003)(451199021)(9686003)(26005)(186003)(6506007)(53546011)(83380400001)(66574015)(52536014)(5660300002)(7696005)(8676002)(8936002)(71200400001)(122000001)(38100700002)(66899021)(478600001)(55016003)(66946007)(86362001)(38070700005)(2906002)(30864003)(110136005)(786003)(966005)(316002)(41300700001)(4326008)(76116006)(33656002)(66476007)(66446008)(64756008)(66556008)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: IIwbOPXsvflzuOLuVKHw1wrfhEci3G7WzMZTM1vDj8txfbF+zUVyZ7LEmSzY23ZzO+u4xKc2NAcu7iArTEUsVKLyR34D91fDzEWN9EcdHVEhxr8ulDg1NKcGvCJ1u4zxet8oZSmdZ56oxM2oDPOCc1mGSXfdEOT4xNZ31FF5PRiffy9SfhVEVrokF3ROMvyu134xOrVcmgHWoO71/onqgTPQ0XxpMTN2J1dHaoRjn9AN3JqPiDzKgFq7QizQmgYBXQNU/hgE9vcl1CBmbauO368ghpvvfZGNS7V3o1xYXYltKPV++LK1tjVb5cTjbJ4cYu5yHYbF2RDvZjGp7xdwiB3lDV7/S/dUK8nAoNjsSs7mA4HCi43ieluOoZWgO+LYnXF/vAk9c5za7u7OjywlD/b3G7leUpQMqZgZCkyHJ9FhjIOLcAxu2IqDkmV6zsesTjWptLObwrpmOR83LlxX3mO9kBPu39QLnUJk+oHmoj8NjqtpE4C9HAztDRRzet3Q5qvrfm9sylI9skro6m/qjuTKixTywHGiFVytfDwD0NUBVnGUhebfiDt1r4p8ZWgkzoWt87LQQgTYsbEDvjWMGMSgK+/j9mKgpMWCZpVpR4vWY5ekt873kAbnGRuW35h77vEDGqsXO8kk8JW+dgdj0CYaXASfLpmaV+wWNIl3M694ofN50a8w3J+F3XCSZz/5phxF2Qxf9hqc6GaJ40Pz4JyJbI0zuI8U8LeNP16kk3wIvopCxcGnpugbKfcRI62MCm3GIQKhDZUnoLJaWKd+Esak+omLeWENcFh7iiGxBWu/hA1Q5o1FrMU23wH6dvXdROmZivQwJqsegLh2Qe/CWAfpWBx3b+ScTsHWupbU0cStUEEi+bQBEfloUDdyYhSxx/rlK5PpQiJJvB4eypQw89BZp04b9gLMri+P7DyAMqSZTLaN3CzoArwOYtncy6hvWy2nYsrV/Ad6yhjGvaLWGak+nNMN0dJmpQl8KD8HjNEU7tlwpBr5KF1FNWgB1w4NSp1cRVC1cp0ZR/dHfEApLP/BXhkziWEyYtnDxyaOfZmyYsLw9s6LwM96Ysy3LxMgsgx+dsjbUOvBD5R7YigKAMjjjY/q76fFjOxH1fGcIBakDF74tz60amBon7tps72yK95HQjBVmmaWMlsBR3xW7RV8a8yDLHHSH1oF53CU4FiaUF+lSqoTFXn+zZ/eR++tW54gr+4Oh9braQ7PbA2RvsaXuCL5ODvlK/vdSnnYk2TV8nofuUG9tdvOb8zb2ttjqGI+WQDXARY0qQZdbODL27+d11XqVaU7g1Xzh0TAup7DXdl/wiFMK82XGvD92eQMuHn+791KPtxRKnU1csWTwDtbeYxLOyjmBwOzKgTZ5KXvenRajdt89m7VHrvxo8hoWWJC+ezt8bdgNUrjVrueQcyESPN0Bh2XKZwVSIE0/DmqsnXqqkJPHuHDnMJNuu7eYRIPlOooeU54W12l7i1wCzUAGYHlcz781FFJAFEsDg0TSDrePxHjiYy8O/Za7gscHD2hJLcb5PNtig5ku8FrOTRXWHDlWOrgUgZiJxhDSoaGxzEeFwS7kc+n+IoPbhrI
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: helsinki.fi
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3196.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fa6ec053-6ea3-4a97-895f-08db76d427e6
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2023 06:02:57.7552 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QdKgLTJ4LSQqP8lDEyjB6DywvKZK3OnKCbSv4MLF5iv8JdQJLsUPfBuE6VfW7r/Dcq6k/Y8DHuc6xC6fO4fUSA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR07MB8944
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/NsCP_RNY3SodJzFr-LDMuspvctU>
Subject: Re: [urn] [IANA #1275238] URN:NAN registration request
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/urn/>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Jun 2023 06:03:08 -0000

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/earchiving-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

-----Alkuperäinen viesti-----
Lähettäjä: urn <urn-bounces@ietf.org> Puolesta John C Klensin
Lähetetty: maanantai 26. kesäkuuta 2023 20.10
Vastaanottaja: Lars G. Svensson <lars.svensson@web.de>; urn@ietf.org
Kopio: urn.nan@kansallisarkisto.fi
Aihe: Re: [urn] [IANA #1275238] URN:NAN registration request

Lars,

Because situations may differ in different countries, I think that the answer ultimately has to be left up to national judgment.  If the IETF or top-level registry tries to specify these things in ways that don't fit well with national institutions and ways of doing things, they will, at best, be ignored.  The good news is that there is lots of experience with systems of this general nature: NBN URNs, and the well-established ISBN and ISSN systems follow approximately the same "delegate to national entities and let it figure out how to manage things in-country" system.  With those systems, some countries use strongly managed central control while, at the other extreme, others allow almost any entity to become a sub-namespace registry and give out its own subsidiary numbers.

What I think the registration document should do is to address some of these issues in a different way, provide guidance to national entities setting up these systems as to what issues they should consider before setting up their systems, if only because, as with many other things, early thinking about design can save a lot of energy in scrambling around to accommodate unanticipated cases later.  My suggestions about early coordinating between NBN and NAN authorities (and others to
come) are in that "think about this early on" category.  Your concerns about types and levels of entities probably belong there too, as to questions about whether those assigned sub-namespaces should be able to create further subdivisions and delegations.  But, beyond, "it would be a good idea to think about these things", I don't know how much advice we can reasonably offer.  And we are still less able to write nation-spanning rules.

If you have not already done so, I suggest reading Juha's note from yesterday -- I think it provides a good deal of practical insight into the situation.

    best,
     john



--On Monday, June 26, 2023 16:43 +0200 "Lars G. Svensson"
<lars.svensson@web.de> wrote:

> Dear all,
> 
> The proposal seems generally fine with me. I have one question 
> regarding the subdivision of the national namespace and to whom the 
> national agency can assign sub-namespaces.
> 
> The registration describes NAN as "a group of identifier systems 
> administered by national archives and institutions authorized by 
> them". Further it is stated that a "national archive MAY also assign 
> URN:NAN sub-namespaces to other organizations with archival fonds such 
> as government institutions". Can those authorised institutions be on 
> any governmental level (e. g. the Hessian Main State Archives or a 
> municipal archive) and can also private organisations (e. g.
> company archives) be authorised to assign NANs?
> 
> Best,
> 
> Lars
> 
> -----Ursprüngliche Nachricht-----
> Von: urn [mailto:urn-bounces@ietf.org] Im Auftrag von Peter 
> Saint-Andre Gesendet: Freitag, 23. Juni 2023 05:03
> An: urn@ietf.org
> Cc: urn.nan@kansallisarkisto.fi
> Betreff: Re: [urn] [IANA #1275238] URN:NAN registration request
> 
> Dear Amanda:
> 
> [moving iana-prot-param-comment@iana.org to bcc]
> 
> Procedurally, as defined in RFC 8141, registrants are to send their 
> requests to the urn@ietf.org discussion list so that the expert review 
> team can provide feedback. Once that is done, the team lead (me) will 
> contact IANA about adding the namespace to the registry.
> 
> Upon cursory review this registration request appears to be in good 
> order, so you might want to leave the ticket open since (barring 
> unforeseen circumstances) I expect that the expert review team will 
> approve it in the next few weeks.
> 
> I'll be back in touch after list discussion and team review.
> 
> Many thanks,
> 
> Peter
> 
> On 6/22/23 4:55 PM, Amanda Baber via RT wrote:
>> Dear URN experts,
>> 
>> IANA has received a request to add "NAN" to the Formal URN Namespaces 
>> registry. See the template and request below. The requester is copied 
>> on this message.
>> 
>> If this ticket should be closed, please let us know.
>> 
>> thanks,
>> 
>> Amanda Baber
>> IANA Operations Manager
>> 
>> ====
>> 
>> TEMPLATE:
>> 
>> Namespace Registration for National Archive Number (NAN)
>> 
>> 
>> Namespace ID:  NAN Requested of IANA.
>> 
>> 
>> Version:  1
>> 
>> 
>> Date:  2023-06-21
>> 
>> 
>> Registrant: The National Archives of Finland
>> 
>> 
>> Name: Lauri Leinonen
>> E-mail: urn.nan@kansallisarkisto.fi
>> Affiliation: The National Archives of Finland
>> Address: Kansallisarkisto, Rauhankatu 17, P.O.Box 258, 00171 
>> Helsinki. Web URL: https://kansallisarkisto.fi/
>> 
>> Requesting entity is the national archive of Finland.
>> 
>> 
>> Purpose:
>> 
>> National Archive Number is a generic name for any identifier system 
>> used by national archives and their partner organizations to identify 
>> archival collections and resources.
>> 
>> There has been no need to develop an international standard 
>> identifier for archival resources. Resources in archival collections 
>> are usually unique and therefore archive-specific identifier systems 
>> have been sufficient. Many national archives have developed their own 
>> identifier systems, but such identifiers are unique only locally.
>> 
>> Digitization or archival resources and long term preservation of such 
>> digital surrogates has created a need for developing a globally 
>> unique, persistent and actionable identifier system for the national 
>> archives and their partner organizations. With URN:NAN, existing 
>> local identifier systems meet this requirement.
>> 
>> 
>> NAN assignment:
>> 
>> National Archive Number (NAN) is a generic term referring to a group 
>> of identifier systems administered by national archives and 
>> institutions authorized by them. The NAN assignment is typically 
>> performed by the organization hosting the resource.
>> 
>> Assignment of NAN-based URNs is controlled on a national level by the 
>> national archive (or national archives, if there is more than one). 
>> National guidelines can differ, but the identified resources 
>> themselves are usually persistent.
>> 
>> NAN assignment policies may differ. Manual assignment by the archive 
>> personnel provides the tightest control. In many
>> (national) archives, NANs are also generated programmatically as a 
>> part of e.g. digitization processes. Usage rules can vary within one 
>> country, between URN:NAN sub-namespaces.
>> 
>> Each national archive uses NANs independently of other national 
>> archives; apart from this registration, there are no guidelines that 
>> specify or control NAN usage. As such, NANs are unique only on the 
>> national level. When used as URNs, base NAN strings MUST be augmented 
>> with a controlled prefix, which is the particular nation's ISO 3166-1 
>> alpha-2 two-letter country code (referred to as "ISO country code"
>> below).  These prefixes guarantee uniqueness of the URN:NANs at the 
>> global scale.
>> 
>> National archives using URN:NANs usually specify local assignment 
>> policies for themselves. Such policy can limit the URN:NAN usage to, 
>> e.g., the born digital or digitized resources stored in the national 
>> archive's fonds.  Although this specification does not specify 
>> principles for URN:NAN assignment policies that can be applied, NANs 
>> assigned to resources which are not archived permanently should not 
>> be made URN:NANs unless such policy can be justified.
>> 
>> NANs as such are locally but not globally unique; two national 
>> archives can assign the same NAN to different resources. A prefix, 
>> based on the ISO country code as described above, guarantees the 
>> global uniqueness of URN:NANs. Once an NAN has been assigned to a 
>> resource, it MUST be persistent, and therefore URN:NANs are 
>> persistent as well.
>> 
>> A URN:NAN, once it has been generated from a NAN, MUST NOT be reused 
>> for another resource.
>> 
>> Users of the URN:NAN namespace MUST ensure that they do not assign 
>> the same URN:NAN twice. Different policies can be applied to 
>> guarantee this.  For instance, NANs and corresponding URN:NANs can be 
>> assigned sequentially by programs in order to avoid human mistakes. 
>> It is also possible to use printable representations of checksums 
>> such as SHA-1 [RFC6234] as NANs.
>> 
>> Syntax:
>> 
>> URN:NAN syntax is equivalent to the URN:NBN syntax. The 
>> Namespace-Specific String (NSS) consists of three parts:
>> 
>> •	a prefix consisting of an ISO 3166-1 alpha-2 country code
>> and optional sub-namespace code(s) separated by a colon(s);
>> 
>> •	a hyphen (-) as the delimiting character; and,
>> 
>> •	an NAN string assigned by the national archive or
>> sub-delegated authority.
>> 
>> The following formal definition uses ABNF [RFC5234].
>> 
>>      nan-nss     = prefix "-" nan-string
>> 
>>      prefix      = iso-cc *( ":" subspc )
>>                  ; The entire prefix is case insensitive.
>> 
>>      iso-cc      = 2ALPHA
>>                  ; Alpha-2 country code as assigned by part 1
>>                  of ISO 3166 ; (identifies the national
>>                  archive to which the branch ; is delegated).
>> 
>>      subspc      = 1*(ALPHA / DIGIT)
>>                  ; As assigned by the respective national
>>                  archive.
>> 
>>      nan-string  = path-rootless
>>                  ; The "path-rootless" rule is defined in RFC
>>                  3986. ; Syntax requirements specified in RFC
>>                  8141 MUST be ; taken into account.
>> 
>> A colon SHOULD be used within the prefix only as a delimiting 
>> character between the ISO 3166-1 country code and sub-namespace 
>> code(s), which splits the national namespace into smaller parts.
>> 
>> The structure (if any) of the NAN_string is determined by the 
>> authority for the prefix. Whereas the prefix is regarded as case 
>> insensitive, NAN strings can be case sensitive at the preference of 
>> the assigning authority; parsers therefore MUST treat these as case 
>> sensitive, and any case mapping needed to introduce case 
>> insensitivity is the responsibility of the relevant resolution 
>> system.
>> 
>> A hyphen SHOULD be used as the delimiting character between the 
>> prefix and the NAN string.  Within the NAN string, a hyphen MAY be 
>> used for separating different sections of the identifier from one 
>> another.
>> 
>> All two-letter codes are reserved by the ISO 3166 Maintenance Agency 
>> for either existing or possible future ISO country codes (or for 
>> private use).
>> 
>> Sub-namespace identifiers MUST be registered on the national level by 
>> the national archive that assigned the identifier.
>> The list of such identifiers can be made publicly available via the 
>> Web.
>> 
>> Note that because case mapping for ASCII letters is completely 
>> reversible and does not lose information, the case used in 
>> case-insensitive matching is a local matter.
>> Implementations can convert to lower or upper case as they see fit; 
>> they only need to do it consistently.
>> 
>> 
>> Encoding considerations and lexical equivalence:
>> 
>> Expressing NANs as URNs is usually straightforward, as normally only 
>> ASCII characters are used in NAN strings. If this is not the case, 
>> non-ASCII characters in NANs MUST be translated into canonical form 
>> as specified in RFC 8141. If a national archive uses NANs that can 
>> contain percent-encoded characters higher than U+007F, the archive 
>> needs to carefully define the canonical transformation from these 
>> NANs into URNs, including normalization forms.
>> 
>> When an NAN is used as a URN, the NSS MUST consist of three
>> parts:
>> 
>> •	a prefix, structured as a primary prefix, which is a
>> two-letter ISO 3166-1 country code of the national arcive's country, 
>> and zero or more secondary prefixes that are each indicated by a 
>> delimiting colon character (:) and a sub-namespace identifier;
>> 
>> •	a hyphen (-) as a delimiting character; and,
>> 
>> •	the NAN string.
>> 
>> Different delimiting characters are not semantically equivalent.
>> 
>> The syntax and roles of the three parts listed above are described in 
>> the previous paragraph.
>> 
>> If there are several national archives in one country or if the 
>> national archive consists of several independent units, these 
>> archives MUST agree on how to divide the national namespace between 
>> themselves using this method before the URN:NAN assignment begins in 
>> any of these archives.
>> 
>> A national archive MAY also assign URN:NAN sub-namespaces to other 
>> organizations with archival fonds such as government institutions.  
>> The sub-namespace MAY be further divided by the partner organization. 
>> All sub-namespace identifiers used within a country-code-based 
>> namespace MUST be registered on the national level by the national 
>> archive that assigned the code.  The national register of these codes 
>> SHOULD be made available online.
>> 
>> Being part of the prefix, sub-namespace identifier strings are 
>> case-insensitive. They MUST NOT contain any colons or hyphens.
>> 
>> Formally, two URN:NANs are lexically equivalent if they are 
>> octet-by-octet equal after the following (conceptional)
>> preprocessing:
>> 
>>     1.  convert all characters in the leading "urn:nan:"
>>     token to a single case;
>> 
>>     2.  convert all characters in the prefix (country code
>>     and its optional sub-divisions) to a single case; and,
>> 
>>     3.  convert all characters embedded in any
>>     percent-encodings to a single case.
>> 
>> Models (indicated line break inserted for readability):
>> 
>>        URN:NAN:<ISO 3166 alpha-2 country code>-<assigned NAN
>>        string>
>> 
>>        URN:NAN:<ISO 3166 alpha-2 country code>:<sub-namespace
>>        code>-\ <assigned NAN string>
>> 
>>     Example:
>> 
>>        URN:NAN:fi:ka:a-1510439051
>> 
>> 
>> Security and Privacy:
>> 
>> This document defines means of encoding NANs as URNs.  A URN 
>> resolution service for NAN-based URNs is technically possible but not 
>> described herein; thus, questions of secure or authenticated 
>> resolution mechanisms and authentication of users are out of scope of 
>> this document.
>> 
>> Although no validation mechanisms are specified on the global level 
>> (beyond a routine check of those characters that require special 
>> encoding when employed in URIs), NANs assigned by any given authority 
>> can have a well-specified and rich syntax (including, e.g., fixed 
>> length and checksum). In such cases, it is possible to validate the 
>> correctness of NANs programmatically.
>> 
>> Issues regarding intellectual property rights or confidentiality 
>> associated with objects identified by the URN:NANs are beyond the 
>> scope of this document, as are questions about rights to the 
>> databases that might be used to construct resolution services.
>> 
>> No specific security threats have been identified for URN:NANs.
>> 
>> 
>> Interoperability:
>> 
>> There is no international standard identifier system URN:NANs would 
>> replace. URN:NAN is compliant with existing local identifier systems, 
>> and will assist the national archives and their partners in making 
>> these systems actionable and globally unique.
>> 
>> Some overlap with other URN namespaces is possible, depending on the 
>> archived resources.
>> 
>> NANs may contain characters which must be percent-encoded when 
>> presented as URN:NANs.
>> 
>> 
>> Resolution:
>> 
>> Depending on the local policy and the nature of the identified 
>> resource, URN:NANs may or may not be actionable.
>> 
>> No centralized resolution service for URN:NANs will be established. 
>> Country-code-based prefix part of the URN:NAN namespace-specific 
>> string will provide a hint needed to find the correct resolution 
>> service for a URN:NAN.
>> 
>> 
>> Additional Documentation:
>> 
>> None
>> 
>> 
>> Revision Information:
>> 
>> None.
>> 
>> 
>> References:
>> 
>> None.
>> 
>> On Wed Jun 21 07:59:11 2023, urn.nan@kansallisarkisto.fi
>> wrote:
>>> Dear recipient,
>>> 
>>> Please find attached the request by the National Archives of Finland  
>>> to register the URN:NAN namespace for archival collections and  
>>> resources. The namespace is modelled after URN:NBN registered by the  
>>> National Library of Finland.
>>> 
>>> If any further documentation or clarification is needed, please let  
>>> me know.
>>> 
>>> Best regards,
>>> Lauri Leinonen
>>> 
>>> Tutkija/Forskare/Researcher
>>> Tutkimus ja innovaatiot/Forskning och innovation/Research and  
>>> Innovation Kansallisarkisto/Riksarkivet/National
>>> Archives  Rauhankatu/Fredsgatan 17 PL/PB/P.O. Box 258,
>>> FI-00171  Helsinki/Helsingfors, Finland puh./tel. +358 29
>>> 533 7398, +358 50 434  2761 e-mail
>>> lauri.leinonen@kansallisarkisto.fi<mailto:lauri.leinonen@kan
>>> sallisark isto.fi>
>> 
>> _______________________________________________
>> urn mailing list
>> urn@ietf.org
>> https://www.ietf.org/mailman/listinfo/urn
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn


_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn