summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8458.txt
blob: 3738ee19d2e90447c958ff4b2b190bb52de47f36 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
Internet Engineering Task Force (IETF)                         J. Hakala
Request for Comments: 8458               The National Library of Finland
Obsoletes: 3188                                             October 2018
Category: Informational
ISSN: 2070-1721


     Using National Bibliography Numbers as Uniform Resource Names

Abstract

   National Bibliography Numbers (NBNs) are used by national libraries
   and other organizations in order to identify resources in their
   collections.  NBNs are usually applied to resources that are not
   catered for by established (standard) identifier systems such as
   International Standard Book Number (ISBN).

   A Uniform Resource Name (URN) namespace for NBNs was established in
   2001 in RFC 3188.  Since then, a number of European national
   libraries have implemented URN:NBN-based systems.

   This document replaces RFC 3188 and defines how NBNs can be supported
   within the updated URN framework.  A revised namespace registration
   (version 4) compliant to RFC 8141 is included.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are candidates for any level of Internet
   Standard; see Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8458.











Hakala                        Informational                     [Page 1]
^L
RFC 8458                        NBN URNs                    October 2018


Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   5
   3.  Fundamental Namespace and Community Considerations for NBN  .   5
     3.1.  The URN:NBN Namespace . . . . . . . . . . . . . . . . . .   5
     3.2.  Community Considerations for NBNs . . . . . . . . . . . .   6
   4.  National Bibliography Number URNs . . . . . . . . . . . . . .   7
     4.1.  Assignment  . . . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . .   8
       4.2.1.  Usage of r-component and q-component  . . . . . . . .  10
       4.2.2.  Usage of f-component  . . . . . . . . . . . . . . . .  10
     4.3.  Encoding Considerations and Lexical Equivalence . . . . .  10
     4.4.  Resolution and Persistence of NBN-based URNs  . . . . . .  12
     4.5.  Additional Considerations . . . . . . . . . . . . . . . .  13
   5.  URN Namespace ID (NID) Registration for the National
       Bibliography Number (NBN) . . . . . . . . . . . . . . . . . .  13
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
   Appendix A.  Significant Changes from RFC 3188  . . . . . . . . .  18
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  18









Hakala                        Informational                     [Page 2]
^L
RFC 8458                        NBN URNs                    October 2018


1.  Introduction

   One of the basic permanent Uniform Resource Identifier (URI) schemes
   (cf. [RFC3986] and [IANA-URI]) is Uniform Resource Name (URN).  URNs
   were originally defined in RFC 2141 [RFC2141].  In 2017, a revision
   was adopted with new definitions and registration procedures
   [RFC8141].  Any traditional identifier, when used within the URN
   system, must have a namespace of its own that is registered with IANA
   [IANA-URN].  National Bibliography Number (NBN) is one such
   namespace, specified in 2001 in RFC 3188 [RFC3188].

   This document describes the syntax and usage of NBN URNs and updates
   the registration of the associated URN namespace.  This document
   additionally describes certain policy assumptions about how national
   libraries and their partner organizations partition, delegate, and
   manage the namespace.  Violation of those assumptions could impact
   the utility of the NBN URN namespace.

   URN:NBNs are in production use in several European countries
   including (in alphabetical order) Austria, Finland, Germany, Hungary,
   Italy, the Netherlands, Norway, Sweden, and Switzerland.  The URN:NBN
   namespace is collectively managed by these national libraries.  URN:
   NBNs have been applied to diverse content including Web archives,
   digitized materials, research data, and doctoral dissertations.  They
   can be used by national libraries and organizations cooperating with
   them.

   As a part of the initial development of the URN system in the late
   1990s, the IETF URN Working Group agreed that it was important to
   demonstrate that the URN syntax can accommodate existing identifier
   systems.  RFC 2288 [RFC2288] investigated the feasibility of using
   ISBN, ISSN, and SICI (Serial Item and Contribution Identifier) as
   URNs, with positive results; however, it did not formally register
   corresponding URN namespaces.  (For further discussion of how these
   systems have evolved as URNs, see RFC 8254 [RFC8254].)  This was in
   part due to the still-evolving process to formalize criteria for
   namespace definition documents and registration.  The criteria were
   consolidated later in the IETF, first in RFC 2611 [RFC2611], then RFC
   3406 [RFC3406], and now RFC 8141 [RFC8141].

   URN namespaces have been registered for NBN, ISBN, and ISSN in RFCs
   3188 [RFC3188], 3187 [RFC3187], and 3044 [RFC3044], respectively.
   ISBN and ISSN namespaces were made compliant with RFC 8141 [RFC8141]
   in 2017 by publishing revised ISSN [ISSN-namespace] and ISBN
   [ISBN-namespace] namespace registrations.






