idnits 2.17.1 draft-saintandre-urn-example-00.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 date (July 31, 2012) is 4280 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Informational July 31, 2012 5 Expires: February 1, 2013 7 A Uniform Resource Name (URN) Namespace for Examples 8 draft-saintandre-urn-example-00 10 Abstract 12 This document defines a Uniform Resource Name (URN) namespace 13 identifier enabling generation of URNs that are appropriate for use 14 in private testing, as examples in documentation, and the like. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on February 1, 2013. 33 Copyright Notice 35 Copyright (c) 2012 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Specification Template . . . . . . . . . . . . . . . . . . . . 3 52 3. Namespace Considerations . . . . . . . . . . . . . . . . . . . 4 53 4. Community Considerations . . . . . . . . . . . . . . . . . . . 5 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 56 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 58 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 1. Introduction 63 The Uniform Resource Name (URN) technology [RFC2141] provides a way 64 to generate persistent, location-independent, resource identifiers. 65 The primary "scope" of a URN is provided by its namespace identifier 66 (NID). As described in the specification for namespace definition 67 mechanisms [RFC3406], there are three kinds of NIDs: formal, 68 informal, and experimental. Most of the NIDs registered to date are 69 formal: as far as is known the few informal namespaces have not been 70 widely used, and the experimental namespaces are by definition 71 unregistered. 73 In particular, the experimental namespaces take the form "X-NID" 74 (where "NID" is the desired namespace identifier). Since the "x-" 75 convention has been deprecated in general [RFC6648], it seems 76 sensible to define a dedicated namespace identifier for use in 77 private testing, as examples in documentation, and the like (similar 78 to "example.com" and other domain names [RFC2606]). Therefore this 79 document registers "example" as a formal namespace identifier. 80 Although publication of this document might make it possible to 81 deprecate the class of experimental namespace identifiers, that is 82 not its primary intent. 84 2. Specification Template 86 2.1. Namespace ID 88 The Namespace ID "example" is requested. 90 2.2. Registration Information 92 Version 1 94 Date: 2012-07-11 96 2.3. Declared Registrant of the Namespace 98 Registering organization: IETF 100 Designated contact: IESG, iesg@ietf.org 102 2.4. Declaration of Syntactic Structure 104 The Namespace Specific String (NSS) of all URNs that use the 105 "example" NID shall have the following structure: 107 urn:example:{NSS} 108 The NSS is a mandatory string of ASCII characters [RFC20] that 109 conforms to the URN syntax requirements [RFC2141] and that provides a 110 name that is useful within the relevant documentation example, test 111 suite, or other application. 113 2.5. Relevant Ancillary Documentation 115 See [RFC6648] for information about deprecation of the "x-" 116 convention in protocol parameters and identifiers. 118 2.6. Identifier Uniqueness Considerations 120 Those who mint example URNs ought to strive for uniqueness in the 121 namespace specific string portion of the URN. 123 2.7. Identifier Persistence Considerations 125 Once minted, an example URN is immutable. However, it is simply a 126 string and there is no guarantee that the documentation, test suite, 127 or other application using the URN is immutable. 129 2.8. Process for Identifier Resolution 131 Example URNs are not intended to be resolved, and the namespace is 132 not and probably never will be registered with a Resolution Discovery 133 System. 135 2.9. Rules for Lexical Equivalence 137 No special considerations; the rules for lexical equivalence 138 specified in [RFC2141] apply. 140 2.10. Conformance with URN Syntax 142 No special considerations 144 2.11. Validation Mechanism 146 None 148 2.12. Scope 150 Global 152 3. Namespace Considerations 154 No existing formal namespace enables entities to generate URNs that 155 are appropriate for use in private testing, as examples in 156 documentation, and the like. It could be argue that no such formal 157 namespace is needed, given that experimental namespaces can be minted 158 at will. However, experimental namespaces run afoul of the trend 159 away from using the "x-" convention in the names of protocol 160 parameters and identifiers [RFC6648]. Additionally, in practice 161 specification authors often mint examples using fake NIDs that go 162 unregistered because they are never intended to be used; to minimize 163 the possibility of confusion, it seems preferable to create a 164 dedicated namespace that can be used to generate example URNs. 166 4. Community Considerations 168 The "example" NID is intended to provide a clean, easily-recognizable 169 space for minting examples to be used in documentation, in private 170 testing, and the like. The Namespace Specific String (NSS) needs to 171 be a unique string, generated by the person, organization, or other 172 entity that creates the documentation, test suite, or other 173 application. There is no issuing authority for example URNs and they 174 cannot be resolved in any way. 176 Note well that the example NID does not obviate the need to 177 coordinate with issuing authorities for existing namespaces (e.g., 178 minting "urn:example:xmpp:foo" instead of requesting issuance of 179 "urn:xmpp:foo"), to register new namespace identifiers if existing 180 namespaces do not match one's desired functionality (e.g., minting 181 "urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637" instead 182 of registering the "urn:sha-1" namespace), or to respect to the basic 183 spirit of URN NID assignment (e.g., setting up shadow NIDs such as 184 "urn:example:MyCompany:*" instead of using HTTP URIs or other 185 formats). 187 5. Security Considerations 189 This document introduces no additional security considerations beyond 190 those associated with the use and resolution of URNs in general. 192 6. IANA Considerations 194 This document defines a URN NID registration of "example", to be 195 added to the formal namespace registration; the completed 196 registration template can be found under Section 2. 198 7. References 199 7.1. Normative References 201 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 202 October 1969. 204 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 206 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 207 "Uniform Resource Names (URN) Namespace Definition 208 Mechanisms", BCP 66, RFC 3406, October 2002. 210 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 211 "Deprecating the "X-" Prefix and Similar Constructs in 212 Application Protocols", BCP 178, RFC 6648, June 2012. 214 7.2. Informative References 216 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 217 Names", BCP 32, RFC 2606, June 1999. 219 Author's Address 221 Peter Saint-Andre 222 Cisco Systems, Inc. 223 1899 Wynkoop Street, Suite 600 224 Denver, CO 80202 225 USA 227 Email: psaintan@cisco.com