idnits 2.17.1 draft-byrne-ldap-alias-00.txt: 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-26) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 6 months document validity. ** 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 1 longer page, the longest (page 1) being 324 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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 6. Security Considerations' ) ** 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 an Authors' Addresses Section. ** There are 44 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([Whal], [Wahl], [Bradner97], [ITU-T], [LDAPv3]), 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 59: '...ng alias objects SHOULD be consistent....' RFC 2119 keyword, line 61: '...Additionally, it MUST be possible to u...' RFC 2119 keyword, line 84: '... alias SHOULD NOT be combine...' RFC 2119 keyword, line 90: '...naming attribute MUST be allowed to fo...' RFC 2119 keyword, line 100: '... object MUST be expanded. A n...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 70 has weird spacing: '...hl] are the ...' == Line 125 has weird spacing: '...wing is not a...' == Line 171 has weird spacing: '...turn an error...' -- 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 (20 April 1998) is 9503 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 section? 'Bradner97' on line 282 looks like a reference -- Missing reference section? 'Wahl' on line 70 looks like a reference -- Missing reference section? 'ITU-T' on line 285 looks like a reference -- Missing reference section? 'LDAPv3' on line 275 looks like a reference -- Missing reference section? 'Whal' on line 278 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft D. Byrne, IBM 2 LDAP Extensions WG L. Poitou, Sun 3 Intended Category: Standards Track E. Stokes, IBM 4 Expires: 20 October 1998 6 20 April 1998 8 Use of Aliases within LDAP 9 11 STATUS OF THIS MEMO 13 This document is an Internet Draft. Internet Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its Areas, and its Working Groups. Note that other 16 groups may also distribute working documents as Internet 17 Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet Drafts as reference material or to cite them other 23 than as a "working draft" or "work in progress." 25 To view the entire list of current Internet-Drafts, please 26 check the "1id-abstracts.txt" listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 28 ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern 29 Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East 30 Coast), or ftp.isi.edu (US West Coast). 32 Comments and suggestions on this document are encouraged. 33 Comments on this document should be sent to the LDAPEXT 34 working group discussion list: 36 ietf-ldapext@netscape.com 38 ABSTRACT 40 This document describes the suggested behavior for aliases for 41 LDAPv3 and above to improve LDAP server interoperability . 43 The key words "MUST", "SHOULD", and "MAY" used in this 44 document are to be interpreted as described in [Bradner97]. 46 1. Objectives 48 Aliases may be used within LDAP to reference entries anywhere 49 within the directory tree. Conceptually, an alias is simply a 50 pointer to the DIT entry it represents. It does not contain 51 additional information about that entry; only the location of 52 the entry. 54 The behavior of the alias object within LDAP is not well- 55 defined, both in creation of the alias object and the behavior 56 when dereferencing the alias. 58 For successful interoperability, the expected behavior of 59 servers when encountering alias objects SHOULD be consistent. 61 Additionally, it MUST be possible to use aliases without 62 changing the LDAPv3 schema as defined in [Wahl] and without 63 adding server-dependent data. 65 2. Schema Definition 67 2.1 Schema Expansion 69 The alias objectclass definitions presented in the LDAPv3 70 Schema [Wahl] are the basis for aliasing within ldap. The 71 alias objectclass is a Structural objectclass with a single 72 required attribute; the single valued aliasObjectName. 74 This definition of the alias objectclass does not allow for 75 any attribute other than 'aliasedObjectName' to be used as the 76 naming attribute within the RDN. The resulting dn for the 77 alias object must therefore be of the form 78 "aliasedObjectName=, , ..." This is not a 79 user-friendly name for a directory entry, and quite possibly 80 corrupts the naming hierarchy within the directory tree. 82 In order to remain true the concept of an alias; that it is 83 merely a pointer to another entry, an entry of objectclass 84 alias SHOULD NOT be combined with any other objectclass. If 85 multiple objectclasses are combined, it becomes possible to 86 add information to the alias entry without violating the 87 schema rules. 89 While not explicitly specified as either a 'required' or 90 'may', any naming attribute MUST be allowed to form the RDN of 91 the alias. Restricting the possible naming attributes would 92 potentially corrupt the hierarchy. For example, it would be 93 impossible to distinguish between a person alias and an 94 organisation alias. 96 2.2 AliasObject Objectclass 98 In order to create an alias object which can be appropriately 99 named to that which it represents, the definition of the alias 100 object MUST be expanded. A new objectclass must be defined 101 which inherits from the current definition of alias but 102 extends the attributes allowed within the RDN. 104 ( 1.3.6.1.4.1.42.2.27.1.2.1 105 NAME 'aliasObject' 106 DESC objectclass for all alias objects 107 SUP 'ALIAS' 108 MAY * 109 ) 111 The '*' allows any naming attribute to be used in forming the 112 RDN of the object. 114 For example, the following is a correct LDIF: 115 dn: cn=John Doe, ou=myOrg, c=US 116 objectclass: alias 117 objectclass: aliasObject 118 aliasedObjectName: cn=President, ou=myOrg, c=US 119 cn: John Doe 121 To prevent the alias from containing extra information about 122 the object, the naming attribute SHOULD contain only a single 123 value. 125 For example, the following is not a correct LDIF: 126 dn: cn=John Doe, ou=myOrg, c=US 127 objectclass: alias 128 objectclass: aliasObject 129 aliasedObjectName: cn=President, ou=myOrg, c=US 130 cn: John Doe 131 cn: Doe 133 Similarly, the following would not be a correct LDIF file 134 because it adds extra information to the alias object. 136 dn: cn=John Doe, ou=myOrg, c=US 137 objectclass: alias 138 objectclass: aliasObject 139 aliasedObjectName: cn=President, ou=myOrg, c=US 140 cn: John Doe 141 title: President 143 The naming attribute used to form the RDN of the object SHOULD 144 reflect the naming attribute of the referenced object. 145 However, there are some cases where the naming attribute MAY 146 be different. 148 Within the X.501 [ITU-T], the attribute used to described the 149 aliased object is 'aliasedEntryName'. Since the OID for 150 'aliasedEntryName' and 'aliasedObjectName' are the same for 151 both X.500 and LDAP, LDAP servers SHOULD treat the 152 'aliasedEntryName' as a synonym for 'aliasedObjectName'. 154 3. Alias Behavior 156 In general alias objects SHOULD NOT be dereferenced during any 157 operation other than search unless requested to do so by the 158 client. 160 Since an alias points to another section of the tree, it MUST 161 NOT be possible to add an object under an alias object; alias 162 objects MUST always be leaf nodes. 164 During the dereferencing of aliases, a loop is detected if the 165 server visits the same alias entry more than once. In this 166 case a data integrity error has occurred and the server MUST 167 return an error of 'aliasProblem' 169 If an alias is dereferenced, and the resulting directory entry 170 does not exists, a data integrity problem has occurred, and 171 the server MUST return an error code of 172 'aliasDereferencingProblem' 174 If the base entry for an ldapsearch is an alias, and alias 175 dereferencing is set to either derefFindBaseObj, or 176 derefAlways, the base entry MUST be dereferenced before the 177 search is performed. The new base for the search will become 178 the entry to which the alias resolves. The search is then 179 performed. 181 If multiple aliases are chained, the alias for the first 182 object MUST resolve to the last entry in the chain. For 183 example, A, B, and C are alias objects. If A points to B which 184 points to C which points to D, A resolves to D when 185 dereferencing the alias. 187 If an alias is dereferenced as part of a search, the alias 188 entry itself SHOULD NOT be returned as part of the search. 190 If an alias matches the search filter, and dereferencing is 191 set to 'searching' or 'always', the dereferenced object SHOULD 192 be returned, even if it does not match the filter. 194 If the alias is not dereferenced during the search, and it 195 matches the filter, then it SHOULD be returned within the 196 search result. 198 Each directory object matching a filter SHOULD be returned 199 only once during a search. If an entry is found twice because 200 of aliases pointing to a part of the tree already searched, 201 the entry SHOULD NOT be returned to the client a second time. 203 4. Scenarios 205 Using the following LDIF, the scenarios would return the 206 expected information as follows: 208 dn: c=myCountry 209 c: myCountry 210 objectclass: country 212 dn: ou=Area1, c=myCountry 213 ou: Area1 214 aliasedObjectName: o=myCorporation, c=myCountry 215 objectclass: alias 216 objectclass:aliasObject 218 dn: o=myCorporation, c=myCountry 219 ou: myCorporation 220 objectclass:organization 222 dn: cn=President, o=myCorporation, c=myCountry 223 cn: President 224 aliasObjectName: cn=John Doe, o=myCorporation, c=myCountry 225 objectclass: alias 226 objectclass: aliasObject 228 dn: cn=John Doe, o=myCorporation, c=myCountry 229 cn: John Doe 230 objectclass: person 232 c = myCountry 233 / | 234 ou = Area1 -----> o = myCorporation 235 | \ 236 cn=President ---> cn = John Doe 238 Performing a base search of 'ou = Area1, c=myCountry' with a 239 filter of 'objectclass=aliasObject' 240 NeverDerefAlias would return 'ou=Area1, c=myCountry' 241 DerefFinding would return 'cn=President, o=myCorporation, 242 c=myCountry' 243 DerefSearching would return 'o=myCorporation, 244 c=myCountry' 245 DerefAlways would return 'cn=John Doe, o=myCorporation, 246 c=myCountry' 248 Performing a one level search of 'c=myCountry' with a filter 249 of 'ou = * ' 250 NeverDerefAlias would return 'ou=Area1, c=myCountry' 251 DerefFinding would return 'ou=Area1, c=myCountry' 252 DerefSearching would return 'o=myCorporation, 253 c=myCountry' 254 DerefAlways would return ' o=myCorporation, c=myCountry' 256 Performing a full tree search of 'c=myCountry' with a filter 257 of ' cn = President ' 258 NeverDerefAlias would return 'cn=President, o=myCorporation, 259 c=myCountry' 260 DerefFinding would return 'cn=President, o=myCorporation, 261 c=myCountry' 262 DerefSearching would return 'cn=John Doe, o=myCorporation, 263 c=myCountry' 264 DerefAlways would return 'cn=John Doe, o=myCorporation, 265 c=myCountry' 267 6. Security Considerations 269 Permissions to dereferencing an alias, adding, deleting or 270 returning alias entries are decided by the directory server's 271 ACL administration policy. 273 7. References 275 [LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory 276 Access Protocol (v3)", RFC 2251, December 1997. 278 [Whal] M.Wahl, A, Coulbeck, T. Howes, S. Kille, "Lightweight 279 Directory Access Protocol (v3)": Attribute Syntax Definitions, 280 RFC 2252, December 1997. 282 [Bradner97] Bradner, Scott, "Key Words for use in RFCs to 283 Indicate Requirement Levels", RFC 2119. 285 [ITU-T] ITU-T Rec. X.501, "The Directory: Models", 1993 287 AUTHOR(S) ADDRESS 289 Debbie Byrne 290 IBM 291 11400 Burnet Rd 292 Austin, TX 78758 293 USA 294 mail-to: djbyrne@us.ibm.com 295 phone: +1 512 838 1930 297 Ludovic Poitou 298 Sun Microsystems 299 32, Chemin du vieux Chene 300 38240 Meylan 301 France 302 Phone: +33.(0)4.76.41.42.12 303 email: ludovic.poitou@france.sun.com 305 Ellen Stokes 306 IBM 307 11400 Burnet Rd 308 Austin, TX 78758 309 USA 310 mail-to: stokes@austin.ibm.com 311 phone: +1 512 838 3725