Hakala                        Informational                     [Page 3]
^L
RFC 8458                        NBN URNs                    October 2018


   The term "National Bibliography Number" encompasses persistent local
   identifier systems that national libraries and their partner
   organizations use in addition to the more formally (and
   internationally) established identifiers.  These partner
   organizations include universities and their libraries and other
   subsidiaries, other research institutions, plus governmental and
   public organizations.  Some national libraries maintain a significant
   number of these liaison relationships; for instance, the German
   National Library had almost 400 by early 2018 [NBN-Resolving].

   In practice, NBN differs from standard identifier systems such as
   ISBN and ISSN because it is not a single identifier system with
   standard-specified scope and syntax.  Each NBN implementer creates
   its own system with its own syntax and assignment rules.  Each user
   organization is also obliged to keep track of how NBNs are being
   used; however, within the generic framework set in this document,
   local NBN assignment policies may vary considerably.

   Historically, NBNs have been applied in the national bibliographies
   to identify the resources catalogued into them.  Prior to the
   emergence of bibliographic standard identifiers in the early 1970s,
   national libraries assigned NBNs to all catalogued publications.

   Since the late 1990s, the NBN scope has been extended to cover a vast
   range of resources, both originally digital and digitized.  Only a
   small subset of these resources is catalogued in the national
   bibliographies or other bibliographic databases.  Digitized resources
   and their component parts (such as still images in books or journal
   articles) are examples of resources that may get NBNs.

   It is possible to extend the scope of the NBN much further.  The
   National Library of Finland is using them in the Finnish National
   Ontology Service Finto to identify corporate names (see
   <http://finto.fi/cn/en/>).  Using NBNs to identify metadata elements
   provides a stable basis for creation of linked data.

   Simple guidelines for using NBNs as URNs and the original namespace
   registration were published in RFC 3188 [RFC3188].  The RFC at hand
   replaces RFC 3188; sections discussing the methods by which URN:NBNs
   should be resolved have been updated, unused features have been
   eliminated, and the text is compliant with the stipulations of the
   revised URN specification [RFC8141].









Hakala                        Informational                     [Page 4]
^L
RFC 8458                        NBN URNs                    October 2018


2.  Conventions Used in This Document

   "NBN" refers to any National Bibliography Number identifier system
   used by the national libraries (or equivalent organizations) and
   other institutions, which use these identifiers with national
   libraries' support and permission.

   In this memo, "URN:NBN" is used as a shorthand for "NBN-based URN".

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Fundamental Namespace and Community Considerations for NBN

3.1.  The URN:NBN Namespace

   NBNs are widely used to identify both hand-held and digital resources
   in the collections of national libraries and other institutions that
   are responsible for preserving the cultural heritage of their
   constituents.  Resources in these collections are usually preserved
   for a long time (i.e., for centuries).  While the preferred methods
   for digital preservation may vary over time and depend on the
   content, the favorite one has been migration.  Whenever necessary, a
   resource in an outdated file format is migrated into a more modern
   file format.  To the extent possible, all old versions of the
   resource are also kept in order to alleviate the negative effects of
   partially successful migrations and the gradual loss of original look
   and feel that may accompany even fully successful migrations.  When
   NBN is used to identify manifestations and there are many of them for
   a single work, local policy can require that each manifestation ought
   to have its own NBN.

   NBNs are typically used to identify objects for which standard
   identifiers such as ISBN are not applicable.  However, NBNs can be
   used for component resources even when the resource as a whole
   qualifies for a standard identifier.  For instance, if a digitized
   book has an ISBN, JPEG image files of its pages might be assigned
   NBNs.  These URN:NBNs can be used as persistent links to the pages.

   The scope of standard identifier systems such as ISBN and ISSN is
   limited; they are applicable only to certain kinds of resources.  One
   of the roles of the NBN is to fill in the gaps left by the standard
   identifiers.  Collectively, these identifiers and NBNs cover all
   resources that national libraries and their partners need to include
   in their collections.



Hakala                        Informational                     [Page 5]
^L
RFC 8458                        NBN URNs                    October 2018


   Section 4 below, and particularly Section 4.1, present a more
   detailed overview of the structure of the NBN namespace, related
   institutions, and the identifier assignment principles used.

3.2.  Community Considerations for NBNs

   National libraries are the key organizations providing persistent URN
   resolution services for resources identified with NBNs, independent
   of their form.  As coordinators of NBN usage, national libraries have
   allowed other organizations, such as university libraries or
   governmental organizations, to assign NBNs to the resources these
   organizations preserve for the long term.  In such case, the national
   library coordinates the use of NBNs at the national level.  National
   libraries can also provide URN resolution services and technical
   services to other NBN users.  These organizations are expected to
   either establish their own URN resolution services or use the
   technical infrastructure provided by the national library.  URN:NBNs
   are expected to be resolvable and support one or more resolution
   services.

   Although NBNs can be used to identify component resources, the NBN
   namespace does not specify a generic, intrinsic syntax for doing
   that.  However, there are at least two different ways in which
   component resources can be taken into account within the NBN
   namespace.

   The simplest and probably the most common approach is to assign a
   separate NBN for each component resource, such as a file containing a
   digitized page of a book, and make no provisions to make such NBNs
   discernible in a systematic way from others.

   Second, if the stipulations of the URI generic syntax [RFC3986] and
   the Internet media type specification [RFC2046] are met, in
   accordance with the provisions in RFC 8141 [RFC8141], the URN
   f-component can be attached to URN:NBNs in order to indicate the
   desired location within the resource supplied by URN resolution.

   From the library community point of view, it is important that the
   f-component is not a part of the Namespace-Specific String (NSS), and
   therefore f-component attachment does not mean that the relevant
   component part is identified.  Moreover, the resolution process still
   retrieves the entire resource even if there is an f-component.  The
   component part selection is applied by the resolution client (e.g.,
   browser) to the resource returned by the resolution process.  In
   other words, in this latter case the component parts are just logical
   and physical parts of the identified resource whereas in the former
   cases they are independently named entities.




Hakala                        Informational                     [Page 6]
^L
RFC 8458                        NBN URNs                    October 2018


   Resources identified by NBNs are not always available in the
   Internet.  If one is not, the URN:NBN can resolve to a surrogate such
   as a metadata record describing the identified resource.

   Section 4 below, and particularly Section 4.4, presents a detailed
   overview of the application of the URN:NBN namespace as well as the
   principles of, and systems used for, the resolution of NBN-based
   URNs.

4.  National Bibliography Number URNs

4.1.  Assignment

   National Bibliography Number (NBN) is a generic term referring to a
   group of identifier systems administered by national libraries and
   institutions authorized by them.  The NBN assignment is typically
   performed by the organization hosting the resource.  National
   libraries are committed to permanent preservation of their deposit
   collections.

   Assignment of NBN-based URNs is controlled on a national level by the
   national library (or national libraries, if there is more than one).
   National guidelines can differ, but the identified resources
   themselves are usually persistent.

   Different national URN:NBN assignment policies have resulted in
   varying levels of control of the assignment process.  Manual URN:NBN
   assignment by the library personnel provides the tightest control,
   especially if the URN:NBNs cover only resources catalogued into the
   national bibliography.  In most national libraries, the scope of
   URN:NBN is already much broader than this.  Usage rules can vary
   within one country, from one URN:NBN sub-namespace to the next.

   Each national library uses NBNs independently of other national
   libraries; apart from this document, there are no guidelines that
   specify or control NBN usage.  As such, NBNs are unique only on the
   national level.  When used as URNs, base NBN 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) [ISO3166-1].  These prefixes guarantee
   uniqueness of the URN:NBNs at the global scale [ISO3166MA].

   National libraries using URN:NBNs usually specify local assignment
   policies for themselves.  Such policy can limit the URN:NBN usage to,
   e.g., the resources stored in the national library's digital
   collections or databases.  Although this specification does not





