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

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
> 
> -----Alkuperäinen viesti-----
> Lähettäjä: urn <[email protected]> Puolesta John C
> Klensin Lähetetty: maanantai 26. kesäkuuta 2023 20.10
> Vastaanottaja: Lars G. Svensson <[email protected]>;
> [email protected] Kopio: [email protected]
> 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"
> <[email protected]> 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:[email protected]] Im Auftrag von Peter 
>> Saint-Andre Gesendet: Freitag, 23. Juni 2023 05:03
>> An: [email protected]
>> Cc: [email protected]
>> Betreff: Re: [urn] [IANA #1275238] URN:NAN registration
>> request
>> 
>> Dear Amanda:
>> 
>> [moving [email protected] to bcc]
>> 
>> Procedurally, as defined in RFC 8141, registrants are to send
>> their  requests to the [email protected] 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: [email protected]
>>> 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, [email protected]
>>> 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
>>>> [email protected]<mailto:lauri.leinonen@kan
>>>> sallisark isto.fi>
>>> 
>>> _______________________________________________
>>> urn mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/urn
>> 
>> _______________________________________________
>> urn mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/urn
>> 
>> _______________________________________________
>> urn mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/urn
> 
> 
> _______________________________________________
> urn mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/urn




_______________________________________________
urn mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/urn