File: rfc2141.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (451 lines) | stat: -rw-r--r-- 14,077 bytes parent folder | download | duplicates (8)
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






Network Working Group                                           R. Moats
Request for Comments: 2141                                          AT&T
Category: Standards Track                                       May 1997


                               URN Syntax

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers. This document sets
   forward the canonical syntax for URNs.  A discussion of both existing
   legacy and new namespaces and requirements for URN presentation and
   transmission are presented.  Finally, there is a discussion of URN
   equivalence and how to determine it.

1. Introduction

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers and are designed to make
   it easy to map other namespaces (which share the properties of URNs)
   into URN-space. Therefore, the URN syntax provides a means to encode
   character data in a form that can be sent in existing protocols,
   transcribed on most keyboards, etc.

2. Syntax

   All URNs have the following syntax (phrases enclosed in quotes are
   REQUIRED):

                     <URN> ::= "urn:" <NID> ":" <NSS>

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading "urn:" sequence is case-insensitive.
   The Namespace ID determines the _syntactic_ interpretation of the
   Namespace Specific String (as discussed in [1]).







Moats                       Standards Track                     [Page 1]

RFC 2141                       URN Syntax                      May 1997


   RFC 1630 [2] and RFC 1737 [3] each presents additional considerations
   for URN encoding, which have implications as far as limiting syntax.
   On the other hand, the requirement to support existing legacy naming
   systems has the effect of broadening syntax.  Thus, we discuss the
   acceptable syntax for both the Namespace Identifier and the Namespace
   Specific String separately.

2.1 Namespace Identifier Syntax

   The following is the syntax for the Namespace Identifier. To (a) be
   consistent with all potential resolution schemes and (b) not put any
   undue constraints on any potential resolution scheme, the syntax for
   the Namespace Identifier is:

   <NID>         ::= <let-num> [ 1,31<let-num-hyp> ]

   <let-num-hyp> ::= <upper> | <lower> | <number> | "-"

   <let-num>     ::= <upper> | <lower> | <number>

   <upper>       ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                     "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                     "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                     "Y" | "Z"

   <lower>       ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                     "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                     "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                     "y" | "z"

   <number>      ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"


   This is slightly more restrictive that what is stated in [4] (which
   allows the characters "." and "+").  Further, the Namespace
   Identifier is case insensitive, so that "ISBN" and "isbn" refer to
   the same namespace.

   To avoid confusion with the "urn:" identifier, the NID "urn" is
   reserved and MUST NOT be used.










Moats                       Standards Track                     [Page 2]

RFC 2141                       URN Syntax                      May 1997


2.2 Namespace Specific String Syntax

   As required by RFC 1737, there is a single canonical representation
   of the NSS portion of an URN.   The format of this single canonical
   form follows:

   <NSS>         ::= 1*<URN chars>

   <URN chars>   ::= <trans> | "%" <hex> <hex>

   <trans>       ::= <upper> | <lower> | <number> | <other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
                     ":" | "=" | "@" | ";" | "$" |
                     "_" | "!" | "*" | "'"

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are not members of the URN
   character set above (<URN chars>).  Such strings MUST be translated
   into canonical NSS format before using them as protocol elements or
   otherwise passing them on to other applications. Translation is done
   by encoding each character outside the URN character set as a
   sequence of one to six octets using UTF-8 encoding [5], and the
   encoding of each of those octets as "%" followed by two characters
   from the <hex> character set above. The two characters give the
   hexadecimal representation of that octet.

2.3 Reserved characters

   The remaining character set left to be discussed above is the
   reserved character set, which contains various characters reserved
   from normal use.  The reserved character set follows, with a
   discussion on the specifics of why each character is reserved.

   The reserved character set is:

   <reserved>    ::= '%" | "/" | "?" | "#"

2.3.1 The "%" character

   The "%" character is reserved in the URN syntax for introducing the
   escape sequence for an octet.  Literal use of the "%" character in a
   namespace must be encoded using "%25" in URNs for that namespace.
   The presence of an "%" character in an URN MUST be followed by two
   characters from the <hex> character set.



Moats                       Standards Track                     [Page 3]

RFC 2141                       URN Syntax                      May 1997


   Namespaces MAY designate one or more characters from the URN
   character set as having special meaning for that namespace.  If the
   namespace also uses that character in a literal sense as well, the
   character used in a literal sense MUST be encoded with "%" followed
   by the hexadecimal representation of that octet.  Further, a
   character MUST NOT be "%"-encoded if the character is not a reserved
   character.  Therefore, the process of registering a namespace
   identifier shall include publication of a definition of which
   characters have a special meaning to that namespace.

2.3.2 The other reserved characters

   RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
   purposes. The URN-WG has not yet debated the applicability and
   precise semantics of those purposes as applied to URNs. Therefore,
   these characters are RESERVED for future developments.  Namespace
   developers SHOULD NOT use these characters in unencoded form, but
   rather use the appropriate %-encoding for each character.

2.4 Excluded characters

   The following list is included only for the sake of completeness.
   Any octets/characters on this list are explicitly NOT part of the URN
   character set, and if used in an URN, MUST be %encoded:

   <excluded> ::= octets 1-32 (1-20 hex) | "\" | """ | "&" | "<"
                  | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | "~"
                  | octets 127-255 (7F-FF hex)

   In addition, octet 0 (0 hex) should NEVER be used, in either
   unencoded or %-encoded form.

   An URN ends when an octet/character from the excluded character set
   (<excluded>) is encountered.  The character from the excluded
   character set is NOT part of the URN.

