idnits 2.17.1 draft-ietf-ldapbis-models-00.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. ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 16 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1757 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 (21 February 2002) is 8094 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: 'SCHEMA' is mentioned on line 487, but not defined == Missing Reference: 'UTF-8' is mentioned on line 945, but not defined == Missing Reference: 'ISO 10646' is mentioned on line 945, but not defined == Missing Reference: 'RFC2222' is mentioned on line 1388, but not defined ** Obsolete undefined reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) == Missing Reference: 'RFC2434' is mentioned on line 1695, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'RFC2044' is defined on line 1532, but no explicit reference was found in the text == Unused Reference: 'Filters' is defined on line 1556, but no explicit reference was found in the text == Unused Reference: 'LDAPURL' is defined on line 1560, but no explicit reference was found in the text == Unused Reference: 'ISO10646' is defined on line 1572, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) ** 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: 11 errors (**), 0 flaws (~~), 13 warnings (==), 24 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: 21 August 2002 21 February 2002 5 Obsoletes: RFC 2251 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. 46 1. Introduction 48 The Directory is "a collection of open systems cooperating to provide 49 directory services" [X.500]. The information held in the Directory is 50 collectively known as the Directory Information Base (DIB). A 51 Directory user, which may be a human or other entity, accesses the 52 Directory through a client (or Directory User Agent (DUA)). The 53 client, on behalf of the directory user, interacts with one or more 54 servers (or Directory System Agents (DSA)). A server holds a fragment 55 of the Directory Information Base. 57 The DIB contains two classes of information: 59 1) user information (e.g., information provided and administrated 60 by users). Section 2 describes the Model of User Information. 62 2) administrative and operational information (e.g., information 63 used to administer and/or operate the directory). Section 3 64 describes the model of Directory Administrative and Operational 65 Information. 67 These two models, referred to as the generic Directory Information 68 Models, describe how information is represented in the Directory. 69 These generic models provide a framework for other information models. 70 Section 4 discusses the subschema information model and subschema 71 discovery. Section 5 discusses the DSA (Server) Informational Model. 73 Other X.500 information models, such as access control, collective 74 attribute, distribution knowledge, and replication knowledge 75 information models, may be adapted for use in LDAP. Specification of 76 how these models are to be used in LDAP is left to future documents. 78 1.1. Relationship to Other LDAP Specifications 80 This document is a integral part of the LDAP technical specification 81 [Roadmap] which obsoletes entirely the previously defined LDAP 82 technical specification [LDAPTS]. 84 This document replaces RFC 2251 sections 3.2 and 3.4, as well as 85 portions of sections 4 and 6. Appendix A.1 summaries changes to these 86 sections. 88 This document replaces RFC 2252 sections 4, 5 and 7 of RFC 2252. 89 Appendix A.2 summaries changes to these sections. 91 This document replaces RFC 2256 Sections 5.1 and portions of Section 7 92 including all of 7.1. Appendix A.3 summarizes changes to these 93 sections 95 The remainder of RFC 2251 is obsoleted by the [Protocol], [AuthMeth], 96 and [Roadmap] documents. The remainder of RFC 2252 is obsoleted by 97 [Syntaxes] and [Schema]. The remainder of RFC 2256 is obsoleted by 98 [Schema] and [Syntaxes]. 100 1.2. Conventions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in BCP 14 [RFC2119]. 106 Schema definitions are provided using LDAP description formats (as 107 defined in Section 4.1). Definitions provided here are formatted 108 (line wrapped) for readability. Matching rules and LDAP syntaxes 109 referenced in these defintions are defined in [Syntaxes]. 111 1.3. Common ABNF Productions 113 A number of syntaxes in this document are described using ABNF 114 [RFC2234]. These syntaxes rely on the following common productions: 116 keystring = leadkeychar *keychar 117 leadkeychar = ALPHA 118 keychar = ALPHA / DIGIT / HYPHEN 120 number = DIGIT / ( LDIGIT 1*DIGIT ) 122 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 123 DIGIT = %x30 / LDIGIT ; "0"-"9" 124 LDIGIT = %x31-39 ; "1"-"9" 126 SP = 1*SPACE 127 WSP = 0*SPACE 129 DOLLAR = %x24 ; "$" 130 DOT = %x2E ; "." 131 HYPHEN = %x2D ; "-" 132 LCURLY = %x7B ; "{" 133 LPAREN = %x28 ; "(" 134 PERIOD = %x2E ; "." 135 QUOTE = %x27 ; "'" 136 RCURLY = %x7D ; "}" 137 RPAREN = %x29 ; ")" 138 SEMI = %x3B ; ";" 139 SPACE = %x20 ; " " 140 USCORE = %x5F ; "_" 141 X = %x58 ; "X" 143 ; Any UTF-8 character 144 UTF8 = UTF1 / UTF2 / UTF3 / UTF4 / UTF5 / UTF6 145 UTF0 = %x80-BF 146 UTF0 = %x00-7F 147 UTF2 = %xC0-DF 1(UTF0) 148 UTF3 = %xE0-EF 2(UTF0) 149 UTF4 = %xF0-F7 3(UTF0) 150 UTF5 = %xF8-FB 4(UTF0) 151 UTF6 = %xFC-FD 5(UTF0) 153 Object identifiers are represented in LDAP using a dot-decimal format 154 (numericoid) conforming to the ABNF: 156 numericoid = number *( DOT number ) 158 Short names, known as descriptors (descr), are used as a more readable 159 aliases for object identifiers. Descriptors are case insensitive and 160 conform to the the ABNF: 162 descr = keystring 164 Where either an object identifier or a short name may be specified, 165 the following production is used: 167 oid = descr / numericoid 169 The descr form is preferred. When a production 'oid' is encoded in a 170 value, the descr encoding option SHOULD be used instead of the 171 numericoid encoding option. 173 2. Model of Directory User Information 175 As [X.501] states: 177 The purpose of the Directory is to hold, and provide access to, 178 information about objects of interest (objects) in some 'world'. 179 An object can be anything which is identifiable (can be named). 181 An object class is an identified family of objects, or conceivable 182 objects, which share certain characteristics. Every object belongs 183 to at least one class. An object class may be a subclass of other 184 object classes, in which case the members of the former class, the 185 subclass, are also considered to be members of the latter classes, 186 the superclasses. There may be subclasses of subclasses, etc., to 187 an arbitrary depth. 189 A directory entry, a named collection of information, is the basic 190 unit of information held in the Directory. An object entry represents 191 a particular object. An alias entry provides alternative naming. A 192 subentry is holds administrative and/or operational information. 193 Alias entries and subentries are not described in this specification. 195 The set of entries representing the DIB are organized hierarchically 196 in a tree structure known as the Directory Information Tree (DIT). 198 Section 2.1 describes the component parts of the DIT. 199 Section 2.2 discusses naming of entries. 200 Section 2.3 discusses the structure of entries. 201 Section 2.4 discusses object classes. 202 Section 2.5 discusses attributes 204 2.1. The Directory Information Tree 206 As noted above, the DIB is composed of a set of entries organized 207 hierarchically in a tree structure known as the Directory Information 208 Tree (DIT). Specifically, a tree where vertices are the entries. 210 The arcs between vertices define relations between entries. If an arc 211 exists from X to Y, then the entry at X is the immediate superior of Y 212 and Y is the immediate subordinate of X. An entry's superiors is the 213 entry's immediate superior and its superiors. An entry's subordinates 214 is all of its immediate subordinates and their subordinates. 216 Similarly, the superior/subordinate relationship between object 217 entries can be used to derive a relation between the objects they 218 represent. DIT structural rules can be used to govern relationships 219 between objects. 221 2.2. Naming of Entries 223 2.2.1. Relative Distinguished Names 225 Each entry is named relative to its immediate superior. This relative 226 name, known as its Relative Distinguished Name (RDN) [X.501], is 227 composed of one or more attribute value assertions (AVA) consisting of 228 an attribute description with zero options and an attribute value. 229 The following are example string representations of RDNs [LDAPDN]: 231 UID=12345 232 OU=Engineering 233 CN=Kurt Zeilenga+L=Redwood Shores 235 An entry's relative distinguished name must be unique among all its 236 siblings. 238 The last is an example of a multi-valued RDN. 240 2.2.2. Distinguished Names 242 An entry's fully qualified name, known as its Distinguished Name (DN) 243 [X.501], is the concatenation of its RDN and its immediate superior's 244 DN. A Distinguished Name unambiguously refers to an entry in the 245 tree. The following are example string representations of DNs 246 [LDAPDN]: 248 UID=nobody@example.com,DC=example,DC=com 249 CN=John Smith,OU=Sales,O=ACME Ltd.,L=Moab,ST=Utah,C=US 251 2.3. Structure of an Entry 253 An entry consist of a set of attributes which hold information about 254 the object which entry represents. 256 An attribute is an attribute description, a type and one or more 257 options, with one or more associated values. The attribute type 258 governs whether the attribute can have multiple values, the syntax and 259 matching rules used to construct and compare values of that attribute, 260 and other functions. Options indicate modes of transfer and other 261 functions. 263 An example of an attribute is 'mail'. There can be one or more values 264 of this attribute, they must be IA5 (ASCII) strings, and they are case 265 insensitive (e.g. "somebody@example.com" will match 266 "SOMEBODY@EXAMPLE.COM"). 268 2.4. Object Classes 270 An object class is "an identified family of objects (or conceivable 271 objects) which share certain characteristics" [X.501]. 273 As defined in [X.501]: 275 Object classes are used in the Directory for a number of purposes: 277 - describing and categorising objects and the entries that 278 correspond to these objects; 280 - where appropriate, controlling the operation of the Directory; 282 - regulating, in conjunction with DIT structure rule 283 specifications, the position of entries in the DIT; 285 - regulating, in conjunction with DIT content rule 286 specifications, the attributes that are contained in entries; 288 - identifying classes of entry that are to be associated with a 289 particular policy by the appropriate administrative authority. 291 An object class (a subclass) may be derived from an object class 292 (its direct superclass) which is itself derived from an even more 293 generic object class. For structural object classes, this process 294 stops at the most generic object class, 'top'. An ordered set of 295 superclasses up to the most superior object class of an object 296 class is its superclass chain. 298 An object class may be derived from two or more direct 299 superclasses (superclasses not part of the same superclass chain). 300 This feature of subclassing is termed multiple inheritance. 302 Each object class identifies the set of attributes required to be 303 present in entries belonging to the class and the set of attributes 304 allowed to be present in entries belonging to the class. As an entry 305 of a class must meet the requirements of each class it belongs to, it 306 can be said that an object class inherits the sets of allowed and 307 required attributes from its superclasses. A subclass can identify an 308 attribute allowed by a subclass as being required. If an attribute is 309 a member of both sets, it is required to be present. 311 Each object class is defined to be one of three kinds of object 312 classes: Abstract, Structural, and Auxiliary. 314 Each object is identified by an object identifier (OID) and, 315 optionally, one or more short names known as descriptors. 317 2.4.1. Abstract Object Classes 319 An Abstract object class, as the name implies, provides a base of 320 characteristics from which other object classes can be defined to 321 inherit from. An entry cannot belong to only abstract object classes. 323 Abstract object classes can not derive from structural nor auxiliary 324 object classes. 326 All structural object classes derive (directly or indirectly) from the 327 'top' abstract object class, defined in X.Y. Auxiliary object classes 328 do not necessarily derive from 'top'. 330 All entries belong to the 'top' abstract class. 332 2.4.2. Structural Object Classes 334 As stated in [X.501]: 336 An object class defined for use in the structural specification of 337 the DIT is termed a structural object class. Structural object 338 classes are used in the definition of the structure of the names 339 of the objects for compliant entries. 341 An object or alias entry is characterised by precisely one 342 structural object class superclass chain which has a single 343 structural object class as the most subordinate object class. This 344 structural object class is referred to as the structural object 345 class of the entry. 347 Structural object classes are related to associated entries: 349 - an entry conforming to a structural object class shall 350 represent the real-world object constrained by the object 351 class; 353 - DIT structure rules only refer to structural object classes; 354 the structural object class of an entry is used to specify the 355 position of the entry in the DIT; 357 - the structural object class of an entry is used, along with an 358 associated DIT content rule, to control the content of an 359 entry. 361 The structural object class of an entry shall not be changed. 363 Each structural object class is a (direct or indirect) subclass of the 364 'top' abstract object class. 366 Structural object classes cannot subclass auxiliary object classes. 368 Each entry is said to belong to its structural object class as well as 369 all classes in its structural object class's superclass chain, which 370 always includes 'top'. 372 2.4.3. Auxiliary Object Classes 374 Auxiliary object classes are used augment the characteristics of 375 entries. They are commonly used to augment the sets of attributes 376 required and allowed attributes to be present in an entry. They can 377 be used to describe entries or classes of entries. 379 Auxiliary object classes cannot subclass structural object classes. 381 Each entry can belong to any number of auxiliary object classes. The 382 set of auxiliary object classes which an entry belongs to can change 383 over time. 385 2.5. Attribute Descriptions 387 An attribute description is composed of an attribute type (2.5.1) and 388 a set of zero or more attribute options (2.5.2). 390 An attribute description is represented by the ABNF: 392 attributedescription = attributetype options 394 attributetype = oid 396 options = *( SEMI option ) 398 option = 1*keychar 400 where attributetype identifies the attribute type and each option 401 identifies an attribute option. Both attributetype and option 402 productions are case insensitive. The order in which options appear 403 is irrelevant. That is, any two attributedescriptions which consist 404 of the same attribute type and options are equivalent. 406 Examples of valid attribute descriptions: 408 2.5.4.0 409 cn;lang-de;lang-en 410 owner 412 An attribute description which consisting of an unrecognized attribute 413 type or an unrecongized attribute option is be treated unrecognized. 415 All attributes of an entry must have distinct attribute descriptions. 417 2.5.1. Attribute Types 419 An attribute type governs whether the attribute can have multiple 420 values, the syntax and matching rules used to construct and compare 421 values of that attribute, and other functions. 423 A user attribute type has userApplications usage. An operational 424 attribute type has one of three usages: directoryOperation, 425 distributedOperation, or dsaOperation. An operational attribute type 426 may be defined as not modifiable by users. 428 An user attribute type cannot be a subtype of an operational attribute 429 type. An operational attribute type which is a subtype must be 430 subtype of an operational attribute type of the same usage 431 (application). 433 An attribute type (a subtype) may derive from another attribute type 434 (a direct supertype). The subtype inherits the matching rules and 435 syntax of its supertype. 437 An attribute description consisting of a subtype and no options is 438 said to the direct description subtype of the attribute description 439 consisting of the subtype's direct supertype and no options. 441 Each attribute type is identified by an object identifier (OID) and, 442 optionally, one or more short names known as descriptors. 444 2.5.2. Attribute Options 446 There are multiple kinds of attribute description options. The LDAP 447 technical specification details two kinds: 449 - tagging options (such as language tag options), defined below and 451 - transfer options (such as ;binary), defined in [Protocol]. 453 Not all options can be associated with attributes held in the 454 directory. Tagging options can be. Transfer options cannot be. 456 An attribute description that contains mutually exclusive options 457 shall be treated as unrecognized. That is, "cn;binary;gser" (where 458 "binary" and "gser" are mutually exclusive) is to be treated as an 459 unrecognized attribute. 461 Other kinds of options may be specified in future documents. These 462 documents must detail how new kinds of options they define relate to 463 tagging and transfer options. In particular, these documents must 464 detail whether or not new kinds of options can be associated with 465 attributes held in the directory, how new kinds of options affect 466 transfer of attribute values, and how new kinds of options are treated 467 in attribute description hierarchies. 469 Options are represented as short case insensitive textual strings 470 conforming to the option production defined in Section 1.2 of this 471 document. 473 2.5.2.1. Tagging Options 475 Attributes held in the directory can have attribute descriptions with 476 one or more tagging options. Tagging options are never mutually 477 exclusive. 479 An attribute description with N tagging options is consider a direct 480 (description) subtype of all attribute descriptions of the same 481 attribute type and all but one of the N options. If the attribute 482 type has a supertype, then the attribute description is also 483 considered a direct (description) subtype of the attribute description 484 of the supertype and the N tagging options. That is, 485 'cn;lang-de;lang-en' is considered a direct subtype of 'cn;lang-de', 486 'cn;lang-en', and 'name;lang-de;lang-en' ('cn' is a subtype of 'name', 487 both are defined in [SCHEMA]). 489 2.5.3. Attribute Description Hierarchies 491 An attribute description can be the direct subtype of zero or more 492 other attribute descriptions as indicated by attribute type subtyping 493 (as described in Section 2.5.1) or attribute tagging option subtyping 494 (as described in Section 2.5.2.1). These subtyping relationships are 495 used to form hierarchies of attribute descriptions and attributes. 497 As adapted from [X.501]: 499 Attribute hierarchies allow access to the DIB with varying degrees 500 of granularity. This is achieved by allowing the value components 501 of attributes to be accessed by using either their specific 502 attribute description (a direct reference to the attribute) or by 503 a more generic attribute description (an indirect reference). 505 Semantically related attributes may be placed in a hierarchical 506 relationship, the more specialized being placed subordinate to the 507 more generalized. Searching for, or retrieving attributes and 508 their values is made easier by quoting the more generalized 509 attribute description; a filter item so specified is evaluated for 510 the more specialized descriptions as well as for the quoted 511 description. 513 Where subordinate specialized descriptions are selected to be 514 returned as part of a search result these descriptions shall be 515 returned if available. Where the more general descriptions are 516 selected to be returned as part of a search result both the 517 general and the specialized descriptions shall be returned, if 518 available. An attribute value shall always be returned as a value 519 of its own attribute description. 521 All of the attribute descriptions in an attribute hierarchy are 522 treated as distinct and unrelated descriptions for the purpose of 523 administration of the entry and for user modification of entry 524 content. 526 For an entry to contain a value of an attribute description 527 belonging to an attribute hierarchy, the attribute type of that 528 description must be explicitly included either in the definition 529 of an object class to which the entry belongs, or because the DIT 530 content rule applicable to that entry permits it. 532 An attribute value stored in a object or alias entry is of 533 precisely one attribute description. The description is indicated 534 when the value is originally added to the entry. 536 Note that the indicated description may include transfer and other 537 options not stored with as part of the attribute. 539 2.5.4. Attribute Values 541 Attribute values conform to the defined syntax of the attribute. 543 When an attribute is used for naming of the entry, one and only one 544 value of the attribute is selected to appear in the Relative 545 Distinguished Name. This value is known as a distinguished value. 547 Only attributes whose descriptions have no options can be used for 548 naming. 550 3. Directory Administrative and Operational Information 552 This section discusses select aspects of the X.500 Directory 553 Administrative and Operational Information model [X.501]. LDAP 554 implementations MAY support other aspects of this model. 556 3.1. Subtrees 558 As defined in [X.501]: 560 A subtree is a collection of object and alias entries situated at 561 the vertices of a tree. Subtrees do not contain subentries. The 562 prefix sub, in subtree, emphasizes that the base (or root) vertex 563 of this tree is usually subordinate to the root of the DIT. 565 A subtree begins at some vertex and extends to some identifiable 566 lower boundary, possibly extending to leaves. A subtree is always 567 defined within a context which implicitly bounds the subtree. For 568 example, the vertex and lower boundaries of a subtree defining a 569 replicated area are bounded by a naming context. Similarly, the 570 scope of a subtree defining a specific administrative area is 571 limited to the context of an enclosing autonomous administrative 572 area. 574 3.2. Subentries 576 A subentry is a "special sort of entry, known by the Directory, used 577 to hold information associated with a subtree or subtree refinement" 578 [X.501]. Subentries are used in Directory to hold for administrative 579 and operational purposes as defined in [X.501]. Their use in LDAP is 580 not detailed in this technical specification, but may be detailed in 581 future documents. 583 The term "(sub)entry" in this specification indicates that servers 584 implementing X.500(93) models are to use a subentry and other servers 585 are to mimic a subentry with an object entry. This object entry's RDN 586 shall be formed from values of the 'cn' (commonName) attribute. 588 3.3. The ObjectClass attribute 590 Each entry in the DIT has an 'objectClass' attribute. 592 ( 2.5.4.0 NAME 'objectClass' 593 EQUALITY objectIdentifierMatch 594 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 596 The 'objectClass' attribute specifies the object classes of an entry, 597 which (among other things) is used in conjunction with user and system 598 schema to determine the permitted attributes of an entry. Values of 599 this attribute can be modified by clients, but the 'objectClass' 600 attribute cannot be removed. 602 Servers which follow X.500(93) models SHALL restrict modifications of 603 this attribute to prevent the basic structural class of the entry from 604 being changed (e.g. one cannot change a 'person' into a 'country'). 606 When creating an entry or adding an 'objectClass' value to an entry, 607 all superclasses of the named classes are implicitly added as well if 608 not already present, and the client must supply values for any 609 mandatory attributes of new superclasses. 611 3.4. Operational attributes 613 Some attributes, termed operational attributes (as defined in Section 614 12.4.1 of [X.501]), are used or maintained by servers for 615 administrative and operational purposes. Not all operational 616 attributes are user modifiable. 618 Operational attributes are not normally visible. They are not 619 returned in search results unless explicitly requested by name. 621 Entries may contain, among others, the following operational 622 attributes. 624 - creatorsName: the Distinguished Name of the user who added this 625 entry to the directory. 627 - createTimestamp: the time this entry was added to the directory. 629 - modifiersName: the Distinguished Name of the user who last 630 modified this entry. 632 - modifyTimestamp: the time this entry was last modified. 634 Servers SHOULD maintain these attributes for all entries of the DIT. 636 3.4.1. createTimestamp 638 This attribute appears in entries which were added using the protocol 639 (e.g., using the Add operation). The value is the time the entry was 640 added. 642 ( 2.5.18.1 NAME 'createTimestamp' 643 EQUALITY generalizedTimeMatch 644 ORDERING generalizedTimeOrderingMatch 645 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 646 SINGLE-VALUE NO-USER-MODIFICATION 647 USAGE directoryOperation ) 649 3.4.2. modifyTimestamp 651 This attribute appears in entries which have been modified using the 652 protocol (e.g., using the Modify operation). The value is the time 653 the entry was modified. 655 ( 2.5.18.2 NAME 'modifyTimestamp' 656 EQUALITY generalizedTimeMatch 657 ORDERING generalizedTimeOrderingMatch 658 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 659 SINGLE-VALUE NO-USER-MODIFICATION 660 USAGE directoryOperation ) 662 3.4.3. creatorsName 664 This attribute appears in entries which were added using the protocol 665 (e.g., using the Add operation). The value is the distinguised name 666 of the creator. 668 ( 2.5.18.3 NAME 'creatorsName' 669 EQUALITY distinguishedNameMatch 670 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 671 SINGLE-VALUE NO-USER-MODIFICATION 672 USAGE directoryOperation ) 674 3.4.4. modifiersName 676 This attribute appears in entries which have been modified using the 677 protocol (e.g., using the Modify operation). The value is the 678 distinguised name of the creator. 680 ( 2.5.18.4 NAME 'modifiersName' 681 EQUALITY distinguishedNameMatch 682 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 683 SINGLE-VALUE NO-USER-MODIFICATION 684 USAGE directoryOperation ) 686 4. Directory Schema 688 As defined in [X.501]: 690 The Directory Schema is a set of definitions and constraints 691 concerning the structure of the DIT, the possible ways entries are 692 named, the information that can be held in an entry, the 693 attributes used to represent that information and their 694 organization into hierarchies to facilitate search and retrieval 695 of the information and the ways in which values of attributes may 696 be matched in attribute value and matching rule assertions. 698 NOTE 1 - The schema enables the Directory system to, for example: 700 - prevent the creation of subordinate entries of the wrong 701 object-class (e.g. a country as a subordinate of a person); 703 - prevent the addition of attribute-types to an entry 704 inappropriate to the object-class (e.g. a serial number to a 705 person's entry); 707 - prevent the addition of an attribute value of a syntax not 708 matching that defined for the attribute-type (e.g. a printable 709 string to a bit string). 711 Formally, the Directory Schema comprises a set of: 713 a) Name Form definitions that define primitive naming relations 714 for structural object classes; 716 b) DIT Structure Rule definitions that define the names that 717 entries may have and the ways in which the the entries may be 718 related to one another in the DIT; 720 c) DIT Content Rule definitions that extend the specification of 721 allowable attributes for entries beyond those indicated by the 722 structural object classes of the entries; 724 d) Object Class definitions that define the basic set of mandatory 725 and optional attributes that shall be present, and may be 726 present, respectively, in an entry of a given class, and which 727 indicate the kind of object class that is being defined; 729 e) Attribute Type definitions that identify the object identifier 730 by which an attribute is known, its syntax, associated matching 731 rules, whether it is an operational attribute and if so its 732 type, whether it is a collective attribute, whether it is 733 permitted to have multiple values and whether or not it is 734 derived from another attribute type; 736 f) Matching Rule definitions that define matching rules. 738 And in LDAP: 740 g) LDAP Syntaxes definitions that define encodings used in LDAP. 742 4.1. Schema Definitions 744 A schema definitions in this section are described using ABNF 745 [RFC2234] and rely on the common productions specified in 746 Section 1.2 as well as these: 748 noidlen = numericoid [ LCURLY len RCURLY ] 750 len = number 752 oids = oid / ( LPAREN SP oidlist SP RPAREN ) 754 oidlist = oid *( SP DOLLAR SP oid ) 756 extensions = *( SP xstring SP qdstrings ) 758 xstring = X HYPHEN 1*( ALPHA / HYPHEN / USCORE ) 760 qdescrs = qdescr / ( LPAREN WHSP qdescrlist WHSP RPAREN ) 762 qdescrlist = [ qdescr *( WHSP qdescr ) ] 764 qdescr = QUOTE descr QUOTE 766 qdstring = QUOTE dstring QUOTE 768 dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF8 string 770 QQ = %x5C %x35 %x37 ; "\27" 772 QS = %x5C %x32 ( %x43 / %x63 ) ; "\5C" / "\5C" 774 ; Any UTF-8 character except %x27 ("'") 775 QUTF8 = QUTF1 / UTF2 / UTF3 / UTF4 / UTF5 / UTF6 777 ; Any ASCII character except %x27 ("'") 778 QUTF1 = %x00-26 / %x28-5B / %x5D-7F 780 Implementors should note that future versions of this document 781 may expand these definitions to include additional terms. 782 Terms whose identifier begins with "X-" are reserved for 783 private experiments, and MUST be followed by a and a 784 tokens. 786 4.1.1. Object Class Definitions 788 Object Class definitions are written according to the ABNF: 790 ObjectClassDescription = RPAREN WSP 791 numericoid ; object identifer 792 [ SP "NAME" SP qdescrs ] ; short names 793 [ SP "DESC" SP qdstring ] ; description 794 [ SP "OBSOLETE" ] ; not active 795 [ SP "SUP" SP oids ] ; superior object classes 796 [ SP kind ] ; kind of class 797 [ SP "MUST" SP oids ] ; attribute types 798 [ SP "MAY" SP oids ] ; attribute types 799 extensions WSP RPAREN 801 kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" 803 where: 804 numericoid is object identifier assigned to this object class; 805 NAME qdescrs are short names identifying this object class; 806 DESC qdstring are short descriptive strings; 807 OBSOLETE indicates this object class is not active; 808 SUP oids specifies the direct superclasses of this object class; 809 where ABSTRACT, STRUCTURAL, AUXILIARY indicate the kind of object 810 class this is, default is STRUCTURAL; 811 MUST and MAY specify the sets of required and allowed attribute 812 types, respectively; and 813 extensions describe extensions. 815 4.1.2. Attribute Types 817 Attribute Type definitions are written according to the ABNF: 819 AttributeTypeDescription = LPAREN WSP 820 numericoid ; object identifer 821 [ SP "NAME" SP qdescrs ] ; short names 822 [ SP "DESC" SP qdstring ] ; description 823 [ SP "OBSOLETE" ] ; not active 824 [ SP "SUP" SP oid ] ; subtype 825 [ SP "EQUALITY" SP oid ] ; equality matching rule 826 [ SP "ORDERING" SP oid ] ; ordering matching rule 827 [ SP "SUBSTR" SP oid ] ; substrings matching rule 828 [ SP "SYNTAX" SP noidlen ] ; value syntax 829 [ SP "SINGLE-VALUE" ] ; single-value 830 [ SP "COLLECTIVE" ] ; collective 831 [ SP "NO-USER-MODIFICATION" ] ; not user modifiable 832 [ SP "USAGE" SP usage ] ; usage 833 extensions WSP RPAREN ; extensions 835 usage = "userApplications" / 836 "directoryOperation" / 837 "distributedOperation" / ; DSA-shared 838 "dsaOperation" ; DSA-specific 840 where: 841 numericoid is object identifier assigned to this attribute type; 842 NAME qdescrs are short names identifying this attribute type; 843 DESC qdstring are short descriptive strings; 844 OBSOLETE indicates this attribute type is not active; 845 SUP oid specifies the direct subtype of this type; 846 EQUALITY, ORDERING, SUBSTRING provide the oid of the equality, 847 ordering, and substrings matching rules, respectively; 848 SYNTAX identifies value syntax by object identifier and suggests a 849 minimum upper bound; 850 COLLECTIVE indicates this attribute type is collective; 851 NO-USER-MODIFICATION indicates this attribute type is not user 852 modifiable; 853 USAGE indicates the application of this attribute type; and 854 extensions describe extensions. 856 Each attribute type description must contain at least one of the "SUP" 857 or "SYNTAX" fields. 859 The default USAGE is userApplications. COLLECTIVE requires USAGE 860 userApplications. NO-USER_MODIFICATION requires usage other than 861 userApplications. 863 Note that the AttributeTypeDescription does not list the matching 864 rules which can can be used with that attribute type in an 865 extensibleMatch search filter. This is done using the 866 'matchingRuleUse' attribute described in Section 4.1.3. 868 This document refines the schema description of X.501 by requiring 869 that the syntax field in an AttributeTypeDescription be a string 870 representation of an object identifier for the LDAP string syntax 871 definition with an optional indication of the suggested minimun bound 872 of a value of this attribute. 874 A suggested minimum upper bound on the number of characters in value 875 with a string-based syntax, or the number of bytes in a value for all 876 other syntaxes, may be indicated by appending this bound count inside 877 of curly braces following the syntax's OBJECT IDENTIFIER in an 878 Attribute Type Description. This bound is not part of the syntax name 879 itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that server 880 implementations should allow a string to be 64 characters long, 881 although they may allow longer strings. Note that a single character 882 of the Directory String syntax may be encoded in more than one byte 883 since UTF-8 is a variable-length encoding. 885 4.1.3. Matching Rules 887 Matching rules are used by servers to compare attribute values against 888 assertion values when performing Search and Compare operations. They 889 are also used to identify the value to be added or deleted when 890 modifying entries, and are used when comparing a purported 891 distinguished name with the name of an entry. 893 A matching rule specifes the syntax of the assertion value. 895 Each matching rule is identified by an object identifier (OID) and, 896 optionally, one or more short names known as descriptors. 898 Matching rule definitions are written according to the ABNF: 900 MatchingRuleDescription = LPAREN WSP 901 numericoid ; object identifer 902 [ SP "NAME" SP qdescrs ] ; short names 903 [ SP "DESC" SP qdstring ] ; description 904 [ SP "OBSOLETE" ] ; not active 905 SP "SYNTAX" SP numericoid ; oid corrected to numericoid 906 extensions WSP RPAREN ; extensions 908 where: 909 numericoid is object identifier assigned to this matching rule; 910 NAME qdescrs are short names identifying this matching rule; 911 DESC qdstring are short descriptive strings; 912 OBSOLETE indicates this matching rule is not active; 913 SYNTAX identifies the assertion syntax by object identifier; and 914 extensions describe extensions. 916 A matching rule use lists the attributes which are suitable for use 917 with an extensible matching rule. 919 Matching rule use descriptions (see Section 4.1.3) are written 920 according to the following ABNF: 922 MatchingRuleUseDescription = LPAREN WSP 923 numericoid ; object identifer 924 [ SP "NAME" SP qdescrs ] ; short names 925 [ SP "DESC" SP qdstring ] ; description 926 [ SP "OBSOLETE" ] ; not active 927 SP "APPLIES" SP oids ; attribute types 928 extensions WSP RPAREN ; extensions 930 where: 931 numericoid is the object identifier of the matching rule associated 932 with this matching rule use description; 933 NAME qdescrs are short names identifying this matching rule use; 934 DESC qdstring are short descriptive strings; 935 OBSOLETE indicates this matching rule use is not active; 936 APPLIES provides a list of attribute types the matching rule applies 937 to; and 938 extensions describe extensions. 940 4.1.4. LDAP Syntaxes 942 LDAP Syntaxes of (attribute and assertion) values are described in 943 terms of ASN.1 [X.680] and, optionally, have an octet string encoding 944 known as the native encoding. Commonly, the native encoding is 945 constrained to [UTF-8] encoded [ISO 10646] (a superset of Unicode) 946 characters. 948 Each LDAP syntax is identified by an object identifier (OID). These 949 are not intended to be displayed to users. 951 LDAP syntax definitions are written according to the ABNF: 953 SyntaxDescription = LPAREN WSP 954 numericoid ; object identifer 955 [ SP "DESC" SP qdstring ] ; description 956 extensions WSP RPAREN ; extensions 958 where: 959 numericoid is object identifier assigned to this LDAP syntax; 960 DESC qdstring are short descriptive strings; and 961 extensions describe extensions. 963 4.1.5. DIT Content Rules 965 A DIT content rule is a "rule governing the content of entries of a 966 particular structural object class" [X.501]. 968 A DIT content rule specifies for DIT entries of a particular 969 structural object class, which auxiliary object classes the entries 970 are allowed to belong to and which additional attributes (by type) are 971 required, allowed or not allowed to appear in the entries. 973 The list of precluded attributes cannot include any attribute listed 974 as mandatory in rule, the structural object class, or any of the 975 allowed auxiliary object classes. 977 Each content rule is identified by the object identifer, as well as 978 any short names, of the structural rule it applies to. 980 An entry may only belong to auxiliary object classes listed in the 981 governing content rule. 983 An entry must contain all attributes required by the object classes 984 the entry belongs to as well as all attributed required by the 985 governing content rule. 987 An entry may contain any non-precluded attributes allowed by the 988 object classes the entry belongs to as well as all attributes allowed 989 by the governing content rule. 991 An entry cannot include any attribute precluded by the governing 992 content rule. 994 An entry is governed by (if present and active in the subschema) the 995 DIT content rule which applies to the structural object class of the 996 entry (see Section 2.4.2). If no active rule is present for the 997 entry's structural object class, the entry's content is governed by 998 the structural object class (and possibly other aspects of user and 999 system schema). 1001 DIT content rule descriptions are written according to the ABNF: 1003 DITContentRuleDescription = LPAREN WSP 1004 numericoid ; object identifer 1005 [ SP "NAME" SP qdescrs ] ; short names 1006 [ SP "DESC" SP qdstring ] ; description 1007 [ SP "OBSOLETE" ] ; not active 1008 [ SP "AUX" SP oids ] ; auxiliary object classes 1009 [ SP "MUST" SP oids ] ; attribute types 1010 [ SP "MAY" SP oids ] ; attribute types 1011 [ SP "NOT" SP oids ] ; attribute types 1012 extensions WSP RPAREN ; extensions 1014 where: 1015 numericoid is the object identifier of the structural object class 1016 associated with this DIT content rule; 1017 NAME qdescrs are short names identifying this DIT content rule; 1018 DESC qdstring are short descriptive strings; 1019 OBSOLETE indicates this DIT content rule use is not active; 1020 AUX specifies a list of auxiliary object classes which entries 1021 subject to this DIT content rule may belong to; 1022 MUST, MAY, and NOT specify lists of attribute types which are 1023 required, allowed, or precluded, respectively, from appearing in 1024 entries subject to this DIT content rule; and 1026 extensions describe extensions. 1028 4.1.6. DIT Structural Rules and Name Forms 1030 It is sometimes desirable to regulate where object entries can be 1031 placed in the DIT and how they can be named based upon their 1032 structural object class. 1034 A DIT structural rule is a "rule governing the structure of the DIT by 1035 specifying a permitted superior to subordinate entry relationship. A 1036 structure rule relates a name form, and therefore a structural object 1037 class, to superior structure rules. This permits entries of the 1038 structural object class identified by the name form to exist in the 1039 DIT as subordinates to entries governed by the indicated superior 1040 structure rules" [X.501]. 1042 A name form "specifies a permissible RDN for entries of a particular 1043 structural object class. A name form identifies a named object class 1044 and one or more attribute types to be used for naming (i.e. for the 1045 RDN). Name forms are primitive pieces of specification used in the 1046 definition of DIT structure rules" [X.501]. 1048 Each name form indicates the structural object class to be named, a 1049 set of required attribute types, and a set of allowed attributes 1050 types. A particular attribute type cannot be listed in both sets. 1052 Entries governed by the form must be named using a value from each 1053 required attribute type and zero or more values from the allowed 1054 attriutue types. 1056 Each name form is identified by an object identifier (OID) and, 1057 optionally, one or more short names known as descriptors. 1059 DIT structure rule descriptions are written according to the ABNF: 1061 DITStructureRuleDescription = LPAREN WSP 1062 ruleid ; rule identifier 1063 [ SP "NAME" SP qdescrs ] ; short names 1064 [ SP "DESC" SP qdstring ] ; description 1065 [ SP "OBSOLETE" ] ; not active 1066 SP "FORM" SP oid ; NameForm 1067 [ SP "SUP" ruleids ] ; superior rules 1068 extensions WSP RPAREN ; extensions 1070 ruleids = ruleid / LPAREN WSP ruleidlist WSP RPAREN 1072 ruleidlist = [ ruleid *( SP ruleid ) ] 1073 ruleid = number 1075 where: 1076 ruleid is the rule identifier of this DIT structure rule; 1077 NAME qdescrs are short names identifying this DIT structure rule; 1078 DESC qdstring are short descriptive strings; 1079 OBSOLETE indicates this DIT structure rule use is not active; 1080 FORM is specifies the name form associated with this DIT strucure rule; 1081 SUP identifies superior rules (by rule id); and 1082 extensions describe extensions. 1084 Name form descriptions are written according to the ABNF: 1086 NameFormDescription = LPAREN WSP 1087 numericoid ; object identifer 1088 [ SP "NAME" SP qdescrs ] ; short names 1089 [ SP "DESC" SP qdstring ] ; description 1090 [ SP "OBSOLETE" ] ; not active 1091 SP "OC" SP oid ; structural object class 1092 SP "MUST" SP oids ; attribute types 1093 [ SP "MAY" SP oids ] ; attribute types 1094 extensions WSP RPAREN ; extensions 1096 where: 1097 numericoid is object identifier assigned to this name form; 1098 NAME qdescrs are short names identifying this name form; 1099 DESC qdstring are short descriptive strings; 1100 OBSOLETE indicates this name form is not active; 1101 OC identifies the structural object class this rule applies to, 1102 MUST and MAY specify the sets of required and allowed, respectively, 1103 naming attributes for this name form; and 1104 extensions describe extensions. 1106 4.2. Subschema Subentries 1108 Subschema (sub)entries are used for administering information about 1109 the directory schema. A single subschema (sub)entry contains all 1110 schema definitions (see Section 4.1) used by entries in a particular 1111 part of the directory tree. 1113 Servers which follow X.500(93) models SHOULD implement subschema using 1114 the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]), 1115 and so these are not ordinary object entries but subentries (see 1116 Section 3.4). LDAP clients SHOULD NOT assume that servers implement 1117 any of the other aspects of X.500 subschema. 1119 Servers MAY allow modification of subschema. Procedures for Subschema 1120 Modification are discussed in Section 14.5 of [X.501]. 1122 A server which masters entries and permits clients to modify these 1123 entries MUST implement and provide access to these subschema 1124 (sub)entries including providing a 'subschemaSubentry' attribute in 1125 each modifiable entry. This so clients may discover the attributes 1126 and object classes which are permitted to be present. It is strongly 1127 RECOMMENDED that all other servers implement this as well. 1129 The value of the subschemaSubentry attribute is the name of the 1130 subschema (sub)entry holding the subschema controlling the entry. 1132 ( 2.5.18.10 NAME 'subschemaSubentry' 1133 EQUALITY distinguishedNameMatch 1134 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1135 NO-USER-MODIFICATION SINGLE-VALUE 1136 USAGE directoryOperation ) 1138 Subschema is held in (sub)entries belonging to the subschema auxiliary 1139 object class. 1141 ( 2.5.20.1 NAME 'subschema' AUXILIARY 1142 MAY ( dITStructureRules $ nameForms $ ditContentRules $ 1143 objectClasses $ attributeTypes $ matchingRules $ 1144 matchingRuleUse ) ) 1146 The ldapSyntaxes operational attribute may also be present in 1147 subschema entries. 1149 Servers MAY provide other attributes in subschema (sub)entries to 1150 reflect additional supported capabilities or for other administrative 1151 and operational purposes. 1153 Servers SHOULD provide the attributes 'createTimestamp' and 1154 'modifyTimestamp' in subschema (sub)entries, in order to allow clients 1155 to maintain their caches of schema information. 1157 The following subsections provide attribute type definitions for each 1158 of schema definition attribute types. 1160 4.2.1 objectClasses 1162 This attribute holds definitions of object classes supported in the 1163 subschema. 1165 ( 2.5.21.6 NAME 'objectClasses' 1166 EQUALITY objectIdentifierFirstComponentMatch 1167 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 1168 USAGE directoryOperation ) 1170 4.2.2 attributeTypes 1172 This attribute holds definitions of attribute types supported in the 1173 subschema. 1175 ( 2.5.21.5 NAME 'attributeTypes' 1176 EQUALITY objectIdentifierFirstComponentMatch 1177 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 1178 USAGE directoryOperation ) 1180 4.2.2 matchingRules 1182 This attribute holds definitions of matching rules supported in the 1183 subschema. 1185 ( 2.5.21.4 NAME 'matchingRules' 1186 EQUALITY objectIdentifierFirstComponentMatch 1187 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 1188 USAGE directoryOperation ) 1190 4.2.3 matchingRuleUse 1192 This attribute holds definitions of matching rule uses supported in 1193 the subschema. 1195 ( 2.5.21.8 NAME 'matchingRuleUse' 1196 EQUALITY objectIdentifierFirstComponentMatch 1197 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 1198 USAGE directoryOperation ) 1200 4.2.4 ldapSyntaxes 1202 This attribute holds definitions of LDAP syntaxes supported in the 1203 subschema. 1205 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' 1206 EQUALITY objectIdentifierFirstComponentMatch 1207 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 1208 USAGE directoryOperation ) 1210 4.2.4 dITContentRules 1212 This attribute lists DIT Content Rules which are in force. 1214 ( 2.5.21.2 NAME 'dITContentRules' 1215 EQUALITY objectIdentifierFirstComponentMatch 1216 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 1217 USAGE directoryOperation ) 1219 4.2.5 dITStructureRules 1221 This attribute lists DIT Structure Rules which are in force. 1223 ( 2.5.21.1 NAME 'dITStructureRules' 1224 EQUALITY integerFirstComponentMatch 1225 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 1226 USAGE directoryOperation ) 1228 4.2.6 nameForms 1230 This attribute lists Name Forms which are in force. 1232 ( 2.5.21.7 NAME 'nameForms' 1233 EQUALITY objectIdentifierFirstComponentMatch 1234 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 1235 USAGE directoryOperation ) 1237 4.3. Subschema Discovery 1239 Clients MAY discover the subschema (sub)entry holding the subschema 1240 controlling a particular entry (or subentry) by reading that entry's 1241 subschemaSubentry operational attribute. 1243 Clients MUST read retrieve desired attributes from a subschema 1244 (sub)entry by requesting a base object search of the (sub)entry, with 1245 the filter "(objectClass=subschema)". This filter allows LDAP servers 1246 which gateway to X.500 to detect detect that subentry information is 1247 being requested. It is noted that attributes holding schema 1248 definitions are operational and like other operational attributes are 1249 be requested by name when desired. 1251 5. DSA (Server) Informational Model 1253 The LDAP protocol assumes there are one or more servers which jointly 1254 provide access to a Directory Information Tree (DIT). 1256 As defined in [X.501]: 1258 context prefix: The sequence of RDNs leading from the Root of the 1259 DIT to the initial vertex of a naming context; corresponds to 1260 the distinguished name of that vertex. 1262 DIB fragment: The portion of the DIB that is held by one master 1263 DSA, comprising one or more naming contexts. 1265 naming context: A subtree of entries held in a single master DSA. 1267 That is, a naming context is the largest collection of entries, 1268 starting at an entry that is mastered by a particular server, and 1269 including all its subordinates and their subordinates, down to the 1270 entries which are mastered by different servers. And the context 1271 prefix is the name of the start entry. 1273 The root of the DIT is a DSA-specific Entry (DSE) and not part of any 1274 naming context (or any subtree); each server has different attribute 1275 values in the root DSE. 1277 5.1. Server-specific Data Requirements 1279 An LDAP server MUST provide information about itself and other 1280 information that is specific to each server. This is represented as a 1281 group of attributes located in the root DSE (DSA-Specific Entry), 1282 which is named with the zero-length LDAPDN. These attributes are 1283 retrievable, subject to access control and other restrictions, if a 1284 client performs a base object search of the root with filter 1285 "(objectClass=*)" requesting the desired attributes. It is noted that 1286 root DSE attributes are operational, and like other operational 1287 attributes, are not returned in search requests unless requested by 1288 name. 1290 The root DSE SHALL NOT be included if the client performs a subtree 1291 search starting from the root. 1293 Servers may allow clients to modify attributes of the root DSE where 1294 appropriate. 1296 The following attributes of the root DSE are defined in [Syntaxes]. 1297 Additional attributes may be defined in other documents. 1299 - altServer: alternative servers; 1300 - namingContexts: naming contexts; 1302 - supportedControl: recongized LDAP controls; 1304 - supportedExtension: recongized LDAP extended operations; 1306 - supportedLDAPVersion: LDAP versions supported; and 1308 - supportedSASLMechanisms: recongized SASL mechnanisms. 1310 The values of these attributes provided may depend on a session 1311 specific and other factors. For example, a server supporting the SASL 1312 EXTERNAL mechanism may only list "EXTERNAL" when the client's identity 1313 has been established by a lower level. See [AuthMeth]. 1315 The root DSE may also include a subschemaSubentry attribute. If so, 1316 it refers to the subschema (sub)entry holding schema controlling 1317 attributes of the root DSE. Client SHOULD NOT assume that the 1318 subschema (sub)entry controlling the root DSE controls any entry held 1319 by the server. General subschema discovery procedures are provided in 1320 Section 4.3. 1322 5.1.1. altServer 1324 The 'altServer' attribute lists URLs referring to alternative servers 1325 which may be contacted when this becomes unavailable. If the server 1326 does not know of any other servers which could be used this attribute 1327 will be absent. Clients may cache this information in case their 1328 preferred LDAP server later becomes unavailable. 1330 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' 1331 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation ) 1333 The IA5 String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in 1334 [Syntaxes]. 1336 5.1.2. namingContexts 1338 The 'namingContexts' attribute lists the context prefixs of the naming 1339 contexts the server masters or shadows (in part or in whole). If the 1340 server does not master or shadow any information (e.g. it is an LDAP 1341 gateway to a public X.500 directory) this attribute will be absent. 1342 If the server believes it masters or shadows the entire directory, the 1343 attribute will have a single value, and that value will be the empty 1344 string (indicating the null DN of the root). This attribute allows a 1345 client to choose suitable base objects for searching when it has 1346 contacted a server. 1348 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' 1349 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation ) 1351 5.1.3. supportedControl 1353 The 'supportedControl' attribute lists object identifiers identifying 1354 the request controls the server supports. If the server does not 1355 support any request controls, this attribute will be absent. 1357 Object identifiers identifying response controls need not be listed. 1359 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' 1360 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) 1362 5.1.4. supportedExtension 1364 The 'supportedExtension' attribute lists object identifiers 1365 identifying the extended operations which the server supports. If the 1366 server does not support any extended operations, this attribute will 1367 be absent. 1369 An extended operation comprises a ExtendedRequest and an 1370 ExtendedResponse [Protocol]. The OID assigned to the ExtendedRequest 1371 is used to identify the extended operation. The OID of the 1372 ExtendedResponse, if assigned, need not be listed. 1374 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' 1375 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) 1377 5.1.5. supportedLDAPVersion 1379 The 'supportedLDAPVersion' attribute lists the versions of LDAP which 1380 the server supports. 1382 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' 1383 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation ) 1385 5.1.6. supportedSASLMechanisms 1387 The 'supportedSASLMechanisms' attribute lists the SASL mechanisms 1388 [RFC2222] which the server recognizes. The contents of this attribute 1389 may depend on the current session state. If the server does support 1390 any SASL mechanisms this attribute will not be present. 1392 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' 1393 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation ) 1395 5. Object Class Definitions 1397 5.1. 'top' 1399 This abstract object class is used as a superclass of all structural 1400 object classes. 1402 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 1404 5.2. 'extensibleObject' 1406 The 'extensibleObject object class allows entries belong to it to 1407 holds any attribute type. The set of allowed attributes of this class 1408 is implicitly the set of all user attribute types. 1410 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 1411 SUP top AUXILIARY ) 1413 The mandatory attributes of the other object classes of this entry are 1414 still required to be present and any precluded attributes are still 1415 not allowed to be present. 1417 Note that not all servers will implement this object class, and those 1418 which do not will reject requests to add entries which contain this 1419 object class, or modify an entry to add this object class. 1421 6. Other Considerations 1423 6.1. Preservation of User Information 1425 Syntaxes may be defined which have specific value and/or value form 1426 (representation) preservation requirements and may be restrict 1427 transfer to applicable modes. For example, a syntax containing 1428 digitally signed data can be defined with mandates requiring values be 1429 transferred using the ;binary option and that the server preserve both 1430 the value and form of value presented to ensure signature is not 1431 invalidated. 1433 Where such requirements have not be explicitly stated, servers SHOULD 1434 preserve the value of user information but MAY return the value in a 1435 different form. Where a server is unable (or unwilling) to preserve 1436 the value of user information, the server SHALL ensure that an 1437 equivalent value is returned. Two values are considered equivalent 1438 would match according to the equality matching rule of the associated 1439 attribute as evaluated (within variances allowed by the rule's 1440 specification) on that server. If the attribute is defined with no 1441 matching rule, two values are equivalent only if and only if they are 1442 identical. 1444 6.2. Short Names 1446 Short names (descriptors) used to identify various schema elements are 1447 non-unique, as two different specifications (neither in standards 1448 track RFCs) may choose the same name. The client can retrieve the 1449 subschema (as described above) to determine the element identified (in 1450 that subschema) by a particular short name. 1452 Schema designers SHOULD register names they choose [LDAPIANA]. 1454 6.3. Cache and Shadowing 1456 Some servers may hold cache or shadow copies of entries, which can be 1457 used to answer search and comparison queries, but will return 1458 referrals or contact other servers if modification operations are 1459 requested. 1461 Servers that perform shadowing or caching MUST ensure that they do not 1462 violate any access control constraints placed on the data by the 1463 originating server. 1465 7. Implementation Guidelines 1467 7.1 Server Guidelines 1469 Servers MUST recognize all attribute types and object classes defined 1470 in this document but, unless stated otherwise, need not support the 1471 associated functionality. 1473 Servers SHOULD recognize all the names of object classes defined in 1474 Section 7 of [Schema]. 1476 Servers MUST ensure that entries conform to user and system schema 1477 rules or other data model constraints. 1479 Servers MAY support DIT Content Rules, DIT Structural Rules, and/or 1480 Name Forms. To indicate support, servers MUST provide in the 1481 subschema the definitions of attribute types associated with the 1482 features they support. 1484 Servers MAY support aliases as defined in [X.501]. 1486 Servers MAY support subentries. If so, they MUST do so in accordance 1487 with [X.501]. Servers which do not support subenties SHOULD use 1488 object entries to mimic subentries as detailed in Section 3.4. 1490 Servers MAY support the 'extensibleObject' object class. To indicate 1491 support, servers MUST provide the 'extensibleObject' definition in the 1492 subschema. 1494 Servers MAY implement additional object classes. Servers SHOULD 1495 provide the definitions of all object classes they support in in 1496 subschema (sub)entries. 1498 7.2 Client Guidelines 1500 Clients MUST NOT display nor attempt to decode as ASN.1, a value if 1501 its syntax is not known. The implementation may attempt to discover 1502 the subschema of the source entry, and retrieve the values of 1503 'attributeTypes' from it. 1505 Clients MUST NOT send attribute values in a request that are not valid 1506 according to the syntax defined for the attributes. 1508 8. Security Considerations 1510 Attributes of directory entries are used to provide descriptive 1511 information about the real-world objects they represent, which can be 1512 people, organizations or devices. Most countries have privacy laws 1513 regarding the publication of information about people. 1515 9. Acknowledgments 1517 This document is based, in part, on [RFC2251] by M. Wahl, T. Howes, 1518 and S. Kille and [RFC2252] by M. Wahl, A. Coulbeck, T. Howes, S. 1519 Kille, both products of the IETF ASID Working Group. This document is 1520 also based, in part, on "The Directory: Models" [X.501], a product of 1521 the ITU. 1523 10. Author's Address 1525 Kurt Zeilenga 1526 E-mail: 1528 11. References 1530 11.1. Normative References 1532 [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and 1533 ISO 10646", RFC 2044, October 1996. 1535 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1536 Requirement Levels", RFC 2119, March 1997. 1538 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax 1539 Specifications: ABNF", RFC 2234, November 1997. 1541 [Roadmap] K. Zeilenga (editor), "LDAP: Technical Specification Road 1542 Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in 1543 progress. 1545 [Protocol] J. Sermersheim (editor), "LDAP: The Protocol", 1546 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 1548 [AuthMeth] R. Harrison (editor), "LDAP: Authentication Methods and 1549 Connection Level Security Mechanisms", 1550 draft-ietf-ldapbis-authmeth-xx.txt, a work in progress. 1552 [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of 1553 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 1554 in progress. 1556 [Filters] M. Smith (editor), LDAPbis WG, "LDAP: String Representation 1557 of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a 1558 work in progress. 1560 [LDAPURL] M. Smith (editor), "LDAP: Uniform Resource Locator", 1561 draft-ietf-ldapbis-url-xx.txt, a work in progress. 1563 [Syntaxes] K. Dally (editor), "LDAP: Syntaxes", 1564 draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress. 1566 [Schema] K. Dally (editor), "LDAP: User Schema", 1567 draft-ietf-ldapbis-user-schema-xx.txt, a work in progress. 1569 [LDAPIANA] K. Zeilenga, "IANA Considerations for LDAP", 1570 draft-ietf-ldapbis-xx.txt (a work in progress). 1572 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 1573 Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 1574 : 1993. 1576 [X.500] ITU-T Rec. X.500, "The Directory: Overview of Concepts, 1577 Models and Service", 1993. 1579 [X.501] ITU-T Rec. X.501, "The Directory: Models", 1993. 1581 [X.511] ITU-T Rec. X.511, "The Directory: Abstract Service 1582 Definition", 1993. 1584 [X.680] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1) - 1585 Specification of Basic Notation", 1994. 1587 11.2. Informative References 1589 [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access 1590 Protocol (v3)", RFC 2251, December 1997. 1592 [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight 1593 Directory Access Protocol (v3): Attribute Syntax 1594 Definitions", RFC 2252, December 1997. 1596 [LDAPTS] J. Hodges, R.L. Morgan, "Lightweight Directory Access 1597 Protocol (v3): Technical Specification", 1598 draft-ietf-ldapbis-ldapv3-ts-xx.txt. 1600 Appendix A. Changes to RFC 2251 / RFC 2252 1602 This appendix is non-normative. 1604 NOTE: This section is NOT COMPLETE. This will be corrected in a 1605 subsequent revision. 1607 This document amounts to nearly a complete rewrite of portions of RFC 1608 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve 1609 overall clarity of technical specification. This appendix provides a 1610 summary of substantive changes made to the portions of these documents 1611 incorporated into this document. Readers should consult [Roadmap], 1612 [Protocol], [Syntaxes], and [Schema] for summaries of remaining 1613 portions of these documents. 1615 A.1 Changes to RFC 2251 1617 This document incorporates from RFC 2251 sections 3.2 and 3.4, 1618 portions of Section 4 and 6 as summarized below. 1620 A.1.1 Section 3.2 of RFC 2251 1622 Section 3.2 of RFC 2251 provided a brief introduction to the X.500 1623 data model, as used by LDAP. The previous specification relied on 1624 [X.501] but lacked clarity in how X.500 models are adapted for use by 1625 LDAP. This document describes the X.500 data models, as used by LDAP 1626 in greater detail, especially in areas where the models require 1627 adaptation is needed. 1629 Section 3.2.1 of RFC 2251 described an attribute as "a type with one 1630 or more associated values." In LDAP, an attribute is better described 1631 as an attribute description, a type with zero or options, and one or 1632 more associated values. 1634 A.1.2 Section 3.4 of RFC 2251 1636 Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". 1637 This material, with changes, was incorporated in Section 5.1 of this 1638 document. 1640 Changes: 1642 - Clarify that attributes of the root DSE are subject to "other 1643 restrictions" in addition to acccess controls. 1645 - Clarify that only recognized extended requests need to be enumerated 1646 'supportedExtension'. 1648 - Clarify that only recognized request controls need to be enumerated 1649 'supportedControl'. 1651 - Clarify that root DSE attributes are operational and, like other 1652 operational attributes, will not be returned in search requests 1653 unless requested by name. 1655 - Clarify that not all root DSE attributes are user modifiable. 1657 - Remove inconsistent text regarding handling of the 1658 'subschemaSubentry' attribute within the root DSE. The previous 1659 specification stated that the 'subschemaSubentry' attribute held in 1660 the root DSE referred to "subschema entries (or subentries) known by 1661 this server." This is inconsistent with the attribute intended use 1662 as well as its formal definition as a single valued attribute 1663 [X.501]. It is also noted that a simple (possibly incomplete) list 1664 of subschema (sub)entries is not terrible useful. This document (in 1665 section 5.1) specifies that the 'subschemaSubentry' attribute of the 1666 root DSE refers to the subschema controlling the root DSE. It is 1667 noted that the general subschema discovery mechanism remains 1668 available (see Section 4.3 of this document). 1670 A.1.2 Section 4 of RFC 2251 1672 Portions of Section 4 of RFC 2251 detailing aspects of the information 1673 model used by LDAP were incorporated in this document, including: 1675 - Restriction of distinguished values to attributes whose descriptions 1676 have no options (from Section 4.1.3). 1678 - Data model aspects of Attribute Types (from Section 4.1.4), 1679 Attribute Descriptions (from 4.1.4), Attribute (from 4.1.8), 1680 Matching Rule Identifer (from 4.1.9). 1682 - User schema requirements (from Section 4.1.6, 4.5.1, and 4.7). 1684 A.1.3 Section 6 of RFC 2251 1686 The Section 6.1 and the section paragraph of section 6.2 of RFC 2251 1687 where incorporated into this document. 1689 A.2 Changes to RFC 2252 1691 This document incorporates from RFC 2252 Sections 4, 5 and 7. 1693 A.2.1 Section 4 of RFC 2252 1695 The specification was updated to use Augmented BNF [RFC2434]. The 1696 string representation of an OBJECT IDENTIFIER was tighten to 1697 disallow leading zeros as described in RFC 2252 text. 1699 The descr syntax was changed to disallow semicolon (U+0003B) 1700 characters to appear to be consistent its natural language 1701 specification "descr is the syntactic representation of an object 1702 descriptor, which consists of letters and digits, starting with a 1703 letter." In a related change, the statement "an AttributeDescription 1704 can be used as the value in a NAME part of an 1705 AttributeTypeDescription" was deleted. RFC 2252 provided no 1706 specification as to the semantics of options appearing in NAME 1707 fields. 1709 The ABNF for a quoted string (qdstring) was updated to reflect 1710 support for the eescaping mechanism described in 4.3 of RFC 2252. 1712 A.2.2 Section 5 of RFC 2252 1714 Definitions of operational attributes provided in Section 5 of RFC 1715 2252 where incorporated into this document. 1717 The supportedExtension description was clarified. A server need 1718 only list the OBJECT IDENTIFIERs associated with the extended 1719 requests of the extended operations it recongizes. 1721 The supportedControl description was clarified. A server need only 1722 list the OBJECT IDENTIFIERs associated with the request controls it 1723 recognizes. 1725 A.2.2 Section 7 of RFC 2252 1727 Section 7 of RFC 2252 provides definitions of the 'extensibleObject' 1728 and 'subschema' object classes. These definitions where integrated 1729 into Section 5.2 and Section 4.2 of this document, respectively. 1730 Section 7 of RFC 2252 also contained the standard object 1731 implementation requirement. This was incorporated into Section 7 of 1732 this document. 1734 A.3 Changes to RFC 2256 1736 This document incorporates Sections 5.1 and 7.1 of RFC 2256. 1738 Section 5.1 of RFC 2256 provided the definition of the 'objectClass' 1739 attribute type. This was integrated into Section 3.2 of this 1740 document. The statement "One of the values is either 'top' or 1741 'alias'" was replaced with statement that one of the values is 'top' 1742 as entries belonging to 'alias' also belong to 'top'. 1744 Section 7.1 of RFC 2256 provided the definition of the 'top' object 1745 class. This was integrated into Section 5.1 of this document. 1747 Copyright 2002, The Internet Society. All Rights Reserved. 1749 This document and translations of it may be copied and furnished to 1750 others, and derivative works that comment on or otherwise explain it 1751 or assist in its implementation may be prepared, copied, published and 1752 distributed, in whole or in part, without restriction of any kind, 1753 provided that the above copyright notice and this paragraph are 1754 included on all such copies and derivative works. However, this 1755 document itself may not be modified in any way, such as by removing 1756 the copyright notice or references to the Internet Society or other 1757 Internet organizations, except as needed for the purpose of 1758 developing Internet standards in which case the procedures for 1759 copyrights defined in the Internet Standards process must be followed, 1760 or as required to translate it into languages other than English. 1762 The limited permissions granted above are perpetual and will not be 1763 revoked by the Internet Society or its successors or assigns. 1765 This document and the information contained herein is provided on an 1766 "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET 1767 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 1768 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1769 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1770 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.