idnits 2.17.1 draft-ietf-asid-ldap-domains-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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. == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There are 48 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 135: '... MUST CONTAIN { domainComponen...' RFC 2119 keyword, line 136: '... MAY CONTAIN {...' == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1279, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 24 has weird spacing: '...listing conta...' -- 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 (July 31, 1996) is 10123 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 206 looks like a reference -- Missing reference section? '2' on line 209 looks like a reference -- Missing reference section? '3' on line 213 looks like a reference -- Missing reference section? '4' on line 216 looks like a reference -- Missing reference section? '5' on line 219 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Kille 2 INTERNET-DRAFT ISODE Consortium 3 Obsoletes: RFC 1279 M. Wahl 4 Critical Angle Inc. 5 Expires in six months from July 31, 1996 6 Intended Category: Experimental 8 An Approach for Using Domains in LDAP Distinguished Names 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, and 15 its working groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 26 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 1. Abstract 30 The Lightweight Directory Access Protocol (LDAP) uses X.500-compatible 31 Distinguished Names for providing unique identifcation of entries. 32 Distinguished Names in currently-deployed X.500 directories have the 33 properties that they are descriptive, hierarchical, and follow common 34 organizational models. However, there is not today a universal 35 registration mechanism to permit individuals and organizations to obtain 36 Distinguished Names. 38 This document describes an experimental mechanism by which a name 39 registered with the Internet Domain Name Service, for which there is an 40 active registration service, can be represented as a Distinguished Name 41 so that it may be used with the LDAP protocol. This is not intended to 42 have LDAP replace the DNS protocol, but to permit further deployment of 43 LDAP into organizations connected to the Internet. 45 2. Domain Names and Distinguished Names 47 The Domain (Nameserver) System (DNS) provides a hierarchical resource 48 labelling system [1]. An example domain name would be 49 "CRITICAL-ANGLE.COM". 51 Entries usually have a single name, although pointers to entries 52 may be provided by CNAME records. Information (resource records) is 53 associated with each entry. Name components are typically chosen to be 54 shortish (e.g., "WWW"). 56 The X.500 Directory provides a very general hierarchical naming framework. 57 A primary difference in specification of Distinguished Names from 58 domain names is that each component of an distinguished name has an 59 explicit attribute type indication. (It is also possible to have multiple 60 components in the same level, but that is not commonly done today). 62 An example Distinguished Name represented in the LDAP string format [2] 63 is "CN=Mark Wahl, O=Critical Angle Incorporated, ST=Texas, C=US". 65 3. Mapping Domain Names into Distinguished Names 67 This section defines a subset of the X.500 naming structure for use in 68 representing names allocated in the Internet Domain Name System. It is 69 expected that it would be possible to algorithmically transform any 70 Internet domain name into a Distinguished Name, and to be able to convert 71 such a name back into a domain name. 73 The algorithm for transforming a domain name is to begin with a DN of 74 "O=Internet", and then attach RDNs for each component of the domain, 75 most significant first. Each of these RDNs have a single 76 AttributeTypeAndValue, where the type is domainComponent (abbreviated "DC") 77 and the value is an IA5 string. 79 Thus the domain name 80 CS.UCL.AC.UK 81 can be transformed into 82 DC=CS, DC=UCL, DC=AC, DC=UK, O=Internet 84 And similarly 85 11.168.192.IN-ADDR.ARPA 86 to 87 DC=11, DC=168, DC=192, DC=IN-ADDR, DC=ARPA, O=Internet 89 X.500 Distinguished Names in which the first RDN is "O=Internet", and there 90 are one or more following RDNs, each with the attribute type 91 domainComponent, can be mapped back into domain names. Note that there 92 will not be an algorithmic domain name equivalence for all other 93 Distinguished Names, such as: 95 CN=Steve Kille, DC=ISODE, DC=COM, O=Internet 96 O=ISODE Consortium, C=GB 98 4. Limitations on Use of this Mechanism 100 This naming mechanism is primarily intended for experimental or single-site 101 pilot projects, or where the directory service does not currently intend to 102 connect to any established service, but still requires a globally unique 103 name. 105 If an organization is running a service in a locality for which there is an 106 official registration authority for distinguished names, an officially 107 registered distinguished name should be used instead of this mechanism. 108 These names are typically based on the concatenation of an organization's 109 registered name and the location of that registry, such as "O=IC, C=GB". 111 If an organization intends to connect to an established directory service, 112 then the guidelines of that service should be followed. 114 5. Attribute Type and Object Class Definition 116 The domainComponent or DC attribute type is defined in [3], and is 117 reproduced here for convenience. 119 domainComponent ATTRIBUTE ::= { 120 WITH SYNTAX IA5String 121 EQUALITY MATCHING RULE iA5EqualityMatchingRule 122 SINGLE VALUE TRUE 123 ID {pilotAttributeType 25} } 125 The encoding of IA5String for use in LDAP is simply the characters of the 126 string itself. The equality matching rule is case insensitive, as is 127 today's DNS. 129 The domain object class would be used as the structural object class of 130 entries whose distinguished names are generated according to the algorithm 131 in section 3. 133 domain OBJECT-CLASS ::= { 134 SUBCLASS OF { top } 135 MUST CONTAIN { domainComponent } 136 MAY CONTAIN { 137 associatedName, 138 organizationName, 139 organizationalAttributeSet } 140 ID {pilotObjectClass 13} } 142 domainNameForm NAME-FORM ::= { 143 NAMES domain 144 WITH ATTRIBUTES { domainComponent } 145 ID {enterprises 1466 345 }} 147 If it is desired to be able to store or retrieve DNS-specific attributes 148 via LDAP, the dNSDomain object class can be used as well. 150 6. Directory Information Structure 152 This algorithm assigns to any organization which has obtained a domain name 153 for use in the Internet a distinguished name for use as a prefix for their 154 own entry's names. 156 Thus a small organization which holds the domain name 157 CRITICAL-ANGLE.COM 159 Might have as their directory entries: 161 CN=Mark Wahl, DC=CRITICAL-ANGLE, DC=COM, O=Internet 162 CN=Postmaster, DC=CRITICAL-ANGLE, DC=COM, O=Internet 164 While an organization with multiple subdomains might structure their 165 entries as: 167 CN=Steve Kille, DC=Richmond, DC=ISODE, DC=COM, O=Internet 168 CN=Greg Lavender, DC=Austin, DC=ISODE, DC=COM, O=Internet 170 There are a number of RFCs, such as [4] and [5], which provide guidance 171 on representing and structuring information in directory entries which 172 would be applicable. 174 7. Relationship with LDAP when Browsing 176 To effectively search the entries in an LDAP server connected to a global 177 directory system, it is necessary to know the base object of the entries 178 a server maintains. 180 If a client does not have any information on a search base to use, then 181 there are three possible approaches: 183 1. Interrogate the server for the naming contexts it holds. 184 2. Create a search base based on the domain name of the contacted server. 185 3. Browse by searching immediately subordinate to the root. 187 Approach 1 is recommended if the client and server both support LDAP 188 version 3 or higher. If this is not the case and there is no other 189 information available to the client, then approach 2 is recommend. 191 Approach 2 makes use of the mechanism defined in this document, with a 192 slight extension. If the least significant component of the contacted 193 server's domain name is "ldap" or "x500", this component is ignored, and 194 the remainer of the domain name is transformed into a distinguished name. 196 Thus for example if the client was asked to contact the server 197 ldap.critical-angle.com and browse, it would using approach 2 issue its 198 searches with the base object "DC=CRITICAL-ANGLE, DC=COM, O=Internet". 200 Approach 3 is not recommended, as the server may chain or refer the 201 operation to another server which holds entries subordinate to the root 202 (such as countries). 204 8. References 206 [1] P. Mockapetris. Domain names - concepts and facilities. 207 RFC 1034, November 1987. 209 [2] S. Kille, M.Wahl. Lightweight Directory Access Protocol (v3): 210 UTF-8 String Representation of Distinguished Names. 211 INTERNET DRAFT draft-ietf-asid-ldapv3-dn-00.txt. July 1996. 213 [3] P. Barker and S.E. Hardcastle-Kille. The COSINE and Internet 214 X.500 schema. Request for Comments RFC 1274, November 1991. 216 [4] P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring 217 Guidelines for X.500 Directory Pilots". RFC 1617 May 1994. 219 [5] B. Jennings, "Building an X.500 Directory Service in the US", 220 RFC 1943, May 1996. 222 9. Security Considerations 224 This memo does not address security issues. 226 10. Author's Address 228 Steve Kille 229 ISODE Consortium 230 The Dome 231 The Square 232 Richmond, Surrey 233 TW9 1DT 234 England 236 Phone: +44-181-332-9091 237 EMail: S.Kille@ISODE.COM 239 Mark Wahl 240 Critical Angle Inc. 241 4815 W. Braker Lane #502-385 242 Austin, TX 78759 243 USA 245 EMail: M.Wahl@critical-angle.com