idnits 2.17.1 draft-ietf-ldapbis-models-04.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: ---------------------------------------------------------------------------- == Line 2077 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 (3 December 2002) is 7807 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 1654, but not defined ** Obsolete undefined reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) == Missing Reference: 'RFC3383bis' is mentioned on line 1701, but not defined ** Obsolete undefined reference: RFC 3383 (Obsoleted by RFC 4520) == Unused Reference: 'LDAPURL' is defined on line 1877, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2279 (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3383 (Obsoleted by RFC 4520) -- 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-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' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 21 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 3 December 2002 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 2002, The Internet Society. All Rights Reserved. Please 35 see the Copyright section near the end of this document for more 36 information. 38 Abstract 40 The Lightweight Directory Access Protocol (LDAP) is an Internet 41 protocol for accessing distributed directory services which act in 42 accordance with X.500 data and service models. This document 43 describes the X.500 Directory Information Models, as used in LDAP. 45 Table of Contents 47 Status of this Memo 1 48 Abstract 49 Table of Contents 2 50 1. Introduction 3 51 1.1. Relationship to Other LDAP Specifications 52 1.2. Conventions 4 53 1.3. Common ABNF Productions 54 2. Model of Directory User Information 6 55 2.1. The Directory Information Tree 56 2.2. Naming of Entries 7 57 2.3. Structure of an Entry 58 2.4. Object Classes 8 59 2.5. Attribute Descriptions 10 60 2.6. Alias Entries 14 61 3. Directory Administrative and Operational Information 15 62 3.1. Subtrees 63 3.2. Subentries 64 3.3. The 'objectClass' attribute 65 3.4. Operational attributes 17 66 4. Directory Schema 19 67 4.1. Schema Definitions 20 68 4.2. Subschema Subentries 28 69 4.3. 'extensibleObject' 32 70 4.4. Subschema Discovery 71 5. DSA (Server) Informational Model 33 72 5.1. Server-specific Data Requirements 73 6. Other Considerations 36 74 6.1. Preservation of User Information 75 6.2. Short Names 37 76 6.3. Cache and Shadowing 77 7. Implementation Guidelines 38 78 7.1. Server Guidelines 79 7.2. Client Guidelines 80 8. Security Considerations 39 81 9. IANA Considerations 82 10. Acknowledgments 40 83 11. Author's Address 84 12. References 85 12.1. Normative References 86 12.2. Informative References 41 87 Appendix A. Changes 88 A.1 Changes to RFC 2251 42 89 A.2 Changes to RFC 2252 44 90 A.3 Changes to RFC 2256 45 91 Copyright 93 1. Introduction 95 This document discusses the X.500 Directory Information Models 96 [X.501], as used by the Lightweight Directory Access Protocol (LDAP) 97 [Roadmap]. 99 The Directory is "a collection of open systems cooperating to provide 100 directory services" [X.500]. The information held in the Directory is 101 collectively known as the Directory Information Base (DIB). A 102 Directory user, which may be a human or other entity, accesses the 103 Directory through a client (or Directory User Agent (DUA)). The 104 client, on behalf of the directory user, interacts with one or more 105 servers (or Directory System Agents (DSA)). A server holds a fragment 106 of the DIB. 108 The DIB contains two classes of information: 110 1) user information (e.g., information provided and administrated 111 by users). Section 2 describes the Model of User Information. 113 2) administrative and operational information (e.g., information 114 used to administer and/or operate the directory). Section 3 115 describes the model of Directory Administrative and Operational 116 Information. 118 These two models, referred to as the generic Directory Information 119 Models, describe how information is represented in the Directory. 120 These generic models provide a framework for other information models. 121 Section 4 discusses the subschema information model and subschema 122 discovery. Section 5 discusses the DSA (Server) Informational Model. 124 Other X.500 information models, such as access control, collective 125 attribute, distribution knowledge, and replication knowledge 126 information models, may be adapted for use in LDAP. Specification of 127 how these models are to be used in LDAP is left to future documents. 129 1.1. Relationship to Other LDAP Specifications 131 This document is a integral part of the LDAP technical specification 132 [Roadmap] which obsoletes the previously defined LDAP technical 133 specification, RFC 3377, in its entirety. 135 This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as 136 portions of sections 4 and 6. Appendix A.1 summaries changes to these 137 sections. The remainder of RFC 2251 is obsoleted by the [Protocol], 138 [AuthMeth], and [Roadmap] documents. 140 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 141 summaries changes to these sections. The remainder of RFC 2252 is 142 obsoleted by [Syntaxes] and [Schema]. 144 This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. 145 Appendix A.3 summarizes changes to these sections. The remainder of 146 RFC 2256 is obsoleted by [Schema] and [Syntaxes]. 148 1.2. Conventions 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in BCP 14 [RFC2119]. 154 Schema definitions are provided using LDAP description formats (as 155 defined in Section 4.1). Definitions provided here are formatted 156 (line wrapped) for readability. Matching rules and LDAP syntaxes 157 referenced in these definitions are specified in [Syntaxes]. 159 1.3. Common ABNF Productions 161 A number of syntaxes in this document are described using Augmented 162 Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a 163 number of syntaxes defined in other documents) rely on the following 164 common productions: 166 keystring = leadkeychar *keychar 167 leadkeychar = ALPHA 168 keychar = ALPHA / DIGIT / HYPHEN 170 number = DIGIT / ( LDIGIT 1*DIGIT ) 172 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 173 DIGIT = %x30 / LDIGIT ; "0"-"9" 174 LDIGIT = %x31-39 ; "1"-"9" 176 HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f 178 SP = 1*SPACE ; one or more " " 179 WSP = 0*SPACE ; zero or more " " 181 NULL = %x00 ; null (0) 182 SPACE = %x20 ; space (" ") 183 DQUOTE = %x22 ; quote (""") 184 SHARP = %x23 ; octothorpe (or sharp sign) ("#") 185 DOLLAR = %x24 ; dollar sign ("$") 186 SQUOTE = %x27 ; single quote ("'") 187 LPAREN = %x28 ; left paren ("(") 188 RPAREN = %x29 ; right paren (")") 189 PLUS = %x2B ; plus sign ("+") 190 COMMA = %x2C ; comma (",") 191 HYPHEN = %x2D ; hyphen ("-") 192 DOT = %x2E ; period (".") 193 SEMI = %x3B ; semicolon (";") 194 LANGLE = %x3C ; left angle bracket ("<") 195 EQUALS = %x3D ; equals sign ("=") 196 RANGLE = %x3E ; right angle bracket (">") 197 X = %x58 ; uppercase x ("X") 198 ESC = %x5C ; backslash ("\") 199 USCORE = %x5F ; underscore ("_") 200 LCURLY = %x7B ; left curly brace "{" 201 RCURLY = %x7D ; right curly brace "}" 203 ; Any UTF-8 character 204 UTF8 = UTF1 / UTFMB 205 UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6 206 UTF0 = %x80-BF 207 UTF1 = %x00-7F 208 UTF2 = %xC0-DF 1(UTF0) 209 UTF3 = %xE0-EF 2(UTF0) 210 UTF4 = %xF0-F7 3(UTF0) 211 UTF5 = %xF8-FB 4(UTF0) 212 UTF6 = %xFC-FD 5(UTF0) 214 ; Any octet 215 OCTET = %x00-FF 217 Object identifiers are represented in LDAP using a dot-decimal format 218 conforming to the ABNF: 220 numericoid = number *( DOT number ) 222 Short names, known as descriptors, are used as more readable aliases 223 for object identifiers. Descriptors are case insensitive and conform 224 to the ABNF: 226 descr = keystring 228 Where either an object identifier or a short name may be specified, 229 the following production is used: 231 oid = descr / numericoid 233 The form is preferred. When a production is encoded in 234 a value, the encoding option SHOULD be used instead of the 235 encoding option. 237 2. Model of Directory User Information 239 As [X.501] states: 241 The purpose of the Directory is to hold, and provide access to, 242 information about objects of interest (objects) in some 'world'. 243 An object can be anything which is identifiable (can be named). 245 An object class is an identified family of objects, or conceivable 246 objects, which share certain characteristics. Every object belongs 247 to at least one class. An object class may be a subclass of other 248 object classes, in which case the members of the former class, the 249 subclass, are also considered to be members of the latter classes, 250 the superclasses. There may be subclasses of subclasses, etc., to 251 an arbitrary depth. 253 A directory entry, a named collection of information, is the basic 254 unit of information held in the Directory. An object entry represents 255 a particular object. An alias entry provides alternative naming. A 256 subentry holds administrative and/or operational information. 258 The set of entries representing the DIB are organized hierarchically 259 in a tree structure known as the Directory Information Tree (DIT). 261 Section 2.1 describes the Directory Information Tree 262 Section 2.2 discusses naming of entries. 263 Section 2.3 discusses the structure of entries. 264 Section 2.4 discusses object classes. 265 Section 2.5 discusses attribute descriptions. 266 Section 2.6 discusses alias entries. 268 2.1. The Directory Information Tree 270 As noted above, the DIB is composed of a set of entries organized 271 hierarchically in a tree structure known as the Directory Information 272 Tree (DIT). Specifically, a tree where vertices are the entries. 274 The arcs between vertices define relations between entries. If an arc 275 exists from X to Y, then the entry at X is the immediate superior of Y 276 and Y is the immediate subordinate of X. An entry's superiors is the 277 entry's immediate superior and its superiors. An entry's subordinates 278 is all of its immediate subordinates and their subordinates. 280 Similarly, the superior/subordinate relationship between object 281 entries can be used to derive a relation between the objects they 282 represent. DIT structural rules can be used to govern relationships 283 between objects. 285 2.2. Naming of Entries 287 2.2.1. Relative Distinguished Names 289 Each entry is named relative to its immediate superior. This relative 290 name, known as its Relative Distinguished Name (RDN) [X.501], is 291 composed of one or more attribute value assertions (AVA) consisting of 292 an attribute description with zero options and an attribute value. An 293 entry's relative distinguished name must be unique among all its 294 siblings. 296 The following are example string representations of RDNs [LDAPDN]: 298 UID=12345 299 OU=Engineering 300 CN=Kurt Zeilenga+L=Redwood Shores 302 The last is an example of a multi-valued RDN. 304 2.2.2. Distinguished Names 306 An entry's fully qualified name, known as its Distinguished Name (DN) 307 [X.501], is the concatenation of its RDN and its immediate superior's 308 DN. A Distinguished Name unambiguously refers to an entry in the 309 tree. The following are example string representations of DNs 310 [LDAPDN]: 312 UID=nobody@example.com,DC=example,DC=com 313 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US 315 2.2.3. Alias Names 317 An alias, or alias name, is "an name for an object, provided by the 318 use of alias entries" [X.501]. Alias entries are described in Section 319 2.6. 321 2.3. Structure of an Entry 323 An entry consist of a set of attributes which hold information about 324 the object which entry represents. 326 An attribute is an attribute description, a type and one or more 327 options, with one or more associated values. The attribute type 328 governs whether the attribute can have multiple values, the syntax and 329 matching rules used to construct and compare values of that attribute, 330 and other functions. Options indicate subtypes and other functions. 331 No two values of an attribute may be equivalent. 333 Two values are considered equivalent if they would match according to 334 the equality matching rule of the associated attribute type. If the 335 attribute type is defined with no equality matching rule, two values 336 are equivalent if and only if they are identical. 338 An example of an attribute is 'givenName'. As described in [Schema] 339 and [Syntaxes], there can be one or more values of this attribute, 340 they must be Directory Strings, and they are case insensitive (e.g. 341 "John" will match "JOHN"). 343 2.4. Object Classes 345 An object class is "an identified family of objects (or conceivable 346 objects) which share certain characteristics" [X.501]. 348 As defined in [X.501]: 350 Object classes are used in the Directory for a number of purposes: 352 - describing and categorising objects and the entries that 353 correspond to these objects; 355 - where appropriate, controlling the operation of the Directory; 357 - regulating, in conjunction with DIT structure rule 358 specifications, the position of entries in the DIT; 360 - regulating, in conjunction with DIT content rule 361 specifications, the attributes that are contained in entries; 363 - identifying classes of entry that are to be associated with a 364 particular policy by the appropriate administrative authority. 366 An object class (a subclass) may be derived from an object class 367 (its direct superclass) which is itself derived from an even more 368 generic object class. For structural object classes, this process 369 stops at the most generic object class, 'top' (defined in Section 370 2.4.1). An ordered set of superclasses up to the most superior 371 object class of an object class is its superclass chain. 373 An object class may be derived from two or more direct 374 superclasses (superclasses not part of the same superclass chain). 375 This feature of subclassing is termed multiple inheritance. 377 Each object class identifies the set of attributes required to be 378 present in entries belonging to the class and the set of attributes 379 allowed to be present in entries belonging to the class. As an entry 380 of a class must meet the requirements of each class it belongs to, it 381 can be said that an object class inherits the sets of allowed and 382 required attributes from its superclasses. A subclass can identify an 383 attribute allowed by a subclass as being required. If an attribute is 384 a member of both sets, it is required to be present. 386 Each object class is defined to be one of three kinds of object 387 classes: Abstract, Structural, and Auxiliary. 389 Each object is identified by an object identifier (OID) and, 390 optionally, one or more short names known as descriptors. 392 2.4.1. Abstract Object Classes 394 An abstract object class, as the name implies, provides a base of 395 characteristics from which other object classes can be defined to 396 inherit from. An entry cannot belong to only abstract object classes. 398 Abstract object classes can not derive from structural nor auxiliary 399 object classes. 401 All structural object classes derive (directly or indirectly) from the 402 'top' abstract object class. Auxiliary object classes do not 403 necessarily derive from 'top'. 405 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 407 All entries belong to the 'top' abstract class. 409 2.4.2. Structural Object Classes 411 As stated in [X.501]: 413 An object class defined for use in the structural specification of 414 the DIT is termed a structural object class. Structural object 415 classes are used in the definition of the structure of the names 416 of the objects for compliant entries. 418 An object or alias entry is characterised by precisely one 419 structural object class superclass chain which has a single 420 structural object class as the most subordinate object class. 421 This structural object class is referred to as the structural 422 object class of the entry. 424 Structural object classes are related to associated entries: 426 - an entry conforming to a structural object class shall 427 represent the real-world object constrained by the object 428 class; 430 - DIT structure rules only refer to structural object classes; 431 the structural object class of an entry is used to specify the 432 position of the entry in the DIT; 434 - the structural object class of an entry is used, along with an 435 associated DIT content rule, to control the content of an 436 entry. 438 The structural object class of an entry shall not be changed. 440 Each structural object class is a (direct or indirect) subclass of the 441 'top' abstract object class. 443 Structural object classes cannot subclass auxiliary object classes. 445 Each entry is said to belong to its structural object class as well as 446 all classes in its structural object class's superclass chain, which 447 always includes 'top'. 449 2.4.3. Auxiliary Object Classes 451 Auxiliary object classes are used augment the characteristics of 452 entries. They are commonly used to augment the sets of attributes 453 required and allowed attributes to be present in an entry. They can 454 be used to describe entries or classes of entries. 456 Auxiliary object classes cannot subclass structural object classes. 458 Each entry can belong to any number of auxiliary object classes. The 459 set of auxiliary object classes which an entry belongs to can change 460 over time. 462 2.5. Attribute Descriptions 463 An attribute description is composed of an attribute type (see Section 464 2.5.1) and a set of zero or more attribute options (see Section 465 2.5.2). 467 An attribute description is represented by the ABNF: 469 attributedescription = attributetype options 471 attributetype = oid 473 options = *( SEMI option ) 475 option = 1*keychar 477 where identifies the attribute type and each