Hakala                        Informational                     [Page 7]
^L
RFC 8458                        NBN URNs                    October 2018


   specify principles for URN:NBN assignment policies that can be
   applied, NBNs assigned to short-lived resources should not be made
   URN:NBNs unless such policy can be justified.

   URN:NBN assignment policy can clarify, for instance, the local policy
   concerning identifier assignment to component parts of resources and
   can specify, with sufficient detail, the syntax of local component
   identifiers (if there is one as a discernible part of the NBNs).  The
   policy can also cover any employed extensions to the default NBN
   scope.

   NBNs as such are locally but not globally unique; two national
   libraries can assign the same NBN to different resources.  A prefix,
   based on the ISO country code as described above, guarantees the
   global uniqueness of URN:NBNs.  Once an NBN has been assigned to a
   resource, it MUST be persistent, and therefore URN:NBNs are
   persistent as well.

   A URN:NBN, once it has been generated from a NBN, MUST NOT be reused
   for another resource.

   Users of the URN:NBN namespace MUST ensure that they do not assign
   the same URN:NBN twice.  Different policies can be applied to
   guarantee this.  For instance, NBNs and corresponding URN:NBNs 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 NBNs.

4.2.  Syntax

   The Namespace-Specific String (NSS) will consist of three parts:

   o  a prefix consisting of an ISO 3166-1 alpha-2 country code and
      optional sub-namespace code(s) separated by a colon(s);

   o  a hyphen (-) as the delimiting character; and,

   o  an NBN string assigned by the national library or sub-delegated
      authority.












