idnits 2.17.1 draft-ietf-asid-ldap-domains-01.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-03-19) 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. 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 53 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 115: '... MUST dc...' RFC 2119 keyword, line 116: '... MAY ( userPassword $ searchGuide...' RFC 2119 keyword, line 131: '...omainNameForm' OC domain MUST ( dc ) )...' RFC 2119 keyword, line 139: '... MAY dNSRecord )...' == 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 (February 6, 1997) is 9903 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) == Missing Reference: '5' is mentioned on line 126, but not defined == Outdated reference: A later version (-03) exists of draft-ietf-asid-ldapv3-dn-00 ** Downref: Normative reference to an Informational RFC: RFC 1617 (ref. '3') ** Downref: Normative reference to an Informational RFC: RFC 1943 (ref. '4') Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 3 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 Ltd. 3 Obsoletes: RFC 1279 M. Wahl 4 Critical Angle Inc. 5 Expires in six months from February 6, 1997 6 Intended Category: Standards Track 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 identification 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 registration 35 mechanism to permit individuals and organizations to obtain distinguished 36 names, regardless of their physical location. 38 This document defines a mechanism by which a name registered with the 39 Internet Domain Name Service [1], for which there are active registration 40 services, can be represented as a distinguished name so that it may be 41 used with the LDAP protocol. This is not intended to have LDAP replace 42 the DNS protocol, but to permit further deployment of LDAP into 43 organizations connected to the Internet. 45 This algorithm automatically assigns a distinguished name to any 46 enterprise which has obtained a domain name for use in the Internet. 47 This distinguished name may be used as a prefix for their names of 48 entries in that enterprise. 50 This document does not define how to represent objects which do not have 51 domain names. Several RFCs, such as [3] and [4], and more recent 52 documents provide additional guidance on representing and structuring 53 information in these entries. Nor does this document define the procedure 54 to locate an enterprises' LDAP directory server, given their domain name. 55 Such as procedure may be defined in future RFCs. 57 2. Introduction to Domain Names and Distinguished Names 59 The Domain (Nameserver) System (DNS) provides a hierarchical resource 60 labeling system. A name is made up of an ordered set of components, 61 each of which are short strings. An example domain name with two 62 components would be "CRITICAL-ANGLE.COM". 64 The X.500 Directory provides a more general hierarchical naming framework. 65 A primary difference in specification of distinguished names from 66 domain names is that each component of an distinguished name has an 67 explicit attribute type indication. 69 An example distinguished name represented in the LDAP string format [2] 70 is "DC=CRITICAL-ANGLE,DC=COM". As with a domain name, the most significant 71 component, closest to the root of the namespace, is written last. 73 3. Mapping Domain Names into Distinguished Names 75 This section defines a subset of the X.500 naming structure for use in 76 representing names allocated in the Internet Domain Name System. It is 77 expected that it would be possible to algorithmically transform any 78 Internet domain name into a distinguished name, and to be able to convert 79 such a name back into a domain name. 81 The algorithm for transforming a domain name is to begin with an empty 82 DN and then attach RDNs for each component of the domain, most significant 83 first. Each of these RDNs have a single AttributeTypeAndValue, where the 84 type is DC and the value is an IA5 string containing the component. 86 Thus the domain name "CS.UCL.AC.UK" can be transformed into 87 DC=CS,DC=UCL,DC=AC,DC=UK 88 and similarly "11.168.192.IN-ADDR.ARPA" to 89 DC=11,DC=168,DC=192,DC=IN-ADDR,DC=ARPA 91 X.500 distinguished names in which there are one or more RDNs, all with 92 the attribute type DC, can be mapped back into domain names. Note that 93 this document does not define a domain name equivalence for any other 94 distinguished names. 96 4. Attribute Type and Object Class Definitions 98 The DC (short for domainComponent) attribute type is defined as follows: 100 ( 0.9.2342.19200300.100.1.25 NAME 'dc' EQUALITY caseIgnoreIA5Match 101 SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 'IA5String' SINGLE-VALUE ) 103 The value of this attribute is a string holding one component of a domain 104 name. The encoding of IA5String for use in LDAP is simply the characters 105 of the string itself. The equality matching rule is case insensitive, as 106 is today's DNS. 108 Objects with names derived from their domain name using the algorithm of 109 section 3 may be represented as an entry in the directory. This allows 110 information (attributes) to be associated with that entry. The entry 111 will have as its structural object class the "domain" object class, or 112 a subclass of "domain". 114 ( 0.9.2342.19200300.100.4.13 NAME 'domain' SUP top STRUCTURAL 115 MUST dc 116 MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ 117 x121Address $ registeredAddress $ destinationIndicator $ 118 preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ 119 telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ 120 street $ postOfficeBox $ postalCode $ postalAddress $ 121 physicalDeliveryOfficeName $ st $ l $ description $ o $ 122 associatedName ) ) 124 The optional attributes of the domain class are used for describing the 125 object represented by this domain, and may also be useful when searching. 126 The semantics of these attributes are defined in X.520 [5]. 128 The DC attribute is used for naming entries of the domain class. This is 129 reflected by the following name form rule. 131 ( 1.3.6.1.4.1.1466.345 NAME 'domainNameForm' OC domain MUST ( dc ) ) 133 If it is desired to be able to store or retrieve DNS record attributes 134 of the domain via LDAP, the dNSDomain object class can be used as well. 135 This object class should only be present in the entry if the DNS records 136 are listed as attributes. 138 ( 0.9.2342.19200300.100.4.15 NAME 'dNSDomain' SUP domain STRUCTURAL 139 MAY dNSRecord ) 141 The dNSRecord attribute may take one or more values. 143 ( 0.9.2342.19200300.100.1.26 NAME 'dNSRecord' 144 EQUALITY caseExactIA5Match SYNTAX 'IA5String' ) 146 5. Relationship between LDAP and DNS Directories 148 Implementations should be aware of the differences in deployment between 149 LDAP and DNS directories. 151 To effectively search the entries in an LDAP service, it is necessary to 152 know the base object of the entries held by that service. Generally that 153 base object will be in one of the naming contexts in the LDAP service. 155 While most objects with domain names are listed in an DNS-capable 156 directory system, it is currently expected that only a small subset of 157 the objects with domain names will be listed in LDAP-capable directories. 159 Furthermore, there may not necessarily be exactly one LDAP-capable 160 directory listing service for many top-level domains (such as ".COM" or 161 ".US"). There many be multiple distinct entries with the same name held 162 by different, disconnected directory services. There may be some objects 163 accessible in a directory service, for which the superior objects are not 164 held by any directory server. 166 LDAP client implementations should not assume that subtree searches may 167 be based at the root of the DIT, or at immediately subordinate entries. 168 Nor should LDAP client implementations assume that a name transformed from 169 a contacted server's domain name will be a context prefix held by that 170 server. If the client and server both implement LDAP version 3, the 171 client may interrogate the server for the naming contexts it holds. 173 6. References 175 [1] P. Mockapetris. Domain names - concepts and facilities. 176 RFC 1034, November 1987. 178 [2] S. Kille, M.Wahl. Lightweight Directory Access Protocol (v3): 179 UTF-8 String Representation of Distinguished Names. 180 INTERNET DRAFT draft-ietf-asid-ldapv3-dn-00.txt. July 1996. 182 [3] P. Barker, S. Kille, T. Lenggenhager, "Naming and Structuring 183 Guidelines for X.500 Directory Pilots". RFC 1617 May 1994. 185 [4] B. Jennings, "Building an X.500 Directory Service in the US", 186 RFC 1943, May 1996. 188 7. Security Considerations 190 This memo describes how attributes of objects may be discovered and 191 retrieved. Servers should ensure that an appropriate security policy 192 is maintained. 194 8. Author's Address 196 Steve Kille 197 Isode Ltd. 198 The Dome 199 The Square 200 Richmond, Surrey 201 TW9 1DT 202 England 203 Phone: +44-181-332-9091 204 EMail: S.Kille@ISODE.COM 206 Mark Wahl 207 Critical Angle Inc. 208 4815 W. Braker Lane #502-385 209 Austin, TX 78759 210 USA 211 EMail: M.Wahl@critical-angle.com