idnits 2.17.1
draft-ietf-urnbis-rfc2141bis-urn-03.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document obsoletes RFC2141, but the
abstract doesn't seem to directly say this. It does mention RFC2141
though, so this could be OK.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== Line 1062 has weird spacing: '...service glob...'
== Line 1063 has weird spacing: '...esource globa...'
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
== The document seems to contain a disclaimer for pre-RFC5378 work, but was
first submitted on or after 10 November 2008. The disclaimer is usually
necessary only for documents that revise or obsolete older RFCs, and that
take significant amounts of text from those RFCs. If you can contact all
authors of the source material and they are willing to grant the BCP78
rights to the IETF Trust, you can and should remove the disclaimer.
Otherwise, the disclaimer is needed and you can ignore this comment.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 16, 2012) is 4208 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 4395 (Obsoleted by RFC 7595)
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
== Outdated reference: A later version (-09) exists of
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03
-- Obsolete informational reference (is this intentional?): RFC 615
(Obsoleted by RFC 645)
-- Obsolete informational reference (is this intentional?): RFC 1738
(Obsoleted by RFC 4248, RFC 4266)
-- Obsolete informational reference (is this intentional?): RFC 1808
(Obsoleted by RFC 3986)
-- Obsolete informational reference (is this intentional?): RFC 2141
(Obsoleted by RFC 8141)
-- Obsolete informational reference (is this intentional?): RFC 2396
(Obsoleted by RFC 3986)
-- Obsolete informational reference (is this intentional?): RFC 2611
(Obsoleted by RFC 3406)
-- Obsolete informational reference (is this intentional?): RFC 2717
(Obsoleted by RFC 4395)
-- Obsolete informational reference (is this intentional?): RFC 2718
(Obsoleted by RFC 4395)
-- Obsolete informational reference (is this intentional?): RFC 3406
(Obsoleted by RFC 8141)
-- Obsolete informational reference (is this intentional?): RFC 4020
(Obsoleted by RFC 7120)
Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 IETF URNbis WG A. Hoenes, Ed.
3 Internet-Draft TR-Sys
4 Obsoletes: 2141 (if approved) October 16, 2012
5 Intended status: Standards Track
6 Expires: April 19, 2013
8 Uniform Resource Name (URN) Syntax
9 draft-ietf-urnbis-rfc2141bis-urn-03
11 Abstract
13 Uniform Resource Names (URNs) are intended to serve as persistent,
14 location-independent, resource identifiers. This document serves as
15 the foundation of the 'urn' URI Scheme according to RFC 3986 and sets
16 forward the canonical syntax for URNs, which subdivides URNs into
17 "namespaces". A discussion of both existing legacy and new
18 namespaces and requirements for URN presentation and transmission are
19 presented. Finally, there is a discussion of URN equivalence and how
20 to determine it. This document supersedes RFC 2141.
22 The requirements and procedures for URN Namespace registration
23 documents are set forth in a companion document, RFC 3406bis (BCP
24 66).
26 Discussion
28 Comments are welcome on the urn@ietf.org mailing list (or sent to the
29 document editor). The home page of the URNbis WG is located at
30 .
31 [[ RFC-Editor: this clause to be deleted before RFC publication ]]
33 Status of This Memo
35 This Internet-Draft is submitted in full conformance with the
36 provisions of BCP 78 and BCP 79.
38 Internet-Drafts are working documents of the Internet Engineering
39 Task Force (IETF). Note that other groups may also distribute
40 working documents as Internet-Drafts. The list of current Internet-
41 Drafts is at http://datatracker.ietf.org/drafts/current/.
43 Internet-Drafts are draft documents valid for a maximum of six months
44 and may be updated, replaced, or obsoleted by other documents at any
45 time. It is inappropriate to use Internet-Drafts as reference
46 material or to cite them other than as "work in progress."
48 This Internet-Draft will expire on April 19, 2013.
50 Copyright Notice
52 Copyright (c) 2012 IETF Trust and the persons identified as the
53 document authors. All rights reserved.
55 This document is subject to BCP 78 and the IETF Trust's Legal
56 Provisions Relating to IETF Documents
57 (http://trustee.ietf.org/license-info) in effect on the date of
58 publication of this document. Please review these documents
59 carefully, as they describe your rights and restrictions with respect
60 to this document. Code Components extracted from this document must
61 include Simplified BSD License text as described in Section 4.e of
62 the Trust Legal Provisions and are provided without warranty as
63 described in the Simplified BSD License.
65 This document may contain material from IETF Documents or IETF
66 Contributions published or made publicly available before November
67 10, 2008. The person(s) controlling the copyright in some of this
68 material may not have granted the IETF Trust the right to allow
69 modifications of such material outside the IETF Standards Process.
70 Without obtaining an adequate license from the person(s) controlling
71 the copyright in such materials, this document may not be modified
72 outside the IETF Standards Process, and derivative works of it may
73 not be created outside the IETF Standards Process, except to format
74 it for publication as an RFC or to translate it into languages other
75 than English.
77 Table of Contents
79 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
80 1.1. Historical Perspective and Motivation . . . . . . . . . . 4
81 1.2. Objective of this Memo . . . . . . . . . . . . . . . . . . 6
82 1.3. Background on Properties of URNs . . . . . . . . . . . . . 6
83 1.4. Requirement Language . . . . . . . . . . . . . . . . . . . 8
84 2. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 8
85 2.1. Namespace Identifier (NID) Syntax . . . . . . . . . . . . 10
86 2.2. Namespace Specific String (NSS) Syntax . . . . . . . . . . 10
87 2.3. Query Part in URI References to URNs . . . . . . . . . . . 11
88 2.3.1. Query Instruction for URN Service Selection . . . . . 13
89 2.3.2. Query Instruction for Component Resource Indication . 13
90 2.4. Fragment Part in URI References to URNs . . . . . . . . . 14
91 2.5. Special and Reserved Characters . . . . . . . . . . . . . 14
92 2.5.1. Delimiter Characters . . . . . . . . . . . . . . . . . 14
93 2.5.2. The Percent Character, Percent-Encoding . . . . . . . 15
94 2.5.3. Other Excluded Characters . . . . . . . . . . . . . . 16
95 3. Support of Existing (Legacy) and New Naming Systems . . . . . 17
96 4. URN Presentation and Transport . . . . . . . . . . . . . . . . 17
97 5. Lexical Equivalence of URNs . . . . . . . . . . . . . . . . . 17
98 5.1. Examples of Lexical Equivalence . . . . . . . . . . . . . 18
99 6. Functional Equivalence of URNs . . . . . . . . . . . . . . . . 19
100 7. The 'urn' URI Scheme . . . . . . . . . . . . . . . . . . . . . 19
101 7.1. Registration Template for URI Scheme 'urn' . . . . . . . . 19
102 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
104 9.1. Registration of URI Scheme 'urn', URN Registry Update . . 22
105 9.2. URN Query Parameters Registry . . . . . . . . . . . . . . 22
106 9.2.1. URN Query Keywords Sub-Registry . . . . . . . . . . . 22
107 9.2.2. URN Resolution Service Designators Sub-Registry . . . 23
108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
110 11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
111 11.2. Informative References . . . . . . . . . . . . . . . . . . 25
112 Appendix A. Handling of URNs by URL Resolvers/Browsers . . . . . 28
113 Appendix B. Collected ABNF (Informative) . . . . . . . . . . . . 28
114 Appendix C. Breakdown of NSS Syntax Evolution since RFC 2141
115 (Informative) . . . . . . . . . . . . . . . . . . . . 29
116 Appendix D. Changes since RFC 2141 (Informative) . . . . . . . . 31
117 D.1. Essential Changes from RFC 2141 . . . . . . . . . . . . . 31
118 D.2. Changes from RFC 2141 to Individual Draft -00 . . . . . . 32
119 D.3. Changes from Individual Draft -00 to -02 . . . . . . . . . 33
120 D.4. Changes from Individual Draft -02 to WG Draft -00 . . . . 33
121 D.5. Changes from WG Draft -00 to WG Draft -01 . . . . . . . . 33
122 D.6. Changes from WG Draft -01 to WG Draft -02 . . . . . . . . 34
123 D.7. Changes from WG Draft -02 to WG Draft -03 . . . . . . . . 34
125 1. Introduction
127 Uniform Resource Names (URNs) are intended to serve as persistent,
128 location-independent, resource identifiers and are designed to make
129 it easy to map other namespaces (that share the properties of URNs)
130 into URI-space. Therefore, the URN syntax provides a means to encode
131 character data in a form that can be sent in existing protocols,
132 transcribed on most keyboards, etc.
134 To this end, URNs are designed as an intrinsic part of the more
135 general framework of Uniform Resource Identifiers (URIs); 'urn' is a
136 particular URI Scheme (according to STD 66, RFC 3986 [RFC3986] and
137 BCP 35, RFC 4395 [RFC4395]) that is dedicated to forming a
138 hierarchical framework for persistent identifiers. (Other, legacy
139 interpretations of the term URN are not considered in this memo.)
141 The first level of hierarchy is given by the classification of URIs
142 into "URI Schemes", and for URNs, the second level is organized into
143 "URN Namespaces". Henceforth both terms are used in this
144 capitalization to distinguish them from the more general common
145 meaning of "scheme" and "namespace".
147 It is an explicit design goal that pre-existing systems of persistent
148 identifiers are mapped into the URN framework. Ordinarily, each such
149 traditional identifier system (namespace) -- standard or otherwise --
150 will occupy its own URN Namespace. However, shared URN Namespaces
151 are possible (and in fact, already exist), but the identifier-driven
152 mechanisms needed to distinguish the originating namespaces make
153 registration and maintenance of such URN Namespaces more complicated.
155 URN (as a URI Scheme) as such does not have a specific scope. The
156 applicability of the URN system, that is, the totality of the
157 resources that URNs can be assigned to, is the union of all
158 identifier systems that have an associated registered URN Namespace.
159 Ideally every new namespace will thus extend the URN applicability.
161 1.1. Historical Perspective and Motivation
163 Since this RFC will be of particular interest for groups and
164 individuals that are interested in persistent identifiers in general,
165 but often not in steady contact with the IETF and the RFC series,
166 this section gives a brief outline of the evolution of the matter
167 over time.
169 Attempts to define generally applicable identifiers for network
170 resources go back to the mid-1970s. Among the applicable RFCs is RFC
171 615 [RFC0615], which subsequently has been obsoleted by RFC 645
172 [RFC0645].
174 The seminal document in the RFC series regarding URIs (Uniform
175 Resource Identifiers) for use with the World Wide Web (WWW) was RFC
176 1630 [RFC1630], published in 1994. In the same year, the general
177 concept or Uniform Resource Names has been laid down in RFC 1737
178 [RFC1737] and that of Uniform Resource Locators (URLs) in RFC 1736
179 [RFC1736].
181 The original formal specification of URN Syntax, RFC 2141 [RFC2141]
182 was adopted in 1997. That document was based on the original
183 specification of URLs in RFC 1738 [RFC1738] and RFC 1808 [RFC1808],
184 which later on, in 1998, was generalized and consolidated in the
185 Generic URI specification, RFC 2396 [RFC2396]. Most parts of these
186 URI/URL documents were superseded in 2005 by STD 66, RFC 3986
187 [RFC3986]. Notably, RFC 2141 makes (essentially normative) reference
188 to a draft version of RFC 2396.
190 Over time, the terms "URI", "URL", and "URN" have been refined and
191 slightly shifted according to emerging insight and use. This has
192 been clarified in a joint effort of the IETF and the World Wide Web
193 Council, published 2002 for the IETF in RFC 3305 [RFC3305].
195 The wealth of URI Schemes and URN Namespaces needs to be organized in
196 a persistent way, in order to guide application developers and users
197 to the standardized top level branches and the related
198 specifications. These registries are maintained by the Internet
199 Assigned Numbers Authority (IANA) [IANA] at [IANA-URI] and
200 [IANA-URN], respectively. Registration procedures for URI Schemes
201 originally had been laid down in RFC 2717 [RFC2717] and guidelines
202 for the related specification documents were given in RFC 2718
203 [RFC2718]. These documents have been obsoleted and consolidated into
204 BCP 35, RFC 4395 [RFC4395], which is based on, and aligned with,
205 RFC 3986.
207 Note that RFC 2141 predates RFC 2717 and, although the 'urn' URI
208 scheme traditionally was listed in [IANA-URI] with a pointer to
209 RFC 2141, this registration has never been performed formally.
211 Similarly, the URN Namespace definition and registration mechanisms
212 originally have been specified in RFC 2611 [RFC2611], which has been
213 obsoleted by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents
214 prescribing IANA procedures have been revised as well over the years,
215 and at the time of this writing, BCP 26, RFC 5226 [RFC5226] is the
216 normative document. Neither RFC 4395 nor RFC 3406 conform to
217 RFC 5226.
219 Early documents specifying URI and URN syntax, including RFC 2141,
220 made use of an ad-hoc variant of the original Backus-Naur Form (BNF)
221 that never has been formally specified.
223 Over the years, the IETF has shifted to the use of a predominant
224 formal language used to define the syntax of textual protocol
225 elements, dubbed "Augmented Backus-Naur Form" (ABNF). The
226 specification of ABNF also has evolved, and now STD 68, RFC 5234
227 [RFC5234] is the normative document for it (that also will be used in
228 this RFC).
230 1.2. Objective of this Memo
232 As pointed out above, RFC 2141 does not seamlessly match current
233 Internet Standards. Therefore, the primary objective of this
234 document is the alignment with the URI standard [RFC3986] and URI
235 Scheme guidelines [RFC4395], the ABNF standard [RFC5234] and the
236 current IANA Guidelines [RFC5226] in general.
238 Further, experience from emerging international efforts to establish
239 a general, distributed, stable URN resolution service have been taken
240 into account during the draft stage of this document.
242 For advancing the URN specification on the Internet Standards-Track,
243 it needs to be based on documents of comparable maturity. Therefore,
244 to further advancements of the formal maturity level of this RFC, it
245 deliberately makes normative references only to documents at Full
246 Standard or Best Current Practice level.
248 Thus, this replacement document for RFC 2141 should make it possible
249 to advance the URN framework on the Internet Standard maturity
250 ladder. All other related documents depend on it; therefore this is
251 the first step to undertake.
253 Out of scope for this document is a revision of the URN Namespace
254 Definition Mechanisms document, BCP 66. This is being undertaken in
255 a companion document, RFC 3406bis
256 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg].
258 1.3. Background on Properties of URNs
260 This section aims at quoting requirements as identified in the past;
261 it does not attempt to revise or redefine these requirements, but it
262 gives some hints where more than a decade of experience with URNs has
263 shed a different light on past views. The citations below are given
264 here to make this document self-contained and avoid normative down-
265 references to old work.
267 RFC 1737 [RFC1737] defined the purpose of URNs as follows:
269 o The purpose or function of a URN is to provide a globally unique,
270 persistent identifier used for recognition, for access to
271 characteristics of the resource, or for access to the resource
272 itself.
274 This means that URNs are intended to uniquely and persistently bind a
275 name to a resource and (some of) its properties (metadata).
277 Section 2 of RFC 1737 [RFC1737] listed the functional requirements
278 for URNs (quote slightly edited to reflect the time passed since that
279 RFC was written and the actual definition of the URN scheme that has
280 happened):
282 o Global scope: A URN is a name with global scope which does not
283 imply a location. It has the same meaning everywhere.
285 o Global uniqueness: The same URN will never be assigned to two
286 different resources.
288 o Persistence: It is intended that the lifetime of a URN be
289 permanent. That is, the URN will be globally unique forever, and
290 may well be used as a reference to a resource well beyond the
291 lifetime of the resource it identifies or of any naming authority
292 involved in the assignment of its name.
294 o Scalability: URNs can be assigned to any resource that might
295 conceivably be available on the network, for hundreds of years.
297 o Legacy support: The URN scheme permits the support of existing
298 legacy naming systems, insofar as they satisfy the other
299 requirements described here. [...]
301 o Extensibility: The URN scheme permits future extensions.
303 o Independence: It is solely the responsibility of a name issuing
304 authority to determine the conditions under which it will issue a
305 name.
307 o Resolution: URNs will not impede resolution. [...]
309 The URN syntax described below also accommodates the fundamental
310 "Requirements for URN Encoding" in Section 3 of RFC 1737 [RFC1737],
311 as far as experience gained has not lead to relax unrealistical
312 detail requirements:
314 o Single encoding: The encoding for presentation for people in clear
315 text, electronic mail and the like is the same as the encoding in
316 other transmissions.
318 o Simple comparison: A comparison algorithm for URNs is simple,
319 local, and deterministic. [...]
321 o Human transcribability: For URNs to be easily transcribable by
322 humans without error, they need to be short, use a minimum of
323 special characters, and be case insensitive. [...]
325 Note:
326 In particular practice gained with active URN Namespaces has
327 shown that this former goal is rather unrealistic, since
328 usually preference is given to 1:1 embedding into URNs of
329 identifier strings drawn from existing namespaces, which might
330 not have this property. However, we hold that, at least, the
331 rough kind of resource identified by a URN should be easily
332 recognizable for humans.
334 o Transport friendliness: A URN can be transported unmodified in the
335 common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc.,
336 as well as printed paper.
338 o Machine consumption: A URN can be parsed by a computer.
340 o Text recognition: The encoding of a URN needs to enhance the
341 ability to find and parse URNs in free text.
343 1.4. Requirement Language
345 When spelled in all-capitals as in this paragraph, the key words
346 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
347 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
348 are to be interpreted as described in BCP 14 [RFC2119].
350 2. URN Syntax
352 This document defines the URI Scheme 'urn'. Hence, URNs are specific
353 URIs as specified in STD 66 [RFC3986]. The formal syntax definitions
354 below are given in ABNF according to STD 68 [RFC5234] and make use of
355 some "Core Rules" specified in Appendix B of that Standard and
356 several generic rules defined in Appendix A of RFC 3986.
358 The syntax definitions below do, and syntax definitions in dependent
359 documents, MUST conform to the URI syntax specified in RFC 3986, in
360 the sense that additional syntax rules are only allowed to further
361 constrain the general rules from RFC 3986. In other words: a general
362 URI parser based on RFC 3986 MUST be able to parse any legal URN,
363 URN-specific semantics can be obtained from URN-specific parsing of
364 its outcome.
366 URNs conform to the variant of the general URI syntax
367 specified in Section 3 of [RFC3986], reproduced here informally:
369 URI = scheme ":" path-rootless [ "?" query ] [ "#" fragment ]
371 path-rootless = segment-nz *( "/" segment )
373 segment-nz = 1*pchar
374 segment = *pchar
375 query = *( pchar / "/" / "?" )
376 fragment = *( pchar / "/" / "?" )
378 pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
380 In the case of URNs, we have:
382 scheme = "urn"
384 and for , only a single segment is used, but the
385 following additional syntax rule is superimposed on
386 to establish a level of hierarchy called "Namespace":
388 urn-path = NID ":" NSS
390 Here "urn" is the URI scheme name, is the Namespace Identifier,
391 and is the Namespace Specific String. The colons are REQUIRED
392 separator characters.
394 Note that it is common practise in several existing URN Namespaces
395 (and fully supported by this syntax) to use additional colon(s) as
396 separator character(s) in order to introduce further level(s) of
397 hierarchy into the NSS syntax, where needed. (See also
398 Section 2.5.1 below.)
400 Per RFC 3986, the URN Scheme name (here "urn") is case-insensitive.
402 The Namespace ID (also a case-insensitive string) determines the
403 syntactic structure and the semantic interpretation of the Namespace
404 Specific String. Details on NID syntax can be found below in
405 Section 2.1, and the NSS syntax is elaborated upon in Section 2.2.
407 Each particular URN Namespace is based on a specific document that
408 must normatively describe (among other things) the details of the
409 values allowed in conjunction with the respective . The
410 syntax and semantics of these values are often carried over
411 from an existing persistent identifier system (namespace); for
412 instance, in the 'ISBN' URN Namespace, each NSS must be a valid ISBN.
413 Some URN Namespaces may have strict rules for well formed NSSs, while
414 some others may be far more relaxed. There may also be significant
415 differences regarding the identifier assignment process. The overall
416 specification requirements and registration procedures for URN
417 Namespaces are the subject of a dedicated companion document, BCP 66,
418 which has been updated for conformance to BCP 26 and alignment with
419 implementation experience RFC 3406bis
420 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg].
422 The syntax of and are defined in RFC 3986.
423 Question mark and hash sign remain reserved as separator characters
424 for these URI components and therefore MUST NOT appear unencoded in a
425 NSS. This rule guarantees backwards compatibility with existing URN
426 Namespaces and improves the compatibility of URN syntax with general
427 URI parsers.
429 For more specifics on the part with URNs, see Section 2.3
430 below; elaborations on the part usage with URNs follow in
431 Section 2.4 below.
433 2.1. Namespace Identifier (NID) Syntax
435 The following is the syntax for the Namespace Identifier. To (i) be
436 consistent with all potential resolution schemes and (ii) not put any
437 undue constraints on any potential resolution scheme, Namespace
438 Identifiers are ASCII strings with the syntax:
440 NID = (ALPHA / DIGIT) 0*30(ALPHA / DIGIT / "-") (ALPHA / DIGIT)
442 Note:
443 The above definition is slightly more restrictive than it was in
444 RFC 2141, to better reflect common practice for "handle"-like
445 identifiers in other IETF protocols (a.k.a. "LDH" syntax) and
446 requirements from RFC 3406bis. RFC 3406bis contains further
447 syntax restrictions on NID strings.
449 Namespace Identifiers are case-insensitive, so that for instance
450 "ISBN" and "isbn" refer to the same namespace.
452 To avoid confusion with the URI Scheme name "urn", the NID "urn" is
453 permanently reserved by this RFC and MUST NOT be used or registered.
455 2.2. Namespace Specific String (NSS) Syntax
457 As already required since RFC 1737, there is a single canonical
458 representation of the NSS portion of an URN.
460 The format of this single canonical form follows:
462 NSS = 1*pchar ; or equivalent: NSS = segment-nz
464 ( and are defined in Section 3.3 of RFC 3986.)
466 Note:
467 The informational Appendix C expands on the evolution of the NSS
468 syntax specification since RFC 2141.
470 Depending on the rules governing a namespace, valid identifiers in a
471 namespace might contain characters that are not members of the URN
472 character repertoire above (). In order to achieve
473 conformance with this NSS specification, such strings MUST be
474 translated into canonical NSS format before embedding them into a
475 URN, using them as protocol elements, or otherwise passing them on to
476 other applications. Translation is done by encoding each character
477 outside the URN character repertoire as a sequence of octets using
478 UTF-8 encoding (STD 63 [RFC3629]), and the "percent-encoding" of each
479 of those octets as "%" followed by two characters. The
480 latter two characters form the hexadecimal representation of that
481 octet. (See Section 2.5.2 below for more details.)
483 2.3. Query Part in URI References to URNs
485 The part MUST NOT be present in any *assigned* URN. A
486 part can only be added to an assigned URN and appear in a URI
487 *reference* [RFC3986] to a URN that is intended to be used with URN
488 resolution services, and, in the spirit of the general specification
489 of this part in RFC 3986, its purpose is restricted to indicate the
490 requested URN resolution service and particular service aspects of
491 the intended resolution response, e.g., the kind of metadata or
492 content sought that are bound to a given object identified by the
493 basic, assigned URN.
495 This specification only defines a generic framework format for this
496 part and basic items to be used therein; it defers more detailed
497 specifications to future standardization related to generic URN
498 services and resolution and to URN Namespace defining documents for
499 namespace-specific usages.
501 Beyond following the generic syntax rules from [RFC3986] quoted
502 above, parts of URN references MUST adhere to the following
503 restricted syntax (compatible with industry standard URL-encoding
504 practice for HTTP).
506 urn-query = directive *( "&" directive)
508 directive = keywd "=" value
509 keywd = ALPHA *( ["-"] (ALPHA / DIGIT))
510 value = *v-pchar
512 v-pchar = unreserved / pct-encoded / v-subdels
513 v-subdels = "!" / "$" / "'" / "(" / ")"
514 / "*" / "+" / "," / ";" / "="
515 / ":" / "@" / "/" / "?"
516 ; this is except "&"
517 ; plus the extra characters allowed in
518 ; and for , as per RFC 3986
520 The part of URN references, if present, consists of an
521 unordered sequence of "directives" of the form =,
522 separated by single instances of the ampersand character ("&"). As
523 common for parts, these directives are regarded as case-
524 sensitive.
526 The tokens are -- preferably short, mnemonic -- LDH-strings
527 of either global or namespace-centric scope. The following
528 subsections specify two basic keywords of global scope. Other
529 tokens can be specified in other documents (including URN
530 Namespace specifications) and are to be registered by IANA. See
531 Section 9.2.1 for registration details.
533 Each registered MUST NOT appear more than once in any URN. A
534 URN resolver that receives a URN reference violating this rule MUST
535 ignore all query directives therein using the offending (s)
536 (this is necessary to maintain independence of the semantics from
537 directive ordering).
539 The tokens have semantics specific to the they are
540 used with. The above syntax rule is the most liberal possible
541 specification guaranteeing unambiguity and still conforming with RFC
542 3986, but prudent specifications of tokens will keep the
543 forms admitted with them as simple as possible.
545 URN resolvers are expected to ignore query keywords they do not
546 support or understand and "gracefully" fall back to namespace-
547 specific default behavior. Similarly, unless specified otherwise in
548 the specification of a particular query keyword, URN resolvers are
549 expected to ignore directives with an unknown/unsupported for
550 a supported and provide default behavior for these cases as
551 well as if an expected directive is not supplied. New/revised URN
552 Namespace specifications need to clearly indicate which s are
553 being supported for the respective URN Namespace and the set of valid
554 s for these (by listing enumerated values and/or specifying
555 additional syntax rules) -- see RFC 3406bis for more information.
557 2.3.1. Query Instruction for URN Service Selection
559 The query keyword "s" has global scope and semantics; it serves to
560 select a specific URN resolution service. The associated is
561 the mnemonic name of the URN resolution operation intended by the URI
562 reference to a URN. Permissible values are registered with IANA by
563 the documents specifying these URN services -- see Section 9.2.2 for
564 details. Pending future revised URN service specifications, the
565 registry is initially populated with provisional entries derived from
566 RFC 2483 [RFC2483].
568 This query keyword is expected to be supported by new URN resolution
569 systems for any URN namespaces. A URN resolver that does not support
570 this query keyword (e.g., because it is based on RFC 2141) or that
571 does not understand the handed to it MUST gracefully fall
572 back to provide the default service for the respective URN Namespace,
573 as specified in the related URN Namespace definition. New/revised
574 URN Namespace specifications need to clearly indicate which services
575 are being supported for the respective URN Namespace -- see RFC
576 3406bis for more information.
578 Example directive (URI to URL service, RFC 2483, Sec. 4.1): s=I2U
580 2.3.2. Query Instruction for Component Resource Indication
582 The query keyword "c" serves to identify a component of the resource
583 named by the basic URN in a uniform, media type independent manner;
584 it applies to structured resources only and otherwise has global
585 scope, but namespace-specific applicability, values, and semantics.
587 URN Namespace designers/maintainers MAY adopt the use of this query
588 instruction for their resolver systems and need to specify that fact
589 in the URN Namespace registration and supply the applicable rules for
590 the "c=" values to be supported by the resolvers for that URN
591 Namespace. See RFC 3406bis for more information.
593 Hypothetical example: Assuming that the ISBN Namespace adopts support
594 of the "c=" query instruction for the I2R URN service provided by
595 URN:ISBN resolvers, further assuming that for a printed book the
596 table of contents is anyway being made available online somewhere by
597 its publisher _and_ the resolver system is aware of this, and
598 provided that the resolvers support designation of the table of
599 contents via the "c" "ToC", a URI reference to the URN:ISBN
600 of such book might indicate the intent to resolve the URN to an URL
601 for that ToC by including the part "s=I2L&c=ToC".
603 2.4. Fragment Part in URI References to URNs
605 The part is not generally allowed in URNs. It is only
606 applicable to URN Namespaces that specifically opt to support its
607 usage in a manner that conforms with RFC 3986. Thus, a URN Namespace
608 registration document MAY specify the usage of with URNs
609 of that particular URN Namespace. Absent a registered namespace
610 definition based on this document and RFC 3406bis that explicitly
611 specifies its usage, URNs for that particular URN Namespace MUST NOT
612 contain a fragment identifier.
614 The part MUST NOT be present in any *assigned* URN; it MAY
615 be present in a URI *reference* to a URN that is intended to be used
616 with URN resolution services, and -- according to RFC 3986 -- it will
617 not be sent to the resolution service but be interpreted by the
618 resolution client in accordance with the specification of the
619 Internet media type returned by the URN service.
621 Note that this is a backwards-compatible and fail-safe extension
622 from RFC 2141 since, based on RFC 3986 and established
623 implementation practice, clients/browsers ignore inapplicable
624 fragment identifiers and silently fall back in such case to
625 rendering the entire resource returned.
627 The requirements for documenting the usage of fragment identifiers
628 with a particular URN Namespace are elaborated upon in RFC 3406bis
629 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg], and that document also
630 explains the different methods available to URN Namespace designers
631 for how URN assignment and resolution can deal with structured
632 resources and their components.
634 2.5. Special and Reserved Characters
636 The remaining printable characters not included in the
637 repertoire comprise the generic delimiters and the reserved
638 characters, which are restricted for special use only. These
639 characters are discussed below, giving the specifics of why each
640 character is special or reserved.
642 2.5.1. Delimiter Characters
644 RFC 3986 [RFC3986] defines the general delimiter characters used in
645 URIs:
647 gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
649 From among the , ":" and "@" are also included in the
650 rule and hence allowed in the path components of URIs.
652 The at-character ("@") in generic URIs only has a specific meaning
653 when contained in the part, which is absent in URNs.
654 Hence, "@" is available in the part of URNs.
656 With URNs, the colon (":") is used as a delimiter character not only
657 between the scheme name ("urn") and the , but also between the
658 latter and the , and many existing URN Namespaces additionally
659 use ":" to further subdivide a single RFC 3986 path segment in the
660 in a hierarchical manner.
662 Note:
663 Using ":" as a sub-delimiter in the path in favor of "/" is
664 attractive because it avoids possible complications that could
665 arise from accidental inappropriate use of relative URI references
666 [RFC3986] for URNs.
668 The characters "/", "?", and "#" separate path components and the
669 and parts in the generic URI syntax; they are
670 restricted to this role in URNs as well, although the in URNs
671 only admits a single and hence "/" is not allowed.
672 Therefore, these characters MUST NOT appear literally in the
673 part of a URN in unencoded form. Namespaces that need these
674 characters MUST employ in their URNs the appropriate percent-encoding
675 for each such character.
677 The square brackets ("[" and "]") also play a particular role when
678 contained in the part, which is absent in URNs. However,
679 for conformance with the generic URI syntax, they are not allowed
680 literally in the component of URNs. If a specific URN
681 Namespace reflects semantics that require these characters, they MUST
682 be percent-encoded in the respective URNs.
684 2.5.2. The Percent Character, Percent-Encoding
686 The percent character ("%") is reserved in the URN syntax for
687 introducing the escape sequence for an octet that is either not a
688 printable ASCII character or reserved for special purposes, as
689 described in this section. The presence of a "%" character in a URN
690 MUST always be followed by two characters, which three
691 characters together semantically represent an abstract
692 octet. Literal use of the "%" character in an underlying namespace
693 MUST therefore be encoded as "%25" in URNs for that namespace.
695 Namespaces MAY designate one or more characters from the URN
696 character repertoire as having special meaning for that namespace
697 (e.g. as being used as a separator character between distinguishable
698 parts of the NSS). If such namespace also allows for such character
699 to occur in identifiers from that namespace in a literal sense (in a
700 part of the identifier that shall be embedded literally into the
701 NSS), the character used in a literal sense MUST be percent-encoded
702 (with "%" followed by the hexadecimal representation of that octet).
703 Further, a character MUST NOT be percent-encoded if the character is
704 not a reserved character. Therefore, the process of registering a
705 namespace identifier shall include publication of a definition of
706 which characters have a special meaning to that namespace -- cf. RFC
707 3406bis [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg].
709 2.5.3. Other Excluded Characters
711 The following list is included only for the sake of completeness. It
712 includes the characters discussed in Sections 2.5.1 and 2.5.2. Any
713 octets/characters on this list are explicitly NOT part of the URN
714 character repertoire, and if used in an URN, MUST be percent-
715 encoded.
717 excluded = CTL / SP ; control characters and space
718 / DQUOTE ; "
719 / "#" ; from
720 / "%" ; see above
721 / "/" ; from
722 / "<" / ">"
723 / "?" ; from
724 / "[" ; from
725 / "\"
726 / "]" ; from
727 / "^"
728 / "`"
729 / "{" / "|" / "}"
730 / %x7F ; DEL (control character)
731 / %x80-FF ; non-ASCII
733 The NUL octet (0 hex) is renowned for a long history of trouble in
734 implementations. It MUST NOT be used in URNs, in either unencoded or
735 percent-encoded form.
737 In a textual context for a URN, the NSS part ends when an octet/
738 character from the excluded character set () is
739 encountered. The character from the excluded character set is NOT
740 part of the NSS.
742 The more general issue of discerning URNs in non-structured text is
743 not specific to URNs, but a general issue for recognizing URIs (by
744 humans or automata), and hence out of scope of this document.
746 3. Support of Existing (Legacy) and New Naming Systems
748 Any identifier to be used as a URN MUST be expressed in conformance
749 with the URI and URN syntax specifications ([RFC3986], and this
750 document). If names from (existing or newly devised) namespaces
751 contain characters other than those defined for the URN character
752 set, they MUST be translated into canonical form as discussed in
753 Section 2.2.
755 On the other hand, every namespace specific string in such URN
756 Namespace MUST be based on an identifier that conforms to the
757 requirements of the identifier system to which the URN Namespace is
758 assigned; in the simplest form, if the syntactical rules admit, the
759 NSS can be the original identifier. For instance, every legal NSS in
760 the ISBN Namespace must be a valid ISBN.
762 4. URN Presentation and Transport
764 The URN syntax defines the canonical format for URNs and all URN
765 transport and interchanges MUST take place in this format. Further,
766 all URN-aware applications MUST offer the option of displaying URNs
767 in this canonical form to allow for direct transcription (for example
768 by cut-and-paste techniques). Such applications MAY support -- even
769 in a manner specific to particular URN Namespaces -- display of URNs
770 in a more human-friendly form and MAY use in that context a character
771 set that includes characters that aren't permitted in URN syntax as
772 defined in this RFC (that is, they may replace %-notation by
773 characters in some extended character set in display to humans).
775 Note: Such transformation for the purpose of presentation, if done
776 blindly without NID-specific knowledge of special character usage,
777 might introduce ambiguity, because in the cases described above in
778 the second paragraph of Section 2.5.2, the unescaped and percent-
779 escaped form of the same character might carry different semantics
780 in NSSs of some URN Namespaces.
782 5. Lexical Equivalence of URNs
784 For various purposes such as caching, it is often desirable to
785 determine whether two URNs are "the same" (i.e., designate the same
786 resource), without resolving them. The general-purpose means of
787 doing so is by testing for "lexical equivalence" as defined below.
788 This procedure only can detect mismatches: two lexically different
789 URNs might still be assigned to the same reource -- be it by
790 assignment practice within a single URN Namespace or by a single
791 resource having assigned names from different URN Namespaces.
793 Two URNs are lexically equivalent if they are octet-by-octet equal
794 after the following preprocessing:
795 1. Normalize the case of the leading "urn" scheme name.
796 2. Normalize the case of the NID.
797 3. Normalize the case of any percent-encoding.
798 4. Remove the part of the URI, if present.
799 5. Depending on the objective, perform either step 5a or step 5b:
800 If the objective is related to distinguishing named resources,
801 perform step 5a; if the objective is related to caching specific
802 URN resolution results, perform step 5b.
803 5a. Remove the part of the URI, if present.
804 5b. Reorder the directives in the part of the URI, if
805 present, bringing them into a preferred order.
807 Note that percent-encoding MUST NOT be removed. It is an
808 implementation detail not affecting interoperability whether a
809 function for lexical URN comparison internally prefers normalization
810 (in the first 3 steps above) to lower or to upper case. Similarly,
811 the "preferred order" in step 5b is an implementation choice without
812 impact on interoperability.
814 Some namespaces may define additional lexical equivalences, such as
815 case-insensitivity of the NSS (or parts thereof). Additional lexical
816 equivalences MUST be documented as part of Namespace registration,
817 MUST always only have the effect of eliminating some of the false
818 negatives obtained by the procedure above, i.e., they MUST NOT say
819 that two URNs are not equivalent if the procedure above says they are
820 equivalent. Only URN software that is aware of such additional rules
821 for a specific NID can detect these additional lexical equivalences
823 5.1. Examples of Lexical Equivalence
825 The following hypothetical URN comparisons highlight the lexical
826 equivalence definitions (assuming that the hypothetical 'foo'
827 namespace does not define additional lexical equivalences):
829 1- URN:foo:a123,456
830 2- urn:foo:a123,456
831 3- urn:FOO:a123,456
832 4- urn:foo:A123,456
833 5- urn:foo:a123%2C456
834 6- URN:FOO:a123%2c456
835 7- urn:foo:a123,456?x=y
836 8- urn:foo:a123,456#xyz
838 URNs 1, 2, 3 and 8 are all lexically equivalent, and URN 7 is also
839 lexically equivalent to these if step 5a is applied, but this does
840 not hold if step 5b above is applied instead. in the normalization.
842 URN 4 is not lexically equivalent to any of the other URNs of the
843 above set. URNs 5 and 6 are only lexically equivalent to each other.
845 6. Functional Equivalence of URNs
847 Functional equivalence within a given URN Namespace is determined by
848 the management of URN assignment practices therein and established by
849 the resolvers for that namespace. Thus, it is beyond the scope of
850 this document. Namespace registrations must include guidance on how
851 to determine functional equivalence for that URN Namespace, i.e.,
852 when two URNs are identical within a namespace.
854 On the other hand, it is permissible to have two entirely different
855 URNs -- even from different URN Namespaces -- be assigned to a
856 particular resource. This can only be detected by resolving the URNs
857 and analysis of the resolution responses; hence, this is out of scope
858 for this memo.
860 7. The 'urn' URI Scheme
862 At the time of publication of RFC 2141, no formal registration
863 procedure for URI Schemes had been established yet, and so IANA only
864 informally has registered the 'urn' URI Scheme with a reference to
865 [RFC2141].
867 Therefore, Section 7.1 below contains the URI scheme registration
868 template for the 'urn' scheme, in accordance with RFC 4395 [RFC4395].
870 Note: In order to be usable as a standalone text (after being
871 extracted from this RFC), the template below does not contain
872 formal anchors to the references listed in Section 11, but instead
873 gives the common document designations in prose. However, for
874 compliance with editorial policy, it needs to be noted here:
876 This registration template refers to RFCs 2196, 2276, 2608, 3401
877 through 3404, 3406bis, 3629 (STD 63), and 3986 (STD 66) ([RFC2169]
878 [RFC2276] [RFC2608] [RFC3401] [RFC3402] [RFC3403] [RFC3404]
879 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg] [RFC3629] [RFC3986]).
881 7.1. Registration Template for URI Scheme 'urn'
883 [[ RFC-Editor: Please replace "XXXX" in all instances of "RFC XXXX"
884 below by the RFC number assigned to this document. ]]
885 URI scheme name: urn
887 Status: permanent
889 URI scheme syntax:
891 See Section 2 of RFC XXXX.
893 URI scheme semantics:
895 'urn' URIs, known as Universal Resource Names (URNs), serve as
896 persistent, location-independent, resource identifiers for
897 concrete and abstract objects ("resource") that have network
898 accessible instances and/or metadata.
900 URNs are structured hierarchically into URN Namespaces, the
901 management of which is delegated to namespace-specific
902 authorities. Each such URN Namespace is founded in an independent
903 specification and registered with IANA, following the guidelines
904 and procedures of BCP 66 (at the time of this registration: RFC
905 3406, an update is in progress as RFC 3406bis
906 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]).
908 Encoding considerations:
910 All URNs are ASCII strings conforming to the general URI syntax
911 from STD 66. As described in Sections 2.2 and 2.5.2 of RFC XXXX,
912 there may be characters allowed by the syntax and semantics of the
913 identifier system underlying the URN Namespace but not contained
914 in the US-ASCII charset. Such characters MUST first be
915 represented in Unicode and encoded in UTF-8 according to STD 63.
916 Any octets outside the allowed character set MUST then be percent-
917 encoded.
919 Note that it is perfectly possible that the syntax and semantics
920 of an underlying identifier system does not admit specific
921 characters allowed by the syntax rules in RFC XXXX.
923 Applications/protocols that use this URI scheme:
925 URNs that serve to identify abstract resources for protocol
926 purposes are expected to be recognized directly by the
927 implementations of these portocols.
929 In general, resolution systems for URNs are specified on a per-
930 namespace basis. If appropriate for the namespace, these systems
931 resolve URNs to (possibly multiple) URIs that allow the network
932 access to the identified object or metadata on it.
934 "Architectural Principles of Uniform Resource Name Resolution"
935 (RFC 2276) explains the basic concepts. Some resolution systems
936 laid down in IETF specifications are:
938 * Trivial HTTP-based URN Resolution (RFC 2169)
940 * Dynamic Delegation Discovery System (DDDS, RFCs 3401-3404)
942 * Service Location Protocol (SLPv2, RFC 2608)
944 Interoperability Considerations:
946 Persistence and stability of URNs require appropriate resolution
947 systems.
949 Security Considerations:
951 See Section 8 of RFC XXXX.
953 Contact:
955 The IETF URNbis working group.
956 This registration will be discussed on the following IETF lists:
957 urn and uri-review (AT ietf.org).
959 Author / Change controller:
961 The authors of RFC XXXX.
962 Change control is with the IESG.
964 References:
966 RFC XXXX.
968 Procedures for the specification and registration of URN
969 Namespaces are detailed in BCP 66 (at the time of this writing:
970 RFC 3406; an update is in progress in the URNbis WG as RFC 3406bis
971 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]).
973 8. Security Considerations
975 This document specifies the syntax and general requirements for URNs,
976 which are the specific URIs that use the 'urn' URI scheme. As such,
977 the general security considerations of STD 66 [RFC3986] apply.
978 However, each URN Namespace will have specific security
979 considerations, according to the semantics and usage of the
980 underlying namespace. While some namespaces may assign special
981 meaning to particular characters generically allowed in the Namespace
982 Specific String, any security considerations resulting from such
983 assignment are outside the scope of this document. It is REQUIRED by
984 BCP 66 (currently [RFC3406], to be replaced by RFC 3406bis
985 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]) that the process of
986 registering a namespace identifier include any such considerations.
988 9. IANA Considerations
990 9.1. Registration of URI Scheme 'urn', URN Registry Update
992 IANA is asked to update the existing informal registration of the
993 'urn' URI Scheme by the template in Section 7.1 above and list this
994 RFC as the current normative reference in [IANA-URI].
996 IANA is asked to add a note to [IANA-URN] that 'urn' is a permanently
997 reserved formal namespace identifier string that cannot be
998 registered, in order to avoid confusion with the 'urn' URI scheme.
1000 [[ RFC-Editor: this para to be deleted before RFC publication. ]]
1001 IANA is asked to again make available the URN Namespace Registry
1002 [IANA-URN] in a generic form (i.e., HTML) at the generic URI given in
1003 the Reference, and to make the XML and TXT versions available from
1004 that HTML version. (This state already had been achieved, but
1005 something seems to have been lost in 2011.)
1007 9.2. URN Query Parameters Registry
1009 IANA is asked to establish a new registry entitled "URN Resolution
1010 Query Parameters" with two sub-registries as described below,
1011 referencing Section 2.3 of this RFC as the authoritative source.
1013 9.2.1. URN Query Keywords Sub-Registry
1015 This registry holds the tokens that can be used in the query
1016 part of URI references to URNs.
1018 Entries capture the following items (that need to be provided by
1019 registration requests:
1021 Keyword - the token to be used in the query part
1023 Purpose - short phrase describing the purpose
1025 Scope - either "global" or "specific"
1027 Defn. Ref. - Reference to defining RFC
1029 Supported by - list of {URN NID, reference} pairs
1030 Keywords of "global" scope are (in principle) open for use with URNs
1031 and URN resolvers for any URN Namespace that choses to adopt it. The
1032 creation or substantive update of such entries requires a document
1033 containing the specification of the query directives using such
1034 keyword, subject to "IETF Review" (cf. BCP 26 [RFC5226]), and the
1035 change control of such entries remains with the IESG.
1037 Keywords of "specific" scope are designed to fulfill the purposes of
1038 a specific URN Namespace or a specific group of URN Namespaces. The
1039 creation or substantive update of such entries requires a
1040 specification document subject to the procedures set out in RFC
1041 3406bis for URN Namespace registration documents; the specification
1042 of the query directives using such keyword can be part of a URN
1043 Namespace registration documents. These entries remain under the
1044 change control of the stakeholders of the URN Namespace(s) given in
1045 the specification document.
1047 Changes in the "Supported by" list of any registry entry is
1048 considered a non-substantive update. Additions will usually be
1049 performed by URN Namespace registration documents (cf. RFC 3406bis),
1050 but to reduce the overhead and encourage usage of this registry, the
1051 maintainers of legacy URN Namespaces (URN NIDs registered before the
1052 publication of this RFC), a URN NID and a non-RFC reference to a
1053 stable document can be added if the maintainers of the URN namespace
1054 demonstrate to IANA the usability of query directives with the
1055 respective keyword; for such requests, IANA may seek advice from the
1056 URN-NID experts as well.
1058 Initial registrations:
1060 Keywd Purpose Scope Defn. Ref.
1061 ----- -------------------------------- -------- ------------------
1062 s intended URN resolution service global RFC this, s. 2.3.1
1063 c component of structured resource global RFC this, s. 2.3.2
1065 The "Supported by" lists for both entries initially are left empty.
1067 9.2.2. URN Resolution Service Designators Sub-Registry
1069 This registry lists the value tokens that can be used with the "s"
1070 keyword in the query part of URI references to URNs, in order to
1071 identify the desired URN resolution service.
1073 Entries capture the following items (that need to be provided by
1074 registration requests:
1076 Name - mnemomonic for the URN service
1078 Purpose - short phrase describing the service
1080 Status - "std", "exp","provisional", or "deprecated"
1082 Reference - Reference to defining RFC
1084 Registration policy is "RFC required" according to BCP 26 [RFC5226],
1085 where the RFC category required needs to match the desired "Status":
1086 Standards Track for "std", Experimental for "exp". Beyond the
1087 initial assignments performed below, "provisional" status can be
1088 assigned for pending registrations using the procedures of BCP 100
1089 [RFC4020]. IESG Approval ([RFC5226]) is required to modify an entry
1090 to change its status to "deprecated".
1092 In preparation for future work to update that document, the registry
1093 is initially populated with entries derived from Section 4 of RFC
1094 2483 [RFC2483], using uniform spelling of plural forms and marking
1095 all entries as "provisional":
1097 Name Purpose Status Reference
1098 ----- ----------------------------- ----------- ------------------
1099 I2L URI to URL provisional RFC 2483, sec. 4.1
1100 I2Ls URI to URLs provisional RFC 2483, sec. 4.2
1101 I2R URI to resource provisional RFC 2483, sec. 4.3
1102 I2Rs URI to resources provisional RFC 2483, sec. 4.4
1103 I2C URI to URC provisional RFC 2483, sec. 4.5
1104 I2Cs URI to URCs provisional RFC 2483, sec. 4.6
1105 I2N URI to URN provisional RFC 2483, sec. 4.7
1106 I2Ns URI to URNs provisional RFC 2483, sec. 4.8
1107 I=I URI equal to URI? provisional RFC 2483, sec. 4.9
1109 10. Acknowledgements
1111 This document is heavily based on RFC 2141 by Ryan Moats, which has
1112 laid the foundation for this work; that RFC contained the following
1113 Acknowledgements:
1115 Thanks to various members of the URN working group for comments on
1116 earlier drafts of this document. This document is partially
1117 supported by the National Science Foundation, Cooperative
1118 Agreement NCR-9218179.
1120 This document also heavily relies on and acknowledges the work done
1121 for STD 66 [RFC3986] and earlier RFCs that are being quoted
1122 informally, in particular RFC 1737 [RFC1737] authored by Karen
1123 Sollins and Larry Masinter. The experiences gathered during the
1124 first (more than a) decade of URN usage were also helpful, so
1125 individuals and organizations which have implemented and used URNs
1126 are also acknowledged. In particular, the experience gained with
1127 parties wanting to make use of the URN framework and submit URN
1128 Namespace registration documents, and their desire to obtain the
1129 necessary collected background information has motivated and shaped
1130 the text put into Section 1 of this document.
1132 Many individuals in the URNbis working group have participated in the
1133 detailed discussion of this memo. Particular thanks for detailed
1134 review comments and text suggestions go to Juha Hakala, Mykyta
1135 Yevstifeyev, Peter Saint-Andre, Subramanian Moonesamy, Bengt Neiss,
1136 and Lars Svensson.
1138 11. References
1140 11.1. Normative References
1142 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1143 Requirement Levels", BCP 14, RFC 2119, March 1997.
1145 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
1146 10646", STD 63, RFC 3629, November 2003.
1148 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1149 Resource Identifier (URI): Generic Syntax", STD 66,
1150 RFC 3986, January 2005.
1152 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
1153 Registration Procedures for New URI Schemes", BCP 35,
1154 RFC 4395, February 2006.
1156 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
1157 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
1158 May 2008.
1160 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
1161 Specifications: ABNF", STD 68, RFC 5234, January 2008.
1163 11.2. Informative References
1165 [I-D.ietf-urnbis-rfc3406bis-urn-ns-reg]
1166 Hoenes, A., "Uniform Resource Name (URN) Namespace
1167 Definition Mechanisms",
1168 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-03 (work in
1169 progress), October 2012.
1171 [IANA] IANA, "The Internet Assigned Numbers Authority",
1172 .
1174 [IANA-URI]
1175 IANA, "URI Schemes Registry",
1176 .
1178 [IANA-URN]
1179 IANA, "URN Namespace Registry",
1180 .
1182 [RFC0615] Crocker, D., "Proposed Network Standard Data Pathname
1183 syntax", RFC 615, March 1974.
1185 [RFC0645] Crocker, D., "Network Standard Data Specification syntax",
1186 RFC 645, June 1974.
1188 [RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
1189 Unifying Syntax for the Expression of Names and Addresses
1190 of Objects on the Network as used in the World-Wide Web",
1191 RFC 1630, June 1994.
1193 [RFC1736] Kunze, J., "Functional Recommendations for Internet
1194 Resource Locators", RFC 1736, February 1995.
1196 [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
1197 Uniform Resource Names", RFC 1737, December 1994.
1199 [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
1200 Resource Locators (URL)", RFC 1738, December 1994.
1202 [RFC1808] Fielding, R., "Relative Uniform Resource Locators",
1203 RFC 1808, June 1995.
1205 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
1207 [RFC2169] Daniel, R., "A Trivial Convention for using HTTP in URN
1208 Resolution", RFC 2169, June 1997.
1210 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource
1211 Name Resolution", RFC 2276, January 1998.
1213 [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
1214 Resource Identifiers (URI): Generic Syntax", RFC 2396,
1215 August 1998.
1217 [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services
1218 Necessary for URN Resolution", RFC 2483, January 1999.
1220 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
1221 "Service Location Protocol, Version 2", RFC 2608,
1222 June 1999.
1224 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
1225 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611,
1226 June 1999.
1228 [RFC2717] Petke, R. and I. King, "Registration Procedures for URL
1229 Scheme Names", BCP 35, RFC 2717, November 1999.
1231 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
1232 "Guidelines for new URL Schemes", RFC 2718, November 1999.
1234 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/
1235 IETF URI Planning Interest Group: Uniform Resource
1236 Identifiers (URIs), URLs, and Uniform Resource Names
1237 (URNs): Clarifications and Recommendations", RFC 3305,
1238 August 2002.
1240 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
1241 Part One: The Comprehensive DDDS", RFC 3401, October 2002.
1243 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
1244 Part Two: The Algorithm", RFC 3402, October 2002.
1246 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
1247 Part Three: The Domain Name System (DNS) Database",
1248 RFC 3403, October 2002.
1250 [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
1251 Part Four: The Uniform Resource Identifiers (URI)",
1252 RFC 3404, October 2002.
1254 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
1255 "Uniform Resource Names (URN) Namespace Definition
1256 Mechanisms", BCP 66, RFC 3406, October 2002.
1258 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
1259 Standards Track Code Points", BCP 100, RFC 4020,
1260 February 2005.
1262 Appendix A. Handling of URNs by URL Resolvers/Browsers
1264 The URN syntax has been defined so that URNs can be used in places
1265 where URLs are expected. A resolver that conforms to the current URI
1266 syntax specification [RFC3986] will extract a scheme value of "urn"
1267 rather than a scheme value of "urn:".
1269 An URN MUST be considered an opaque URI by URL resolvers and passed
1270 (with the "urn:" tag) to a URN resolver for resolution. The URN
1271 resolver can either be an external resolver that the URL resolver
1272 knows of, or it can be functionality built into the URL resolver.
1274 However note that, according to RFC 3986, the part of a
1275 URN will be stripped by a resolver client before passing the URN to
1276 the resolver, and subsequently be applied to the returned result --
1277 in the manner specified for the returned media type.
1279 To avoid confusion of users, a URL browser SHOULD display the
1280 complete URN (including the "urn:" tag) to ensure that there is no
1281 confusion between URN Namespace identifiers and URI Scheme names.
1283 Appendix B. Collected ABNF (Informative)
1285 As a service to implementers specifically interested in URN syntax,
1286 the complete ABNF for URNs is collected here, including the
1287 referenced rules from [RFC5234] and [RFC3986]. In case of
1288 (unexpected) inconsistencies, these documents remain normative for
1289 the respective productions.
1291 URNs conform to the variant of the general URI syntax
1292 specified in Section 3 of [RFC3986] :
1294 URI = scheme ":" path-rootless [ "?" query ] [ "#" fragment ]
1296 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
1297 path-rootless = segment-nz *( "/" segment )
1298 query = *( pchar / "/" / "?" )
1299 fragment = *( pchar / "/" / "?" )
1301 segment-nz = 1*pchar
1302 segment = *pchar
1303 pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
1305 unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
1306 pct-encoded = "%" HEXDIG HEXDIG
1307 sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
1308 / "*" / "+" / "," / ";" / "="
1310 In the case of URNs, the above rules are subject to more specific
1311 restrictions, specified in Section 2 of this RFC:
1313 scheme = "urn"
1314 ; specific, fixed (assigned) value
1316 urn-path = NID ":" NSS
1317 ; to be superimposed on ,
1318 ; which needs to be only
1320 NID = ( ALPHA / DIGIT ) 1*31( ALPHA / DIGIT / "-" )
1321 ; RFC 3406[bis] contains more specific rules
1323 NSS = 1*pchar
1324 ; or equivalent: NSS = segment-nz
1326 urn-query = directive *( "&" directive)
1327 ; to be superimposed on
1329 directive = keywd "=" value
1330 keywd = ALPHA *( ["-"] (ALPHA / DIGIT))
1331 value = *v-pchar
1333 v-pchar = unreserved / pct-encoded / v-subdels
1334 v-subdels = "!" / "$" / "'" / "(" / ")"
1335 / "*" / "+" / "," / ";" / "="
1336 ; this is equivalent to except "&"
1337 / ":" / "@" / "/" / "?"
1338 ; plus the extra characters allowed in
1339 ; and for , as per RFC 3986
1341 The above rules make use of the following "Core Rules" from Appendix
1342 B.1 of [RFC5234] :
1344 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
1345 DIGIT = %x30-39 ; 0-9
1346 HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
1348 Appendix C. Breakdown of NSS Syntax Evolution since RFC 2141
1349 (Informative)
1351 In order to make visible the detailed migration path from RFC 2141
1352 and the influence of the evolution of URI syntax from RFC 2396 to RFC
1353 3986 on it, this appendix provides a highly annotated and expanded
1354 version of the NSS syntax provided in Section 2.2:
1356 NSS = 1*pchar ; or equivalent: NSS = segment-nz
1358 In particular, the breakdown below serves to provide evidence of that
1359 this syntax correctly reflects the addition of "&" and "~" to the
1360 repertoire of characters allowed in the NSS portion of URNs
1361 previously allowed by RFC 2141; it expands on the syntax specified in
1362 RFC 2141 after translation to standard ABNF.
1364 NSS = 1*URN-char
1366 URN-char = trans / pct-encoded
1367 ; Note that from RFC 3986 here replaces the
1368 ; explicit, expanded form used in RFC 2141.
1370 trans = ALPHA / DIGIT / u-other
1371 ; Note that RFC 2141's has been disambiguated here
1372 ; into .
1373 ; RFC 2141 also said:
1374 ; / reserved
1375 ; This caused an ambiguity in RFC 2141 with respect to "%", which
1376 ; now is resolved here by omission of this dangling alternative.
1377 ;
1378 ; After adoption of the generic URI syntax from RFC 3986, there
1379 ; is no more need to deal here with the higher-level separator
1380 ; characters "/", "?", and "#" contained in
1381 ; (beyond "%", which is fully taken care of by ),
1382 ; which are part of RFC 3986's , as shown below.
1384 ; From RFC 2141:
1385 ; reserved = '%" / "/" / "?" / "#" ; SIC!
1386 ; ^ ^
1388 u-other = ":" / "@"
1389 ; those from RFC 3986
1390 ; specifically allowed in .
1391 ; From RFC 3986:
1392 ; gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
1394 / "!" / "$" / "'" / "(" / ")"
1395 / "*" / "+" / "," / ";" / "="
1396 ; this is RFC 3986 except "&".
1397 ; From RFC 3986:
1398 ; sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
1399 ; / "*" / "+" / "," / ";" / "="
1400 ; The URNbis WG arrived at unanimous consensus that "&" can be
1401 ; allowed without harm to backward compatibility for existing
1402 ; URN Namespaces.
1404 / "-" / "." / "_" ; except "~"
1405 ; From RFC 3986:
1407 ; unreserved = ALPHA / DIGIT
1408 ; / "-" / "." / "_" / "~"
1409 ; The URNbis WG arrived at unanimous consensus that "~" can be
1410 ; allowed without harm to backward compatibility for existing
1411 ; URN Namespaces.
1413 ; Since we now allow "&" and "~" , becomes ,
1414 ; greatly simplifying the syntax rules and parsers!
1416 ; From RFC 3986:
1417 ; segment-nz = 1*pchar
1418 ; pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
1420 Appendix D. Changes since RFC 2141 (Informative)
1422 D.1. Essential Changes from RFC 2141
1424 [[ RFC-Editor: please remove the Appendix D.1 headline and all
1425 subsequent subsections starting with Appendix D.2. ]]
1427 Expanded Introduction to cover background material frequently
1428 requested by interested parties not well acquainted with RFCs and
1429 past/present work in the IETF, in particular prospective URN
1430 Namespace stakeholders and applicants for URN Namespace
1431 registrations. The material included also serves to avoid normative
1432 downrefs to legacy RFCs that are very unlikely to be progressed on
1433 the Standards Track in the foreseeable future.
1435 Document references updated and split; Normative References now only
1436 to Full Internet Standards to allow for future progress of this memo
1437 on the IETF Standards Track.
1439 Formal syntax now specified using ABNF (STD 68), using productions
1440 from Generic URI Syntax (STD 66) and STD 68.
1442 NID Syntax slightly more restrictive than in RFC 2141 (compatible
1443 with existing and in-progress NID registrations).
1445 NSS syntax now allows "&" and "~" to align URN syntax with generic
1446 rule from STD 66; an ambiguity in the formal rules and
1447 incompatibilities between the formal rules and the prose description
1448 in RFC 2141 have been straightened out ("%" no more allowed outside
1449 percent-encoding triples, other characters no more
1450 admitted by formal syntax rules).
1452 Use of query and fragment part with URNs now specified, mostly by
1453 reference to STD 66. Syntactical pattern for query part defined;
1454 IANA registry for query keywords in URN references established.
1456 This document also performs the outstanding formal registration of
1457 the 'urn' URI scheme.
1459 Supplemental material in Appendices documents considerations and
1460 decisions made in the development of this memo.
1462 D.2. Changes from RFC 2141 to Individual Draft -00
1464 Abstract amended: URI scheme, replacement for 2141, point to 3406.
1465 Use contemporary boilerplate. Added transient "Discussion" section.
1467 s1: added new 1st para (URI scheme) and 3rd para (hierarchy).
1468 s1.1 (Historical Perspective) added for background & motivation.
1469 s1.2 (Objective) added.
1470 s1.3 (2119 keywords) added -- used now throughout normative text.
1472 s2 (URN Syntax): Shifted from BNF to ABNF; explain relationship to
1473 3986 and gaps, how the gaps could be bridged, distinguish between URI
1474 generics and URN specifics; got rid of references to immature
1475 documents (1630, 1737).
1476 s2.1 (NID syntax): Use ABNF and RFC 5234 terminals (core rules);
1477 removed reference to an old draft of 2396; clarified prohibition to
1478 use "urn" as NID.
1479 s2.2 (NSS syntax): Shifted from BNF to ABNF; made ABNF consistent
1480 with subsequent textual description; exposition much expanded,
1481 showing relationship with 3986 and resulting incompatibilities;
1482 proposed how to bridge gaps, to make parsing more uniform among URIs;
1483 updated i18n considerations and pointer to UTF-8 specification.
1484 s.2.3, s2.3.*: reworked and much expanded, along the grouping of
1485 delimiter characters from 3986 in new s2.3.1 (including old s.2.3.2);
1486 made text fully consistent with ABNF in s2.2; consistent usage of
1487 term "percent-encoded"; old s.2.3.1 became s2.3.2; old s3.4 became
1488 s3.3.3, providing complete, annotated list of excluded characters,
1489 ordered by ascending code point; and restating design decisions
1490 needed to be made to close gaps to 3986.
1492 s3 through s6: only minor editorial changes.
1494 s7: formal registration of 'urn' URI scheme added, using 4395
1495 template.
1497 s8: Security Cons. slightly amended.
1499 s9: new: IANA Cons. added wrt s7.1 and prohibition of NID "urn".
1501 s10: Acknowledgments amended.
1503 s11: References split into Normative and Informative; updated refs
1504 and added many; only FS and BCP allowed as Normative Refs to further
1505 promotion of document.
1507 Added Appendices A through D.
1509 D.3. Changes from Individual Draft -00 to -02
1511 Updated "Discussion" on front page to point to dedicated urn list.
1513 Numerous editorial improvements and additions for clarification, in
1514 particular in the Introduction. No technical changes.
1516 More Informative References; missing details supplied in D.2.
1518 D.4. Changes from Individual Draft -02 to WG Draft -00
1520 Added new s1.2 to Introduction, with excerpts from RFC 1737 to
1521 provide background on URN functional and syntax requirements.
1522 Renumbered previous s1.2 and s1.3 to s1.3 and s1.4, respectively.
1524 Supplied text in s2 regarding the envisioned use of query and
1525 fragment parts, based on various discussion -- including a
1526 preliminary evaluation in PersID.
1528 Changed "SHOULD never" to "MUST NOT" for NUL character in NSS.
1530 Various editorial and grammar fixes; corrected STD / BCP numbers.
1532 D.5. Changes from WG Draft -00 to WG Draft -01
1534 Reflect WG consensus on adding "&" and "~" to the set of characters
1535 allowed in the NSS part of URNs, thus aligning URN syntax with
1536 generic URI syntax from RFC 3986.
1538 Moved breakdown of NSS syntax evolution from s2.2 to new Appendix C.
1540 Avoid "[URN] character set" in favor of "character repertoire" to
1541 minimize potential clashes with IETF terminology on charsets.
1543 s2.3.3: URN recognition in text documents is regarded out of scope.
1545 The previous version was ambiguous on whether eventual query and/or
1546 fragment parts were regarded as part of the NSS; after closer
1547 inspection of the syntax, clarification has been added that the syntax is indeed superimposed on the ABNF rule for
1549 URNs, and hence does not cover the trailing higher level parts
1550 (query, fragment) according to the URI syntax.
1552 Filled in Appendix B contents.
1554 Numerous editorial and grammar improvements.
1556 D.6. Changes from WG Draft -01 to WG Draft -02
1558 Added note at the beginning of Section 1.3 highlighting the purpose
1559 of this section. The URNbis charter excludes a revision of RFC 1738,
1560 and hence the changes suggested on the list to alter and update this
1561 section have been dismissed.
1563 Added hint to URN Namespace designers in Section 2 that ":" is
1564 customarily used in URN Namespaces to provide further level(s) of
1565 hierarchical subdivision of NSSs.
1567 Reworked text on fragment identification issues and resulting
1568 specification, mostly based on Juha Hakala's evaluation of the
1569 consensus evolving from the list discussion.
1571 Modified ABNF rule for NIDs to better align it with rules for similar
1572 identifiers used in IETF protocols. The new rule now prohibits a
1573 trailing hyphen, but defers further restricting rules on NID syntax
1574 (based on the kind of NID) to RFC 3406bis.
1576 More clearly documented and marked (still open / already closed)
1577 ISSUES. The related text will be removed in the next draft version,
1578 whence it should have been transferred into the IETF issue tracking
1579 system.
1581 Text of Section 3 revised, based on Juha's suggestion.
1583 In Section 5, added removal of part (but not part)
1584 to canonicalization steps for the purpose of determining lexical
1585 equivalence of URNs (Juha's comment). Also added examples showing
1586 this.
1588 Elaborated a bit more on Encoding Consideration in the URI Scheme
1589 registration template (Juha's comments).
1591 Numerous editorial corrections and improvements.
1593 D.7. Changes from WG Draft -02 to WG Draft -03
1595 Added text in s1.1 to reflect a comment from SM on other, legacy
1596 interpretations of "URN".
1598 Added note in old s1.2 to reflect importance of the name binding
1599 established by a URN (derived from list discussion on other topic,
1600 Keith Moore et al.).
1601 However, (despite comments from SM and PSA) preserved excerpts there
1602 to keep document self-contained and avoid normative down-references
1603 (as discussed during WG chartering process and pointed out in the
1604 third para of old s1.3). Doing so should also help to avoid another
1605 future recurrence of the discussion on these topics that has consumed
1606 a lot of resources unnecessarily during the WG formation process.
1608 Swapped s1.2 and s1.3 (note from SM); however, for logical reasons,
1609 motivation (part of s1.1) needs to stay in the text before the
1610 objectives derived thereof (now s1.2).
1612 Material on query part enhanced (new subsection 2.3); structure of
1613 query part formally specified with a rather liberal syntax (could be
1614 more restrictive, if WG prefers); IANA registry of URN query keywords
1615 established, with two initial entries for the global scope "s" and
1616 "c" keywords now specified in s2.3.1 and s2.3.2.
1618 To avoid further confusion (as seen on the list discussion), this I-D
1619 uses the term "fragment" only for the trailing component in the
1620 Generic URI Syntax and the semantics associated with it in RFC 3986;
1621 otherwise this I-D talks about "components" of structured resources.
1623 Material on fragment part heavily revised and stripped down, put in
1624 new subsection 2.4. New text is intended to reflect least common
1625 denominator of list discussion; i.e., mostly just enable usage by
1626 specific URN Namespace and otherwise point to RFC 3986 and RFC
1627 3406bis.
1628 Namespace designers now have three options to design-in component
1629 resource designation (if warranted for the namespace), whichever is
1630 the best fit for their underlying identifier system: (1) media-
1631 specific designation using fragment part, (2) media-independent,
1632 abstract designation using query part (to be dealt with by resolution
1633 system, not resolution client), and (3) media-independent designation
1634 via assignment of distinct NSSs to component resources.
1635 (That is being elaborated upon to a greater extent in the -03 version
1636 of the rfc3406bis I-D.)
1638 Added text to percent-encoding considerations (Bengt Neiss'
1639 concerns).
1641 Amended text on support of existing identifier systems (s3), based on
1642 various comments received.
1644 Revised part of text in s5 and s6 on lexical/functional equivalence
1645 to reflect the new specification for query and fragment (new s2.3,
1646 s2.4) and to address several comments received; changed s5.1
1647 accordingly.
1649 In spite of the challenges raised by serious evidence of improper
1650 management practices for the ISBN system and hence the URN:ISBN
1651 Namespace (Lars Svensson), the I-D still contains one (hypothetical)
1652 example based on URN:ISBN; this is being thought acceptable because
1653 it is in the tradition of earlier documents and we can expect that
1654 every potential reader of the memo will have an understanding what
1655 ISBNs are for (or should be).
1657 Modified title of s7.1 to avoid clash with new s9.1. Added IANA
1658 Considerations for "URN Query Parameters" registries (s9.2).
1660 Acknowledgements expanded.
1662 Amended Appendix A with text regarding usage.
1664 Filled in details in Appendix D.1; added this Appendix D.7.
1666 Former Appendix E (guide to IETF document repositories) and pointer
1667 to it removed (comment from SM).
1669 Multiple editorial enhancements and fixes.
1671 Author's Address
1673 Alfred Hoenes (editor)
1674 TR-Sys
1675 Gerlinger Str. 12
1676 Ditzingen D-71254
1677 Germany
1679 EMail: ah@TR-Sys.de