Hakala                        Informational                     [Page 8]
^L
RFC 8458                        NBN URNs                    October 2018


   The following formal definition uses ABNF [RFC5234].

    nbn-nss     = prefix "-" nbn-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 library to which the branch
                ; is delegated).

    subspc      = 1*(ALPHA / DIGIT)
                ; As assigned by the respective national library.

    nbn-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 nbn_string is determined by the
   authority for the prefix.  Whereas the prefix is regarded as case
   insensitive, NBN 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 NBN string.  Within the NBN 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 library 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



Hakala                        Informational                     [Page 9]
^L
RFC 8458                        NBN URNs                    October 2018


   to lower or upper case as they see fit; they only need to do it
   consistently.

4.2.1.  Usage of r-component and q-component

   URN:NBN resolvers do not currently support the use of either
   r-component or q-component.

   Resolution services based on r-component can be implemented in the
   future when the r-component syntax and semantics have been specified.

4.2.2.  Usage of f-component

   If URN:NBN resolves to the identified resource and the media type of
   the resource supports f-component usage, it can be used to indicate a
   location within the identified resource.  Persistence is achieved if
   the URN:NBN is assigned to one and only one version of a resource,
   such as a PDF/A version of a book.

   The URN:NBN namespace does not impose any restrictions of its own on
   f-component usage.

4.3.  Encoding Considerations and Lexical Equivalence

   Expressing NBNs as URNs is usually straightforward, as normally only
   ASCII characters are used in NBN strings.  If this is not the case,
   non-ASCII characters in NBNs MUST be translated into canonical form
   as specified in RFC 8141.  If a national library uses NBNs that can
   contain percent-encoded characters higher than U+007F, the library
   needs to carefully define the canonical transformation from these
   NBNs into URNs, including normalization forms.

   When an NBN is used as a URN, the NSS MUST consist of three parts:

   o  a prefix, structured as a primary prefix, which is a two-letter
      ISO 3166-1 country code of the library's country, and zero or more
      secondary prefixes that are each indicated by a delimiting colon
      character (:) and a sub-namespace identifier;

   o  a hyphen (-) as a delimiting character; and,

   o  the NBN string.

   Different delimiting characters are not semantically equivalent.

   The syntax and roles of the three parts listed above are described in
   Section 4.2.




