idnits 2.17.1 draft-hahn-schemapart-00.txt: ** The Abstract section seems to be numbered -(83): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(84): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(90): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(101): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(104): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(131): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(134): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(145): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(154): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(161): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(191): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(201): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(232): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(249): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(250): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(253): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(279): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(287): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(315): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(330): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(336): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(346): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(364): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(366): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(372): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(378): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 70 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2251]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2001) is 8320 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) -- Looks like a reference, but probably isn't: '1' on line 77 == Missing Reference: 'LDAPREFERRALS' is mentioned on line 159, but not defined == Unused Reference: 'RFC2252' is defined on line 400, but no explicit reference was found in the text == Unused Reference: 'LDAPREFERRAL' is defined on line 409, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) == Outdated reference: A later version (-05) exists of draft-zeilenga-ldap-namedref-03 -- Possible downref: Normative reference to a draft: ref. 'LDAPSUBENTRY' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Hahn 3 Document: draft-hahn-schemapart-00.txt IBM 4 Expires: January 2002 July 2001 6 Approach for identifying different schemas in effect across a 7 Directory Name-space 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with 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 Internet- 17 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 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 2. Abstract 34 IETF RFC 2251 [RFC2251] provides a mechanism for indicating, given 35 any particular entry in the directory tree, what entry in the 36 directory tree holds the directory schema information for that 37 particular entry. RFC 2251 does not, however, provide guidance on 38 how different directory servers, each of which might have their own 39 active directory schema, should �publicize� this directory schema 40 such that the different active schemas are distinct from one another 41 when viewing the entire directory name-space. This document 42 describes a way to name sub-schema sub-entry entries such that 43 different active schemas can be distinguished from one another 44 across the entire directory name-space. 46 Identifying multiple schemas 48 3. Table of Contents 50 1. Status of this Memo............................................1 51 2. Abstract.......................................................1 52 3. Table of Contents..............................................2 53 4. Conventions used in this document..............................3 54 5. Review of RFC 2251 and RFC 2252 definition of subschemasubentry3 55 6. Contents of subschemasubentry..................................3 56 7. Method of naming subschemasubentry entries as distinct from one 57 another............................................................4 58 7.1. Potential problems with ambiguous subschemasubentry values..4 59 7.2. Subschema sub-entry is really an administrative element.....5 60 7.3. Subschema sub-entry entries as ldapSubEntry entries.........6 61 8. Summary........................................................8 62 9. Security Considerations........................................8 63 10. References...................................................9 64 11. Copyright Notice.............................................9 65 12. Author's Address.............................................9 66 Identifying multiple schemas 68 4. Conventions used in this document 70 In this document, directory entries will be described using LDAP 71 Data Interchange Format (LDIF). See RFC 2849 [RFC2849] for details 72 on LDIF. 74 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 75 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 76 this document are to be interpreted as described in RFC-2119 [1]. 78 5. Review of RFC 2251 and RFC 2252 definition of subschemasubentry 80 In RFC 2251 and RFC 2252, an operational attribute was defined 81 called subschemasubentry. This attribute can be requested from any 82 entry in the directory tree. When requested, the attribute�s value 83 will be a distinguished name which �points to� another entry in the 84 name-space. The entry �pointed to� contains the definition of the 85 directory schema which controls that entry. 87 While this allows the schema that controls an entry to be found 88 given any entry in the name-space, it does not give guidance on how 89 servers that manage multiple �active schemas� or multiple servers 90 would make their active schemas appear �unique� from other schemas 91 that are active in the name-space. 93 Based on implementation experience, the distinguished names that 94 have been chosen for the subschemasubentry have ranged from fixed 95 names such as �cn=schema� to names relative to the namingContexts 96 attribute values in the root DSE entry such as �cn=schema, o=Your 97 Company, c=US�. It is clear that to promote interoperability and 98 organization of the directory name-space (within single servers and 99 across multiple server environments), more specification of how to 100 name the subschema sub-entry entries is required. If multiple 101 servers name their schema �cn=schema� and each subschema sub-entry 102 is different from one another, applications which access data in 103 each of those servers will have difficulty determining which 104 �cn=schema� entry is in effect for the name-space. This problem is 105 further confounded with the use of LDAP referrals where the LDAP 106 server on which a request originates may not be the server on which 107 the request is processed. 109 This document will provide a means of naming subschema sub-entry 110 entries such that each �active schema� has a unique name in the 111 directory name-space. 113 6. Contents of subschemasubentry 115 RFC 2251 provides a description of the attributes which should be 116 contained in the subschemasubentry entry. These attributes are 117 �attributetypes�, �objectclasses�, �ldapsyntaxes�, and 118 �matchingrules�. Implementation experience has shown that 119 implementers have added additional attributes including attributes 120 that further define attribute type definitions as well as attributes 121 Identifying multiple schemas 122 to describe naming formats and structure rules. The definition of 123 the subschema sub-entry entry in RFC 2251 has its roots in the X.500 124 directory model and its definition of a sub-entry which defines the 125 schema for an area of the directory name-space. 127 A few implementations have named the subschema sub-entry entries 128 based on the tree of information that is controlled by that schema. 129 In these implementations, the subschema sub-entry is also defined as 130 an object class that is derived from the X.500 �subentry� object 131 class. The �subentry� object class has since been modeled in LDAP 132 schema as a �ldapSubEntry� object class [LDAPSUBENTRY]. 134 By using the �ldapSubEntry� construct coupled with the notion that 135 different portions of the directory name-space may be controlled by 136 different schemas, we can define a mechanism for uniquely naming 137 subschema sub-entry entries across single and multiple server 138 environments. 140 7. Method of naming subschemasubentry entries as distinct from one 141 another 143 7.1. Potential problems with ambiguous subschemasubentry values 145 RFC 2252 defines the �subschemasubentry� attribute value. It does 146 not require all entries in the directory to return the same value 147 for this attribute. Indeed, an implementation could choose to 148 define a separate value for every entry in the directory name-space 149 it is controlling and still conform to the requirements for the 150 subschemasubentry attribute from RFC 2251. 152 Most implementations today take a �single server� view of the 153 directory name-space. With this view, the choice of naming the 154 �subschemasubentry� entry as �cn=schema� does not appear to cause 155 any difficulty. After all, if there is only one server serving the 156 directory, there need not be more than one schema. When multiple 157 servers are serving the overall directory name-space (for example, 158 when multiple servers are tied together using LDAP referrals 159 [LDAPREFERRALS], then different servers might contain different 160 active schemas. At this point, if all servers name their schema as 161 �cn=schema�, problems can arise as applications access the subschema 162 sub-entry. The same distinguished name refers to different entries, 163 depending upon the server that is contacted. If a server is 164 contacted through following a referral, a subsequent request to 165 retrieve the subschema sub-entry may not follow the referral, 166 causing the wrong subschema sub-entry entry to be returned to the 167 application. 169 As an example, consider two LDAP servers, server A and server B. If 170 server A has namingContexts in the root DSE entry of: 172 namingContexts: ou=Marketing, o=Your Company 173 namingContexts: ou=Research, o=Your Company 175 While server B has namingContexts of: 177 Identifying multiple schemas 179 namingContexts: ou=Dept 14, ou=Marketing, o=Your Company 181 Further, assume that server A holds a referral to server B such that 182 applications which request information below �ou=Dept 14, 183 ou=Marketing, o=Your Company� will be re-routed to server B for 184 processing. 186 Also assume that both server A and server B use the same 187 distinguished name, �cn=schema� for the subschemasubentry attribute 188 value. 190 If an application requests the �subschemasubentry� attribute from 191 �ou=Dept 14, ou=Marketing, o=Your Company� from server A, referrals 192 will be followed (presumably), and the value �cn=schema� will be 193 returned from server B (unbeknownst to the application). If the 194 application then requests the subschema sub-entry from server A, it 195 will get the �cn=schema� entry from server A (not from server B). 196 If the two subschema sub-entry entries were named uniquely, this 197 situation would not occur. 199 It is within the bounds of RFC 2251 that server A and server B use 200 different distinguished names for the subschema sub-entry. For 201 example, server A could use �cn=schema, ou=Research, o=Your Company� 202 and server B could use �cn=schema, ou=Dept 14, ou=Marketing, o=Your 203 Company�. If this were done, then when the application requested 204 the subschemasubentry attribute in the prior example, it would be 205 returned a distinguished name that was also in server B�s �name- 206 space�. If the request for this entry was sent to server A, then 207 the LDAP referral which re-routed the first request to server B 208 would do so again, re-directing the request for the subshema sub- 209 entry to the server on which the schema exists. 211 There are two other possibilities as well: multiple servers all use 212 the same schema or a single server uses multiple schemas. In either 213 of these cases, if the subschema sub-entry entry is named uniquely 214 (relative to other subschema sub-entry entries that might exist in 215 the directory name-space) then the �right� schema can be retrieved 216 unambiguously. 218 7.2. Subschema sub-entry is really an administrative element 220 The active schema (or schemas) in a directory server is (are) really 221 an administrative element of that server. This information, similar 222 to replication information or namingContext information, is related 223 to administering the directory server(s) and the directory name- 224 space(s) that those servers are serving. 226 As an administrative element, it seems a good fit that the subschema 227 sub-entry entry use the object classes and structures that have been 228 defined for modeling administrative elements in the directory name- 229 space, namely the ldapSubEntry object class defined in 230 [LDAPSUBENTRY]. Using ldapSubEntry also provides the notion of a 231 Identifying multiple schemas 232 �span of control� for the subschema sub-entry entry, something that 233 has been missing from RFC 2251. 235 There is a slight problem today with defining only the 236 subschemasubentry attribute per RFC 2251. This has to do with 237 predicting which sub-schema subentry will be used when an entry is 238 added to the directory. Since the directory entry does not exist 239 yet, it has no subschemasubentry attribute � thus, there is no way 240 to point to the subschema sub-entry entry that �would be� used to 241 verify the entry�s structure during the processing of the add 242 operation. 244 Further, when found in the root DSE entry, the single-valued 245 subschemasubentry attribute does not refer to the schema across the 246 server but rather to the subschema entry that contains the 247 definition of the attribute types in the root DSE entry. 249 By using the ldapSubEntry construct, applications would get a �hint� 250 regarding what subschema sub-entry �would be� in effect when adding 251 an entry to the directory as the ldapSubEntry construct defines its 252 span of control �downward� in the tree until an overriding 253 ldapSubEntry is encountered. Note that this is only a �hint� since 254 the active schema could change right at the point in the directory 255 name-space where the new entry is being added. This could occur, 256 for example, when the entry at the top of a namingContext is being 257 added and the namingContext is located on a different server. 259 7.3. Subschema sub-entry entries as ldapSubEntry entries 261 With the justification in the last two sections, the proposal for 262 naming subschema sub-entry entries across the directory name-space 263 is to 265 1) define the subschema sub-entry entry to be derived from the 266 ldapSubEntry object class: 268 ( 1.3.18.0.2.6.x NAME �ldapSubSchemaSubEntry� 269 SUP ldapSubEntry 270 STRUCTURAL 271 DESC �LDAP sub-entry which represents the active schema 272 that is in effect across a sub-tree of the directory 273 name-space. The subschema AUXILIARY object class 274 is attached to this sub-entry to reflect the schema 275 information.� 276 ) 278 By using the ldapSubSchemaSubEntry object class above, the naming 279 attribute for the entry is �cn� (per the ldapSubEntry object class). 280 Further, the entry should exist just below the entry at which the 281 subschema sub-entry starts controlling entries in the directory 282 name-space. Subschema entries are named in relation to the portion 283 of the overall directory name-space to which they apply. 285 Identifying multiple schemas 286 2) recommend that directory servers use this construct to define 287 their subschema sub entry entries and that the �subschemasubentry� 288 attribute for an entry should point to the schema that �controls� 289 the entry (per RFC 2251), and that the name of the subschema sub- 290 entry entry should be specific to what information it controls (if 291 the schema only applies to information in one or a set of servers, 292 then the subschema sub-entry should have a name specific to that 293 server or set of servers). 295 Using the example from the previous section with server A and server 296 B, server A would have two subschema sub-entry entries: 298 dn: cn=schema, ou=Marketing, o=Your Company 299 objectclass: ldapSubEntry 300 objectclass: ldapSubSchemaSubEntry 301 objectclass: subschema 302 attributetypes: . . . 303 objectclasses: . . . 304 matchingrules: . . . 306 dn: cn=schema, ou=Research, o=Your Company 307 objectclass: ldapSubEntry 308 objectclass: ldapSubSchemaSubEntry 309 objectclass: subschema 310 attributetypes: . . . 311 objectclasses: . . . 312 matchingrules: . . . 314 There is nothing preventing server A from using the same �active 315 schema� for both of these entries while �publicizing� them at both 316 locations in the directory name-space. 318 Server B from the previous example would have a subschema sub-entry 319 named: 321 dn: cn=schema, ou=Dept 14, ou=Marketing, o=Your Company 322 objectclass: ldapSubEntry 323 objectclass: ldapSubSchemaSubEntry 324 objectclass: subschema 325 attributetypes: . . . 326 objectclasses: . . . 327 matchingrules: . . . 329 By basing this object class on the ldapSubEntry construct, the 330 active schema is presumed to be �in effect� in the directory name- 331 space starting at the directory entry directly above the 332 ldapSubSchemaSubEntry/ldapSubEntry, until another 333 ldapSubSchemaSubEntry object is encountered lower in the directory 334 name-space. 336 3) define a new root DSE attribute which �points to� the subschema 337 sub-entry entries that are active within that specific server (since 338 it is possible that multiple schemas may be active within a single 339 server). 341 Identifying multiple schemas 343 Since multiple active schemas may exist across the directory name- 344 space, it would be useful for applications to be able to query the 345 root DSE entry in a directory server to find the names of all 346 �active schemas� in that server. The �subschemasubentry� attribute 347 in the root DSE is not used for this purpose since this attribute 348 should be used to refer to the subschema sub-entry attribute which 349 controls the formats of the attributes used in the root DSE. 351 A new attribute must be defined to hold this information: 353 ( 1.3.18.0.2.4.x NAME �subschemasubentries� 354 SYNTAX distinguishedName 355 EQUALITY distinguishedNameMatch 356 DESC �multi-valued attribute in the root DSE which points to 357 all ldapSubSchemaSubEntry entries that are in effect/used 358 on this server� ) 360 8. Summary 362 This document has described the current problem of naming subschema 363 sub-entry entries with identical names across multiple LDAP servers 364 that are using different �active schemas�. Problems can occur for 365 applications that are attempting to access and/or modify the 366 currently �active schema�, especially when LDAP referrals are used 367 in the environment to build a directory name-space that spans 368 multiple directory servers. 370 This document recommends that subschema sub-entries build on the 371 ldapSubEntry construct to unambiguously name subschema sub-entry 372 entries across the directory name-space as well as provide a �hint� 373 for applications in determining the �active schema� that will be 374 used when a new entry is added to the directory. The name of the 375 scubschema sub-entry is distinct in the overall directory name-space 376 from other subschema sub-entries by their placement in the name- 377 space. In addition, this document defines a new root DSE attribute 378 to allow directory servers to �publicize� the set of subschema sub- 379 entries that are controlling entries in the portion of the directory 380 name-space being served by that server. 382 9. Security Considerations 384 There are no additional security considerations introduced by the 385 recommendations made in this document. It should be noted that 386 access to and update of the active schema in a directory server 387 should be controlled by some means of access control to ensure that 388 only qualified entities are able to access and/or update the active 389 schema. Unauthorized updates to the active schema could cause 390 existing information in the directory to become unreachable. 392 Identifying multiple schemas 394 10. References 396 [RFC2251] 397 M. Wahl, T. Howes, S. Kille, �Lightweight Directory Access Protocol 398 (v3)�, RFC 2251, December 1997. 400 [RFC2252] 401 M. Wahl, A. Coulbeck, T. Howes, S. Kille, �Lightweight Directory 402 Access Protocol (v3): Attribute Syntax Definitions�, RFC 2252, 403 December 1997. 405 [RFC2849] 406 G. Good, �The LDAP Data Interchange Format (LDIF) - Technical 407 Specification�, RFC 2849, June 2000. 409 [LDAPREFERRAL] 410 K. Zeilenga, �Named Subordinate References in LDAP Directories�, 411 Internet Draft, draft-zeilenga-ldap-namedref-03.txt. 413 [LDAPSUBENTRY] 414 E. Reed, �LDAP SubEntry Definition�, Internet Draft, draft-ietf- 415 ldup-subentry-08.txt, April 2001. 417 11. Copyright Notice 419 Copyright (C) The Internet Society (2001). All Rights Reserved. 421 This document and translations of it may be copied and furnished to 422 others, and derivative works that comment on or otherwise explain it 423 or assist in its implementation may be prepared, copied, published 424 and distributed, in whole or in part, without restriction of any 425 kind, provided that the above copyright notice and this paragraph 426 are included on all such copies and derivative works. However, this 427 document itself may not be modified in any way, such as by removing 428 the copyright notice or references to the Internet Society or other 429 Internet organizations, except as needed for the purpose of 430 developing Internet standards in which case the procedures for 431 copyrights defined in the Internet Standards process must be 432 followed, or as required to translate it into languages other than 433 English. 435 The limited permissions granted above are perpetual and will not be 436 revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein is provided on an 439 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 440 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 441 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 442 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 443 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 445 12. Author's Address 446 Identifying multiple schemas 447 Tim Hahn 448 IBM 449 Bldg 256-2, Dept. C8NG 450 1701 North St. 451 Endicott, NY 13760 USA 452 E-mail: hahnt@us.ibm.com