idnits 2.17.1 draft-saintandre-urn-example-04.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 (March 10, 2013) is 4058 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) ** 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: Best Current Practice March 10, 2013 5 Expires: September 11, 2013 7 A Uniform Resource Name (URN) Namespace for Examples 8 draft-saintandre-urn-example-04 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 September 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 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Completed Namespace Definition 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). As specified in [RFC3406], there are three kinds of NID: 65 formal, informal, and experimental. Most of the NIDs registered to 66 date are formal: as far as is known the few informal namespaces have 67 not been widely used, and the experimental namespaces are by 68 definition unregistered. 70 The experimental namespaces take the form "X-NID" (where "NID" is the 71 desired namespace identifier). Because the "x-" convention has been 72 deprecated in general [RFC6648], it seems sensible to achieve the 73 same objective in a different way. Therefore this document registers 74 a formal namespace identifier of "example", similar to "example.com" 75 and other domain names [RFC2606]. Under the "example" NID, 76 specification authors and code developers can mint URNs for use in 77 documentation and private testing by assigning their own unique 78 namespace-specific strings. 80 2. Completed Namespace Definition Template 82 2.1. Namespace ID 84 The Namespace ID "example" is requested. 86 2.2. Registration Information 88 Version 1 90 Date: [to be assigned] 92 2.3. Declared Registrant of the Namespace 94 Registering organization: IETF 95 Designated contact: IESG, iesg@ietf.org 97 2.4. Declaration of Syntactic Structure 99 URNs that use the "example" NID shall have the following structure: 101 urn:example:{NSS} 103 The Namespace Specific String (NSS) is a mandatory string of ASCII 104 characters [RFC20] that conforms to the URN syntax requirements 105 [RFC2141] and that provides a name that is useful within the relevant 106 documentation example, test suite, or other application. 108 2.5. Relevant Ancillary Documentation 110 See [RFC6648] for information about deprecation of the "x-" 111 convention in protocol parameters and identifiers. 113 2.6. Identifier Uniqueness Considerations 115 Those who mint example URNs ought to strive for uniqueness in the 116 namespace specific string portion of the URN. However, such 117 uniqueness cannot be guaranteed through the assignment process. As a 118 result, implementers are counselled against using example URNs for 119 any purposes other than documentation, private testing, and truly 120 experimental contexts. 122 2.7. Identifier Persistence Considerations 124 Once minted, an example URN is immutable. However, it is simply a 125 string and there is no guarantee that the documentation, test suite, 126 or other application using the URN is immutable. 128 2.8. Process of Identifier Assignment 130 Assignment is completely open, since anyone can mint example URNs for 131 use in documentation, private testing, and other experimental 132 contexts. 134 2.9. Process for Identifier Resolution 136 Example URNs are not intended to be resolved, and the namespace will 137 probably never be registered with a Resolution Discovery System 138 (unless to simply inform requesters that such URNs are merely 139 examples). 141 2.10. Rules for Lexical Equivalence 142 No special considerations; the rules for lexical equivalence 143 specified in [RFC2141] apply. 145 2.11. Conformance with URN Syntax 147 No special considerations 149 2.12. Validation Mechanism 151 None 153 2.13. Scope 155 The scope of an example URN is limited to the documentation in which 156 it is found, the test in which it is used, the experiment in which it 157 appears, etc. Example URNs have no meaning outside such strictly- 158 limited contexts. 160 3. Namespace Considerations 162 No existing formal namespace enables entities to generate URNs that 163 are appropriate for use as examples in documentation, in private 164 testing, and the like. It could be argued that no such formal 165 namespace is needed, given that experimental namespaces can be minted 166 at will. However, experimental namespaces run afoul of the trend 167 away from using the "x-" convention in the names of protocol 168 parameters and identifiers [RFC6648]. Additionally, in practice 169 specification authors often mint examples using fake NIDs that go 170 unregistered because they are never intended to be used. To minimize 171 the possibility of confusion, use of this dedicated example namespace 172 is recommended for generating example URNs. 174 4. Community Considerations 176 The "example" NID is intended to provide a clean, easily-recognizable 177 space for minting examples to be used in documentation, in private 178 testing, and the like. The Namespace Specific String (NSS) needs to 179 be a unique string, generated by the person, organization, or other 180 entity that creates the documentation, test suite, or other 181 application. There is no issuing authority for example URNs and they 182 cannot be resolved in any meaningful way. 184 The "example" NID does not obviate the need to coordinate with 185 issuing authorities for existing namespaces (e.g., minting 186 "urn:example:xmpp:foo" instead of requesting issuance of 187 "urn:xmpp:foo"), to register new namespace identifiers if existing 188 namespaces do not match one's desired functionality (e.g., minting 189 "urn:example:sha-1:29ead03e784b2f636a23ffff95ed12b56e2f2637" instead 190 of registering the "sha-1" NID), or to respect the basic spirit of 191 URN NID assignment (e.g., setting up shadow NIDs such as 192 "urn:example:MyCompany:*" instead of using, say, HTTP URIs). 194 5. Security Considerations 196 This document introduces no additional security considerations beyond 197 those associated with the use and resolution of URNs in general. 199 6. IANA Considerations 201 This document defines a URN NID registration of "example", to be 202 added to the Uniform Resource Names (URN) Formal Namespaces registry. 203 The completed registration template can be found in under Section 2. 205 7. References 207 7.1. Normative References 209 [RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, 210 October 1969. 212 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 214 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 215 "Uniform Resource Names (URN) Namespace Definition 216 Mechanisms", BCP 66, RFC 3406, October 2002. 218 7.2. Informative References 220 [RFC2606] Eastlake, D.E. and A. Panitz, "Reserved Top Level DNS 221 Names", BCP 32, RFC 2606, June 1999. 223 [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, 224 "Deprecating the "X-" Prefix and Similar Constructs in 225 Application Protocols", BCP 178, RFC 6648, June 2012. 227 Appendix A. Acknowledgements 229 Thanks to Martin Duerst, Barry Leiba, Julian Reschke, and Jim Schaad 230 for their feedback. 232 Author's Address 233 Peter Saint-Andre 234 Cisco Systems, Inc. 235 1899 Wynkoop Street, Suite 600 236 Denver, CO 80202 237 USA 239 Email: psaintan@cisco.com