Hakala                        Informational                    [Page 10]
^L
RFC 8458                        NBN URNs                    October 2018


   If there are several national libraries in one country, these
   libraries MUST agree on how to divide the national namespace between
   themselves using this method before the URN:NBN assignment begins in
   any of these libraries.

   A national library MAY also assign URN:NBN sub-namespaces to trusted
   organizations such as universities or 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
   library 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:NBNs are lexically equivalent if they are octet-
   by-octet equal after the following (conceptional) preprocessing:

   1.  convert all characters in the leading "urn:nbn:" 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:NBN:<ISO 3166 alpha-2 country code>-<assigned NBN string>

      URN:NBN:<ISO 3166 alpha-2 country code>:<sub-namespace code>-\
      <assigned NBN string>

   Examples:

      URN:NBN:fi-fe201003181510

      urn:nbn:ch:bel-9039

      urn:nbn:se:uu:diva-3475

      urn:nbn:hu-3006







Hakala                        Informational                    [Page 11]
^L
RFC 8458                        NBN URNs                    October 2018


4.4.  Resolution and Persistence of NBN-based URNs

   Eventually, URNs might be resolved with the help of a Global Resolver
   Discovery Service (GRDS), and URN:NBN syntax makes it possible to
   locate the relevant resolver.  Since no GRDS system has been
   installed yet in the Internet, URN:NBNs are embedded in HTTP URIs in
   order to make them actionable in the present Internet.  In these HTTP
   URIs, the authority part must point to the appropriate URN resolution
   service.  For instance, in Finland, the address of the national URN
   resolver is <http://urn.fi>.  Thus, the HTTP URI for the Finnish URN
   in the example above is <http://urn.fi/URN:NBN:fi-fe201003181510>.

   The country-code-based prefix part of the URN:NBN namespace-specific
   string will provide a hint needed to find the correct resolution
   service for URN:NBNs from the GRDS when it is established.

   There are three interrelated aspects of persistence that need to be
   discussed: persistence of the objects itself, persistence of the
   identifier, and persistence of the URN resolvers.

   NBNs have traditionally been assigned to printed resources, which
   tend to be persistent.  In contrast, digital resources require
   frequent migrations to guarantee accessibility.  Although it is
   impossible to estimate how often migrations are needed, hardware and
   software upgrades take place frequently, and a lifetime exceeding
   10-20 years can be considered as long.

   However, it is a common practice to keep also the original and
   previously migrated versions of resources.  Therefore, even outdated
   versions of resources can be available in digital archives, no matter
   how old or difficult to use they have become.

   If all versions of a resource are kept, a user who requires
   authenticity can retrieve the original version of the resource,
   whereas a user to whom the ease of use is a priority is likely to be
   satisfied with the latest version.  In order to enable the users to
   find the best match, a national library can link all manifestations
   of a resource to each other so as to make a user aware of them.

   Thus, even if specific versions of digital resources are not normally
   persistent, persistent identifiers such as URN:NBNs support
   information architectures that enable persistent access to any
   version of the resource, including ones that can only be utilized by
   using digital archaeology tools such as custom-made applications to
   render the resource.






Hakala                        Informational                    [Page 12]
^L
RFC 8458                        NBN URNs                    October 2018


   Persistence of URN resolvers themselves is mainly an organizational
   issue that is related to the persistence of organizations maintaining
   them.  As URN:NBN resolution services will be supplied (primarily) by
   the national libraries, these services are likely to be long lived.

4.5.  Additional Considerations

   It is a good idea to apply URN:NBNs (or other persistent identifiers)
   to all resources that have been prioritized in the organization's
   digital preservation plan.

   Assignment of URN:NBNs to resources that are known to not be
   persistent should be considered carefully.  URN:NBNs can, however, be
   applied to resources that have a low-level preservation priority and
   will not be migrated to more modern file formats or preserved via
   emulation.

   If the identified version of a resource has disappeared, the
   resolution process can supply a surrogate if one exists.  A surrogate
   can be, for instance, a more modern digital version of the original
   electronic resource.

