idnits 2.17.1 draft-saintandre-urn-example-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 date (January 7, 2013) is 4120 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 January 7, 2013 5 Expires: July 11, 2013 7 A Uniform Resource Name (URN) Namespace for Examples 8 draft-saintandre-urn-example-01 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 documentation, private testing, 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 July 11, 2013. 33 Copyright Notice 35 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . 5 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 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 The Uniform Resource Name (URN) technology [RFC2141] provides a way 65 to generate persistent, location-independent, resource identifiers. 66 The primary "scope" of a URN is provided by its namespace identifier 67 (NID) [RFC3406]. There are three kinds of NID: formal, informal, and 68 experimental. Most of the NIDs registered to date are formal: as far 69 as is known the few informal namespaces have not been widely used, 70 and the experimental namespaces are by definition unregistered. 72 The experimental namespaces take the form "X-NID" (where "NID" is the 73 desired namespace identifier). Because the "x-" convention has been 74 deprecated in general [RFC6648], it seems sensible to achieve the 75 same objective in a different way. Therefore this document registers 76 a formal namespace identifier of "example", similar to "example.com" 77 and other domain names [RFC2606]. Under the "example" NID, 78 specification authors and code developers can mint URNs for use in 79 documentation and private testing by assigning their own unique 80 namespace-specific strings. 82 2. Specification Template 84 2.1. Namespace ID 86 The Namespace ID "example" is requested. 88 2.2. Registration Information 90 Version 1 92 Date: [to be assigned] 94 2.3. Declared Registrant of the Namespace 96 Registering organization: IETF 98 Designated contact: IESG, iesg@ietf.org 100 2.4. Declaration of Syntactic Structure 102 The Namespace Specific String (NSS) of all URNs that use the 103 "example" NID shall have the following structure: 105 urn:example:{NSS} 107 The NSS is a mandatory string of ASCII characters [RFC20] that 108 conforms to the URN syntax requirements [RFC2141] and that provides a 109 name that is useful within the relevant documentation example, test 110 suite, or other application. 112 2.5. Relevant Ancillary Documentation 114 See [RFC6648] for information about deprecation of the "x-" 115 convention in protocol parameters and identifiers. 117 2.6. Identifier Uniqueness Considerations 119 Those who mint example URNs ought to strive for uniqueness in the 120 namespace specific string portion of the URN. However, such 121 uniqueness cannot be guaranteed through the assignment process. As a 122 result, implementers are counselled against using example URNs for 123 any purposes other than documentation, private testing, and truly 124 experimental contexts. 126 2.7. Identifier Persistence Considerations 128 Once minted, an example URN is immutable. However, it is simply a 129 string and there is no guarantee that the documentation, test suite, 130 or other application using the URN is immutable. 132 2.8. Process for Identifier Resolution 134 Example URNs are not intended to be resolved, and the namespace is 135 not and probably never will be registered with a Resolution Discovery 136 System. 138 2.9. Rules for Lexical Equivalence 140 No special considerations; the rules for lexical equivalence 141 specified in [RFC2141] apply. 143 2.10. Conformance with URN Syntax 145 No special considerations 147 2.11. Validation Mechanism 149 None 151 2.12. Scope 153 Global 155 3. Namespace Considerations 157 No existing formal namespace enables entities to generate URNs that 158 are appropriate for use as examples in documentation, in private 159 testing, and the like. It could be argue that no such formal 160 namespace is needed, given that experimental namespaces can be minted 161 at will. However, experimental namespaces run afoul of the trend 162 away from using the "x-" convention in the names of protocol 163 parameters and identifiers [RFC6648]. Additionally, in practice 164 specification authors often mint examples using fake NIDs that go 165 unregistered because they are never intended to be used; to minimize 166 the possibility of confusion, it seems preferable to create a 167 dedicated namespace that can be used to generate example URNs. 169 4. Community Considerations 171 The "example" NID is intended to provide a clean, easily-recognizable 172 space for minting examples to be used in documentation, in private 173 testing, and the like. The Namespace Specific String (NSS) needs to 174 be a unique string, generated by the person, organization, or other 175 entity that creates the documentation, test suite, or other 176 application. There is no issuing authority for example URNs and they 177 cannot be resolved in any way. 179 The example NID does not obviate the need to coordinate with issuing 180 authorities for existing namespaces (e.g., minting 181 "urn:example:xmpp:foo" instead of requesting issuance of 182 "urn:xmpp:foo"), to register new namespace identifiers if existing 183 namespaces do not match one's desired functionality (e.g., minting 184 "urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637" instead 185 of registering the "urn:sha-1" namespace), or to respect the basic 186 spirit of URN NID assignment (e.g., setting up shadow NIDs such as 187 "urn:example:MyCompany:*" instead of using, say, HTTP URIs). 189 5. Security Considerations 191 This document introduces no additional security considerations beyond 192 those associated with the use and resolution of URNs in general. 194 6. IANA Considerations 196 This document defines a URN NID registration of "example", to be 197 added to the formal namespace registration; the completed 198 registration template can be found under Section 2. 200 7. References 202 7.1. Normative References 204 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 205 October 1969. 207 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 209 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 210 "Uniform Resource Names (URN) Namespace Definition 211 Mechanisms", BCP 66, RFC 3406, October 2002. 213 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 214 "Deprecating the "X-" Prefix and Similar Constructs in 215 Application Protocols", BCP 178, RFC 6648, June 2012. 217 7.2. Informative References 219 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 220 Names", BCP 32, RFC 2606, June 1999. 222 Appendix A. Acknowledgements 224 Thanks to Jim Schaad for his feedback. 226 Author's Address 228 Peter Saint-Andre 229 Cisco Systems, Inc. 230 1899 Wynkoop Street, Suite 600 231 Denver, CO 80202 232 USA 234 Email: psaintan@cisco.com