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

John C Klensin <john-ietf@jck.com> Sun, 25 June 2023 21:06 UTC

Return-Path: <john-ietf@jck.com>
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 40400C1519BD for <urn@ietfa.amsl.com>; Sun, 25 Jun 2023 14:06:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 QnmVJJAZGQw3 for <urn@ietfa.amsl.com>; Sun, 25 Jun 2023 14:06:29 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F06C14E515 for <urn@ietf.org>; Sun, 25 Jun 2023 14:06:28 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1qDWwC-000ESJ-5H; Sun, 25 Jun 2023 17:06:24 -0400
Date: Sun, 25 Jun 2023 17:05:59 -0400
From: John C Klensin <john-ietf@jck.com>
To: "Hakala, Juha E" <juha.hakala@helsinki.fi>, Peter Saint-Andre <stpeter@stpeter.im>
cc: urn@ietf.org
Message-ID: <0D2E8CF6A056B4B77C4A957D@PSB>
In-Reply-To: <HE1PR07MB319666615D051B10B7CC53EEFA21A@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> <2D3F6397996346B5CF98A9BF@PSB> <HE1PR07MB319666615D051B10B7CC53EEFA21A@HE1PR07MB3196.eurprd07.prod.outlook.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/urn/mX0uZGSsDk7FneWyZBNGmEH85Hs>
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: Sun, 25 Jun 2023 21:06:34 -0000

Juha,

About Finland in particular, this is just the information I
think was needed, so many thanks.

In that context, I think a paragraph in the NAN request/
documentation, and the NMN one when it arrives, should encourage
precisely the sorts of conversations, on a national level, that
you and your colleagues have had.  There is potential for
confusion.  The solution to it is communication and
understanding at the national level.  If, for whatever reason,
that isn't possible, it should not be the IETF's or IANA's
problem but a reminder, in the documentation and registry,
about its importance can, IMO, do no harm and will sometimes be
beneficial.

thanks again and all best regards,
   john


--On Sunday, June 25, 2023 18:55 +0000 "Hakala, Juha E"
<juha.hakala@helsinki.fi> wrote:

> Hello, 
> 
> I have discussed with the colleagues from the National Archive
> when they were preparing this request and can tell something
> about the background. 
> 
> URN:NANs will be used to identify archival collections (fonds)
> and records. As far as I know, URN:NBN has not been used for
> this purpose, and colleagues in the national archive are not
> aware of archives among URN:NBN users. There are 13 national
> URN:NBN sub-namespaces, and all of them have been registered
> by national libraries. 
> 
> National libraries may of course use URN:NAN to identify
> resources in archival collections. They just need to agree
> with the national archive on how to do that. And of course a
> national archive may use URN:NBN and URN:ISBN to publications
> in their collections. Our national archive has a library, and
> it could register a URN:NBN sub-namespace for itself. 
> 
> There are also some political and organizational issues that
> should be kept in mind. I am the registrant of URN:NBN, and I
> do understand at least in some level the needs national
> libraries may have in identifying their resources. Answering
> questions should not be impossible. I do not feel comfortable
> with the idea of extending the scope of URN:NBN to archives
> (and perhaps to museums in the future). I do not know the
> identifier systems they use, because they are organization
> specific; there are no standard identifiers like ISBN or ISSN.
> And I am not familiar with their needs, which are different
> from ours. For instance, unlike publications received via
> legal deposit, archival records are rarely kept forever.
> Therefore large percentage of URN:NANs will eventually resolve
> to tombstones.  
> 
> Colleagues in the national archive also felt that they will be
> more comfortable with having a namespace of their own.
> Libraries and archives are co-operating more closely now than
> before, but using a URN namespace called national bibliography
> number might still become a stumbling block in some countries. 
> 
> We have not discussed yet with the National Board of
> Antiquities about registering NMN (national museum number) but
> that may happen in the future. So I would like to lock that
> NID for the time being. One reason why museum sector will need
> URNs just like archives and libraries is that in Finland major
> libraries, archives and museums have a shared long term
> preservation system, and it is not possible to send documents
> to that system unless they have persistent identifier. 
> 
> All the best, 
> 
> Juha
> 
> -----Alkuperäinen viesti-----
> Lähettäjä: urn <urn-bounces@ietf.org> Puolesta John C
> Klensin Lähetetty: perjantai 23. kesäkuuta 2023 7.10
> Vastaanottaja: Peter Saint-Andre <stpeter@stpeter.im>
> Kopio: urn@ietf.org
> Aihe: Re: [urn] [IANA #1275238] URN:NAN registration request
> 
> Peter,
> 
> In my capacity as a long-ago dropout from the review effort, I
> have nonetheless let my curiosity get the best of me and read
> through the application.  It raises one question that I think
> would be usefully addressed: even if it is just an example to
> be considered by others, what recommendation would Finland
> make about when to use an NBN (RFC 8458 and mentioned in the
> application) and when to use an NAN?  Given that national
> entities make up their own rules, it would almost certainly be
> inappropriate to have a firm rule.  However, given that
> "national archives and their partner organizations" would
> often include the national libraries that are the assigners of
> NBNs, some advisory suggestions as to the boundary would, I
> think, be helpful.  If not, why not just use NBNs and assign
> subspace identifiers to the archives and such other their
> partners who are not already partners of the libraries?
> 
> best,
>    john
> 
> 
> --On Thursday, June 22, 2023 21:02 -0600 Peter Saint-Andre
> <stpeter@stpeter.im> wrote:
> 
>> 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
>>>> sallisarkisto.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