5.  URN Namespace ID (NID) Registration for the National Bibliography
    Number (NBN)

   This URN namespace registration describes how National Bibliography
   Numbers (NBNs) can be supported within the URN framework; it uses the
   updated IANA template specified in RFC 8141.

   Namespace Identifier:  NBN
      This namespace ID was formally assigned to the National
      Bibliography Number in October 2001, when the namespace was
      registered officially [RFC3188].  Utilization of URN:NBNs had
      started in demo systems already in 1998.  Since 2001, tens of
      millions of URN:NBNs have been assigned.  The number of users of
      the namespace has grown in two ways: new national libraries have
      started using NBNs, and many national libraries using the system
      have formed new liaisons.

   Version:  4

   Date:  2018-04-09









Hakala                        Informational                    [Page 13]
^L
RFC 8458                        NBN URNs                    October 2018


   Registrant:
      Name: Juha Hakala
      Affiliation: Senior Adviser, The National Library of Finland
      Email: juha.hakala@helsinki.fi
      Postal: P.O. Box 15, 00014 Helsinki University, Finland
      Web URL: http://www.nationallibrary.fi/

      The National Library of Finland registered the namespace on behalf
      of the Conference of the European National Librarians (CENL) and
      Conference of Directors of National Libraries (CDNL).  The NBN
      namespace is available for free for the national libraries.  They
      can allow other organizations to assign URN:NBNs and use the
      resolution services established by the library for free or for a
      fee.  The fees, if collected, can be based on, e.g., the
      maintenance costs of the system.

   Purpose:  See Section 3 of RFC 8458

   Syntax:  See Section 4.2 of RFC 8458

   Assignment:  See Section 4.1 of RFC 8458

   Security and Privacy:  See Section 7 of RFC 8458

   Interoperability:
      National libraries and their partners usually apply URN:NBNs if a
      standard identifier such as ISBN is not applicable for the
      resource to be identified.  Some overlap with other URN namespaces
      is possible.

      URN:NBNs may contain characters which must be percent-encoded, but
      usually they consist of printable ASCII characters only.

   Resolution:  See Section 4.4 of RFC 8458

   Documentation:  RFC 8458

   Revision Information:
      This version of the URN:NBN namespace registration has been
      updated to use the revised definition of URN syntax from RFC 8141,
      although usage of r-components is not specified yet.  In addition,
      non-ISO 3166 (country code) based NBNs have been deleted due to
      lack of deployment.  The entire NBN prefix is now specified to be
      case insensitive in accordance with established practice.  This
      version also includes numerous clarifications based on actual
      usage of URN:NBNs.





Hakala                        Informational                    [Page 14]
^L
RFC 8458                        NBN URNs                    October 2018


6.  IANA Considerations

   IANA has updated the existing registration of the formal URN
   namespace, "NBN", using the template given above in Section 5.

7.  Security Considerations

   This document defines means of encoding NBNs as URNs.  A URN
   resolution service for NBN-based URNs is depicted but only at a
   generic level; 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), NBNs 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 NBNs programmatically.

   Issues regarding intellectual property rights associated with objects
   identified by the URN:NBNs are beyond the scope of this document, as
   are questions about rights to the databases that might be used to
   construct resolution services.

   Beyond the generic security considerations laid out in the underlying
   documents listed in the Normative References, no specific security
   threats have been identified for NBN-based URNs.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.




