idnits 2.17.1 draft-ietf-ldapbis-models-02.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 2085 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 (12 August 2002) is 7928 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 1668, but not defined ** Obsolete undefined reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) == Unused Reference: 'Filters' is defined on line 1865, but no explicit reference was found in the text == Unused Reference: 'LDAPURL' is defined on line 1869, 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: 7 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 12 August 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 4 51 1.1. Relationship to Other LDAP Specifications 52 1.2. Conventions 5 53 1.3. Common ABNF Productions 54 2. Model of Directory User Information 7 55 2.1. The Directory Information Tree 56 2.2. Naming of Entries 8 57 2.2.1. Relative Distinguished Names 58 2.2.2. Distinguished Names 59 2.2.3. Alias Names 60 2.3. Structure of an Entry 61 2.4. Object Classes 9 62 2.4.1. Abstract Object Classes 10 63 2.4.2. Structural Object Classes 64 2.4.3. Auxiliary Object Classes 11 65 2.5. Attribute Descriptions 66 2.5.1. Attribute Types 12 67 2.5.2. Attribute Options 13 68 2.5.2.1. Tagging Options 69 2.5.3. Attribute Description Hierarchies 14 70 2.5.4. Attribute Values 15 71 2.6. Alias Entries 72 2.6.1. 'alias' 16 73 2.6.2. 'aliasObjectName' 74 3. Directory Administrative and Operational Information 75 3.1. Subtrees 76 3.2. Subentries 17 77 3.3. The 'objectClass' attribute 78 3.4. Operational attributes 18 79 3.4.1. 'creatorsName' 80 3.4.2. 'createTimestamp' 19 81 3.4.3. 'modifiersName' 82 3.4.4. 'modifyTimestamp' 83 4. Directory Schema 20 84 4.1. Schema Definitions 21 85 4.1.1. Object Class Definitions 22 86 4.1.2. Attribute Types 23 87 4.1.3. Matching Rules 24 88 4.1.4. LDAP Syntaxes 25 89 4.1.5. DIT Content Rules 26 90 4.1.6. DIT Structural Rules and Name Forms 27 91 4.2. Subschema Subentries 29 92 4.2.1. 'objectClasses' 30 93 4.2.2. 'attributeTypes' 94 4.2.3. 'matchingRules' 31 95 4.2.4. 'matchingRuleUse' 96 4.2.5. 'ldapSyntaxes' 97 4.2.6. 'dITContentRules' 32 98 4.2.7. 'dITStructureRules' 99 4.2.8. 'nameForms' 100 4.3. 'extensibleObject' 101 4.4. Subschema Discovery 33 102 5. DSA (Server) Informational Model 103 5.1. Server-specific Data Requirements 34 104 5.1.1. 'altServer' 35 105 5.1.2. 'namingContexts' 106 5.1.3. 'supportedControl' 107 5.1.4. 'supportedExtension' 36 108 5.1.5. 'supportedLDAPVersion' 109 5.1.6. 'supportedSASLMechanisms' 110 6. Other Considerations 37 111 6.1. Preservation of User Information 112 6.2. Short Names 113 6.3. Cache and Shadowing 114 7. Implementation Guidelines 38 115 7.1. Server Guidelines 116 7.2. Client Guidelines 117 8. Security Considerations 39 118 9. IANA Considerations 119 10. Acknowledgments 40 120 11. Author's Address 121 12. References 122 12.1. Normative References 123 12.2. Informative References 41 124 Appendix A. Changes 42 125 A.1 Changes to RFC 2251 126 A.1.1 Section 3.2 of RFC 2251 127 A.1.2 Section 3.4 of RFC 2251 43 128 A.1.2 Section 4 of RFC 2251 129 A.1.3 Section 6 of RFC 2251 44 130 A.2 Changes to RFC 2252 131 A.2.1 Section 4 of RFC 2252 132 A.2.2 Section 5 of RFC 2252 133 A.2.3 Section 7 of RFC 2252 45 134 A.3 Changes to RFC 2256 135 Copyright 137 1. Introduction 139 This document discusses the X.500 Directory Information Models 140 [X.501], as used by the Lightweight Directory Access Protocol (LDAP) 141 [Roadmap]. 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. The remainder of RFC 2251 is obsoleted by the [Protocol], 182 [AuthMeth], and [Roadmap] documents. 184 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 185 summaries changes to these sections. The remainder of RFC 2252 is 186 obsoleted by [Syntaxes] and [Schema]. 188 This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. 189 Appendix A.3 summarizes changes to these sections. The remainder of 190 RFC 2256 is obsoleted by [Schema] and [Syntaxes]. 192 1.2. Conventions 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in BCP 14 [RFC2119]. 198 Schema definitions are provided using LDAP description formats (as 199 defined in Section 4.1). Definitions provided here are formatted 200 (line wrapped) for readability. Matching rules and LDAP syntaxes 201 referenced in these defintions are defined in [Syntaxes]. 203 1.3. Common ABNF Productions 205 A number of syntaxes in this document are described using ABNF 206 [RFC2234]. These syntaxes (as well as a number of syntaxes defined in 207 other documents) rely on the following common productions: 209 keystring = leadkeychar *keychar 210 leadkeychar = ALPHA 211 keychar = ALPHA / DIGIT / HYPHEN 213 number = DIGIT / ( LDIGIT 1*DIGIT ) 215 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 216 DIGIT = %x30 / LDIGIT ; "0"-"9" 217 LDIGIT = %x31-39 ; "1"-"9" 219 HEX = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f 221 SP = 1*SPACE ; one or more " " 222 WSP = 0*SPACE ; zero or more " " 224 NULL = %x00 ; null (0) 225 SPACE = %x20 ; space (" ") 226 DQUOTE = %x22 ; quote (""") 227 SHARP = %x23 ; octothorpe (or sharp sign) ("#") 228 DOLLAR = %x24 ; dollar sign ("$") 229 SQUOTE = %x27 ; single quote ("'") 230 LPAREN = %x28 ; left paren ("(") 231 RPAREN = %x29 ; right paren (")") 232 PLUS = %x2B ; plus sign ("+") 233 COMMA = %x2C ; comma (",") 234 HYPHEN = %x2D ; hypen ("-") 235 DOT = %x2E ; period (".") 236 SEMI = %x3B ; semicolon (";") 237 LANGLE = %x3C ; left angle bracket ("<") 238 EQUALS = %x3D ; equals sign ("=") 239 RANGLE = %x3E ; right angle bracket (">") 240 X = %x58 ; uppercase x ("X") 241 ESC = %x5C ; backslash ("\") 242 USCORE = %x5F ; underscore ("_") 243 LCURLY = %x7B ; left curly brace "{" 244 RCURLY = %x7D ; right curly brace "}" 246 ; Any UTF-8 character 247 UTF8 = UTF1 / UTFMB 248 UTFMB = UTF2 / UTF3 / UTF4 / UTF5 / UTF6 249 UTF0 = %x80-BF 250 UTF1 = %x00-7F 251 UTF2 = %xC0-DF 1(UTF0) 252 UTF3 = %xE0-EF 2(UTF0) 253 UTF4 = %xF0-F7 3(UTF0) 254 UTF5 = %xF8-FB 4(UTF0) 255 UTF6 = %xFC-FD 5(UTF0) 257 ; Any octet 258 OCTET = %x00-FF 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 ) 512 option = 1*keychar 514 where identifies the attribute type and each