idnits 2.17.1 draft-mealling-oid-urn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 73 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2000) is 8769 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 167, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1778 (ref. '3') (Obsoleted by RFC 3494) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M.M. Mealling 3 Internet-Draft Network Solutions, Inc. 4 Expires: September 30, 2000 April 2000 6 A URN Namespace of Object Identifiers 7 draft-mealling-oid-urn-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To view the entire list of Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 This Internet-Draft will expire on September 30, 2000. 29 Copyright Notice 31 Copyright (C) The Internet Society (2000). All Rights Reserved. 33 Abstract 35 This document describes a URN namespace that contains Object 36 Identifiers (OIDs). 38 1. Introduction 40 An Object Identifier is a series of digits delimited in some way. 41 The rules roughly state that once an entity is assigned an Object 42 Identifier (OID) it has sole discrection to further subdelegate off 43 of that OID. Some examples of OIDs include: 45 o 1.3.6.1 - the Internet OID 46 o 1.3.6.1.4.1 - IANA-assigned company OIDs, used for private MIBs 47 and such things 48 o 1.3.6.1.2.1.27 - The Applications MIB 49 o 0.9.2342.19200300.100.4 - Object ID's used in the directory pilot 50 project to identify X.500 Object Classes. Mostly defined in 51 RFC-1274. 53 This document specifies the "oid" URN namespace[1]. This namespace 54 is for encoding an Object Identifier as specified in ASN.1[2] as a 55 URI. 57 The namespace specification is for a formal namespace. 59 2. Specification Template 61 Namespace ID: 63 "oid" requested. 65 Registration Information: 67 Registration Version Number: 1 68 Registration Date: 2000-04-30 70 Declared registrant of the namespace: 72 The ISO/IEC Joint Technical Committee 1 - SubCommittee 6 74 The real authority is the ASN.1 specification itself but SC6 75 is the committee that has the authority to interpret what that 76 means, thus that committee is listed as the registrant. 78 Declaration of structure: 80 The NSS portion of the identifier follows the string encoding 81 rules found in RFC 1778 Section 2.15[3]which specifies a series 82 of digits seperated by a period with the most significant digit 83 being at the left and the least significant being at the right. 85 No changes are anticipated since Object Identifiers are fairly 86 simple and have been standardized with no changes for many years. 88 Relevant ancillary documentation: 90 Relevant documentation can be found in X.660/Amd 2 | ISO/IEC 91 9834-1/Amd 2[2]. 93 Identifier uniqueness considerations: 95 The rules for assignment of OIDs requires that each OID be unique 96 to the OID space and that it cannot be reassigned or reused. By 97 reference this URN namespace inherents those rules. 99 Identifier persistence considerations: 101 The rules concerning the use of OIDs requires that they not be 102 reused once assigned. By reference this URN namespace inherents 103 those rules. 105 Process of identifier assignment: 107 Once an OID is assigned to some entity, that entity can then 108 create and assign new OIDs below that particular OID. There are 109 multiple entities that assign new OIDs to the general public. The 110 top three levels are pre-assigned as follows: 111 0 - ITU-T assigned 112 1 - ISO assigned 113 2 - Joint ISO/ITU-T assignment 115 several assigned OIDs that are of importance to the Internet are: 116 1.3.6.1 - the Internet OID 117 1.3.6.1.4.1 - IANA-assigned company OIDs, used for private 118 MIBs and such things 120 Process of identifier resolution: 122 At this time no resolution mechanism is defined. 124 Rules for Lexical Equivalence: 126 OIDs are composed of multiple occurences of digits and the "." 127 character. Lexical equivalence is achieved by exact string match. 129 Conformance with URN Syntax: 131 There are no additional characters reserved. 133 Validation mechanism: 135 None. 137 Scope: 139 Global 141 3. Examples 143 The following examples are taken from the example OIDs from the 144 Introduction: 145 urn:oid:1.3.6.1 146 urn:oid:1.3.6.1.4.1 147 urn:oid:1.3.6.1.2.1.27 148 URN:OID:0.9.2342.19200300.100.4 150 4. Security Considerations 152 None not already inherent to using unverifiable OIDs 154 5. Acknowledgements 156 The author would like to thank Harald Alvestrand for the use of his 157 OID database as a source for examples and references. 159 References 161 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 163 [2] CCITT, "Specification of Basic Encoding Rules for Abstract 164 Syntax Notation One (ASN.1)", CCITT Recommendation X.209, 165 January 1988. 167 [3] Howes, T., Kille, S., Yeong, W. and C. Robbins, "The String 168 Representation of Standard Attribute Syntaxes", RFC 1778, March 169 1995. 171 Author's Address 173 Michael Mealling 174 Network Solutions, Inc. 175 505 Huntmar Park Drive 176 Herndon, VA 22070 177 US 179 Phone: +1 770 935 5492 180 EMail: michaelm@netsol.com 181 URI: http://www.netsol.com 183 Full Copyright Statement 185 Copyright (C) The Internet Society (2000). All Rights Reserved. 187 This document and translations of it may be copied and furnished to 188 others, and derivative works that comment on or otherwise explain it 189 or assist in its implmentation may be prepared, copied, published 190 and distributed, in whole or in part, without restriction of any 191 kind, provided that the above copyright notice and this paragraph 192 are included on all such copies and derivative works. However, this 193 document itself may not be modified in any way, such as by removing 194 the copyright notice or references to the Internet Society or other 195 Internet organizations, except as needed for the purpose of 196 developing Internet standards in which case the procedures for 197 copyrights defined in the Internet Standards process must be 198 followed, or as required to translate it into languages other than 199 English. 201 The limited permissions granted above are perpetual and will not be 202 revoked by the Internet Society or its successors or assigns. 204 This document and the information contained herein is provided on an 205 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 206 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 207 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 208 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 209 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 211 Acknowledgement 213 Funding for the RFC editor function is currently provided by the 214 Internet Society.