Hakala                        Informational                    [Page 15]
^L
RFC 8458                        NBN URNs                    October 2018


   [RFC8141]  Saint-Andre, P. and J. Klensin, "Uniform Resource Names
              (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
              <https://www.rfc-editor.org/info/rfc8141>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [IANA-URI] IANA, "Uniform Resource Identifier (URI) Schemes",
              <http://www.iana.org/assignments/uri-schemes>.

   [IANA-URN] IANA, "Uniform Resource Names (URN) Namespaces",
              <http://www.iana.org/assignments/urn-namespaces>.

   [ISBN-namespace]
              Griffiths, S., "Namespace Registration for International
              Standard Book Number (ISBN) ISO 2108:2017",
              <https://www.iana.org/assignments/urn-formal/isbn>.

   [ISO3166-1]
              ISO, "Codes for the representation of names of countries
              and their subdivisions -- Part 1: Country codes",
              ISO 3166-1:2013, November 2013,
              <https://www.iso.org/standard/63545.html>.

   [ISO3166MA]
              ISO, "ISO 3166 Country Codes",
              <https://www.iso.org/iso/country_codes.htm>.

   [ISSN-namespace]
              Bequet, G., "Namespace Registration for International
              Standard Serial Number (ISSN) and Linking ISSN (ISSN-L)
              based on ISO 3297:2007", June 2017,
              <https://www.iana.org/assignments/urn-formal/issn>.

   [NBN-Resolving]
              Deutsche Nationalbibliothek, "URN:NBN Resolver fuer
              Deutschland und Schweiz: Information ueber Partner
              Institutionen", <https://nbn-resolving.org/institutions>.

   [PERSID]   PersID initiative, 2009-2011, "persid: Building a
              persistent identifier infrastructure",
              <http://www.persid.org>.






Hakala                        Informational                    [Page 16]
^L
RFC 8458                        NBN URNs                    October 2018


   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              DOI 10.17487/RFC2046, November 1996,
              <https://www.rfc-editor.org/info/rfc2046>.

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
              May 1997, <https://www.rfc-editor.org/info/rfc2141>.

   [RFC2288]  Lynch, C., Preston, C., and R. Daniel, "Using Existing
              Bibliographic Identifiers as Uniform Resource Names",
              RFC 2288, DOI 10.17487/RFC2288, February 1998,
              <https://www.rfc-editor.org/info/rfc2288>.

   [RFC2611]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "URN Namespace Definition Mechanisms", BCP 33, RFC 2611,
              DOI 10.17487/RFC2611, June 1999,
              <https://www.rfc-editor.org/info/rfc2611>.

   [RFC3044]  Rozenfeld, S., "Using The ISSN (International Serial
              Standard Number) as URN (Uniform Resource Names) within an
              ISSN-URN Namespace", RFC 3044, DOI 10.17487/RFC3044,
              January 2001, <https://www.rfc-editor.org/info/rfc3044>.

   [RFC3187]  Hakala, J. and H. Walravens, "Using International Standard
              Book Numbers as Uniform Resource Names", RFC 3187,
              DOI 10.17487/RFC3187, October 2001,
              <https://www.rfc-editor.org/info/rfc3187>.

   [RFC3188]  Hakala, J., "Using National Bibliography Numbers as
              Uniform Resource Names", RFC 3188, DOI 10.17487/RFC3188,
              October 2001, <https://www.rfc-editor.org/info/rfc3188>.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", RFC 3406, DOI 10.17487/RFC3406, October 2002,
              <https://www.rfc-editor.org/info/rfc3406>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC8254]  Klensin, J. and J. Hakala, "Uniform Resource Name (URN)
              Namespace Registration Transition", RFC 8254,
              DOI 10.17487/RFC8254, October 2017,
              <https://www.rfc-editor.org/info/rfc8254>.





Hakala                        Informational                    [Page 17]
^L
RFC 8458                        NBN URNs                    October 2018


Appendix A.  Significant Changes from RFC 3188

   Numerous clarifications have been made based on a decade of
   experience with RFC 3188.

   NBNs that are not based on ISO 3166 (country codes) have been removed
   due to lack of usage.

   In accordance with established practice, the whole NBN prefix is now
   declared case insensitive.

   The document is based on the new URN syntax specification, RFC 8141.

   Use of query components and fragment components with this namespace
   is now specified in accordance with RFC 8141.

Acknowledgements

   Revision of RFC 3188 started during the project PersID [PERSID].
   Later, the revision was included in the charter of the URNbis Working
   Group and worked on in that group in parallel with what became RFCs
   8141 and 8254.  The author wishes to thank his colleagues in the
   PersID project and the URNbis participants for their support and
   review comments.

   Tommi Jauhiainen has provided feedback on an early draft version of
   this document.  The author wishes to thank Tommi Jauhiainen, Bengt
   Neiss, and Lars Svensson for the comments they have provided to
   various draft versions of this document.

   John Klensin provided significant editorial and advisory support for
   later draft versions of the document.

Contributors

   This document would not have been possible without contributions by
   Alfred Hoenes.

Author's Address

   Juha Hakala
   The National Library of Finland
   P.O. Box 26
   FIN-00014 Helsinki University
   Finland

   Email: juha.hakala@helsinki.fi




Hakala                        Informational                    [Page 18]
^L