/
171.txt
1119 lines (918 loc) · 42.7 KB
/
171.txt
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
;; [1] [CODE(URI)@en[[[info:]]]] も参照。
Network Working Group H. Van de Sompel
Request for Comments: 4452 LANL
Category: Informational T. Hammond
[PRE[
NPG
E. Neylon
Manifest Solutions
S. Weibel
OCLC
April 2006
]PRE]
[PRE[
The "info" URI Scheme
for Information Assets with Identifiers in Public Namespaces
]PRE]
Status of This Memo
[PRE[
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
]PRE]
Copyright Notice
[PRE[
Copyright (C) The Internet Society (2006).
]PRE]
* Abstract
[PRE[
This document defines the "info" Uniform Resource Identifier (URI)
scheme for information assets with identifiers in public namespaces.
Namespaces participating in the "info" URI scheme are regulated by an
"info" Registry mechanism.
]PRE]
この文書は、公開名前空間の識別子により[[情報資産]]を識別する
[CODE(URI)@en[[[info]]]] [[統一資源識別子]] ([[URI]])
scheme を定義します。
[CODE(URI)@en[[[info]]]] [[URI scheme]]
に属する[[名前空間]]は [CODE(URI)@en[[[info]]]]
登録簿機構が統制します。
* Table of Contents
[PRE[
1. Introduction ....................................................3
1.1. Terminology ................................................3
1.2. Information Assets .........................................3
2. Application of the "info" URI Scheme ............................4
3. The "info" Registry .............................................5
3.1. Management Characteristics of the "info" Registry ..........5
3.2. Functional Characteristics of the "info" Registry ..........5
3.3. Maintenance of the "info" Registry .........................6
4. The "info" URI Scheme ...........................................6
4.1. Definition of "info" URI Syntax ............................6
4.2. Allowed Characters Under the "info" URI Scheme .............8
4.3. Examples of "info" URIs ....................................9
5. Normalization and Comparison of "info" URIs ....................10
6. Rationale ......................................................12
6.1. Why Create a New URI Scheme for Identifiers from Public
Namespaces? ...............................................12
6.2. Why Not Use an Existing URI Scheme for Identifiers
from Public Namespaces? ...................................12
6.3. Why Not Create a New URN Namespace ID for
Identifiers from Public Namespaces? .......................12
7. Security Considerations ........................................13
8. IANA Considerations ............................................14
9. Acknowledgements ...............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................15
]PRE]
* 1. Introduction
[PRE[
This document defines the "info" Uniform Resource Identifier (URI)
scheme for information assets that have identifiers in public
namespaces but are not part of the URI allocation. By "information
asset" this document intends any information construct that has
identity within a public namespace.
]PRE]
この文書は、公開名前空間に識別子を持つものの [[URI]]
割当の対象となっていない[[情報資産]]のための [CODE(URI)@en[[[info]]]]
[[統一資源識別子]] ([[URI]]) scheme を定義します。
この文書において[DFN[[[情報資産]]]]とは、
公開名前空間中で識別される情報構造を指します。
** 1.1. Terminology
[PRE[
In this document, the keywords "MUST", "MUST NOT", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "MAY", "MAY NOT", and "RECOMMENDED" are
to be interpreted as described in RFC 2119 [RFC2119] and indicate
requirement levels for compliant implementations.
]PRE]
** 1.2. Information Assets
[PRE[
There exist many information assets with identifiers in public
namespaces that are not referenceable by URI schemes. Examples of
such namespaces include Dewey Decimal Classifications [DEWEY],
Library of Congress Control Numbers [LCCN], NISO Serial Item and
Contribution Identifiers [SICI], NASA Astrophysics Data System
Bibcodes [BIBCODE], and National Library of Medicine PubMed
identifiers [PMID]. Other candidate namespaces include Online
Computer Library Center OCLC Numbers [OCLCNUM] and NISO OpenURL
Framework identifiers [OFI].
]PRE]
公開名前空間中の識別子を持つ、 [[URI scheme]]
により参照可能でない[[情報資産]]は多く存在します。
そのような名前空間の例としては、 [[デューイ十進分類法]]、
[[米国議会図書館管理番号]]、[[NISO逐次刊行物及び寄稿識別子]]、
[[NASA宇宙物理学データ・システム書誌符号]]、
[[米国国立医学図書館PubMed識別子]]などがあります。
その他の名前空間の候補としては、
[[オンライン計算機図書館センター]] [[PCLC番号]]や
[[NISO]] [[OpenURL枠組識別子]]があります。
[PRE[
The "info" URI scheme facilitates the referencing of information
assets that have identifiers in such public namespaces by means of
URIs. When referencing an information asset by means of its "info"
URI, the asset SHALL be considered a "resource" as defined in RFC
3986 [RFC3986] and SHALL enjoy the same common syntactic, semantic,
and shared language benefits that the URI presentation confers. As
such, the "info" URI scheme enables public namespaces that are not
part of the URI allocation to be represented within the allocation.
The "info" URI scheme thus provides a bridging mechanism to allow
public namespaces to become part of the URI allocation.
]PRE]
[CODE(URI)@en[[[info]]]] [[URI scheme]] は、
このような公開名前空間に識別子を持つ[[情報資産]]の [[URI]]
による参照を促進します。[[情報資産]]をその [CODE(URI)@en[[[info]]]]
[[URI]] により参照する時は、その[[情報資産]]は [[RFC 3986]]
で定義された[Q[[[資源]]]]と考慮し[['''なければなりません''']]し、
[[URI]] 表現により与えられる同じ共通の構文的、意味的、
そして共通言語の利益を享受し[['''なければなりません''']]。
ですから、 [CODE(URI)@en[[[info]]]] [[URI scheme]]
は [[URI]] が割当てられていなかった公開名前空間に [[URI]]
を割当てて使用することを可能とします。従いまして、 [CODE(URI)@en[[[info]]]]
[[URI scheme]] は公開名前空間が [[URI]] 割当の一部となるような橋梁機構を提供します。
[PRE[
Namespaces declared under the "info" URI scheme are regulated by an
"info" Registry mechanism. The "info" Registry allows a public
namespace that is not part of the URI allocation to be declared in a
registration process by the organization that manages it (the
Namespace Authority). The "info" Registry supports the declaration
of public namespaces that are not part of the URI allocation in a
manner that facilitates the construction of URIs for information
assets without imposing the burdens of independent URI registration
and maintenance of resource representations on the Namespace
Authority. Information assets identified within a registered
namespace SHALL be added or deleted according to the business
processes of the Namespace Authority, and yet MAY be referenced
within network applications via the "info" URI in an open,
standardized way without additional action on the part of the
Namespace Authority.
]PRE]
[PRE[
The "info" URI scheme exists primarily for identification purposes.
Implementations MUST NOT assume that an "info" URI can be
dereferenced to a representation of the resource identified by the
URI although Namespace Authorities MAY disclose in the registration
record references to service mechanisms pertaining to identifiers
from the registered namespace. Applications of the "info" URI scheme
are restricted to the identification of information assets and the
declaration of normalization rules for comparing identifiers of such
information assets regardless of whether any services relating to
such information assets are accessible via the Internet. References
to such services MAY be disclosed within an "info" registration
record, but these services SHALL NOT be regarded as authoritative.
The "info" URI scheme does not support global resolution methods.
]PRE]
* 2. Application of the "info" URI Scheme
[PRE[
Public namespaces that are used for the identification of information
assets and that are not part of the URI allocation MAY be registered
as namespaces within the "info" Registry. Namespace Authorities MAY
register these namespaces in the "info" Registry, thereby making
these namespaces available to applications that need to reference
information assets by means of a URI. Registrations of public
namespaces that are not part of the URI allocation by parties other
than the Namespace Authority SHALL NOT be permitted, thereby ensuring
against hostile usurpation or inappropriate usage of registered
service marks or the public namespaces of others.
]PRE]
[PRE[
Registration of a public namespace under the "info" Registry implies
no particular functionalities of the identifiers from the registered
namespace other than the identification of information assets. No
resolution mechanisms can be assumed for the "info" URI scheme,
though for any particular namespace there MAY exist mechanisms for
resolving identifiers to network services. The definition of such
services falls outside the scope of the "info" URI scheme.
Registration does not define namespace-specific semantics for
identifiers within a registered namespace, though allowable character
sets and normalization rules are specified in Sections 4 and 5 so as
to ensure that the URIs created using such identifiers are compliant
with applications that use URIs.
]PRE]
Van de Sompel, et al. Informational [Page 4]
[PRE[
RFC 4452 The "info" URI Scheme April 2006
]PRE]
[PRE[
The registration of a public namespace in the "info" Registry SHALL
NOT preclude further development of services associated with that
namespace that MAY qualify the namespace for additional publication
elsewhere within the URI allocation.
]PRE]
3. The "info" Registry
[PRE[
The "info" Registry provides a mechanism for the registration of
public namespaces that are used for the identification of information
assets and that are not part of the URI allocation.
]PRE]
[PRE[
NISO [NISO], the National Information Standards Organization, will
act as the Maintenance Agency for the "info" Registry and will
delegate the day-to-day operation of the "info" Registry to a
Registry Operator. As the Maintenance Agency, NISO will ensure that
the Registry Operator operates the "info" Registry in accordance with
a publicly articulated policy document established under NISO
governance and made available on the "info" website,
<http://info-uri.info/>. The "info" Registry policy defines a review
process for candidate namespaces and provides measures of quality
control and suitability for entry of namespaces.
]PRE]
3.1. Management Characteristics of the "info" Registry
[PRE[
The "info" Registry will be managed according to policies established
under the auspices of NISO. All such policies, as well as the
namespace declarations in the "info" Registry, will be public.
]PRE]
3.2. Functional Characteristics of the "info" Registry
[PRE[
The "info" Registry will be publicly accessible and will support
discovery (by both humans and machines) of:
]PRE]
[PRE[
o string literals identifying the namespaces for which the Registry
provides a guarantee of uniqueness and persistence
o names and contact information of Namespace Authorities
o syntax requirements for identifiers maintained in such namespaces
o normalization methodologies for identifiers maintained in such
namespaces
o network references to a description of service mechanisms (if any)
for identifiers maintained in such namespaces
o ancillary documentation
]PRE]
[PRE[
Registry entries refer to the corresponding "namespace" and
"identifier" components, which are defined in the ABNF given in
Section 4.1 of this document.
]PRE]
Van de Sompel, et al. Informational [Page 5]
[PRE[
RFC 4452 The "info" URI Scheme April 2006
]PRE]
3.3. Maintenance of the "info" Registry
[PRE[
The public namespaces that MAY be registered in the "info" Registry
will be those of interest to the communities served by NISO, and
therefore NISO is committed to act as Maintenance Authority for the
"info" Registry and to assign a Registry Operator to operate it.
]PRE]
[PRE[
NISO, a non-profit association accredited by the American National
Standards Institute (ANSI), identifies, develops, maintains, and
publishes technical standards to manage information in the digital
environment. NISO standards apply technologies to the full range of
information-related needs, including retrieval, re-purposing,
storage, metadata, and preservation.
]PRE]
[PRE[
Founded in 1939, incorporated as a not-for-profit education
association in 1983, and assuming its current name the following
year, NISO draws its support from the communities it serves. The
leaders of over 70 organizations in the fields of publishing,
libraries, IT, and media serve as its voting members. Hundreds of
experts and practitioners serve on NISO committees and as officers of
the association.
]PRE]
[PRE[
NISO has been designated by ANSI to represent US interests to the
International Organization for Standardization's (ISO) Technical
Committee 46 on Information and Documentation.
]PRE]
[PRE[
The NISO headquarters office is located at 4733 Bethesda Ave.,
Bethesda, MD 20814, USA. (For further information, see the NISO
website, <http://www.niso.org/>.)
]PRE]
* 4. The "info" URI Scheme
** 4.1. Definition of "info" URI Syntax
[PRE[
The "info" URI syntax presented in this document is conformant with
the generic URI syntax defined in RFC 3986 [RFC3986]. This
specification uses the Augmented Backus-Naur Form (ABNF) notation of
RFC 4234 [RFC4234] to define the URI. The following core ABNF
productions are used by this specification as defined by Appendix B.1
of RFC 4234: ALPHA, DIGIT, HEXDIG.
]PRE]
この文書に示す [CODE(URI)@en[[[info]]]] [[URI]] 構文は [[RFC 3986]]
で定義された共通 [[URI]] 構文に[[適合]]します。
この仕様書は [[URI]] を定義するために [[RFC 4234]] の[[増補バッカス・ナウア形式]]
([[ABNF}]) 記法を使います。 [[RFC 4234]] の附属書 B.1]]
で定義されている中核 [[ABNF]] [[生成規則]]
[CODE(ABNF)@en[[[ALPHA]]]]、[CODE(ABNF)@en[[[DIGIT]]]]、
[CODE(ABNF)@en[[[HEXDIG]]]] を使います。
[PRE[
The "info" URI syntax is presented in two parts. Part A contains
productions specific to the "info" URI scheme, while Part B contains
generic productions from RFC 3986 [RFC3986], which are repeated here
both for completeness and for reference. The following set of
productions (Part A) is specific to the "info" URI scheme:
]PRE]
[CODE(URI)@en[[[info]]]] [[URI]] 構文は二部に分けて示します。
A部は [CODE(URI)@en[[[info]]]] [[URI scheme]] に固有の[[生成規則]]です。
B部は [[RFC 3986]] にある共通の[[生成規則]]で、
完全性と参照のためにここに再録します。
次の[[生成規則]] (A部) は [CODE(URI)@en[[[info]]]]
[[URI scheme]] 固有のものです。
[PRE[
; Part A:
; productions specific to the "info" URI scheme
]PRE]
[PRE[
info-URI = info-scheme ":" info-identifier [ "#" fragment ]
]PRE]
[PRE[
info-scheme = "info"
]PRE]
[PRE[
info-identifier = namespace "/" identifier
]PRE]
[PRE[
namespace = scheme
]PRE]
[PRE[
identifier = *( pchar / "/" )
]PRE]
[PRE[
; Note that "info" URIs containing dot-segments (i.e., segments
; whose full content consists of "." or "..") MAY NOT be suitable
; for use with applications that perform dot-segment normalization
]PRE]
;; [CODE(URI)@en[[[info]]]] [[URI]] は[[点分節]]
(つまり、内容全体が [CODE(URI)[[[.]]]] や [CODE(URI)[[[..]]]]
であるような[[分節]]) は[[点分節正規化]]を行う[[応用]]で使うのには適切と[['''してはいけません''']]。
[PRE[
This next set of productions (Part B) are generic productions
reproduced from RFC 3986 [RFC3986]:
]PRE]
次の[[生成規則]] (B部) は [[RFC 3986]] の共通の[[生成規則]]を再録したものです。
[PRE[
; Part B:
; generic productions from RFC 3986 [RFC3986]
]PRE]
[PRE[
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
]PRE]
[PRE[
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
]PRE]
[PRE[
fragment = *( pchar / "/" / "?" )
]PRE]
[PRE[
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
]PRE]
[PRE[
pct-encoded = "%" HEXDIG HEXDIG
]PRE]
[PRE[
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
]PRE]
[PRE[
An "info" URI has an "info-identifier" as its scheme-specific part
and MAY take an optional "fragment" component. An "info-identifier"
is constructed by appending an "identifier" component to a
"namespace" component separated by a slash "/" character. The "info"
URI scheme is supportive of hierarchical processing as indicated by
the presence of the slash "/" character, although the slash "/"
character SHOULD NOT be interpreted as a strict hierarchy delimiter.
]PRE]
scheme 固有部として [CODE(ABNF)@en[[[info-identifier]]]]
を持つ [CODE(URI)@en[[[info]]]] [[URI]] は、任意選択の
[CODE(URI)@en[[[fragment]]]] 部品を保持[['''して構いません''']]。
[CODE(ABNF)@en[[[info-identifier]]]] は、
[CODE(ABNF)@en[[[namespace]]]] 部品の後に[[斜線]] [CODE(URI)[[[/]]]]
[[文字]]と [CODE(ABNF)@en[[[identifier]]]] 部品を連結して構築します。
[CODE(URI)@en[[[info]]]] [[URI scheme]] は[[斜線]] [CODE(URI)@en[[[/]]]]
[[文字]]を使うことにより階層的な処理に支援的です。
ただし、[[斜線]] [CODE(URI)@en[[[/]]]] [[文字]]は厳密な階層区切りとして解釈[['''するべきではありません''']]。
[PRE[
Values for the "namespace" component of the "info" URI are name
tokens composed of URI scheme characters only (cf. the "scheme"
production). They identify the public namespace in which the
(unescaped) value for the "identifier" component originates, and are
registered in the "info" Registry, which guarantees their uniqueness
and persistence. Although the "namespace" component is
case-insensitive, the canonical form is lowercase and documents that
specify values for the "namespace" component SHOULD do so using
lowercase letters. An implementation SHOULD accept uppercase letters
as equivalent to lowercase in "namespace" names, for the sake of
robustness, but SHOULD only generate lowercase "namespace" names, for
consistency.
]PRE]
[PRE[
Values for the "identifier" component of the "info" URI MAY be viewed
as being hierarchical strings composed of path segments built from
path segment characters (cf. the "pchar" production), the segments
being separated by slash "/" characters, although any semantic
interpretation of the "/" character as a hierarchy delimiter MUST NOT
be assumed. In their originating public namespace, the (unescaped)
values for the "identifier" component identify information assets.
The values for the "identifier" component MUST be %-escaped as
required by this syntax. The "identifier" component SHOULD be
treated as case-sensitive, although the "info" Registry MAY record
the case-sensitivity of identifiers from particular registered public
namespaces. The "info" Registry MAY also disclose additional
normalization rules regarding the treatment of punctuation characters
and the like.
]PRE]
[PRE[
Values for the "fragment" component of the "info" URI are strings
composed of path segment characters (cf. the "pchar" production) plus
the slash "/" character and the question mark "?" character. No
semantic role is assigned to the slash "/" character and the question
mark "?" character within the "fragment" component. The (unescaped)
values for the "fragment" component identify secondary information
assets with respect to the primary information asset, which is
referenced by the "info-identifier". The values for the "fragment"
component MUST be %-escaped as required by this syntax. The
"fragment" component MUST be treated as being case-sensitive.
]PRE]
** 4.2. Allowed Characters Under the "info" URI Scheme
[PRE[
The "info" URI syntax uses the same set of allowed US-ASCII
characters as specified in RFC 3986 [RFC3986] for a generic URI. An
"info" URI string SHOULD be represented as a Unicode [UNICODE] string
and be encoded in UTF-8 [RFC3629] form. Reserved characters as well
as excluded US-ASCII characters and non-US-ASCII characters MUST be
%-escaped before forming the URI. Details of the %-escape encoding
can be found in RFC 3986 [RFC3986], Section 2.4.
]PRE]
** 4.3. Examples of "info" URIs
[PRE[
Some examples of syntactically valid "info" URIs are given below:
]PRE]
[PRE[
a) info:ddc/22/eng//004.678
]PRE]
[PRE[
where "ddc" is the "namespace" component for a Dewey Decimal
Classification [DEWEY] namespace and "22/eng//004.678" is the
"identifier" component for an identifier of an information asset
within that namespace.
]PRE]
[PRE[
The information asset identified by the identifier "22/eng//004.678"
in the namespace for (22nd Ed.) English-language Dewey Decimal
Classifications is the classification
]PRE]
[PRE[
"Internet"
]PRE]
[PRE[
b) info:lccn/2002022641
]PRE]
[PRE[
where "lccn" is the "namespace" component for a Library of Congress
Control Number [LCCN] namespace and "2002022641" is the "identifier"
component for an identifier of an information asset within that
namespace.
]PRE]
[PRE[
The information asset identified by the identifier "2002022641" in
the namespace for Library of Congress Control Numbers is the metadata
record
]PRE]
[PRE[
"Newcomer, Eric. Understanding Web services: XML, WSDL,
SOAP, and UDDI. Boston: Addison-Wesley, 2002."
]PRE]
[PRE[
c) info:sici/0363-0277(19950315)120:5%3C%3E1.0.TX;2-V
]PRE]
[PRE[
where "sici" is the "namespace" component for a Serial Item and
Contribution Identifier [SICI] namespace and
"0363-0277(19950315)120:5%3C%3E1.0.TX;2-V" is the "identifier"
component for an identifier of an information asset in that namespace
in %-escaped form, or in unescaped form
"0363-0277(19950315)120:5<>1.0.TX;2-V".
]PRE]
[PRE[
The information asset identified by the identifier
"0363-0277(19950315)120:5<>1.0.TX;2-V" in the namespace for Serial
Item and Contribution Identifiers is the journal issue
]PRE]
[PRE[
"Library Journal, Vol. 120, no. 5. March 15, 1995."
]PRE]
[PRE[
d) <rdf:Description about="info:bibcode/2003Icar..163..263Z"/>
]PRE]
[PRE[
where "bibcode" is the "namespace" component for a NASA Astrophysics
Data System (ADS) Bibcode [BIBCODE] namespace and
"2003Icar..163..263Z" is the "identifier" component for an identifier
of an information asset within that namespace. This example further
shows an application of an "info" URI as the subject of a Resource
Description Framework (RDF) statement.
]PRE]
[PRE[
The information asset identified by the identifier
"2003Icar..163..263Z" in the namespace for NASA ADS Bibcodes is the
metadata record in the ADS system that describes the journal article
]PRE]
[PRE[
"K. Zahnle, P. Schenk, H. Levison and L. Dones, Cratering rates
in the outer Solar System, Icarus, 163 (2003) pp. 263-289."
]PRE]
[PRE[
e) info:pmid/12376099
]PRE]
[PRE[
where "pmid" is the "namespace" component for a PubMed Identifier
[PMID] namespace and "12376099" is the "identifier" component for an
identifier of an information asset in that namespace.
]PRE]
[PRE[
The information asset identified by the identifier "12376099" in the
namespace for PubMed Identifiers is the metadata record in the PubMed
database that describes the journal article
]PRE]
[PRE[
"Wijesuriya SD, Bristow J, Miller WL. Localization and analysis
of the principal promoter for human tenascin-X. Genomics. 2002
Oct;80(4):443-52."
]PRE]
* 5. Normalization and Comparison of "info" URIs
[PRE[
In order to facilitate comparison of "info" URIs, a sequence of
normalization steps SHOULD be applied as detailed below. After
normalizing the URI strings, comparison of two "info" URIs is then
applied on a character-by-character basis as prescribed by RFC 3986
[RFC3986], Section 6.2.1.
]PRE]
[CODE(URI)@en[[[info]]]] [[URI]] の[[比較]]を容易にするために、
次に詳述する[[正規化]]の手順を適用[['''するべきです''']]。
[[URI]] 文字列の[[正規化]]の後に、2つの [CODE(URI)@en[[[info]]]]
[[URI]] に対して [[RFC 3986]] で説明されている[[文字]]毎の比較を適用します。
[PRE[
The following generic normalization steps SHOULD anyway be applied by
applications processing "info" URIs:
]PRE]
[CODE(URI)@en[[[info]]]] [[URI]] を処理する[[応用]]は、
いずれにせよ次の共通の[[正規化]]手順を適用[['''するべきです''']]。
[PRE[
a) Normalize the case of the "scheme" component to be
lowercase
b) Normalize the case of the "namespace" component to be
lowercase
c) Unescape all unreserved %-escaped characters in the
"namespace" and "identifier" components
d) Normalize the case of any %-escaped characters in the
"namespace" and "identifier" components to be
uppercase
]PRE]
= [CODE(ABNF)@en[[[scheme]]]] 部品を[[小文字]]に[[正規化]]
= [CODE(ABNF)@en[[[namespace]]]] 部品を[[小文字]]に[[正規化]]
= [CODE(ABNF)@en[[[namespace]]]] 部品と [CODE(ABNF)@en[[[identifier]]]]
部品の[[百分率符号化]]された[[未予約文字]]をすべて[[復号]]
= [CODE(ABNF)@en[[[namespace]]]] 部品と [CODE(ABNF)@en[[[identifier]]]]
部品の[[百分率符号化]]された[[文字]]を[[大文字]]に[[正規化]]
[PRE[
Further normalization steps MAY be applied by applications to "info"
URIs based on rules recorded in the "info" Registry for a registered
public namespace, but such normalization steps remain outside of the
scope of the "info" URI definition.
]PRE]
[[応用]]は [CODE(URI)@en[[[info]]]] 登録簿で登録済み公開名前空間について記録されている規則に基づき
[CODE(URI)@en[[[info]]]] [[URI]] を更に[[正規化]][['''して構いません''']]が、
そのような[[正規化]]は [CODE(URI)@en[[[info]]]]
[[URI]] の定義の[[適用範囲]]外とします。
[PRE[
Since the "info" URI SHOULD be treated as being case-sensitive, a
canonical form MAY only be arrived at by consulting the "info"
Registry for possible information on the case-sensitivity for
identifiers from a registered public namespace, and any case
normalization step to apply. The "info" Registry MAY also disclose
additional normalization rules regarding the treatment of punctuation
characters and the like.
]PRE]
[CODE(URI)@en[[[info]]]] [[URI]]
は[[大文字・小文字を区別する]]ものと[['''するべきです''']]から、
登録済み公開名前空間の識別子が[[大文字]]・[[小文字]]を区別するかどうかの情報や[[大文字]]・[[小文字]]の[[正規化]]の方法についての情報は
[CODE(URI)@en[[[info]]]] 登録簿を調べることによりのみ到達[['''して構いません''']]。
[CODE(URI)@en[[[info]]]] [[登録簿]]は[[句読点文字]]等の取り扱いに関する[[正規化]]の規則についても公開[['''して構いません''']]。
[PRE[
In cases, however, where no single canonical form of the "identifier"
component exists, it is nevertheless RECOMMENDED that a Namespace
Authority nominate a preferred form, which SHOULD be used wherever
possible within an "info" URI so that applications MAY have an
increased chance of successful comparison of two "info" URIs.
]PRE]
しかし、 [CODE(ABNF)@en[[[identifier]]]] 部品に単一の[[正準形]]が存在しない場合であっても、
[[名前空間当局者]]は優先形を指定することを[['''推奨''']]し、
可能であれば常に [CODE(URI)@en[[[info]]]] [[URI]]
ではその優先形を使用[['''するべきです''']]し、
そうすれば[[応用]]は2つの [CODE(URI)@en[[[info]]]] [[URI]]
の比較に成功する機会が増加[['''して構いません''']]。
[PRE[
Note that "info" URIs containing dot-segments (i.e., segments whose
full content consists of "." or "..") MAY NOT be suitable for use
with applications that perform dot-segment normalization.
]PRE]
[[点分節]] (つまり、内容全体が [CODE(URI)[[[.]]]] または
[CODE(URI)[[[..]]]] である[[分節]]) を含む [CODE(URI)@en[[[info]]]] [[URI]]
は[[点分節正規化]]を行う[[応用]]で使うのに適切と[['''してはいけません''']]。
[PRE[
The following unnormalized forms of an "info" URI
]PRE]
[PRE[
U1. INFO:PII/S0888-7543(02)96852-7
U2. info:PII/S0888754302968527
U3. info:pii/S0888%2D7543%2802%2996852%2D7
U4. info:pii/s0888-7543(02)96852-7
]PRE]
[PRE[
are normalized to the following respective forms
]PRE]
[PRE[
N1. info:pii/S0888-7543(02)96852-7
N2. info:pii/S0888754302968527
N3. info:pii/S0888-7543(02)96852-7
N4. info:pii/s0888-7543(02)96852-7
]PRE]
[PRE[
The "info" URI definition does not prescribe further normalization
steps, although applications MAY apply additional normalization steps
according to any rules recorded in the "info" Registry for a
registered public namespace.
]PRE]
* 6. Rationale
** 6.1. Why Create a New URI Scheme for Identifiers from Public Namespaces?
[PRE[
Under RFC 4395, "Guidelines and Registration Procedures for New URI
Schemes" [RFC4395], it is stated in Section 2.1 "Demonstrable, New,
Long-Lived Utility" that "New URI schemes SHOULD have clear utility
to the broad Internet community, beyond that available with already
registered URI schemes". The "info" URI scheme allows identifiers
within public namespaces, used for the identification of information
assets, to be referred to within the URI allocation. Once a
namespace is registered in the "info" Registry, the "info" URI scheme
enables an information asset with an identifier in that namespace to
be referenced by means of a URI. As a result, the information asset
SHALL be considered a resource as defined in RFC 3986 [RFC3986] and
SHALL enjoy the same common syntactic, semantic, and shared language
benefits that the URI presentation confers.
]PRE]
** 6.2. Why Not Use an Existing URI Scheme for Identifiers from Public Namespaces?
[PRE[
Existing URI schemes are not suitable for employment as the "info"
URI scheme admits of no global dereference mechanism. While examples
of resource identifiers minted under other URI schemes MAY not always
be dereferenceable, nevertheless there is always a common expectation
that such URIs can be dereferenced by various resolution mechanisms,
whether they be location-dependent or location-independent resource
identifiers. The "info" URI scheme applies to a class of resource
identifiers whose Namespace Authorities MAY or MAY NOT choose to
disclose service mechanisms. Nevertheless, Namespace Authorities are
encouraged to disclose in the "info" registration record references
to any such service mechanisms in order to provide a greater utility
to network applications.
]PRE]
** 6.3. Why Not Create a New URN Namespace ID for Identifiers from Public Namespaces?
[PRE[
RFC 2141 [RFC2141] states that "Uniform Resource Names (URNs) are
intended to serve as persistent, location-independent, resource
identifiers". The "info" URI scheme, on the other hand, does not
assert the persistence of the identifiers created under this scheme
but rather of the public namespaces grandfathered under this scheme.
It exists primarily to disclose the identity of information assets
and to facilitate a lightweight registration mechanism for public
namespaces of identifiers managed according to the policies and
business models of the Namespace Authorities. The "info" URI scheme
is neutral with respect to identifier persistence. Moreover, for
"info" to operate as a URN Network Identifier (NID) would require
that "info" be constituted as a delegated naming authority. It is
not clear that a URN NID would be an appropriate choice for naming
authority delegation.
]PRE]
[PRE[
Further, the "info" URI scheme is not globally dereferenceable in
contrast to the specific recommendation given in RFC 1737,
"Functional Requirements for Uniform Resource Names" [RFC1737] that
"It is strongly recommended that there be a mapping between the names
generated by each naming authority and URLs". Individual Namespace
Authorities registered in the "info" Registry MAY, however, disclose
references to service mechanisms and are encouraged to do so.
]PRE]
[PRE[
An extra consideration is that the "urn" URI syntax explicitly
excludes generic URI hierarchy by reserving the slash "/" character.
An "info" URI, on the other hand, admits of hierarchical processing,
while remaining neutral with respect to supporting actual hierarchy,
and thus allows the slash "/" character (as well as more liberally
allowing the ampersand "&" and tilde "~" characters). It therefore
represents a lower barrier to entry for Namespace Authorities in
keeping with its intention of acting as a bridging mechanism to allow
public namespaces to become part of the URI allocation. In sum, an
"info" URI is more widely supportive of "human transcribability" as
discussed in RFC 3986 [RFC3986] than is a "urn" URI.
]PRE]
[PRE[
Additionally, the "urn" URI syntax does not support "fragment"
components as does the "info" URI syntax for indirect identification
of secondary resources.
]PRE]
* 7. Security Considerations
[PRE[
The "info" URI scheme syntax is subject to the same security
considerations as the generic URI syntax described in RFC 3986
[RFC3986].
]PRE]
[PRE[
While some "info" Namespace Authorities MAY choose to disclose
service mechanisms, any security considerations resulting from the
execution of such services fall outside the scope of this document.
It is strongly recommended that the registration record of an "info"
namespace include any such considerations.
]PRE]
* 8. IANA Considerations
[PRE[
The IANA registry for URI schemes
<http://www.iana.org/assignments/uri-schemes.html> SHOULD be updated
to include an entry for the "info" URI scheme when the "info" URI
scheme is accepted for publication as an RFC. This entry SHOULD
contain the following values:
]PRE]
[PRE[
Scheme Name: info
]PRE]
[PRE[
Description: Information Assets with Identifiers in Public
Namespaces
]PRE]
[PRE[
Reference: RFC 4452
]PRE]
* 9. Acknowledgements
[PRE[
The authors acknowledge the contributions of Michael Mealling,
Verisign, and Patrick Hochstenbach, Ghent University.
]PRE]
* 10. References
** 10.1. Normative References
[PRE[
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
]PRE]
[PRE[
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
]PRE]
[PRE[
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
]PRE]
[PRE[
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
]PRE]
[PRE[
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
]PRE]
[PRE[
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
]PRE]
[PRE[
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115, RFC
4395, February 2006.
]PRE]
[PRE[
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
4.0.0, defined by: The Unicode Standard, Version 4.0".
(Reading, MA, Addison-Wesley, 2003). ISBN 0-321-18578-1.
]PRE]
** 10.2. Informative References
[PRE[
[BIBCODE] "NASA Astrophysics Data System Bibliographic Code",
<http://adsdoc.harvard.edu/abs_doc/help_pages/data.html>.
]PRE]
[PRE[
[DEWEY] "Dewey Decimal Classification",
<http://www.oclc.org/dewey/>.
]PRE]
[PRE[
[LCCN] "Library of Congress Control Number",
<http://lcweb.loc.gov/marc/lccn_structure.html>.
]PRE]
[PRE[
[NISO] "National Information Standards Organization",
<http://www.niso.org/>.
]PRE]
[PRE[
[OCLCNUM] "Online Computer Library Center OCLC Control Number",
<http://www.oclc.org/bibformats/en/fixedfield/oclc.shtm>.
]PRE]
[PRE[
[OFI] "ANSI/NISO Z39.88-2004, "The OpenURL Framework for
Context-Sensitive Services", ISBN 1-880124-61-0",
<http://www.niso.org/standards/resources/Z39_88_2004.pdf>.
]PRE]
[PRE[
[PMID] "PubMed Overview", <http://www.ncbi.nlm.nih.gov/entrez/
query/static/overview.html>.
]PRE]
[PRE[
[SICI] "ANSI/NISO Z39.56-1996 (R2002), "Serial Item and
Contribution Identifier (SICI)", ISBN 1-880124-28-9",
<http://www.niso.org/standards/resources/Z39-56.pdf>.
]PRE]