idnits 2.17.1
draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== 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 31, 2011) is 4561 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-22) exists of
draft-ietf-urnbis-rfc2141bis-urn-01
** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126)
-- Obsolete informational reference (is this intentional?): RFC 2611
(Obsoleted by RFC 3406)
-- Obsolete informational reference (is this intentional?): RFC 3406
(Obsoleted by RFC 8141)
-- Obsolete informational reference (is this intentional?): RFC 4020
(Obsoleted by RFC 7120)
-- Obsolete informational reference (is this intentional?): RFC 4395
(Obsoleted by RFC 7595)
Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 IETF URNbis WG A. Hoenes
3 Internet-Draft TR-Sys
4 Obsoletes: 3406 (if approved) October 31, 2011
5 Intended status: BCP
6 Expires: May 3, 2012
8 Uniform Resource Name (URN) Namespace Definition Mechanisms
9 draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01
11 Abstract
13 Uniform Resource Names (URNs) are intended to serve as persistent,
14 location-independent, resource identifiers. To structure and
15 organize their usage, the URN syntax specifies a hierarchy that
16 divides the set of possible URNs into "URN Namespaces" that can be
17 individually defined and managed. URN Namespaces in particular serve
18 to map existing identifier systems into the URN system and thereby
19 make available generic, network-based resolution services for the
20 identified documents, artifacts, and other objects (and their
21 metadata).
23 To actually leverage such synergetic advantage, URN Namespaces need
24 to be specified in a comparable manner, and their Namespace
25 Identifiers (NIDs) need to be registered with IANA, so that naming
26 conflicts are avoided and implementers of services can follow a
27 structured approach in support of various namespaces, guided by the
28 registry to the related documents and the particularities of specific
29 namespaces, as described in these namespace registration documents.
31 This document serves as a guideline for authors of URN Namespace
32 definition and registration documents. It describes the essential
33 content of such documents and how they shall be structured to allow
34 readers familar with the scheme to quickly assess the properties of a
35 specific URN Namespace. Further, this RFC describes the process to
36 be followed to get a URN Namespace registered with IANA.
38 This document is a companion document to the revised URN Syntax
39 specification, RFC 2141bis; it supersedes and replaces RFC 3406.
41 Discussion
43 Discussion of this memo utilizes the urn@ietf.org mailing list.
45 Status of This Memo
47 This Internet-Draft is submitted in full conformance with the
48 provisions of BCP 78 and BCP 79.
50 Internet-Drafts are working documents of the Internet Engineering
51 Task Force (IETF). Note that other groups may also distribute
52 working documents as Internet-Drafts. The list of current Internet-
53 Drafts is at http://datatracker.ietf.org/drafts/current/.
55 Internet-Drafts are draft documents valid for a maximum of six months
56 and may be updated, replaced, or obsoleted by other documents at any
57 time. It is inappropriate to use Internet-Drafts as reference
58 material or to cite them other than as "work in progress."
60 This Internet-Draft will expire on May 3, 2012.
62 Copyright Notice
64 Copyright (c) 2011 IETF Trust and the persons identified as the
65 document authors. All rights reserved.
67 This document is subject to BCP 78 and the IETF Trust's Legal
68 Provisions Relating to IETF Documents
69 (http://trustee.ietf.org/license-info) in effect on the date of
70 publication of this document. Please review these documents
71 carefully, as they describe your rights and restrictions with respect
72 to this document. Code Components extracted from this document must
73 include Simplified BSD License text as described in Section 4.e of
74 the Trust Legal Provisions and are provided without warranty as
75 described in the Simplified BSD License.
77 This document may contain material from IETF Documents or IETF
78 Contributions published or made publicly available before November
79 10, 2008. The person(s) controlling the copyright in some of this
80 material may not have granted the IETF Trust the right to allow
81 modifications of such material outside the IETF Standards Process.
82 Without obtaining an adequate license from the person(s) controlling
83 the copyright in such materials, this document may not be modified
84 outside the IETF Standards Process, and derivative works of it may
85 not be created outside the IETF Standards Process, except to format
86 it for publication as an RFC or to translate it into languages other
87 than English.
89 Table of Contents
91 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
92 1.1. Requirement Language . . . . . . . . . . . . . . . . . . . 5
93 2. What is a URN Namespace? . . . . . . . . . . . . . . . . . . . 5
94 3. URN Namespace (Registration) Types . . . . . . . . . . . . . . 6
95 3.1. Experimental Namespaces . . . . . . . . . . . . . . . . . 6
96 3.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 6
97 3.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 7
98 4. URN Namespace Registry: Processes for Registration and
99 Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
100 4.1. Experimental Namespaces: No Registration . . . . . . . . . 9
101 4.2. Informal Namespaces . . . . . . . . . . . . . . . . . . . 9
102 4.3. Formal Namespaces . . . . . . . . . . . . . . . . . . . . 10
103 4.4. Registration Documents . . . . . . . . . . . . . . . . . . 11
104 4.4.1. Namespace Considerations in Registration Documents . . 11
105 4.4.2. Community Considerations in Registration Documents . . 12
106 4.4.3. Security Considerations in Registration Documents . . 12
107 4.4.4. IANA Considerations in Registration Documents . . . . 13
108 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
109 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
110 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
112 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
113 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
114 Appendix A. URN Namespace Definition Template . . . . . . . . . . 16
115 Appendix B. Illustration . . . . . . . . . . . . . . . . . . . . 22
116 B.1. Example Template . . . . . . . . . . . . . . . . . . . . . 22
117 B.2. Registration steps in practice . . . . . . . . . . . . . . 24
118 Appendix C. Changes from RFC 3406 . . . . . . . . . . . . . . . . 25
119 C.1. Essential Changes since RFC 3406 . . . . . . . . . . . . . 25
120 C.2. Changes from RFC 3406 to URNbis WG Draft -00 . . . . . . . 25
121 Appendix D. Open Issues . . . . . . . . . . . . . . . . . . . . . 28
123 1. Introduction
125 Uniform Resource Names (URNs) are resource identifiers with the
126 specific requirements for enabling location-independent
127 identification of a resource, as well as longevity of reference.
128 URNs are part of the larger Uniform Resource Identifier (URI) family
129 (see the joint W3C/IETF memorandum, RFC 3305 [RFC3305], and the IETF
130 STD 66, RFC 3986 [RFC3986]) with the specific goal of providing
131 persistent naming of resources.
133 There are two assumptions that are key to this document:
135 Assumption #1: Assignment of a URN is a managed process.
137 I.e., not all strings that conform to URN syntax are necessarily
138 valid URNs. A URN is assigned according to the rules of a
139 particular namespace (in terms of syntax, semantics, and process).
141 Assumption #2: The space of URN Namespaces is managed.
143 I.e., not all syntactically correct URN Namespaces (per the URN
144 syntax definition) are valid URN Namespaces. A URN Namespace must
145 have a recognized definition in order to be valid.
147 The purpose of this document is to outline a mechanism and provide a
148 template for explicit namespace definition, as well as provide the
149 mechanism for associating an identifier (called a "Namespace ID", or
150 NID), which is registered with the Internet Assigned Numbers
151 Authority (IANA) [IANA] in the URN Namespaces registry maintained at
152 [IANA-URN].
154 The URN Namespace definition and registration mechanisms originally
155 have been specified in RFC 2611 [RFC2611], which has been obsoleted
156 by BCP 66, RFC 3406 [RFC3406]. Guidelines for documents prescribing
157 IANA procedures have been revised as well over the years, and at the
158 time of this writing, BCP 26, RFC 5226 [RFC5226] is the normative
159 document. This document is a revision of RFC 3406 based on the
160 revised URN Syntax specification RFC 2141bis
161 [I-D.ietf-urnbis-rfc2141bis-urn] and RFC 5226.
163 The reader is referred to Section 1.1 of RFC 2141bis
164 [I-D.ietf-urnbis-rfc2141bis-urn] for a more detailed synopsis of the
165 history of documents fundamental for URNs.
167 Note that this document restricts itself to the description of
168 processes for the creation of URN Namespaces. If generic
169 "resolution" of any so-created URN identifiers is desired, a separate
170 process of registration in a global NID directory, such as that
171 provided by the DDDS system [RFC3401], is necessary. See [RFC3405]
172 for information on obtaining registration in the DDDS global NID
173 directory.
175 1.1. Requirement Language
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
179 document are to be interpreted as described in RFC 2119 [RFC2119].
180 In this document, these key words describe requirements for the
181 process to be followed and the content to be provided in namespace
182 definition documents and registration templates.
184 For the purpose of this document, its subject is spelled "URN
185 Namespace" (in headline case), whereas in other context, "namespace"
186 is spelled in lowercase, e.g. to designate a (standard or non-
187 standard) identifier system on which a URN Namespace is based.
189 2. What is a URN Namespace?
191 For the purposes of URNs, a "namespace" is a collection of uniquely-
192 assigned identifiers. That is, the identifiers are not ever assigned
193 to more than 1 resource, nor are they ever re-assigned to a different
194 resource. A single resource, however, may have more than one URN
195 assigned to it for different purposes. Such namespace might be
196 defined by some pre-established (standard or non-standard) identifier
197 system that can be made "network-actionable" by embedding it into the
198 URN framework using a specific URN Namespace. A URN Namespace itself
199 has an identifier in order to:
201 - ensure global uniqueness of URNs,
203 - (where desired) provide a cue for the structure of the identifier.
205 For example, many identifier systems use strings of numbers as
206 identifiers (e.g., ISBN, ISSN, phone numbers). It is conceivable
207 that there might be some numbers that are valid identifiers in two
208 different established identifier systems. Using different
209 designators for the two collections ensures that no two URNs will be
210 the same for different resources (since each collection is required
211 to uniquely assign each identifier).
213 The development of an identifier structure, and thereby a collection
214 of identifiers, is a process that is inherently dependent on the
215 requirements of the community defining the identifier, how they will
216 be assigned, and the uses to which they will be put. All of these
217 issues are specific to the individual community seeking to define a
218 namespace (e.g., publishing community, association of booksellers,
219 protocol developers, etc.); they are beyond the scope of the IETF URN
220 work.
222 This document outlines the processes by which a collection of
223 identifiers satisfying certain constraints (uniqueness of assignment,
224 etc.) can become a bona fide URN Namespace by obtaining a NID. In a
225 nutshell, a template for the definition of the namespace is completed
226 for deposit with IANA, and a NID is assigned. The details of the
227 process and possibilities for NID strings are outlined below.
229 3. URN Namespace (Registration) Types
231 There are three categories of URN Namespaces defined here,
232 distinguished by expected level of service and required procedures
233 for registration. Registration processes for each of these namespace
234 types are given in Section 4.
236 3.1. Experimental Namespaces
238 These are not explicitly registered with IANA.
240 No provision is made for avoiding collision of experimental NIDs;
241 they are intended for use within internal or limited experimental
242 contexts. However, as described below in Section 4.1, these are
243 designated by a specific form of the NID to allow differentiation
244 (without preexisting knowledge of details) from the other URN
245 Namespace types.
247 [[ Editorial Note:
248 Has anybody ever seen usage of such experimental URN Namespaces?
249 According to the observations of the author, three years of RFC 2611
250 and nine years of RFC 3406 have constantly seen "tentative grabbing"
251 and subsequent usage of NIDs that the stakeholders later have tried
252 to register with IANA as Formal NIDs (with varying success).
253 So should this kind of namespaces better be dropped and a kind of
254 provisional NIDs be created? -- This would be in the spirit of BCP
255 100, RFC 4020 [RFC4020], and it would resemble the manner how URI
256 Scheme registrations are dealt with (RFC 4395 [RFC4395], [IANA-URI]).
257 ]]
259 3.2. Informal Namespaces
261 These are fully fledged URN Namespaces, with all the rights and
262 requirements associated thereto. Informal namespaces can be
263 registered in global registration services. They are required to
264 uphold the general principles of a well-managed URN Namespace --
265 providing persistent identification of resources and unique
266 assignment of identifier strings. Informal and formal namespaces
267 (described below) differ in the NID assignment. IANA will assign an
268 alphanumeric NID (following a defined pattern) to registered informal
269 namespaces, per the process outlined in Section 4.
271 3.3. Formal Namespaces
273 A formal namespace may be requested, and IETF review sought, in cases
274 where the publication of the NID proposal and the underlying
275 namespace will provide benefit to some subset of users on the
276 Internet. That is, a formal NID proposal, if accepted, must be
277 functional on and with the global Internet, not limited to users in
278 communities or networks not connected to the Internet. For example,
279 assume a NID is requested that is meant for naming of physics
280 research. If that NID request required that the user use a
281 proprietary network or service that was not at all open to the
282 general Internet user, then it would make a poor request for a formal
283 NID. The intent is that, while the community of those who may
284 actively use the names assigned within that NID may be small (but no
285 less important), the potential use of names within that NID is open
286 to any user on the Internet.
288 It is expected that Formal NIDs may be applied to namespaces where
289 some aspects are not fully open. For example, a namespace may make
290 use of a fee-based, privately managed, or proprietary registry for
291 assignment of URNs in the namespace, but it may still provide benefit
292 to some Internet users if the services associated have openly-
293 published access protocols.
295 In addition to the basic registration information defined in the
296 registration template (in Appendix A), a formal namespace request
297 must be accompanied by documented considerations of the need for a
298 new namespace and of the community benefit from formally establishing
299 the proposed URN Namespace.
301 Additionally, since the goal of URNs is to provide persistent
302 identification, some consideration as to the longevity and
303 maintainability of the namespace must be given. The collective
304 experience of the IETF community contains a wealth of information on
305 technical factors that will prevent longevity of identification.
306 Thus, the IESG may elect not to accept a proposed namespace
307 registration if the IETF community consensus is that the registration
308 document contains technical flaws that will prevent (or seriously
309 impair the possibility of) persistent identification, and that it
310 therefore should not be published as an RFC.
312 In addition to the technical aspects of the namespace and its
313 resolution, consideration should be given to the following
314 organizatorial aspects:
316 - the organization maintaining the URN Namespace should demonstrate
317 stability and the ability to maintain the URN namespace for a long
318 time, and/or it should be clear how the namespace can continue to
319 be usable/useful if the organization ceases to be able to foster
320 it;
322 - it should demonstrate ability and competency in name assignment;
323 this should improve the likelihood of persistence (e.g., to
324 minimize the likelihood of conflicts);
326 - it needs to commit to not re-assigning existing names and allowing
327 old names to continue to be valid, even if the owners or assignees
328 of those names are no longer members or customers of that
329 organization; this does not mean that there must be resolution of
330 such names, but that they must not resolve the name to false or
331 stale information, and that they must not be reassigned.
333 These aspects, though hard to quantify objectively, should be
334 considered by organizations/people considering the development of a
335 Formal URN Namespace, and they will be kept in mind when evaluating
336 the technical merits of any proposed Formal URN Namespace. The kind
337 of mandate upon which the organization aims to undertake this
338 activity might give a strong indication for this evaluation, because
339 it likely mirrors the trust that other parties (e.g. states,
340 international treaty organizations, professionals' associations,
341 etc.) put on the organization.
343 4. URN Namespace Registry: Processes for Registration and Update
345 Different levels of disclosure are expected/defined for namespaces.
346 According to the level of open-forum discussion surrounding the
347 disclosure, a URN Namespace may be assigned an identifier or may
348 request a particular identifier.
350 The IANA Considerations Guidelines document (BCP 26, RFC 5226
351 [RFC5226]) suggests the need to specify update mechanisms for
352 registrations -- who is given the authority to do so, from time to
353 time, and what are the processes. Since URNs are meant to be
354 persistently useful, few (if any) changes should be made to the
355 structural interpretation of URN strings (e.g., adding or removing
356 rules for lexical equivalence that might affect the interpretation of
357 URN IDs already assigned). However, it may be important to introduce
358 clarifications, expand the list of authorized URN assigners, etc.,
359 over the natural course of a namespace's lifetime. Specific
360 processes are outlined below.
362 The official list of registered URN Namespaces is currently
363 maintained by IANA at
364 .
366 The registraty is subdivided into two sub-registries, one for "Formal
367 URN Namespaces" and one for "Informal URN Namespaces", and each entry
368 there links to a stable repository of the registration document or
369 (an escrow copy of) the filled-out registration template.
371 The registration and maintenance procedures vary slightly between the
372 namespace types.
374 4.1. Experimental Namespaces: No Registration
376 The NIDs of Experimental Namespaces (Section 3.1) are not explicitly
377 registered with IANA. They take the form:
379 X-
381 where is a string consisting solely of letters, decimal digits,
382 and hyphen ("-") characters, as specified by the NID syntax
383 specification in Section 2.1 of RFC 2141bis
384 [I-D.ietf-urnbis-rfc2141bis-urn].
386 No provision is made for avoiding collision of experimental NIDs;
387 they are intended for use within internal or limited experimental
388 contexts exclusively.
390 As there is no registration, no registration/maintenance procedures
391 are needed.
393 Usage of Experimental URN Namespaces MUST be short-lived and whithin
394 a private scope; it MUST NOT be disclosed to the Internet at large,
395 e.g. by distribution of software versions that make use of such.
397 4.2. Informal Namespaces
399 The NIDs of Informal Namespaces are synthesized by the IANA using an
400 assigned sequence number and registered in their own sub-registry, as
401 indicated in Section 4; they take the format:
403 urn-
405 where is the decimal representation of a natural number,
406 with no leading zeroes. This sequence number is assigned by the IANA
407 on a First-Come-First-Served [RFC5226] basis to registration requests
408 for informal namespaces.
410 Registrants should send a copy of the registration template (as shown
411 in Appendix A), duly completed, to the urn-nid@ietf.org mailing list
412 for review and allow for a two-week discussion period for clarifying
413 the expression of the registration information and suggestions for
414 technical improvements to the namespace proposal.
415 [[ NOTE: Longer time is needed in practice! Increase to 4 weeks? ]]
417 After suggestions for clarification of the registration information
418 have been incorporated, the template may be submitted for assignment
419 of a NID by email to iana@iana.org .
421 Registrations may be updated later by the original registrant, or by
422 an entity designated by the registrant, by updating the registration
423 template, submitting it to the discussion list for a further two-week
424 discussion period, and finally resubmitting it to IANA in a message
425 to iana@iana.org .
427 4.3. Formal Namespaces
429 Formal NIDs are assigned via IETF Review, as defined in BCP 26
430 [RFC5226]. The designated expert(s) for URN Namespace registrations
431 are nominated by the IESG, and their role adheres to the regulations
432 in BCP 26, unless specified otherwise below.
434 NIDs for Formal URN Namespaces MUST NOT have the forms indicated in
435 the preceding two sections for the other two Namespace types. (The
436 detailed formal rules are given below in Section 4.4.4.) Applicants,
437 in concert with the IANA experts, should ensure that the sought NID
438 strings are "proper" for the designated purpose, according to common
439 sense (and applicable legal rules).
441 This means that the Formal NID application is made via submission to
442 the IETF of an Internet-Draft that contains the namespace definition
443 and targets publication as an RFC of Informational or Standards Track
444 category, which needs to be approved by the IESG after performing an
445 IETF Last Call on the document and evaluating review comments. The
446 applicant can be an individual or an IETF working group, in alignment
447 with the designation of the Internet-Draft. It is RECOMMENDED that
448 the registration documents for NIDs belonging to an established
449 standard namespace aim at Standards Track, whereas other applications
450 aim at Informational.
452 Before publication can be requested, however, the draft namespace
453 specification document must undergo an Expert Review process
454 [RFC5226] pursuant to the guidelines written here (as well as
455 standard RFC publication guidelines). The template defined in
456 Appendix A SHOULD be included as part of an RFC-to-be defining some
457 other aspect(s) of the namespace, or it may be put forward as a
458 namespace definition document in its own right. The proposed
459 template (including a pointer to a readily available copy of the
460 registration document) should be sent to the urn-nid@ietf.org mailing
461 list for review. This list is monitored by the designated expert(s).
463 The applicant has to allow for a two-week [[ four-week ? ]]
464 discussion period for clarifying the expression of the registration
465 information, and SHOULD improve the namespace document and/or
466 registration template based on the comments received, under the
467 guidance of the designated expert(s), before the IESG reviews the
468 document.
470 Working groups generally SHOULD seek early expert review for a
471 namespace definition document, before they hand it over to the IESG,
472 and individual applicants are also advised to seek expert comments
473 early enough. The aforementioned list can be contacted for informal
474 advice at any stage.
476 4.4. Registration Documents
478 The following subsections describe essential, MANDATORY parts of URN
479 Namespace registration documents, which will be focal in the expert
480 Review process and IETF Review.
482 4.4.1. Namespace Considerations in Registration Documents
484 The namespace definition document MUST include a "Namespace
485 Considerations" section that outlines the perceived need for a new
486 namespace (i.e., where existing namespaces fall short of the
487 proposer's requirements).
489 Considerations MUST include, directly or with the help of referenced
490 stable (and preferably readily available) documents:
492 - URN assignment procedures;
494 - URN resolution/delegation;
496 - type of resources to be identified;
498 - type of services to be supported.
500 NOTE: It is expected that more than one namespace may serve the same
501 "functional" purpose; the intent of the "Namespace Considerations"
502 section is to provide a record of the proposer's "due diligence" in
503 exploring existing possibilities, for the IESG's consideration.
505 [[ Editorial Note: See the endnote of the next section!
506 In particular, the above list (from RFC 3406) seems to be rather
507 orthogonal to the primary purpose of such section (as indicated in
508 the first paragraph), namely to provide evidence for the perceived
509 need for the new namespace.
510 ]]
512 4.4.2. Community Considerations in Registration Documents
514 The namespace definition document MUST also include a "Community
515 Considerations" section that indicates the dimensions upon which the
516 proposer expects its community to be able to benefit by publication
517 of this namespace, as well as how a general Internet user will be
518 able to use the space if they care to do so.
520 Potential considerations include:
522 - open assignment and use of identifiers within the namespace;
524 - open operation of resolution servers for the namespace
525 (server);
527 - creation of software that can meaningfully resolve and access
528 services for the namespace (client).
530 [[ Editorial Note:
531 It is acknowledged that, in many cases, the Namespace Considerations
532 and Community Considerations are closely intertwined. Further, the
533 bulleted lists above (from RFC 3406) seems to be more related to the
534 items in the registration template entitled "Identifier uniqueness
535 considerations", "Identifier persistence considerations", "Process of
536 identifier assignment", and "Process for identifier resolution" than
537 to the primary objectives presented in the first paragraph above
538 (also from RFC 3406).
539 In fact, namespace registration documents seen so far duplicate in
540 the registration template material from the "Community
541 Considerations" that addresses the above bullets.
542 Therefore: Should this specification now allow a combined section
543 "Namespace and Community Considerations" that focuses on the
544 (non-)utility of possible alternate namespace re-use and the
545 *benefits* of an independent new namespace?
546 ]]
548 4.4.3. Security Considerations in Registration Documents
550 According to the general procurements for RFCs, URN Namespace
551 definition documents must include a "Security Considerations" section
552 (cf. BCP 72 [RFC3552]). That section has to identify the security
553 considerations specific to the subject URN Namespace. If the subject
554 URN Namespace is based on an underlying namespace, the registration
555 can include substantive security considerations described in
556 specifications related to that particular namespace by reference to
557 these documents. For general security considerations regarding URN
558 usage (and more generally, URI usage), for the sake of clarity and
559 brevity, it should refer to the Security Considerations in STD 63
561 [RFC3986] and in the URN Syntax document
562 [I-D.ietf-urnbis-rfc2141bis-urn].
564 4.4.4. IANA Considerations in Registration Documents
566 According to the general procurements for RFCs, URN Namespace
567 definitions documents must include an "IANA Considerations" section
568 (cf. BCP 26 [RFC5226]). That section has to indicate that the
569 document includes a URN Namespace registration that is to be entered
570 into the IANA registry of Formal URN Namespaces.
572 Registration documents for formal URN Namespaces will provide a
573 particular, unique, desired NID string, and this will be assigned by
574 the Standards/Protocol Action of the IESG that approves the
575 publication of the registration document as an RFC. RFC 2141bis
576 [I-D.ietf-urnbis-rfc2141bis-urn] specifies that NID strings are ASCII
577 strings that are interpreted in a case-insensitive manner, but the
578 NID string SHALL be registered in the capitalization form preferred
579 by the registrant. The proposed NID string MUST conform with the
580 syntax rule in Section 2.1 of RFC 2141bis
581 [I-D.ietf-urnbis-rfc2141bis-urn] and it MUST adhere to the following
582 additional constraints:
584 - not be an already-registered NID;
586 - not start with "X-" (see Section 4.1 above);
588 - not start with "urn-" (see Section 4.2 above);
590 - not start with "xy-", where xy is any combination of 2 ASCII
591 letters (see NOTE below);
593 - be more than 2 characters long.
595 NOTE: All two-letter combinations as well as two-letter combinations
596 followed by "-" and any sequence of valid NID characters are reserved
597 for potential use as countrycode-based NIDs for eventual national
598 registrations of URN Namespaces. The definition and scoping of rules
599 for allocation of responsibility for such namespaces is beyond the
600 scope of this document.
601 Further, to avoid confusion, "urn" is not allowed as an NID string;
602 IANA has permanently reserved this string to prohibit assignment.
604 Registrations may be revised by updating the RFC through standard
605 IETF RFC update processes. In any case, a revised document, in the
606 form of a new Internet-Draft, must be published, and the proposed
607 updated template must be circulated on the urn-nid discussion list,
608 allowing for a two-week [[ four-week ? ]] review period before
609 pursuing RFC publication of the new document.
611 5. Security Considerations
613 This document largely focuses on providing mechanisms for the
614 declaration of public information. Nominally, these declarations
615 should be of relatively low security profile, however there is always
616 the danger of "spoofing" and providing mis-information. Information
617 in these declarations should be taken as advisory.
619 6. IANA Considerations
621 This document outlines the processes for registering URN Namespaces,
622 and has implications for the IANA in terms of registries to be
623 maintained, as previously defined in RFC 3406 [RFC3406]. This
624 document replaces RFC 3406; it contains a revised description for the
625 management of the "Uniform Resource Names (URN) Namespaces" IANA
626 Registry that uses the policy designation terms from BCP 26, RFC 5226
627 [RFC5226], but does not introduce significant changes to the
628 applicable procedures.
630 All references there to the predecessor, [RFC3406], should be
631 replaced by references to this document.
632 We would appreciate a reorganization of the Registry web page to make
633 the registration templates for Informal URN Namespaces directly
634 linked from the main page; this would make the page /assignments/
635 urn-informal.htm page dispensable (for persistency's sake, the web
636 server should redirect requests to the /assignments/urn-namespaces
637 page.
639 Section 4.4.4 above describes the syntax rules for NIDs to which the
640 registry needs to obey. As pointed out in Section 4.4.4 above and in
641 RFC 2141bis [I-D.ietf-urnbis-rfc2141bis-urn], the string "urn" is
642 permanently reserved and MUST NOT be assigned as an NID.
644 In all cases of new namespace registration proposals, the IANA should
645 provisionally assign the appropriate NID (informal or formal), as
646 described throughout the body of this memo, once an IESG-designated
647 expert has confirmed that the requisite registration process steps
648 have been completed. These registrations become permanent and can be
649 made publicly available once the registration document has been
650 approved by the IESG for publications as a Standards Track or
651 Informational RFC.
653 7. Acknowledgements
655 This document is heavily based on RFC 3406, the authors of which are
656 cordially acknowledged.
658 This document also been inspired by other recent documents that have
659 updated important IANA registries, and the countless authors and
660 contributors to these efforts are acknowledged anonymously.
662 Several individuals in the URNbis working group have participated in
663 the detailed discussion of this memo. Particular thanks for detailed
664 review comments and text suggestions go to Juha Hakala and Mykyta
665 Yevstifeyev.
667 8. References
669 8.1. Normative References
671 [I-D.ietf-urnbis-rfc2141bis-urn]
672 Hoenes, A., "Uniform Resource Name (URN) Syntax",
673 draft-ietf-urnbis-rfc2141bis-urn-01 (work in progress),
674 October 2011.
676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
677 Requirement Levels", BCP 14, RFC 2119, March 1997.
679 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
680 Internet: Timestamps", RFC 3339, July 2002.
682 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
683 Resource Identifier (URI): Generic Syntax", STD 66,
684 RFC 3986, January 2005.
686 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
687 IANA Considerations Section in RFCs", BCP 26, RFC 5226,
688 May 2008.
690 8.2. Informative References
692 [IANA] IANA, "The Internet Assigned Numbers Authority",
693 .
695 [IANA-URI] IANA, "URI Schemes Registry",
696 .
698 [IANA-URN] IANA, "Uniform Resource Names (URN) Namespace Registry",
699 .
701 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource
702 Name Resolution", RFC 2276, January 1998.
704 [RFC2611] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
705 "URN Namespace Definition Mechanisms", BCP 33, RFC 2611,
706 June 1999.
708 [RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint W3C/
709 IETF URI Planning Interest Group: Uniform Resource
710 Identifiers (URIs), URLs, and Uniform Resource Names
711 (URNs): Clarifications and Recommendations", RFC 3305,
712 August 2002.
714 [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
715 Part One: The Comprehensive DDDS", RFC 3401, October 2002.
717 [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
718 Part Five: URI.ARPA Assignment Procedures", BCP 65,
719 RFC 3405, October 2002.
721 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
722 "Uniform Resource Names (URN) Namespace Definition
723 Mechanisms", BCP 66, RFC 3406, October 2002.
725 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
726 Text on Security Considerations", BCP 72, RFC 3552,
727 July 2003.
729 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of
730 Standards Track Code Points", BCP 100, RFC 4020,
731 February 2005.
733 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
734 Registration Procedures for New URI Schemes", BCP 35,
735 RFC 4395, February 2006.
737 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
738 Specifications: ABNF", STD 68, RFC 5234, January 2008.
740 Appendix A. URN Namespace Definition Template
742 Definition of a URN Namespace is accomplished by completing the
743 following information template.
744 Apart from providing a mechanism for disclosing the structure of the
745 URN Namespace, this information is designed to be useful for
746 - entities seeking to have a URN assigned in a namespace (if
747 applicable) and
749 - entities seeking to provide URN resolvers for a namespace (if
750 applicable).
752 This is particularly important for communities evaluating the
753 possibility of using a portion of an existing URN Namespace rather
754 than creating their own.
756 Applications for Formal URN Namespaces must also document "Namespace
757 Considerations", "Community Considerations", "Security
758 Considerations", and "IANA Considerations", as described in
759 Section 4.4.
761 Information in the template is as follows (text in curly braces is
762 tutorial and should be removed from filled-in templates):
764 Namespace ID:
766 { If request is for an Informal NID, indicate so; the number will
767 be assigned by IANA. In the case of a Formal NID registration,
768 regularly a particular NID string will be requested. }
770 Registration Information:
772 { This is information to identify the particular version of
773 registration information: }
774 - version number:
775 { starting with 1, incrementing by 1 with each new version }
776 - date:
777 { date submitted to the IANA or date of approval of
778 registration document, using the format outlined in "Date and
779 Time on the Internet: Timestamps", [RFC3339]: YYYY-MM-DD }
781 Declared registrant of the namespace:
783 - Registering organization:
784 Name: { ... }
785 Address: { ... }
786 - Designated contact person:
787 Name: { ... }
788 { Address: ...
789 (at least one of: Email, Phone, Postal address) }
791 Declaration of syntactic structure of NSS part:
793 [[ Editorial Note: In the past, there has been iterated trouble in
794 tentative registration documents with confusion between entire URN
795 syntax and NSS syntax (only). Since the "urn:" prefix is fixed
796 and the NID is fully determined by the "Namespace ID" clause
797 above, in order to avoid error prone duplication, this version of
798 the template tentatively restricts this clause to the NSS
799 (namespace specific string) part of the new URNs. ]]
801 {
802 This section should outline any structural features of identifiers
803 in this namespace. At the very least, this description may be
804 used to introduce terminology used in other sections. This
805 structure may also be used for determining realistic caching/
806 shortcuts approaches; suitable caveats should be provided. If
807 there are any specific character encoding rules (e.g., which
808 character should always be used for single-quotes), these should
809 be listed here.
811 Answers might include, but are not limited to:
812 - the structure is opaque (no exposition);
813 - a regular expression for parsing the identifier into
814 components, including naming authorities;
815 - formal syntax of the NSS, preferably in ABNF (STD 68
816 [RFC5234]).
817 }
819 Relevant ancillary documentation:
821 {
822 This section should list any RFCs, standards, or other published
823 documentation that defines or explains all or part of the
824 namespace structure.
826 Answers might include, but are not limited to:
827 - RFCs that outline the syntax of the namespace;
828 - other documents of the defining community (e.g., ISO) that
829 outline the syntax of the identifiers in the namespace;
830 - explanatory material that introduces the namespace.
831 }
833 Conformance with URN Syntax:
835 [[ Editorial Note: This clause moved into vicinity of "syntax". ]]
837 {
838 This section should outline any special considerations required
839 for conforming with the URN syntax. This is particularly
840 applicable in the case of legacy naming systems that are used in
841 the context of URNs.
843 For example, if a namespace is used in contexts other than URNs,
844 it may make use of characters that are reserved in the URN syntax.
846 This section should flag any such characters, and outline
847 necessary mappings to conform to URN syntax. Normally, this will
848 be handled by percent-encoding the symbol.
849 }
851 Rules for Lexical Equivalence of NSS part:
853 [[ Editorial Note: This clause moved into vicinity of "syntax". ]]
855 [[ Editorial Note: In the past, there has been iterated trouble in
856 tentative registration documents with regard to what rules can be
857 imposed for lexical equivalence. Since the "urn:" prefix and the
858 NID part both are invariably case-insensitive per RFC 3986 and RFC
859 2141[bis], in order to avoid repeated confusion, this version of
860 the template tentatively restricts this clause to only the NSS
861 part of the new URN Namespace definition documents. ]]
863 {
864 If there are particular algorithms for determining equivalence
865 between two identifiers in the underlying namespace (and hence, in
866 the URN string itself), rules can be provided here.
868 Some examples include:
869 - equivalence between hyphenated and non-hyphenated groupings in
870 the identifier string;
871 - equivalence between single-quotes and double-quotes;
872 - namespace-defined equivalences between specific characters,
873 such as "character X with or without diacritic marks".
875 Note that these are not normative statements for any kind of best
876 practice for handling equivalences between characters; they are
877 statements limited to reflecting the namespace's own rules.
878 }
880 Identifier uniqueness considerations:
882 {
883 This section should address the requirement that URN identifiers
884 be assigned uniquely -- they are assigned to at most one resource,
885 and are not reassigned.
887 (Note that the definition of "resource" is fairly broad; for
888 example, information on "Today's Weather" might be considered a
889 single resource, although the content is dynamic.)
891 Possible answers include, but are not limited to:
892 - exposition of the structure of the identifiers, and
893 partitioning of the space of identifiers amongst assignment
894 authorities that are individually responsible for respecting
895 uniqueness rules;
896 - identifiers are assigned sequentially;
897 - information is withheld; that is, the namespace is opaque.
898 }
900 Identifier persistence considerations:
902 {
903 Although non-reassignment of URN identifiers ensures that a URN
904 will persist in identifying a particular resource even after the
905 "lifetime of the resource", some consideration should be given to
906 the persistence of the usability of the URN. This is particularly
907 important in the case of URN Namespaces providing global
908 resolution.
910 Possible answers include, but are not limited to:
911 - quality of service considerations.
912 }
914 Process of identifier assignment:
916 {
917 This section should detail the mechanisms and/or authorities for
918 assigning URNs to resources. It should make clear whether
919 assignment is completely open, or if limited, how to become an
920 assigner of identifiers, and/or get one assigned by existing
921 assignment authorities.
923 Answers could include, but are not limited to:
924 - assignment is completely open, following a particular
925 algorithm;
926 - assignment is delegated to authorities recognized by a
927 particular organization (e.g., the Digital Object Identifier
928 Foundation controls the DOI assignment space and its
929 delegation);
930 - assignment is completely closed (e.g., for a private
931 organization).
932 }
934 Process for identifier resolution:
936 {
937 If a namespace is intended to be accessible for global resolution,
938 it must be registered in an RDS (Resolution Discovery System, see
939 RFC 2276 [RFC2276]) such as the DDDS (see RFC 3401 [RFC3401]).
940 Resolution then proceeds according to standard URI resolution
941 processes, and the mechanisms of the RDS. What this section
942 should outline is the requirements for becoming a recognized
943 resolver of URNs in this namespace (and being so listed in the RDS
944 registry).
946 Answers may include, but are not limited to:
947 - the namespace is not listed with an RDS, this is not relevant;
948 - resolution mirroring is completely open, with a mechanism for
949 updating an appropriate RDS;
950 - resolution is controlled by entities to which assignment has
951 been delegated.
952 }
954 Validation mechanism:
956 {
957 Apart from attempting resolution of a URN, a URN Namespace may
958 provide mechanisms for "validating" a URN -- i.e., determining
959 whether a given string is currently a validly-assigned URN. There
960 are 2 issues here: 1) users should not "guess" URNs in a
961 namespace; 2) when the URN Namespace is based on an existing
962 identifier system, it may not be the case that all the existing
963 identifiers are assigned on Day 0. The reasonable expectation is
964 that the resource associated with each resulting URN is somehow
965 related to the thing identified by the original identifier system,
966 but those resources may not exist for each original identifier.
967 For example, even if a telephone number-based URN Namespace was
968 created, it is not clear that all telephone numbers would
969 immediately become "valid" URNs, that could be resolved using
970 whatever mechanisms are described as part of the namespace
971 registration.
973 Validation mechanisms might be:
974 - a syntax grammar;
975 - an on-line service;
976 - an off-line service.
977 }
979 Scope:
981 {
982 This section should outline the scope of the use of the
983 identifiers in this namespace. Apart from considerations of
984 private vs. public namespaces, this section is critical in
985 evaluating the applicability of a requested NID. For example, a
986 namespace claiming to deal with "social security numbers" should
987 have a global scope and address all social security number
988 structures (unlikely). On the other hand, at a national level, it
989 is reasonable to propose a URN Namespace for "this nation's social
990 security numbers".
991 }
993 Appendix B. Illustration
995 B.1. Example Template
997 [[ Editorial Note: Do we really need this any more?
998 Such an almost-concrete example likely contradicts current IESG
999 policy on usage of examples in RFCs. ]]
1001 The following example is provided for the purposes of illustrating
1002 the URN NID template described in Appendix A. Although it is based
1003 on a hypothetical "generic Internet namespace" that has been
1004 discussed informally within the URN WG, there are still technical and
1005 infrastructural issues that would have to be resolved before such a
1006 namespace could be properly and completely described.
1008 Namespace ID:
1010 To be assigned
1012 Registration Information:
1014 - version number: 1
1015 - date:
1017 Declared registrant of the namespace:
1019 - Registering organization:
1020 Name: Thinking Cat Example Enterprises
1021 Postal: 1 ThinkingCat Way
1022 Trupville, NewCountry
1024 - Designated contact person:
1025 Name: L. Daigle
1026 Email: leslie@thinkingcat.example
1028 Declaration of syntactic structure of NSS part:
1030 The namespace specific string structure is as follows:
1032 :
1034 where FQDN is a fully-qualified domain name, and the assigned
1035 string is conformant to URN syntax requirements.
1037 Relevant ancillary documentation:
1039 Definition of domain names, found in:
1041 P. Mockapetris, "DOMAIN NAMES - CONCEPTS AND FACILITIES", STD 13,
1042 RFC 1034, November 1987.
1044 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION",
1045 STD 13, RFC 1035, November 1987.
1047 Conformance with URN Syntax:
1049 No special considerations.
1051 Rules for Lexical Equivalence of NSS part:
1053 FQDNs are case-insensitive. Thus, the leading portion of the URN
1054 up to the colon after the FQDN is case-insensitive for matches.
1055 The remainder of the identifier must be considered case-sensitive.
1057 Identifier uniqueness considerations:
1059 Uniqueness is guaranteed as long as the assigned string is never
1060 reassigned for a given FQDN, and that the FQDN is never
1061 reassigned.
1063 N.B.: operationally, there is nothing that prevents a domain name
1064 from being reassigned; indeed, it is not an uncommon occurrence.
1065 This is one of the reasons that this example makes a poor URN
1066 namespace in practice, and is therefore not seriously being
1067 proposed as it stands.
1069 Identifier persistence considerations:
1071 Persistence of identifiers is dependent upon suitable delegation
1072 of resolution at the level of "FQDN"s, and persistence of FQDN
1073 assignment.
1075 Same note as above.
1077 Process of identifier assignment:
1079 Assignment of these URNs is delegated to individual domain name
1080 holders (for FQDNs). The holder of the FQDN registration is
1081 required to maintain an entry (or delegate it) in the DDDS.
1082 Within each of these delegated name partitions, the string may be
1083 assigned per local requirements.
1085 E.g., urn:urn-:thinkingcat.example:001203
1087 Process for identifier resolution:
1089 Domain name holders are responsible for operating or delegating
1090 resolution servers for the FQDN in which they have assigned URNs.
1092 Validation mechanism:
1094 None specified.
1096 Scope:
1098 Global.
1100 B.2. Registration steps in practice
1102 The key steps for registration of informal or formal namespaces
1103 typically play out as follows:
1105 A) Informal NID:
1107 1. Complete the registration template. This may be done as part
1108 of an Internet-Draft.
1110 2. Communicate the registration template to urn-nid@ietf.org for
1111 technical review -- as an email with a pointer to the
1112 submitted I-D or inline text containing the template.
1114 3. Update the registration template (and/or document) as
1115 necessary from comments, and repeat steps 2 and 3 as
1116 necessary.
1118 4. Once comments have been addressed (and the review period has
1119 expired), send a request to IANA with the revised registration
1120 template.
1122 B) Formal NID:
1124 1. Write an Internet-Draft describing the namespace and include
1125 the registration template, duly completed. Be sure to include
1126 "Namespace Considerations", "Community Considerations",
1127 "Security Considerations", and "IANA Considerations" sections,
1128 as described in Section 4.4.
1130 2. Submit the Internet-Draft, and send a pointer to the I-D
1131 (perhaps using a copy of the I-D announcement) to
1132 urn-nid@ietf.org in order to solicit technical review.
1134 3. Update the Internet-Draft as necessary from comments, and
1135 repeat steps 2 and 3 as needed.
1137 4. If the Internet-Draft is the product of a working group in the
1138 IETF, follow the usual WG process to forward the document to
1139 the IESG for publication as an RFC. Otherwise, find a
1140 sponsoring Area Director willing to guide the draft through
1141 the IESG. The IESG (or the IETF at large in case an IETF-wide
1142 last call is deemed necessary) may request further changes
1143 (submitted as I-D revisions) and/or direct discussion to
1144 designated working groups, area experts, etc.
1146 5. The IESG evaluation process includes a review by IANA, and if
1147 the IESG approves the document for publication as an RFC, IANA
1148 processing of the document will follow the regular work-flow
1149 between the RFC Editor and IANA. This way, the NID
1150 registration will be made public by IANA when the RFC is
1151 published.
1153 Appendix C. Changes from RFC 3406
1155 C.1. Essential Changes since RFC 3406
1157 [ RFC Editor: please remove the Appendix C.1 headline and all
1158 subsequent subsections of Appendix C starting with Appendix C.2. ]
1160 T.B.D. (after consolidation of this memo)
1162 C.2. Changes from RFC 3406 to URNbis WG Draft -00
1163 o Abstract: rewritten entirely;
1165 o Section 1 (Introduction): added historical RFC information;
1167 o Section 1.1 (Requirements Language): added;
1169 o Section 3.1: added Note that challenges the utility of
1170 Experimental namespaces and raises question of whether formal
1171 "provisional" registrations would be useful;
1173 o Section 4: text expanded and updated; background material added;
1174 added Note to challenge IANA website practices;
1176 o Section 4.2 ff: changed "home" of URN-NID registration discussion
1177 list (it already had been moved to the IETF Secretariat servers);
1179 o Section 4.2: added Note to challenge the 2-week review period; in
1180 current practice, that is almost always exceeded, and some regard
1181 it as too short;
1183 o Section 4.3: largely clarified procedures as they happen in
1184 practice; adapted language for conformance with RFC 5226; use new
1185 home of URN-NID (as mentioned above); the registration template
1186 (Appendix A) now "SHOULD" be used;
1188 o Section 4.3: split off new Section 4.4 on Registration Documents,
1189 because registrants essentially are encouraged to follow these
1190 guidelines for Informal namespaces as well, as far as practical;
1191 replaced "RFC" by "Registration Document"; Section 4.4 is
1192 subdivided for all mandatory sections;
1194 o Section 4.4.1: made requirements a "MUST";
1196 o Sections 4.4.1 and 4.4.2: added common Note that challenges the
1197 need to split Namespace and Community Considerations, based on
1198 observed problems in practice to separate the topics, and pointing
1199 to overlap with clauses in the registration template due to
1200 bullets listed that are not so clearly related to the headlines
1201 under which they appear; suggestion is to avoid duplication, place
1202 factual stuff into the template and focus on rationale in these
1203 Considerations, perhaps in a common section;
1205 o Section 4.4.3: added discussion of Security Considerations
1206 section; advice is to focus on namespace-specific considerations
1207 and refer to the SecCons in the "generic" RFCs for the general
1208 issues;
1210 o Section 4.4.4: amended discussion of IANA Considerations section;
1211 this tries to reflect standing practice and codifies that Formal
1212 NIDs are generally proposed by the registrant; added Note that
1213 "urn" is permanently reserved and MUST NOT be assigned as a NID,
1214 to avoid confusion (as also specified in RFC 2141bis draft); wrt
1215 registration maintenance: got rid of wrong reference in RFC 3406
1216 (to RFC 2606);
1218 o Section 6 (IANA Considerations): updated and rephrased description
1219 of the role of this document, including a sketch of the history;
1220 added teat that tries to precisely describe what is expected from
1221 IANA on approval of this draft; added text on procedures and
1222 suggest a provisional assignment practice upon "thumbs-up" of the
1223 IANA Expert to protect prospective registrants from collateral
1224 damage on NID precedence in case the document suffers from delays
1225 unrelated to the registration template before it eventually gets
1226 approved;
1228 o Section 7 (Acknowledgements): added;
1230 o References: Updated and amended references; added pointers to
1231 chartered URNbis work items; removed entirely outdated example
1232 material related to legacy documents;
1234 o Appendix A and B.1: added words on Security Considerations
1235 section;
1237 o Appendix A (Registration Template): clarified role of text
1238 snippets in the Template: hint and commentary now all enclosed in
1239 curly braces, with not that these parts shall be removed when
1240 filling in the tempalte; indicate that Formal NIDs are normally
1241 proposed by registrant; changed date/time ref. from ISO 8601 to
1242 RFC 3339; use inherited term "percent-encoding";
1244 o Appendix A -- structure: moved formal clauses on Conformance with
1245 URN Syntax and Rules for Lexical Equivalence to vicinity of
1246 namespace specific syntax clause, to which these are closely
1247 related;
1249 o Appendix A -- changes of clauses: the Declaration of syntactic
1250 structure and Rules for Lexical Equivalence clauses now
1251 tentatively have been restricted to the NSS part only; this change
1252 is described in NOTEs and motivated by the observation of repeated
1253 confusion in past and present registration documents, which
1254 hopefully can be avoided (and the job of the Expert and reviewers
1255 made easier) by leaving discussion of the invariate parts that
1256 cannot be re-specified there at the single place where they belong
1257 to: the NID is fully specified in the initial clause, rules for
1258 the NID and the URI scheme name "urn" are inherited from RFC
1259 2141[bis] and RFC 3986, respectively, and hence the new clause
1260 descriptions avoid conflict by taking these components out of
1261 scope of these clauses;
1263 o Appendix B.1 (Example Template): facelifted a bit; concerns with
1264 IESG policy on examples in RFCs raised in a NOTE;
1266 o Appendix B.2 (Registration steps in practice): updated and
1267 clarified description of procedure, in alignment to current
1268 practice;
1270 o Appendix C: removed "Changes from RFC 2611"; added this change
1271 log;
1273 o General: numerous editorial changes and enhancements, following
1274 contemporary RFC style.
1276 Appendix D. Open Issues
1278 Discuss consequences of RFC 2141bis (once consensus is achieved); if
1279 proposal for fragment part is adopted, details need to be described
1280 per namespace that wants to adopt these possibilities, and maybe the
1281 registration template needs a new clause where this will be specified
1282 -- or the information has to be assigned to existing clauses.
1284 More elaboration on Services. Since RFC 2483 is considered outdated,
1285 but RFC 2483bis not yet a URNbis work item, we might need a registry
1286 for URN Services (initially populated from RFC 2483) that can be
1287 referred to in namespace registration documents, thus avoiding
1288 normative dependencies on a future RFC 2483bis.
1290 Do we actually need Experimental Namespaces?
1292 The syntax of the NID strings for the various NID types is given in
1293 an informal manner (as has been done in RFC 3406); is it worth the
1294 effort to introduce ABNF for this purpose?
1296 Increase review/timeout periods for urn-nid list and IANA experts to
1297 4 weeks?
1299 Clarification of the desired content of the "Namespace
1300 Considerations" and "Community Considerations" sections in
1301 registration documents. Shall we admit a combined section for both
1302 topics? (so far supported by 2 postings) Cf. the NOTEs in Sections
1303 4.4.1 and 4.4.2 for more details.
1305 Shall other strings than "urn" also be 'reserved' in the NID
1306 registry? (e.g. "uri", "url", "urc", "example", ...)
1307 Do we still need Appendix B.1 ? (There are lots of real-life
1308 examples now!)
1310 Also see the Editorial Notes interspersed in the body of this draft.
1312 Author's Address
1314 Alfred Hoenes
1315 TR-Sys
1316 Gerlinger Str. 12
1317 Ditzingen D-71254
1318 Germany
1320 EMail: ah@TR-Sys.de