3. Support of existing legacy naming systems and new naming systems

   Any namespace (existing or newly-devised) that is proposed as an
   URN-namespace and fulfills the criteria of URN-namespaces MUST be
   expressed in this syntax.  If names in these namespaces contain
   characters other than those defined for the URN character set, they
   MUST be translated into canonical form as discussed in section 2.2.








Moats                       Standards Track                     [Page 4]

RFC 2141                       URN Syntax                      May 1997


4. URN presentation and transport

   The URN syntax defines the canonical format for URNs and all URN
   transport and interchanges MUST take place in this format. Further,
   all URN-aware applications MUST offer the option of displaying URNs
   in this canonical form to allow for direct transcription (for example
   by cut and paste techniques).  Such applications MAY support display
   of URNs in a more human-friendly form and may use a character set
   that includes characters that aren't permitted in URN syntax as
   defined in this RFC (that is, they may replace %-notation by
   characters in some extended character set in display to humans).

5. Lexical Equivalence in URNs

   For various purposes such as caching, it's often desirable to
   determine if two URNs are the same without resolving them. The
   general purpose means of doing so is by testing for "lexical
   equivalence" as defined below.

   Two URNs are lexically equivalent if they are octet-by-octet equal
   after the following preprocessing:

           1. normalize the case of the leading "urn:" token
           2. normalize the case of the NID
           3. normalizing the case of any %-escaping

   Note that %-escaping MUST NOT be removed.

   Some namespaces may define additional lexical equivalences, such as
   case-insensitivity of the NSS (or parts thereof).  Additional lexical
   equivalences MUST be documented as part of namespace registration,
   MUST always have the effect of eliminating some of the false
   negatives obtained by the procedure above, and MUST NEVER say that
   two URNs are not equivalent if the procedure above says they are
   equivalent.

6. Examples of lexical equivalence

   The following URN comparisons highlight the lexical equivalence
   definitions:

           1- URN:foo:a123,456
           2- urn:foo:a123,456
           3- urn:FOO:a123,456
           4- urn:foo:A123,456
           5- urn:foo:a123%2C456
           6- URN:FOO:a123%2c456




Moats                       Standards Track                     [Page 5]

RFC 2141                       URN Syntax                      May 1997


   URNs 1, 2, and 3 are all lexically equivalent.  URN 4 is not
   lexically equivalent any of the other URNs of the above set.  URNs 5
   and 6 are only lexically equivalent to each other.

7. Functional Equivalence in URNs

   Functional equivalence is determined by practice within a given
   namespace and managed by resolvers for that namespeace. Thus, it is
   beyond the scope of this document.  Namespace registration must
   include guidance on how to determine functional equivalence for that
   namespace, i.e. when two URNs are the identical within a namespace.

8. Security considerations

   This document specifies the syntax for URNs.  While some namespaces
   resolvers may assign special meaning to certain of the characters of
   the Namespace Specific String, any security consideration resulting
   from such assignment are outside the scope of this document.  It is
   strongly recommended that the process of registering a namespace
   identifier include any such considerations.

9. Acknowledgments

   Thanks to various members of the URN working group for comments on
   earlier drafts of this document.  This document is partially
   supported by the National Science Foundation, Cooperative Agreement
   NCR-9218179.

10. References

   Request For Comments (RFC) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

   [1]         Sollins, K. R., "Requirements and a Framework for
               URN Resolution Systems," Work in Progress.

   [2]         Berners-Lee, T., "Universal Resource Identifiers in
               WWW," RFC 1630, June 1994.

   [3]         Sollins, K. and L. Masinter,  "Functional Requirements
               for Uniform Resource Names," RFC 1737.
               December 1994.









Moats                       Standards Track                     [Page 6]

RFC 2141                       URN Syntax                      May 1997


   [4]         Berners-Lee, T., R. Fielding, L. Masinter, "Uniform
               Resource Locators (URL),"  Work in Progress.

   [5]         Appendix A.2 of The Unicode Consortium, "The
               Unicode Standard, Version 2.0", Addison-Wesley
               Developers Press, 1996.  ISBN 0-201-48345-9.

11. Editor's address

      Ryan Moats
      AT&T
      15621 Drexel Circle
      Omaha, NE 68135-2358
      USA

      Phone:  +1 402 894-9456
      EMail:  jayhawk@ds.internic.net


































Moats                       Standards Track                     [Page 7]

RFC 2141                       URN Syntax                      May 1997


Appendix A. Handling of URNs by URL resolvers/browsers.

   The URN syntax has been defined so that URNs can be used in places
   where URLs are expected.  A resolver that conforms to the current URL
   syntax specification [3] will extract a scheme value of "urn:" rather
   than a scheme value of "urn:<nid>".

   An URN MUST be considered an opaque URL by URL resolvers and passed
   (with the "urn:" tag) to an URN resolver for resolution.  The URN
   resolver can either be an external resolver that the URL resolver
   knows of, or it can be functionality built-in to the URL resolver.

   To avoid confusion of users, an URL browser SHOULD display the
   complete URN (including the "urn:" tag) to ensure that there is no
   confusion between URN namespace identifiers and URL scheme
   identifiers.



































Moats                       Standards Track                     [Page 8]