idnits 2.17.1 draft-saintandre-urn-example-02.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 (February 13, 2013) is 4061 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 February 13, 2013 5 Expires: August 17, 2013 7 A Uniform Resource Name (URN) Namespace for Examples 8 draft-saintandre-urn-example-02 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 August 17, 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 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Specification Template . . . . . . . . . . . . . . . . . . . 2 51 3. Namespace Considerations . . . . . . . . . . . . . . . . . . 4 52 4. Community Considerations . . . . . . . . . . . . . . . . . . 4 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 55 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1. Introduction 61 The Uniform Resource Name (URN) technology [RFC2141] provides a way 62 to generate persistent, location-independent, resource identifiers. 63 The primary "scope" of a URN is provided by its namespace identifier 64 (NID) [RFC3406]. There are three kinds of NID: formal, informal, and 65 experimental. Most of the NIDs registered to date are formal: as far 66 as is known the few informal namespaces have not been widely used, 67 and the experimental namespaces are by definition unregistered. 69 The experimental namespaces take the form "X-NID" (where "NID" is the 70 desired namespace identifier). Because the "x-" convention has been 71 deprecated in general [RFC6648], it seems sensible to achieve the 72 same objective in a different way. Therefore this document registers 73 a formal namespace identifier of "example", similar to "example.com" 74 and other domain names [RFC2606]. Under the "example" NID, 75 specification authors and code developers can mint URNs for use in 76 documentation and private testing by assigning their own unique 77 namespace-specific strings. 79 2. Specification Template 81 2.1. Namespace ID 83 The Namespace ID "example" is requested. 85 2.2. Registration Information 87 Version 1 89 Date: [to be assigned] 91 2.3. Declared Registrant of the Namespace 93 Registering organization: IETF 95 Designated contact: IESG, iesg@ietf.org 97 2.4. Declaration of Syntactic Structure 99 The Namespace Specific String (NSS) of all URNs that use the 100 "example" NID shall have the following structure: 102 urn:example:{NSS} 104 The NSS is a mandatory string of ASCII characters [RFC20] that 105 conforms to the URN syntax requirements [RFC2141] and that provides a 106 name that is useful within the relevant documentation example, test 107 suite, or other application. 109 2.5. Relevant Ancillary Documentation 111 See [RFC6648] for information about deprecation of the "x-" 112 convention in protocol parameters and identifiers. 114 2.6. Identifier Uniqueness Considerations 116 Those who mint example URNs ought to strive for uniqueness in the 117 namespace specific string portion of the URN. However, such 118 uniqueness cannot be guaranteed through the assignment process. As a 119 result, implementers are counselled against using example URNs for 120 any purposes other than documentation, private testing, and truly 121 experimental contexts. 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 will 132 probably never be registered with a Resolution Discovery System 133 (unless to simply inform requesters that such URNs are merely 134 examples). 136 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 as examples in documentation, in private 156 testing, and the like. It could be argued 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 meaningful way. 176 The example NID does not obviate the need to coordinate with issuing 177 authorities for existing namespaces (e.g., minting 178 "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 "sha-1" NID), or to respect the basic spirit of 183 URN NID assignment (e.g., setting up shadow NIDs such as 184 "urn:example:MyCompany:*" instead of using, say, HTTP URIs). 186 5. Security Considerations 188 This document introduces no additional security considerations beyond 189 those associated with the use and resolution of URNs in general. 191 6. IANA Considerations 193 This document defines a URN NID registration of "example", to be 194 added to the formal namespace registration; the completed 195 registration template can be found under Section 2. 197 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.E. and A. Panitz, "Reserved Top Level DNS 217 Names", BCP 32, RFC 2606, June 1999. 219 Appendix A. Acknowledgements 221 Thanks to Martin Duerst and Jim Schaad for their feedback. 223 Author's Address 225 Peter Saint-Andre 226 Cisco Systems, Inc. 227 1899 Wynkoop Street, Suite 600 228 Denver, CO 80202 229 USA 231 Email: psaintan@cisco.com