idnits 2.17.1 draft-ietf-ldapbis-models-06.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 2170 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 (16 December 2002) is 7795 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 1732, but not defined ** Obsolete undefined reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) == Missing Reference: 'RFC3383bis' is mentioned on line 1787, but not defined ** Obsolete undefined reference: RFC 3383 (Obsoleted by RFC 4520) == Unused Reference: 'LDAPURL' is defined on line 1968, 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 16 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 8 58 2.4. Object Classes 59 2.5. Attribute Descriptions 11 60 2.6. Alias Entries 15 61 3. Directory Administrative and Operational Information 16 62 3.1. Subtrees 63 3.2. Subentries 17 64 3.3. The 'objectClass' attribute 65 3.4. Operational attributes 18 66 4. Directory Schema 20 67 4.1. Schema Definitions 21 68 4.2. Subschema Subentries 30 69 4.3. 'extensibleObject' 34 70 4.4. Subschema Discovery 71 5. DSA (Server) Informational Model 72 5.1. Server-specific Data Requirements 35 73 6. Other Considerations 38 74 6.1. Preservation of User Information 75 6.2. Short Names 76 6.3. Cache and Shadowing 39 77 7. Implementation Guidelines 40 78 7.1. Server Guidelines 79 7.2. Client Guidelines 80 8. Security Considerations 41 81 9. IANA Considerations 82 10. Acknowledgments 42 83 11. Author's Address 84 12. References 85 12.1. Normative References 86 12.2. Informative References 43 87 Appendix A. Changes 88 A.1 Changes to RFC 2251 44 89 A.2 Changes to RFC 2252 46 90 A.3 Changes to RFC 2256 47 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, also known as descriptors, are used as more readable 223 aliases for object identifiers. Short names are case insensitive and 224 conform 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 protocol field, attribute value, assertion value, or elsewhere), the 235 encoding option SHOULD be used instead of the 236 encoding option. 238 2. Model of Directory User Information 240 As [X.501] states: 242 The purpose of the Directory is to hold, and provide access to, 243 information about objects of interest (objects) in some 'world'. 244 An object can be anything which is identifiable (can be named). 246 An object class is an identified family of objects, or conceivable 247 objects, which share certain characteristics. Every object belongs 248 to at least one class. An object class may be a subclass of other 249 object classes, in which case the members of the former class, the 250 subclass, are also considered to be members of the latter classes, 251 the superclasses. There may be subclasses of subclasses, etc., to 252 an arbitrary depth. 254 A directory entry, a named collection of information, is the basic 255 unit of information held in the Directory. There are multiple kinds 256 of directory entries. 258 An object entry represents a particular object. An alias entry 259 provides alternative naming. A subentry holds administrative and/or 260 operational information. 262 The set of entries representing the DIB are organized hierarchically 263 in a tree structure known as the Directory Information Tree (DIT). 265 Section 2.1 describes the Directory Information Tree 266 Section 2.2 discusses naming of entries. 267 Section 2.3 discusses the structure of entries. 268 Section 2.4 discusses object classes. 269 Section 2.5 discusses attribute descriptions. 270 Section 2.6 discusses alias entries. 272 2.1. The Directory Information Tree 274 As noted above, the DIB is composed of a set of entries organized 275 hierarchically in a tree structure known as the Directory Information 276 Tree (DIT). Specifically, a tree where vertices are the entries. 278 The arcs between vertices define relations between entries. If an arc 279 exists from X to Y, then the entry at X is the immediate superior of Y 280 and Y is the immediate subordinate of X. An entry's superiors are the 281 entry's immediate superior and its superiors. An entry's subordinates 282 are all of its immediate subordinates and their subordinates. 284 Similarly, the superior/subordinate relationship between object 285 entries can be used to derive a relation between the objects they 286 represent. DIT structure rules can be used to govern relationships 287 between objects. 289 Note: An entry's immediate superior is also known as the entry's 290 parent and an entry's immediate subordinate is also known as the 291 entry's child. 293 2.2. Naming of Entries 295 2.2.1. Relative Distinguished Names 297 Each entry is named relative to its immediate superior. This relative 298 name, known as its Relative Distinguished Name (RDN) [X.501], is 299 composed of an unordered set of one or more attribute value assertions 300 (AVA) consisting of an attribute description with zero options and an 301 attribute value. These AVAs are chosen from the attributes of the 302 entry. 304 An entry's relative distinguished name must be unique among all 305 immediate subordinates of the entry's immediate superior (i.e., all 306 siblings). 308 The following are example string representations of RDNs [LDAPDN]: 310 UID=12345 311 OU=Engineering 312 CN=Kurt Zeilenga+L=Redwood Shores 314 The last is an example of a multi-valued RDN. That is, an RDN 315 composed of multiple AVAs. 317 2.2.2. Distinguished Names 319 An entry's fully qualified name, known as its Distinguished Name (DN) 320 [X.501], is the concatenation of its RDN and its immediate superior's 321 DN. A Distinguished Name unambiguously refers to an entry in the 322 tree. The following are example string representations of DNs 323 [LDAPDN]: 325 UID=nobody@example.com,DC=example,DC=com 326 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US 328 2.2.3. Alias Names 330 An alias, or alias name, is "an name for an object, provided by the 331 use of alias entries" [X.501]. Alias entries are described in Section 332 2.6. 334 2.3. Structure of an Entry 336 An entry consists of a set of attributes which hold information about 337 the object which entry represents. Some attributes represent user 338 information and are called user attributes. Other attributes 339 represent operational and/or administrative information and are called 340 operational attributes. 342 An attribute is an attribute description (a type and zero or more 343 options) with one or more associated values. An attribute is often 344 referred to by its attribute description. For example, the 345 'givenName' attribute is the attribute which consists of the attribute 346 description 'givenName' (the 'givenName' attribute type [Schema] and 347 zero options) and one or more associated values. 349 The attribute type governs whether the attribute can have multiple 350 values, the syntax and matching rules used to construct and compare 351 values of that attribute, and other functions. Options indicate 352 subtypes and other functions. No two values of an attribute may be 353 equivalent. 355 Two values are considered equivalent if they would match according to 356 the equality matching rule of the attribute type. If the attribute 357 type is defined with no equality matching rule, two values are 358 equivalent if and only if they are identical. 360 For example, the 'givenName' attribute can have can have more than one 361 value, they must be Directory Strings, and they are case insensitive. 362 The 'givenName' attribute cannot hold both "John" and "JOHN" as these 363 are equivalent values per the equality matching rule of the attribute 364 type. 366 2.4. Object Classes 368 An object class is "an identified family of objects (or conceivable 369 objects) which share certain characteristics" [X.501]. 371 As defined in [X.501]: 373 Object classes are used in the Directory for a number of purposes: 375 - describing and categorising objects and the entries that 376 correspond to these objects; 378 - where appropriate, controlling the operation of the Directory; 380 - regulating, in conjunction with DIT structure rule 381 specifications, the position of entries in the DIT; 383 - regulating, in conjunction with DIT content rule 384 specifications, the attributes that are contained in entries; 386 - identifying classes of entry that are to be associated with a 387 particular policy by the appropriate administrative authority. 389 An object class (a subclass) may be derived from an object class 390 (its direct superclass) which is itself derived from an even more 391 generic object class. For structural object classes, this process 392 stops at the most generic object class, 'top' (defined in Section 393 2.4.1). An ordered set of superclasses up to the most superior 394 object class of an object class is its superclass chain. 396 An object class may be derived from two or more direct 397 superclasses (superclasses not part of the same superclass chain). 398 This feature of subclassing is termed multiple inheritance. 400 Each object class identifies the set of attributes required to be 401 present in entries belonging to the class and the set of attributes 402 allowed to be present in entries belonging to the class. As an entry 403 of a class must meet the requirements of each class it belongs to, it 404 can be said that an object class inherits the sets of allowed and 405 required attributes from its superclasses. A subclass can identify an 406 attribute allowed by a subclass as being required. If an attribute is 407 a member of both sets, it is required to be present. 409 Each object class is defined to be one of three kinds of object 410 classes: Abstract, Structural, and Auxiliary. 412 Each object class is identified by an object identifier (OID) and, 413 optionally, one or more short names (descriptors). 415 2.4.1. Abstract Object Classes 417 An abstract object class, as the name implies, provides a base of 418 characteristics from which other object classes can be defined to 419 inherit from. An entry cannot belong to an abstract object class 420 unless it belongs to a structural or auxiliary class which inherits 421 from that abstract class. 423 Abstract object classes can not derive from structural nor auxiliary 424 object classes. 426 All structural object classes derive (directly or indirectly) from the 427 'top' abstract object class. Auxiliary object classes do not 428 necessarily derive from 'top'. 430 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 432 All entries belong to the 'top' abstract object class. 434 2.4.2. Structural Object Classes 436 As stated in [X.501]: 438 An object class defined for use in the structural specification of 439 the DIT is termed a structural object class. Structural object 440 classes are used in the definition of the structure of the names 441 of the objects for compliant entries. 443 An object or alias entry is characterised by precisely one 444 structural object class superclass chain which has a single 445 structural object class as the most subordinate object class. 446 This structural object class is referred to as the structural 447 object class of the entry. 449 Structural object classes are related to associated entries: 451 - an entry conforming to a structural object class shall 452 represent the real-world object constrained by the object 453 class; 455 - DIT structure rules only refer to structural object classes; 456 the structural object class of an entry is used to specify the 457 position of the entry in the DIT; 459 - the structural object class of an entry is used, along with an 460 associated DIT content rule, to control the content of an 461 entry. 463 The structural object class of an entry shall not be changed. 465 Each structural object class is a (direct or indirect) subclass of the 466 'top' abstract object class. 468 Structural object classes cannot subclass auxiliary object classes. 470 Each entry is said to belong to its structural object class as well as 471 all classes in its structural object class's superclass chain, which 472 always includes 'top'. 474 2.4.3. Auxiliary Object Classes 476 Auxiliary object classes are used augment the characteristics of 477 entries. They are commonly used to augment the sets of attributes 478 required and allowed attributes to be present in an entry. They can 479 be used to describe entries or classes of entries. 481 Auxiliary object classes cannot subclass structural object classes. 483 Each entry can belong to any number of auxiliary object classes. The 484 set of auxiliary object classes which an entry belongs to can change 485 over time. 487 2.5. Attribute Descriptions 489 An attribute description is composed of an attribute type (see Section 490 2.5.1) and a set of zero or more attribute options (see Section 491 2.5.2). 493 An attribute description is represented by the ABNF: 495 attributedescription = attributetype options 497 attributetype = oid 499 options = *( SEMI option ) 501 option = 1*keychar 503 where identifies the attribute type and each