idnits 2.17.1 draft-ietf-ldapbis-models-09.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 36 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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 RFC2251, but the abstract doesn't seem to directly say this. It does mention RFC2251 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2252, but the abstract doesn't seem to directly say this. It does mention RFC2252 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2247 has weird spacing: '...for the purpo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (27 October 2003) is 7477 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: 'RFC2222' is mentioned on line 1773, but not defined ** Obsolete undefined reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) == Unused Reference: 'LDAPURL' is defined on line 1990, but no explicit reference was found in the text == Unused Reference: 'ASCII' is defined on line 2013, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BCP64bis' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-filter-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Filters' -- No information found for draft-ietf-ldapbis-url-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPURL' -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Schema' -- No information found for draft-yergeau-rfc2279bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'UTF-8' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires in six months 27 October 2003 5 Obsoletes: RFC 2251, RFC 2252, RFC 2256 7 LDAP: Directory Information Models 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be published as a Standard Track RFC. 16 Distribution of this memo is unlimited. Technical discussion of this 17 document will take place on the IETF LDAP Revision Working Group 18 mailing list . Please send editorial 19 comments directly to the author . 21 Internet-Drafts are working documents of the Internet Engineering Task 22 Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 . The list of 31 Internet-Draft Shadow Directories can be accessed at 32 . 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Please see the Full Copyright section near the end of this document 37 for more information. 39 Abstract 41 The Lightweight Directory Access Protocol (LDAP) is an Internet 42 protocol for accessing distributed directory services which act in 43 accordance with X.500 data and service models. This document 44 describes the X.500 Directory Information Models, as used in LDAP. 46 Table of Contents 48 Status of this Memo 1 49 Abstract 50 Table of Contents 2 51 1. Introduction 3 52 1.1. Relationship to Other LDAP Specifications 53 1.2. Relationship to X.501 4 54 1.3. Conventions 55 1.4. Common ABNF Productions 56 2. Model of Directory User Information 6 57 2.1. The Directory Information Tree 7 58 2.2. Naming of Entries 59 2.3. Structure of an Entry 8 60 2.4. Object Classes 9 61 2.5. Attribute Descriptions 11 62 2.6. Alias Entries 15 63 3. Directory Administrative and Operational Information 17 64 3.1. Subtrees 65 3.2. Subentries 66 3.3. The 'objectClass' attribute 18 67 3.4. Operational attributes 68 4. Directory Schema 21 69 4.1. Schema Definitions 22 70 4.2. Subschema Subentries 31 71 4.3. 'extensibleObject' 34 72 4.4. Subschema Discovery 35 73 5. DSA (Server) Informational Model 74 5.1. Server-specific Data Requirements 36 75 6. Other Considerations 39 76 6.1. Preservation of User Information 77 6.2. Short Names 78 6.3. Cache and Shadowing 40 79 7. Implementation Guidelines 80 7.1. Server Guidelines 81 7.2. Client Guidelines 41 82 8. Security Considerations 83 9. IANA Considerations 84 10. Acknowledgments 42 85 11. Author's Address 86 12. References 43 87 12.1. Normative References 88 12.2. Informative References 44 89 Appendix A. Changes 90 A.1 Changes to RFC 2251 44 91 A.2 Changes to RFC 2252 46 92 A.3 Changes to RFC 2256 48 93 Intellectual Property Rights 94 Full Copyright 49 96 1. Introduction 98 This document discusses the X.500 Directory Information Models 99 [X.501], as used by the Lightweight Directory Access Protocol (LDAP) 100 [Roadmap]. 102 The Directory is "a collection of open systems cooperating to provide 103 directory services" [X.500]. The information held in the Directory is 104 collectively known as the Directory Information Base (DIB). A 105 Directory user, which may be a human or other entity, accesses the 106 Directory through a client (or Directory User Agent (DUA)). The 107 client, on behalf of the directory user, interacts with one or more 108 servers (or Directory System Agents (DSA)). A server holds a fragment 109 of the DIB. 111 The DIB contains two classes of information: 113 1) user information (e.g., information provided and administrated 114 by users). Section 2 describes the Model of User Information. 116 2) administrative and operational information (e.g., information 117 used to administer and/or operate the directory). Section 3 118 describes the model of Directory Administrative and Operational 119 Information. 121 These two models, referred to as the generic Directory Information 122 Models, describe how information is represented in the Directory. 123 These generic models provide a framework for other information models. 124 Section 4 discusses the subschema information model and subschema 125 discovery. Section 5 discusses the DSA (Server) Informational Model. 127 Other X.500 information models, such as access control, collective 128 attribute, distribution knowledge, and replication knowledge 129 information models, may be adapted for use in LDAP. Specification of 130 how these models apply to LDAP is left to future documents. 132 1.1. Relationship to Other LDAP Specifications 134 This document is a integral part of the LDAP technical specification 135 [Roadmap] which obsoletes the previously defined LDAP technical 136 specification, RFC 3377, in its entirety. 138 This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as 139 portions of sections 4 and 6. Appendix A.1 summaries changes to these 140 sections. The remainder of RFC 2251 is obsoleted by the [Protocol], 141 [AuthMeth], and [Roadmap] documents. 143 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 144 summaries changes to these sections. The remainder of RFC 2252 is 145 obsoleted by [Syntaxes]. 147 This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. 148 Appendix A.3 summarizes changes to these sections. The remainder of 149 RFC 2256 is obsoleted by [Schema] and [Syntaxes]. 151 1.2. Relationship to X.501 153 This document includes material, with and without adaptation, from the 154 [X.501]. The material in this document takes precedence over that in 155 [X.501]. 157 1.3. Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in BCP 14 [RFC2119]. 163 Schema definitions are provided using LDAP description formats (as 164 defined in Section 4.1). Definitions provided here are formatted 165 (line wrapped) for readability. Matching rules and LDAP syntaxes 166 referenced in these definitions are specified in [Syntaxes]. 168 1.4. Common ABNF Productions 170 A number of syntaxes in this document are described using Augmented 171 Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a 172 number of syntaxes defined in other documents) rely on the following 173 common productions: 175 keystring = leadkeychar *keychar 176 leadkeychar = ALPHA 177 keychar = ALPHA / DIGIT / HYPHEN 179 number = DIGIT / ( LDIGIT 1*DIGIT ) 181 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 182 DIGIT = %x30 / LDIGIT ; "0"-"9" 183 LDIGIT = %x31-39 ; "1"-"9" 184 HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f 186 SP = 1*SPACE ; one or more " " 187 WSP = 0*SPACE ; zero or more " " 189 NULL = %x00 ; null (0) 190 SPACE = %x20 ; space (" ") 191 DQUOTE = %x22 ; quote (""") 192 SHARP = %x23 ; octothorpe (or sharp sign) ("#") 193 DOLLAR = %x24 ; dollar sign ("$") 194 SQUOTE = %x27 ; single quote ("'") 195 LPAREN = %x28 ; left paren ("(") 196 RPAREN = %x29 ; right paren (")") 197 PLUS = %x2B ; plus sign ("+") 198 COMMA = %x2C ; comma (",") 199 HYPHEN = %x2D ; hyphen ("-") 200 DOT = %x2E ; period (".") 201 SEMI = %x3B ; semicolon (";") 202 LANGLE = %x3C ; left angle bracket ("<") 203 EQUALS = %x3D ; equals sign ("=") 204 RANGLE = %x3E ; right angle bracket (">") 205 X = %x58 ; uppercase x ("X") 206 ESC = %x5C ; backslash ("\") 207 USCORE = %x5F ; underscore ("_") 208 LCURLY = %x7B ; left curly brace "{" 209 RCURLY = %x7D ; right curly brace "}" 211 ; Any UTF-8 character 212 UTF8 = UTF1 / UTFMB 213 UTFMB = UTF2 / UTF3 / UTF4 214 UTF0 = %x80-BF 215 UTF1 = %x00-7F 216 UTF2 = %xC2-DF UTF0 217 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / 218 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) 219 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / 220 %xF4 %x80-8F 2(UTF0) 222 ; Any octet 223 OCTET = %x00-FF 225 Object identifiers (OIDs) [X.680] are represented in LDAP using a dot- 226 decimal format conforming to the ABNF: 228 numericoid = number *( DOT number ) 230 Short names, also known as descriptors, are used as more readable 231 aliases for object identifiers. Short names are case insensitive and 232 conform to the ABNF: 234 descr = keystring 236 Where either an object identifier or a short name may be specified, 237 the following production is used: 239 oid = descr / numericoid 241 While the form is generally preferred when the usage is 242 restricted to short names referring to object identifiers which 243 identify like kinds of objects (e.g., attribute type descriptions, 244 matching rule descriptions, object class descriptions), the 245 form should be used when the object identifiers may 246 identify multiple kinds of objects or when an unambiguous short name 247 (descriptor) is not available. 249 When the form is used, the representation SHALL be considered 250 invalid if the usage is not restricted as discussed above or the 251 implementation cannot determine unambiguously which object identifier 252 the refers to. 254 Short Names (descriptors) are discussed further in Section 6.2. 256 2. Model of Directory User Information 258 As [X.501] states: 260 The purpose of the Directory is to hold, and provide access to, 261 information about objects of interest (objects) in some 'world'. 262 An object can be anything which is identifiable (can be named). 264 An object class is an identified family of objects, or conceivable 265 objects, which share certain characteristics. Every object belongs 266 to at least one class. An object class may be a subclass of other 267 object classes, in which case the members of the former class, the 268 subclass, are also considered to be members of the latter classes, 269 the superclasses. There may be subclasses of subclasses, etc., to 270 an arbitrary depth. 272 A directory entry, a named collection of information, is the basic 273 unit of information held in the Directory. There are multiple kinds 274 of directory entries. 276 An object entry represents a particular object. An alias entry 277 provides alternative naming. A subentry holds administrative and/or 278 operational information. 280 The set of entries representing the DIB are organized hierarchically 281 in a tree structure known as the Directory Information Tree (DIT). 283 Section 2.1 describes the Directory Information Tree 284 Section 2.2 discusses naming of entries. 285 Section 2.3 discusses the structure of entries. 286 Section 2.4 discusses object classes. 287 Section 2.5 discusses attribute descriptions. 288 Section 2.6 discusses alias entries. 290 2.1. The Directory Information Tree 292 As noted above, the DIB is composed of a set of entries organized 293 hierarchically in a tree structure known as the Directory Information 294 Tree (DIT). Specifically, a tree where vertices are the entries. 296 The arcs between vertices define relations between entries. If an arc 297 exists from X to Y, then the entry at X is the immediate superior of Y 298 and Y is the immediate subordinate of X. An entry's superiors are the 299 entry's immediate superior and its superiors. An entry's subordinates 300 are all of its immediate subordinates and their subordinates. 302 Similarly, the superior/subordinate relationship between object 303 entries can be used to derive a relation between the objects they 304 represent. DIT structure rules can be used to govern relationships 305 between objects. 307 Note: An entry's immediate superior is also known as the entry's 308 parent and an entry's immediate subordinate is also known as the 309 entry's child. Entries which have the same parent are known as 310 siblings. 312 2.2. Naming of Entries 314 2.2.1. Relative Distinguished Names 316 Each entry is named relative to its immediate superior. This relative 317 name, known as its Relative Distinguished Name (RDN) [X.501], is 318 composed of an unordered set of one or more attribute value assertions 319 (AVA) consisting of an attribute description with zero options and an 320 attribute value. These AVAs are chosen from the attributes of the 321 entry. 323 An entry's relative distinguished name must be unique among all 324 immediate subordinates of the entry's immediate superior (i.e., all 325 siblings). 327 The following are example string representations of RDNs [LDAPDN]: 328 UID=12345 329 OU=Engineering 330 CN=Kurt Zeilenga+L=Redwood Shores 332 The last is an example of a multi-valued RDN. That is, an RDN 333 composed of multiple AVAs. 335 2.2.2. Distinguished Names 337 An entry's fully qualified name, known as its Distinguished Name (DN) 338 [X.501], is the concatenation of its RDN and its immediate superior's 339 DN. A Distinguished Name unambiguously refers to an entry in the 340 tree. The following are example string representations of DNs 341 [LDAPDN]: 343 UID=nobody@example.com,DC=example,DC=com 344 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US 346 2.2.3. Alias Names 348 An alias, or alias name, is "an name for an object, provided by the 349 use of alias entries" [X.501]. Alias entries are described in Section 350 2.6. 352 2.3. Structure of an Entry 354 An entry consists of a set of attributes which hold information about 355 the object which entry represents. Some attributes represent user 356 information and are called user attributes. Other attributes 357 represent operational and/or administrative information and are called 358 operational attributes. 360 An attribute is an attribute description (a type and zero or more 361 options) with one or more associated values. An attribute is often 362 referred to by its attribute description. For example, the 363 'givenName' attribute is the attribute which consists of the attribute 364 description 'givenName' (the 'givenName' attribute type [Schema] and 365 zero options) and one or more associated values. 367 The attribute type governs whether the attribute can have multiple 368 values, the syntax and matching rules used to construct and compare 369 values of that attribute, and other functions. Options indicate 370 subtypes and other functions. No two values of an attribute may be 371 equivalent. 373 Two values are considered equivalent if they would match according to 374 the equality matching rule of the attribute type. If the attribute 375 type is defined with no equality matching rule, two values are 376 equivalent if and only if they are identical. 378 For example, the 'givenName' attribute can have can have more than one 379 value, they must be Directory Strings, and they are case insensitive. 380 The 'givenName' attribute cannot hold both "John" and "JOHN" as these 381 are equivalent values per the equality matching rule of the attribute 382 type. 384 2.4. Object Classes 386 An object class is "an identified family of objects (or conceivable 387 objects) which share certain characteristics" [X.501]. 389 As defined in [X.501]: 391 Object classes are used in the Directory for a number of purposes: 393 - describing and categorising objects and the entries that 394 correspond to these objects; 396 - where appropriate, controlling the operation of the Directory; 398 - regulating, in conjunction with DIT structure rule 399 specifications, the position of entries in the DIT; 401 - regulating, in conjunction with DIT content rule 402 specifications, the attributes that are contained in entries; 404 - identifying classes of entry that are to be associated with a 405 particular policy by the appropriate administrative authority. 407 An object class (a subclass) may be derived from an object class 408 (its direct superclass) which is itself derived from an even more 409 generic object class. For structural object classes, this process 410 stops at the most generic object class, 'top' (defined in Section 411 2.4.1). An ordered set of superclasses up to the most superior 412 object class of an object class is its superclass chain. 414 An object class may be derived from two or more direct 415 superclasses (superclasses not part of the same superclass chain). 416 This feature of subclassing is termed multiple inheritance. 418 Each object class identifies the set of attributes required to be 419 present in entries belonging to the class and the set of attributes 420 allowed to be present in entries belonging to the class. As an entry 421 of a class must meet the requirements of each class it belongs to, it 422 can be said that an object class inherits the sets of allowed and 423 required attributes from its superclasses. A subclass can identify an 424 attribute allowed by its superclass as being required. If an 425 attribute is a member of both sets, it is required to be present. 427 Each object class is defined to be one of three kinds of object 428 classes: Abstract, Structural, or Auxiliary. 430 Each object class is identified by an object identifier (OID) and, 431 optionally, one or more short names (descriptors). 433 2.4.1. Abstract Object Classes 435 An abstract object class, as the name implies, provides a base of 436 characteristics from which other object classes can be defined to 437 inherit from. An entry cannot belong to an abstract object class 438 unless it belongs to a structural or auxiliary class which inherits 439 from that abstract class. 441 Abstract object classes can not derive from structural nor auxiliary 442 object classes. 444 All structural object classes derive (directly or indirectly) from the 445 'top' abstract object class. Auxiliary object classes do not 446 necessarily derive from 'top'. 448 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 450 All entries belong to the 'top' abstract object class. 452 2.4.2. Structural Object Classes 454 As stated in [X.501]: 456 An object class defined for use in the structural specification of 457 the DIT is termed a structural object class. Structural object 458 classes are used in the definition of the structure of the names 459 of the objects for compliant entries. 461 An object or alias entry is characterised by precisely one 462 structural object class superclass chain which has a single 463 structural object class as the most subordinate object class. 464 This structural object class is referred to as the structural 465 object class of the entry. 467 Structural object classes are related to associated entries: 469 - an entry conforming to a structural object class shall 470 represent the real-world object constrained by the object 471 class; 473 - DIT structure rules only refer to structural object classes; 474 the structural object class of an entry is used to specify the 475 position of the entry in the DIT; 477 - the structural object class of an entry is used, along with an 478 associated DIT content rule, to control the content of an 479 entry. 481 The structural object class of an entry shall not be changed. 483 Each structural object class is a (direct or indirect) subclass of the 484 'top' abstract object class. 486 Structural object classes cannot subclass auxiliary object classes. 488 Each entry is said to belong to its structural object class as well as 489 all classes in its structural object class's superclass chain, which 490 always includes 'top'. 492 2.4.3. Auxiliary Object Classes 494 Auxiliary object classes are used augment the characteristics of 495 entries. They are commonly used to augment the sets of attributes 496 required and allowed attributes to be present in an entry. They can 497 be used to describe entries or classes of entries. 499 Auxiliary object classes cannot subclass structural object classes. 501 An entry can belong to any subset of the set of auxiliary object 502 classes allowed by the DIT content rule associated with structural 503 object class of the entry. If no DIT content rule is associated with 504 the structural object class of the entry, the entry cannot belong to 505 any auxiliary object class. 507 The set of auxiliary object classes which an entry belongs to can 508 change over time. 510 2.5. Attribute Descriptions 512 An attribute description is composed of an attribute type (see Section 513 2.5.1) and a set of zero or more attribute options (see Section 514 2.5.2). 516 An attribute description is represented by the ABNF: 518 attributedescription = attributetype options 520 attributetype = oid 522 options = *( SEMI option ) 524 option = 1*keychar 526 where identifies the attribute type and each