idnits 2.17.1 draft-ietf-ldapbis-models-01.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 is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == 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 2071 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 (28 May 2002) is 8002 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 1660, but not defined ** Obsolete undefined reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) == Unused Reference: 'Filters' is defined on line 1855, but no explicit reference was found in the text == Unused Reference: 'LDAPURL' is defined on line 1859, 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) -- 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' -- No information found for draft-ietf-ldapbis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPIANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- Obsolete informational reference (is this intentional?): RFC 2251 (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- No information found for draft-ietf-ldapbis-ldapv3-ts-xx - is the name correct? Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 26 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 28 May 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. 36 Please see the Copyright section near the end of this document for 37 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 4 52 1.1. Relationship to Other LDAP Specifications 53 1.2. Conventions 5 54 1.3. Common ABNF Productions 55 2. Model of Directory User Information 7 56 2.1. The Directory Information Tree 57 2.2. Naming of Entries 8 58 2.2.1. Relative Distinguished Names 59 2.2.2. Distinguished Names 60 2.2.3. Alias Names 61 2.3. Structure of an Entry 62 2.4. Object Classes 9 63 2.4.1. Abstract Object Classes 10 64 2.4.2. Structural Object Classes 65 2.4.3. Auxiliary Object Classes 11 66 2.5. Attribute Descriptions 67 2.5.1. Attribute Types 12 68 2.5.2. Attribute Options 13 69 2.5.2.1. Tagging Options 70 2.5.3. Attribute Description Hierarchies 14 71 2.5.4. Attribute Values 15 72 2.6. Alias Entries 73 2.6.1. 'alias' 16 74 2.6.2. 'aliasObjectName' 75 3. Directory Administrative and Operational Information 76 3.1. Subtrees 77 3.2. Subentries 17 78 3.3. The ObjectClass attribute 79 3.4. Operational attributes 80 3.4.1. 'createTimestamp' 18 81 3.4.2. 'modifyTimestamp' 82 3.4.3. 'creatorsName' 19 83 3.4.4. 'modifiersName' 84 4. Directory Schema 85 4.1. Schema Definitions 21 86 4.1.1. Object Class Definitions 22 87 4.1.2. Attribute Types 88 4.1.3. Matching Rules 24 89 4.1.4. LDAP Syntaxes 25 90 4.1.5. DIT Content Rules 26 91 4.1.6. DIT Structural Rules and Name Forms 27 92 4.2. Subschema Subentries 29 93 4.2.1. 'objectClasses' 30 94 4.2.2. 'attributeTypes' 95 4.2.3. 'matchingRules' 96 4.2.4. 'matchingRuleUse' 31 97 4.2.5. 'ldapSyntaxes' 98 4.2.6. 'dITContentRules' 99 4.2.7. 'dITStructureRules' 32 100 4.2.8. 'nameForms' 101 4.3. 'extensibleObject' 102 4.4. Subschema Discovery 33 103 5. DSA (Server) Informational Model 104 5.1. Server-specific Data Requirements 34 105 5.1.1. 'altServer' 106 5.1.2. 'namingContexts' 35 107 5.1.3. 'supportedControl' 108 5.1.4. 'supportedExtension' 36 109 5.1.5. 'supportedLDAPVersion' 110 5.1.6. 'supportedSASLMechanisms' 111 6. Other Considerations 112 6.1. Preservation of User Information 37 113 6.2. Short Names 114 6.3. Cache and Shadowing 115 7. Implementation Guidelines 116 7.1. Server Guidelines 117 7.2. Client Guidelines 38 118 8. Security Considerations 119 9. IANA Considerations 39 120 10. Acknowledgments 40 121 11. Author's Address 122 12. References 123 12.1. Normative References 124 12.2. Informative References 41 125 Appendix A. Changes 126 A.1 Changes to RFC 2251 42 127 A.1.1 Section 3.2 of RFC 2251 128 A.1.2 Section 3.4 of RFC 2251 129 A.1.2 Section 4 of RFC 2251 43 130 A.1.3 Section 6 of RFC 2251 131 A.2 Changes to RFC 2252 44 132 A.2.1 Section 4 of RFC 2252 133 A.2.2 Section 5 of RFC 2252 134 A.2.2 Section 7 of RFC 2252 135 A.3 Changes to RFC 2256 45 136 Copyright 138 1. Introduction 140 This document discusses the X.500 Directory Information Models 141 [X.501], as used by LDAP. 143 The Directory is "a collection of open systems cooperating to provide 144 directory services" [X.500]. The information held in the Directory is 145 collectively known as the Directory Information Base (DIB). A 146 Directory user, which may be a human or other entity, accesses the 147 Directory through a client (or Directory User Agent (DUA)). The 148 client, on behalf of the directory user, interacts with one or more 149 servers (or Directory System Agents (DSA)). A server holds a fragment 150 of the DIB. 152 The DIB contains two classes of information: 154 1) user information (e.g., information provided and administrated 155 by users). Section 2 describes the Model of User Information. 157 2) administrative and operational information (e.g., information 158 used to administer and/or operate the directory). Section 3 159 describes the model of Directory Administrative and Operational 160 Information. 162 These two models, referred to as the generic Directory Information 163 Models, describe how information is represented in the Directory. 164 These generic models provide a framework for other information models. 165 Section 4 discusses the subschema information model and subschema 166 discovery. Section 5 discusses the DSA (Server) Informational Model. 168 Other X.500 information models, such as access control, collective 169 attribute, distribution knowledge, and replication knowledge 170 information models, may be adapted for use in LDAP. Specification of 171 how these models are to be used in LDAP is left to future documents. 173 1.1. Relationship to Other LDAP Specifications 175 This document is a integral part of the LDAP technical specification 176 [Roadmap] which obsoletes entirely the previously defined LDAP 177 technical specification [LDAPTS]. 179 This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as 180 portions of sections 4 and 6. Appendix A.1 summaries changes to these 181 sections. 183 This document obsoletes RFC 2252 sections 4, 5 and 7 of RFC 2252. 184 Appendix A.2 summaries changes to these sections. 186 This document obsoletes RFC 2256 Sections 5.1 and portions of Section 187 7 including all of 7.1. Appendix A.3 summarizes changes to these 188 sections. 190 The remainder of RFC 2251 is obsoleted by the [Protocol], [AuthMeth], 191 and [Roadmap] documents. The remainder of RFC 2252 is obsoleted by 192 [Syntaxes] and [Schema]. The remainder of RFC 2256 is obsoleted by 193 [Schema] and [Syntaxes]. 195 1.2. Conventions 197 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 198 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 199 document are to be interpreted as described in BCP 14 [RFC2119]. 201 Schema definitions are provided using LDAP description formats (as 202 defined in Section 4.1). Definitions provided here are formatted 203 (line wrapped) for readability. Matching rules and LDAP syntaxes 204 referenced in these defintions are defined in [Syntaxes]. 206 1.3. Common ABNF Productions 208 A number of syntaxes in this document are described using ABNF 209 [RFC2234]. These syntaxes (as well as a number of syntaxes defined in 210 other documents) rely on the following common productions: 212 keystring = leadkeychar *keychar 213 leadkeychar = ALPHA 214 keychar = ALPHA / DIGIT / HYPHEN 216 number = DIGIT / ( LDIGIT 1*DIGIT ) 218 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 219 DIGIT = %x30 / LDIGIT ; "0"-"9" 220 LDIGIT = %x31-39 ; "1"-"9" 222 HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f 224 SP = 1*SPACE ; one or more " " 225 WSP = 0*SPACE ; zero or more " " 227 NULL = %x00 ; null (0) 228 SPACE = %x20 ; space (" ") 229 DQUOTE = %x22 ; quote (""") 230 SHARP = %x23 ; octothorpe (or sharp sign) ("#") 231 DOLLAR = %x24 ; dollar sign ("$") 232 SQUOTE = %x27 ; single quote ("'") 233 LPAREN = %x28 ; left paren ("(") 234 RPAREN = %x29 ; right paren (")") 235 PLUS = %x2B ; plus sign ("+") 236 COMMA = %x2C ; comma (",") 237 HYPHEN = %x2D ; hypen ("-") 238 DOT = %x2E ; period (".") 239 SEMI = %x3B ; semicolon (";") 240 LANGLE = %x3C ; left angle bracket ("<") 241 EQUALS = %x3D ; equals sign ("=") 242 RANGLE = %x3E ; right angle bracket (">") 243 X = %x58 ; uppercase x ("X") 244 ESC = %x5C ; backslash ("\") 245 USCORE = %x5F ; underscore ("_") 246 LCURLY = %x7B ; left curly brace "{" 247 RCURLY = %x7D ; right curly brace "}" 249 ; Any UTF-8 character 250 UTF8 = UTF1 / UTFMB 251 UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6 252 UTF0 = %x80-BF 253 UTF1 = %x00-7F 254 UTF2 = %xC0-DF 1(UTF0) 255 UTF3 = %xE0-EF 2(UTF0) 256 UTF4 = %xF0-F7 3(UTF0) 257 UTF5 = %xF8-FB 4(UTF0) 258 UTF6 = %xFC-FD 5(UTF0) 260 Object identifiers are represented in LDAP using a dot-decimal format 261 conforming to the ABNF: 263 numericoid = number *( DOT number ) 265 Short names, known as descriptors, are used as a more readable aliases 266 for object identifiers. Descriptors are case insensitive and conform 267 to the the ABNF: 269 descr = keystring 271 Where either an object identifier or a short name may be specified, 272 the following production is used: 274 oid = descr / numericoid 276 The form is preferred. When a production is encoded in 277 a value, the encoding option SHOULD be used instead of the 278 encoding option. 280 2. Model of Directory User Information 282 As [X.501] states: 284 The purpose of the Directory is to hold, and provide access to, 285 information about objects of interest (objects) in some 'world'. 286 An object can be anything which is identifiable (can be named). 288 An object class is an identified family of objects, or conceivable 289 objects, which share certain characteristics. Every object belongs 290 to at least one class. An object class may be a subclass of other 291 object classes, in which case the members of the former class, the 292 subclass, are also considered to be members of the latter classes, 293 the superclasses. There may be subclasses of subclasses, etc., to 294 an arbitrary depth. 296 A directory entry, a named collection of information, is the basic 297 unit of information held in the Directory. An object entry represents 298 a particular object. An alias entry provides alternative naming. A 299 subentry holds administrative and/or operational information. 301 The set of entries representing the DIB are organized hierarchically 302 in a tree structure known as the Directory Information Tree (DIT). 304 Section 2.1 describes the Directory Information Tree 305 Section 2.2 discusses naming of entries. 306 Section 2.3 discusses the structure of entries. 307 Section 2.4 discusses object classes. 308 Section 2.5 discusses attributes 309 Section 2.6 discusses alias entries 311 2.1. The Directory Information Tree 313 As noted above, the DIB is composed of a set of entries organized 314 hierarchically in a tree structure known as the Directory Information 315 Tree (DIT). Specifically, a tree where vertices are the entries. 317 The arcs between vertices define relations between entries. If an arc 318 exists from X to Y, then the entry at X is the immediate superior of Y 319 and Y is the immediate subordinate of X. An entry's superiors is the 320 entry's immediate superior and its superiors. An entry's subordinates 321 is all of its immediate subordinates and their subordinates. 323 Similarly, the superior/subordinate relationship between object 324 entries can be used to derive a relation between the objects they 325 represent. DIT structural rules can be used to govern relationships 326 between objects. 328 2.2. Naming of Entries 330 2.2.1. Relative Distinguished Names 332 Each entry is named relative to its immediate superior. This relative 333 name, known as its Relative Distinguished Name (RDN) [X.501], is 334 composed of one or more attribute value assertions (AVA) consisting of 335 an attribute description with zero options and an attribute value. An 336 entry's relative distinguished name must be unique among all its 337 siblings. 339 The following are example string representations of RDNs [LDAPDN]: 341 UID=12345 342 OU=Engineering 343 CN=Kurt Zeilenga+L=Redwood Shores 345 The last is an example of a multi-valued RDN. 347 2.2.2. Distinguished Names 349 An entry's fully qualified name, known as its Distinguished Name (DN) 350 [X.501], is the concatenation of its RDN and its immediate superior's 351 DN. A Distinguished Name unambiguously refers to an entry in the 352 tree. The following are example string representations of DNs 353 [LDAPDN]: 355 UID=nobody@example.com,DC=example,DC=com 356 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US 358 2.2.3. Alias Names 360 An alias, or alias name, is "an name for an object, provided by the 361 use of alias entries" [X.501]. Alias entries are described in Section 362 2.6. 364 2.3. Structure of an Entry 366 An entry consist of a set of attributes which hold information about 367 the object which entry represents. 369 An attribute is an attribute description, a type and one or more 370 options, with one or more associated values. The attribute type 371 governs whether the attribute can have multiple values, the syntax and 372 matching rules used to construct and compare values of that attribute, 373 and other functions. Options indicate subtypes and other functions. 375 An example of an attribute is 'givenName' [Schema]. There can be one 376 or more values of this attribute, they must be directory strings, and 377 they are case insensitive (e.g. "John" will match "JOHN"). 379 2.4. Object Classes 381 An object class is "an identified family of objects (or conceivable 382 objects) which share certain characteristics" [X.501]. 384 As defined in [X.501]: 386 Object classes are used in the Directory for a number of purposes: 388 - describing and categorising objects and the entries that 389 correspond to these objects; 391 - where appropriate, controlling the operation of the Directory; 393 - regulating, in conjunction with DIT structure rule 394 specifications, the position of entries in the DIT; 396 - regulating, in conjunction with DIT content rule 397 specifications, the attributes that are contained in entries; 399 - identifying classes of entry that are to be associated with a 400 particular policy by the appropriate administrative authority. 402 An object class (a subclass) may be derived from an object class 403 (its direct superclass) which is itself derived from an even more 404 generic object class. For structural object classes, this process 405 stops at the most generic object class, 'top' (defined in Section 406 2.4.1). An ordered set of superclasses up to the most superior 407 object class of an object class is its superclass chain. 409 An object class may be derived from two or more direct 410 superclasses (superclasses not part of the same superclass chain). 411 This feature of subclassing is termed multiple inheritance. 413 Each object class identifies the set of attributes required to be 414 present in entries belonging to the class and the set of attributes 415 allowed to be present in entries belonging to the class. As an entry 416 of a class must meet the requirements of each class it belongs to, it 417 can be said that an object class inherits the sets of allowed and 418 required attributes from its superclasses. A subclass can identify an 419 attribute allowed by a subclass as being required. If an attribute is 420 a member of both sets, it is required to be present. 422 Each object class is defined to be one of three kinds of object 423 classes: Abstract, Structural, and Auxiliary. 425 Each object is identified by an object identifier (OID) and, 426 optionally, one or more short names known as descriptors. 428 2.4.1. Abstract Object Classes 430 An Abstract object class, as the name implies, provides a base of 431 characteristics from which other object classes can be defined to 432 inherit from. An entry cannot belong to only abstract object classes. 434 Abstract object classes can not derive from structural nor auxiliary 435 object classes. 437 All structural object classes derive (directly or indirectly) from the 438 'top' abstract object class. Auxiliary object classes do not 439 necessarily derive from 'top'. 441 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 443 All entries belong to the 'top' abstract class. 445 2.4.2. Structural Object Classes 447 As stated in [X.501]: 449 An object class defined for use in the structural specification of 450 the DIT is termed a structural object class. Structural object 451 classes are used in the definition of the structure of the names 452 of the objects for compliant entries. 454 An object or alias entry is characterised by precisely one 455 structural object class superclass chain which has a single 456 structural object class as the most subordinate object class. 457 This structural object class is referred to as the structural 458 object class of the entry. 460 Structural object classes are related to associated entries: 462 - an entry conforming to a structural object class shall 463 represent the real-world object constrained by the object 464 class; 466 - DIT structure rules only refer to structural object classes; 467 the structural object class of an entry is used to specify the 468 position of the entry in the DIT; 470 - the structural object class of an entry is used, along with an 471 associated DIT content rule, to control the content of an 472 entry. 474 The structural object class of an entry shall not be changed. 476 Each structural object class is a (direct or indirect) subclass of the 477 'top' abstract object class. 479 Structural object classes cannot subclass auxiliary object classes. 481 Each entry is said to belong to its structural object class as well as 482 all classes in its structural object class's superclass chain, which 483 always includes 'top'. 485 2.4.3. Auxiliary Object Classes 487 Auxiliary object classes are used augment the characteristics of 488 entries. They are commonly used to augment the sets of attributes 489 required and allowed attributes to be present in an entry. They can 490 be used to describe entries or classes of entries. 492 Auxiliary object classes cannot subclass structural object classes. 494 Each entry can belong to any number of auxiliary object classes. The 495 set of auxiliary object classes which an entry belongs to can change 496 over time. 498 2.5. Attribute Descriptions 500 An attribute description is composed of an attribute type (see Section 501 2.5.1) and a set of zero or more attribute options (see Section 502 2.5.2). 504 An attribute description is represented by the ABNF: 506 attributedescription = attributetype options 508 attributetype = oid 510 options = *( SEMI option ) 511 option = 1*keychar 513 where identifies the attribute type and each