1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 4512 OpenLDAP Foundation 9Obsoletes: 2251, 2252, 2256, 3674 June 2006 10Category: Standards Track 11 12 13 Lightweight Directory Access Protocol (LDAP): 14 Directory Information Models 15 16Status of This Memo 17 18 This document specifies an Internet standards track protocol for the 19 Internet community, and requests discussion and suggestions for 20 improvements. Please refer to the current edition of the "Internet 21 Official Protocol Standards" (STD 1) for the standardization state 22 and status of this protocol. Distribution of this memo is unlimited. 23 24Copyright Notice 25 26 Copyright (C) The Internet Society (2006). 27 28Abstract 29 30 The Lightweight Directory Access Protocol (LDAP) is an Internet 31 protocol for accessing distributed directory services that act in 32 accordance with X.500 data and service models. This document 33 describes the X.500 Directory Information Models, as used in LDAP. 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58Zeilenga Standards Track [Page 1] 59 60RFC 4512 LDAP Models June 2006 61 62 63Table of Contents 64 65 1. Introduction ....................................................3 66 1.1. Relationship to Other LDAP Specifications ..................3 67 1.2. Relationship to X.501 ......................................4 68 1.3. Conventions ................................................4 69 1.4. Common ABNF Productions ....................................4 70 2. Model of Directory User Information .............................6 71 2.1. The Directory Information Tree .............................7 72 2.2. Structure of an Entry ......................................7 73 2.3. Naming of Entries ..........................................8 74 2.4. Object Classes .............................................9 75 2.5. Attribute Descriptions ....................................12 76 2.6. Alias Entries .............................................16 77 3. Directory Administrative and Operational Information ...........17 78 3.1. Subtrees ..................................................17 79 3.2. Subentries ................................................18 80 3.3. The 'objectClass' attribute ...............................18 81 3.4. Operational Attributes ....................................19 82 4. Directory Schema ...............................................22 83 4.1. Schema Definitions ........................................23 84 4.2. Subschema Subentries ......................................32 85 4.3. 'extensibleObject' object class ...........................35 86 4.4. Subschema Discovery .......................................35 87 5. DSA (Server) Informational Model ...............................36 88 5.1. Server-Specific Data Requirements .........................36 89 6. Other Considerations ...........................................40 90 6.1. Preservation of User Information ..........................40 91 6.2. Short Names ...............................................41 92 6.3. Cache and Shadowing .......................................41 93 7. Implementation Guidelines ......................................42 94 7.1. Server Guidelines .........................................42 95 7.2. Client Guidelines .........................................42 96 8. Security Considerations ........................................43 97 9. IANA Considerations ............................................43 98 10. Acknowledgements ..............................................44 99 11. Normative References ..........................................45 100 Appendix A. Changes ...............................................47 101 A.1. Changes to RFC 2251 .......................................47 102 A.2. Changes to RFC 2252 .......................................49 103 A.3. Changes to RFC 2256 .......................................50 104 A.4. Changes to RFC 3674 .......................................51 105 106 107 108 109 110 111 112 113 114Zeilenga Standards Track [Page 2] 115 116RFC 4512 LDAP Models June 2006 117 118 1191. Introduction 120 121 This document discusses the X.500 Directory Information Models 122 [X.501], as used by the Lightweight Directory Access Protocol (LDAP) 123 [RFC4510]. 124 125 The Directory is "a collection of open systems cooperating to provide 126 directory services" [X.500]. The information held in the Directory 127 is collectively known as the Directory Information Base (DIB). A 128 Directory user, which may be a human or other entity, accesses the 129 Directory through a client (or Directory User Agent (DUA)). The 130 client, on behalf of the directory user, interacts with one or more 131 servers (or Directory System Agents (DSA)). A server holds a 132 fragment of the DIB. 133 134 The DIB contains two classes of information: 135 136 1) user information (e.g., information provided and administrated 137 by users). Section 2 describes the Model of User Information. 138 139 2) administrative and operational information (e.g., information 140 used to administer and/or operate the directory). Section 3 141 describes the model of Directory Administrative and Operational 142 Information. 143 144 These two models, referred to as the generic Directory Information 145 Models, describe how information is represented in the Directory. 146 These generic models provide a framework for other information 147 models. Section 4 discusses the subschema information model and 148 subschema discovery. Section 5 discusses the DSA (Server) 149 Informational Model. 150 151 Other X.500 information models (such as access control distribution 152 knowledge and replication knowledge information models) may be 153 adapted for use in LDAP. Specification of how these models apply to 154 LDAP is left to future documents. 155 1561.1. Relationship to Other LDAP Specifications 157 158 This document is a integral part of the LDAP technical specification 159 [RFC4510], which obsoletes the previously defined LDAP technical 160 specification, RFC 3377, in its entirety. 161 162 This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as 163 portions of Sections 4 and 6. Appendix A.1 summarizes changes to 164 these sections. The remainder of RFC 2251 is obsoleted by the 165 [RFC4511], [RFC4513], and [RFC4510] documents. 166 167 168 169 170Zeilenga Standards Track [Page 3] 171 172RFC 4512 LDAP Models June 2006 173 174 175 This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2 176 summarizes changes to these sections. The remainder of RFC 2252 is 177 obsoleted by [RFC4517]. 178 179 This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2. 180 Appendix A.3 summarizes changes to these sections. The remainder of 181 RFC 2256 is obsoleted by [RFC4519] and [RFC4517]. 182 183 This document obsoletes RFC 3674 in its entirety. Appendix A.4 184 summarizes changes since RFC 3674. 185 1861.2. Relationship to X.501 187 188 This document includes material, with and without adaptation, from 189 [X.501] as necessary to describe this protocol. These adaptations 190 (and any other differences herein) apply to this protocol, and only 191 this protocol. 192 1931.3. Conventions 194 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in BCP 14 [RFC2119]. 198 199 Schema definitions are provided using LDAP description formats (as 200 defined in Section 4.1). Definitions provided here are formatted 201 (line wrapped) for readability. Matching rules and LDAP syntaxes 202 referenced in these definitions are specified in [RFC4517]. 203 2041.4. Common ABNF Productions 205 206 A number of syntaxes in this document are described using Augmented 207 Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a 208 number of syntaxes defined in other documents) rely on the following 209 common productions: 210 211 keystring = leadkeychar *keychar 212 leadkeychar = ALPHA 213 keychar = ALPHA / DIGIT / HYPHEN 214 number = DIGIT / ( LDIGIT 1*DIGIT ) 215 216 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 217 DIGIT = %x30 / LDIGIT ; "0"-"9" 218 LDIGIT = %x31-39 ; "1"-"9" 219 HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f" 220 221 SP = 1*SPACE ; one or more " " 222 WSP = 0*SPACE ; zero or more " " 223 224 225 226Zeilenga Standards Track [Page 4] 227 228RFC 4512 LDAP Models June 2006 229 230 231 NULL = %x00 ; null (0) 232 SPACE = %x20 ; space (" ") 233 DQUOTE = %x22 ; quote (""") 234 SHARP = %x23 ; octothorpe (or sharp sign) ("#") 235 DOLLAR = %x24 ; dollar sign ("$") 236 SQUOTE = %x27 ; single quote ("'") 237 LPAREN = %x28 ; left paren ("(") 238 RPAREN = %x29 ; right paren (")") 239 PLUS = %x2B ; plus sign ("+") 240 COMMA = %x2C ; comma (",") 241 HYPHEN = %x2D ; hyphen ("-") 242 DOT = %x2E ; period (".") 243 SEMI = %x3B ; semicolon (";") 244 LANGLE = %x3C ; left angle bracket ("<") 245 EQUALS = %x3D ; equals sign ("=") 246 RANGLE = %x3E ; right angle bracket (">") 247 ESC = %x5C ; backslash ("\") 248 USCORE = %x5F ; underscore ("_") 249 LCURLY = %x7B ; left curly brace "{" 250 RCURLY = %x7D ; right curly brace "}" 251 252 ; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character 253 UTF8 = UTF1 / UTFMB 254 UTFMB = UTF2 / UTF3 / UTF4 255 UTF0 = %x80-BF 256 UTF1 = %x00-7F 257 UTF2 = %xC2-DF UTF0 258 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / 259 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) 260 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / 261 %xF4 %x80-8F 2(UTF0) 262 263 OCTET = %x00-FF ; Any octet (8-bit data unit) 264 265 Object identifiers (OIDs) [X.680] are represented in LDAP using a 266 dot-decimal format conforming to the ABNF: 267 268 numericoid = number 1*( DOT number ) 269 270 Short names, also known as descriptors, are used as more readable 271 aliases for object identifiers. Short names are case insensitive and 272 conform to the ABNF: 273 274 descr = keystring 275 276 277 278 279 280 281 282Zeilenga Standards Track [Page 5] 283 284RFC 4512 LDAP Models June 2006 285 286 287 Where either an object identifier or a short name may be specified, 288 the following production is used: 289 290 oid = descr / numericoid 291 292 While the <descr> form is generally preferred when the usage is 293 restricted to short names referring to object identifiers that 294 identify like kinds of objects (e.g., attribute type descriptions, 295 matching rule descriptions, object class descriptions), the 296 <numericoid> form should be used when the object identifiers may 297 identify multiple kinds of objects or when an unambiguous short name 298 (descriptor) is not available. 299 300 Implementations SHOULD treat short names (descriptors) used in an 301 ambiguous manner (as discussed above) as unrecognized. 302 303 Short Names (descriptors) are discussed further in Section 6.2. 304 3052. Model of Directory User Information 306 307 As [X.501] states: 308 309 The purpose of the Directory is to hold, and provide access to, 310 information about objects of interest (objects) in some 'world'. 311 An object can be anything which is identifiable (can be named). 312 313 An object class is an identified family of objects, or conceivable 314 objects, which share certain characteristics. Every object 315 belongs to at least one class. An object class may be a subclass 316 of other object classes, in which case the members of the former 317 class, the subclass, are also considered to be members of the 318 latter classes, the superclasses. There may be subclasses of 319 subclasses, etc., to an arbitrary depth. 320 321 A directory entry, a named collection of information, is the basic 322 unit of information held in the Directory. There are multiple kinds 323 of directory entries. 324 325 An object entry represents a particular object. An alias entry 326 provides alternative naming. A subentry holds administrative and/or 327 operational information. 328 329 The set of entries representing the DIB are organized hierarchically 330 in a tree structure known as the Directory Information Tree (DIT). 331 332 Section 2.1 describes the Directory Information Tree. 333 Section 2.2 discusses the structure of entries. 334 Section 2.3 discusses naming of entries. 335 336 337 338Zeilenga Standards Track [Page 6] 339 340RFC 4512 LDAP Models June 2006 341 342 343 Section 2.4 discusses object classes. 344 Section 2.5 discusses attribute descriptions. 345 Section 2.6 discusses alias entries. 346 3472.1. The Directory Information Tree 348 349 As noted above, the DIB is composed of a set of entries organized 350 hierarchically in a tree structure known as the Directory Information 351 Tree (DIT); specifically, a tree where vertices are the entries. 352 353 The arcs between vertices define relations between entries. If an 354 arc exists from X to Y, then the entry at X is the immediate superior 355 of Y, and Y is the immediate subordinate of X. An entry's superiors 356 are the entry's immediate superior and its superiors. An entry's 357 subordinates are all of its immediate subordinates and their 358 subordinates. 359 360 Similarly, the superior/subordinate relationship between object 361 entries can be used to derive a relation between the objects they 362 represent. DIT structure rules can be used to govern relationships 363 between objects. 364 365 Note: An entry's immediate superior is also known as the entry's 366 parent, and an entry's immediate subordinate is also known as 367 the entry's child. Entries that have the same parent are known 368 as siblings. 369 3702.2. Structure of an Entry 371 372 An entry consists of a set of attributes that hold information about 373 the object that the entry represents. Some attributes represent user 374 information and are called user attributes. Other attributes 375 represent operational and/or administrative information and are 376 called operational attributes. 377 378 An attribute is an attribute description (a type and zero or more 379 options) with one or more associated values. An attribute is often 380 referred to by its attribute description. For example, the 381 'givenName' attribute is the attribute that consists of the attribute 382 description 'givenName' (the 'givenName' attribute type [RFC4519] and 383 zero options) and one or more associated values. 384 385 The attribute type governs whether the attribute can have multiple 386 values, the syntax and matching rules used to construct and compare 387 values of that attribute, and other functions. Options indicate 388 subtypes and other functions. 389 390 Attribute values conform to the defined syntax of the attribute type. 391 392 393 394Zeilenga Standards Track [Page 7] 395 396RFC 4512 LDAP Models June 2006 397 398 399 No two values of an attribute may be equivalent. Two values are 400 considered equivalent if and only if they would match according to 401 the equality matching rule of the attribute type. Or, if the 402 attribute type is defined with no equality matching rule, two values 403 are equivalent if and only if they are identical. (See 2.5.1 for 404 other restrictions.) 405 406 For example, a 'givenName' attribute can have more than one value, 407 they must be Directory Strings, and they are case insensitive. A 408 'givenName' attribute cannot hold both "John" and "JOHN", as these 409 are equivalent values per the equality matching rule of the attribute 410 type. 411 412 Additionally, no attribute is to have a value that is not equivalent 413 to itself. For example, the 'givenName' attribute cannot have as a 414 value a directory string that includes the REPLACEMENT CHARACTER 415 (U+FFFD) code point, as matching involving that directory string is 416 Undefined per this attribute's equality matching rule. 417 418 When an attribute is used for naming of the entry, one and only one 419 value of the attribute is used in forming the Relative Distinguished 420 Name. This value is known as a distinguished value. 421 4222.3. Naming of Entries 423 4242.3.1. Relative Distinguished Names 425 426 Each entry is named relative to its immediate superior. This 427 relative name, known as its Relative Distinguished Name (RDN) 428 [X.501], is composed of an unordered set of one or more attribute 429 value assertions (AVA) consisting of an attribute description with 430 zero options and an attribute value. These AVAs are chosen to match 431 attribute values (each a distinguished value) of the entry. 432 433 An entry's relative distinguished name must be unique among all 434 immediate subordinates of the entry's immediate superior (i.e., all 435 siblings). 436 437 The following are examples of string representations of RDNs 438 [RFC4514]: 439 440 UID=12345 441 OU=Engineering 442 CN=Kurt Zeilenga+L=Redwood Shores 443 444 The last is an example of a multi-valued RDN; that is, an RDN 445 composed of multiple AVAs. 446 447 448 449 450Zeilenga Standards Track [Page 8] 451 452RFC 4512 LDAP Models June 2006 453 454 4552.3.2. Distinguished Names 456 457 An entry's fully qualified name, known as its Distinguished Name (DN) 458 [X.501], is the concatenation of its RDN and its immediate superior's 459 DN. A Distinguished Name unambiguously refers to an entry in the 460 tree. The following are examples of string representations of DNs 461 [RFC4514]: 462 463 UID=nobody@example.com,DC=example,DC=com 464 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US 465 4662.3.3. Alias Names 467 468 An alias, or alias name, is "an name for an object, provided by the 469 use of alias entries" [X.501]. Alias entries are described in 470 Section 2.6. 471 4722.4. Object Classes 473 474 An object class is "an identified family of objects (or conceivable 475 objects) that share certain characteristics" [X.501]. 476 477 As defined in [X.501]: 478 479 Object classes are used in the Directory for a number of purposes: 480 481 - describing and categorizing objects and the entries that 482 correspond to these objects; 483 484 - where appropriate, controlling the operation of the Directory; 485 486 - regulating, in conjunction with DIT structure rule 487 specifications, the position of entries in the DIT; 488 489 - regulating, in conjunction with DIT content rule 490 specifications, the attributes that are contained in entries; 491 492 - identifying classes of entry that are to be associated with a 493 particular policy by the appropriate administrative authority. 494 495 An object class (a subclass) may be derived from an object class 496 (its direct superclass) which is itself derived from an even more 497 generic object class. For structural object classes, this process 498 stops at the most generic object class, 'top' (defined in Section 499 2.4.1). An ordered set of superclasses up to the most superior 500 object class of an object class is its superclass chain. 501 502 503 504 505 506Zeilenga Standards Track [Page 9] 507 508RFC 4512 LDAP Models June 2006 509 510 511 An object class may be derived from two or more direct 512 superclasses (superclasses not part of the same superclass chain). 513 This feature of subclassing is termed multiple inheritance. 514 515 Each object class identifies the set of attributes required to be 516 present in entries belonging to the class and the set of attributes 517 allowed to be present in entries belonging to the class. As an entry 518 of a class must meet the requirements of each class it belongs to, it 519 can be said that an object class inherits the sets of allowed and 520 required attributes from its superclasses. A subclass can identify 521 an attribute allowed by its superclass as being required. If an 522 attribute is a member of both sets, it is required to be present. 523 524 Each object class is defined to be one of three kinds of object 525 classes: Abstract, Structural, or Auxiliary. 526 527 Each object class is identified by an object identifier (OID) and, 528 optionally, one or more short names (descriptors). 529 5302.4.1. Abstract Object Classes 531 532 An abstract object class, as the name implies, provides a base of 533 characteristics from which other object classes can be defined to 534 inherit from. An entry cannot belong to an abstract object class 535 unless it belongs to a structural or auxiliary class that inherits 536 from that abstract class. 537 538 Abstract object classes cannot derive from structural or auxiliary 539 object classes. 540 541 All structural object classes derive (directly or indirectly) from 542 the 'top' abstract object class. Auxiliary object classes do not 543 necessarily derive from 'top'. 544 545 The following is the object class definition (see Section 4.1.1) for 546 the 'top' object class: 547 548 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 549 550 All entries belong to the 'top' abstract object class. 551 552 553 554 555 556 557 558 559 560 561 562Zeilenga Standards Track [Page 10] 563 564RFC 4512 LDAP Models June 2006 565 566 5672.4.2. Structural Object Classes 568 569 As stated in [X.501]: 570 571 An object class defined for use in the structural specification of 572 the DIT is termed a structural object class. Structural object 573 classes are used in the definition of the structure of the names 574 of the objects for compliant entries. 575 576 An object or alias entry is characterized by precisely one 577 structural object class superclass chain which has a single 578 structural object class as the most subordinate object class. 579 This structural object class is referred to as the structural 580 object class of the entry. 581 582 Structural object classes are related to associated entries: 583 584 - an entry conforming to a structural object class shall 585 represent the real-world object constrained by the object 586 class; 587 588 - DIT structure rules only refer to structural object classes; 589 the structural object class of an entry is used to specify the 590 position of the entry in the DIT; 591 592 - the structural object class of an entry is used, along with an 593 associated DIT content rule, to control the content of an 594 entry. 595 596 The structural object class of an entry shall not be changed. 597 598 Each structural object class is a (direct or indirect) subclass of 599 the 'top' abstract object class. 600 601 Structural object classes cannot subclass auxiliary object classes. 602 603 Each entry is said to belong to its structural object class as well 604 as all classes in its structural object class's superclass chain. 605 6062.4.3. Auxiliary Object Classes 607 608 Auxiliary object classes are used to augment the characteristics of 609 entries. They are commonly used to augment the sets of attributes 610 required and allowed to be present in an entry. They can be used to 611 describe entries or classes of entries. 612 613 Auxiliary object classes cannot subclass structural object classes. 614 615 616 617 618Zeilenga Standards Track [Page 11] 619 620RFC 4512 LDAP Models June 2006 621 622 623 An entry can belong to any subset of the set of auxiliary object 624 classes allowed by the DIT content rule associated with the 625 structural object class of the entry. If no DIT content rule is 626 associated with the structural object class of the entry, the entry 627 cannot belong to any auxiliary object class. 628 629 The set of auxiliary object classes that an entry belongs to can 630 change over time. 631 6322.5. Attribute Descriptions 633 634 An attribute description is composed of an attribute type (see 635 Section 2.5.1) and a set of zero or more attribute options (see 636 Section 2.5.2). 637 638 An attribute description is represented by the ABNF: 639 640 attributedescription = attributetype options 641 attributetype = oid 642 options = *( SEMI option ) 643 option = 1*keychar 644 645 where <attributetype> identifies the attribute type and each <option> 646 identifies an attribute option. Both <attributetype> and <option> 647 productions are case insensitive. The order in which <option>s 648 appear is irrelevant. That is, any two <attributedescription>s that 649 consist of the same <attributetype> and same set of <option>s are 650 equivalent. 651 652 Examples of valid attribute descriptions: 653 654 2.5.4.0 655 cn;lang-de;lang-en 656 owner 657 658 An attribute description with an unrecognized attribute type is to be 659 treated as unrecognized. Servers SHALL treat an attribute 660 description with an unrecognized attribute option as unrecognized. 661 Clients MAY treat an unrecognized attribute option as a tagging 662 option (see Section 2.5.2.1). 663 664 All attributes of an entry must have distinct attribute descriptions. 665 6662.5.1. Attribute Types 667 668 An attribute type governs whether the attribute can have multiple 669 values, the syntax and matching rules used to construct and compare 670 values of that attribute, and other functions. 671 672 673 674Zeilenga Standards Track [Page 12] 675 676RFC 4512 LDAP Models June 2006 677 678 679 If no equality matching is specified for the attribute type: 680 681 - the attribute (of the type) cannot be used for naming; 682 - when adding the attribute (or replacing all values), no two 683 values may be equivalent (see 2.2); 684 - individual values of a multi-valued attribute are not to be 685 independently added or deleted; 686 - attribute value assertions (such as matching in search filters 687 and comparisons) using values of such a type cannot be 688 performed. 689 690 Otherwise, the specified equality matching rule is to be used to 691 evaluate attribute value assertions concerning the attribute type. 692 The specified equality rule is to be transitive and commutative. 693 694 The attribute type indicates whether the attribute is a user 695 attribute or an operational attribute. If operational, the attribute 696 type indicates the operational usage and whether or not the attribute 697 is modifiable by users. Operational attributes are discussed in 698 Section 3.4. 699 700 An attribute type (a subtype) may derive from a more generic 701 attribute type (a direct supertype). The following restrictions 702 apply to subtyping: 703 704 - a subtype must have the same usage as its direct supertype, 705 - a subtype's syntax must be the same, or a refinement of, its 706 supertype's syntax, and 707 - a subtype must be collective [RFC3671] if its supertype is 708 collective. 709 710 An attribute description consisting of a subtype and no options is 711 said to be the direct description subtype of the attribute 712 description consisting of the subtype's direct supertype and no 713 options. 714 715 Each attribute type is identified by an object identifier (OID) and, 716 optionally, one or more short names (descriptors). 717 7182.5.2. Attribute Options 719 720 There are multiple kinds of attribute description options. The LDAP 721 technical specification details one kind: tagging options. 722 723 Not all options can be associated with attributes held in the 724 directory. Tagging options can be. 725 726 727 728 729 730Zeilenga Standards Track [Page 13] 731 732RFC 4512 LDAP Models June 2006 733 734 735 Not all options can be used in conjunction with all attribute types. 736 In such cases, the attribute description is to be treated as 737 unrecognized. 738 739 An attribute description that contains mutually exclusive options 740 shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where 741 "x-foo" and "x-bar" are mutually exclusive, is to be treated as 742 unrecognized. 743 744 Other kinds of options may be specified in future documents. These 745 documents must detail how new kinds of options they define relate to 746 tagging options. In particular, these documents must detail whether 747 or not new kinds of options can be associated with attributes held in 748 the directory, how new kinds of options affect transfer of attribute 749 values, and how new kinds of options are treated in attribute 750 description hierarchies. 751 752 Options are represented as short, case-insensitive textual strings 753 conforming to the <option> production defined in Section 2.5 of this 754 document. 755 756 Procedures for registering options are detailed in BCP 64, RFC 4520 757 [RFC4520]. 758 7592.5.2.1. Tagging Options 760 761 Attributes held in the directory can have attribute descriptions with 762 any number of tagging options. Tagging options are never mutually 763 exclusive. 764 765 An attribute description with N tagging options is a direct 766 (description) subtype of all attribute descriptions of the same 767 attribute type and all but one of the N options. If the attribute 768 type has a supertype, then the attribute description is also a direct 769 (description) subtype of the attribute description of the supertype 770 and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct 771 (description) subtype of 'cn;lang-de', 'cn;lang-en', and 772 'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined 773 in [RFC4519]). 774 7752.5.3. Attribute Description Hierarchies 776 777 An attribute description can be the direct subtype of zero or more 778 other attribute descriptions as indicated by attribute type subtyping 779 (as described in Section 2.5.1) or attribute tagging option subtyping 780 (as described in Section 2.5.2.1). These subtyping relationships are 781 used to form hierarchies of attribute descriptions and attributes. 782 783 784 785 786Zeilenga Standards Track [Page 14] 787 788RFC 4512 LDAP Models June 2006 789 790 791 As adapted from [X.501]: 792 793 Attribute hierarchies allow access to the DIB with varying degrees 794 of granularity. This is achieved by allowing the value components 795 of attributes to be accessed by using either their specific 796 attribute description (a direct reference to the attribute) or a 797 more generic attribute description (an indirect reference). 798 799 Semantically related attributes may be placed in a hierarchical 800 relationship, the more specialized being placed subordinate to the 801 more generalized. Searching for or retrieving attributes and 802 their values is made easier by quoting the more generalized 803 attribute description; a filter item so specified is evaluated for 804 the more specialized descriptions as well as for the quoted 805 description. 806 807 Where subordinate specialized descriptions are selected to be 808 returned as part of a search result these descriptions shall be 809 returned if available. Where the more general descriptions are 810 selected to be returned as part of a search result both the 811 general and the specialized descriptions shall be returned, if 812 available. An attribute value shall always be returned as a value 813 of its own attribute description. 814 815 All of the attribute descriptions in an attribute hierarchy are 816 treated as distinct and unrelated descriptions for user 817 modification of entry content. 818 819 An attribute value stored in an object or alias entry is of 820 precisely one attribute description. The description is indicated 821 when the value is originally added to the entry. 822 823 For the purpose of subschema administration of the entry, a 824 specification that an attribute is required is fulfilled if the entry 825 contains a value of an attribute description belonging to an 826 attribute hierarchy where the attribute type of that description is 827 the same as the required attribute's type. That is, a "MUST name" 828 specification is fulfilled by 'name' or 'name;x-tag-option', but is 829 not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a 830 subtype of 'name'). Likewise, an entry may contain a value of an 831 attribute description belonging to an attribute hierarchy where the 832 attribute type of that description is either explicitly included in 833 the definition of an object class to which the entry belongs or 834 allowed by the DIT content rule applicable to that entry. That is, 835 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST 836 name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" 837 (or by "MUST name"). 838 839 840 841 842Zeilenga Standards Track [Page 15] 843 844RFC 4512 LDAP Models June 2006 845 846 847 For the purposes of other policy administration, unless stated 848 otherwise in the specification of the particular administrative 849 model, all of the attribute descriptions in an attribute hierarchy 850 are treated as distinct and unrelated descriptions. 851 8522.6. Alias Entries 853 854 As adapted from [X.501]: 855 856 An alias, or an alias name, for an object is an alternative name 857 for an object or object entry which is provided by the use of 858 alias entries. 859 860 Each alias entry contains, within the 'aliasedObjectName' 861 attribute (known as the 'aliasedEntryName' attribute in X.500), a 862 name of some object. The distinguished name of the alias entry is 863 thus also a name for this object. 864 865 NOTE - The name within the 'aliasedObjectName' is said to be 866 pointed to by the alias. It does not have to be the 867 distinguished name of any entry. 868 869 The conversion of an alias name to an object name is termed 870 (alias) dereferencing and comprises the systematic replacement of 871 alias names, where found within a purported name, by the value of 872 the corresponding 'aliasedObjectName' attribute. The process may 873 require the examination of more than one alias entry. 874 875 Any particular entry in the DIT may have zero or more alias names. 876 It therefore follows that several alias entries may point to the 877 same entry. An alias entry may point to an entry that is not a 878 leaf entry and may point to another alias entry. 879 880 An alias entry shall have no subordinates, so that an alias entry 881 is always a leaf entry. 882 883 Every alias entry shall belong to the 'alias' object class. 884 885 An entry with the 'alias' object class must also belong to an object 886 class (or classes), or be governed by a DIT content rule, which 887 allows suitable naming attributes to be present. 888 889 Example: 890 891 dn: cn=bar,dc=example,dc=com 892 objectClass: top 893 objectClass: alias 894 objectClass: extensibleObject 895 896 897 898Zeilenga Standards Track [Page 16] 899 900RFC 4512 LDAP Models June 2006 901 902 903 cn: bar 904 aliasedObjectName: cn=foo,dc=example,dc=com 905 9062.6.1. 'alias' Object Class 907 908 Alias entries belong to the 'alias' object class. 909 910 ( 2.5.6.1 NAME 'alias' 911 SUP top STRUCTURAL 912 MUST aliasedObjectName ) 913 9142.6.2. 'aliasedObjectName' Attribute Type 915 916 The 'aliasedObjectName' attribute holds the name of the entry an 917 alias points to. The 'aliasedObjectName' attribute is known as the 918 'aliasedEntryName' attribute in X.500. 919 920 ( 2.5.4.1 NAME 'aliasedObjectName' 921 EQUALITY distinguishedNameMatch 922 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 923 SINGLE-VALUE ) 924 925 The 'distinguishedNameMatch' matching rule and the DistinguishedName 926 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. 927 9283. Directory Administrative and Operational Information 929 930 This section discusses select aspects of the X.500 Directory 931 Administrative and Operational Information model [X.501]. LDAP 932 implementations MAY support other aspects of this model. 933 9343.1. Subtrees 935 936 As defined in [X.501]: 937 938 A subtree is a collection of object and alias entries situated at 939 the vertices of a tree. Subtrees do not contain subentries. The 940 prefix sub, in subtree, emphasizes that the base (or root) vertex 941 of this tree is usually subordinate to the root of the DIT. 942 943 A subtree begins at some vertex and extends to some identifiable 944 lower boundary, possibly extending to leaves. A subtree is always 945 defined within a context which implicitly bounds the subtree. For 946 example, the vertex and lower boundaries of a subtree defining a 947 replicated area are bounded by a naming context. 948 949 950 951 952 953 954Zeilenga Standards Track [Page 17] 955 956RFC 4512 LDAP Models June 2006 957 958 9593.2. Subentries 960 961 A subentry is a "special sort of entry, known by the Directory, used 962 to hold information associated with a subtree or subtree refinement" 963 [X.501]. Subentries are used in Directory to hold for administrative 964 and operational purposes as defined in [X.501]. Their use in LDAP is 965 detailed in [RFC3672]. 966 967 The term "(sub)entry" in this specification indicates that servers 968 implementing X.500(93) models are, in accordance with X.500(93) as 969 described in [RFC3672], to use a subentry and that other servers are 970 to use an object entry belonging to the appropriate auxiliary class 971 normally used with the subentry (e.g., 'subschema' for subschema 972 subentries) to mimic the subentry. This object entry's RDN SHALL be 973 formed from a value of the 'cn' (commonName) attribute [RFC4519] (as 974 all subentries are named with 'cn'). 975 9763.3. The 'objectClass' attribute 977 978 Each entry in the DIT has an 'objectClass' attribute. 979 980 ( 2.5.4.0 NAME 'objectClass' 981 EQUALITY objectIdentifierMatch 982 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 983 984 The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER 985 (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517]. 986 987 The 'objectClass' attribute specifies the object classes of an entry, 988 which (among other things) are used in conjunction with the 989 controlling schema to determine the permitted attributes of an entry. 990 Values of this attribute can be modified by clients, but the 991 'objectClass' attribute cannot be removed. 992 993 Servers that follow X.500(93) models SHALL restrict modifications of 994 this attribute to prevent the basic structural class of the entry 995 from being changed. That is, one cannot change a 'person' into a 996 'country'. 997 998 When creating an entry or adding an 'objectClass' value to an entry, 999 all superclasses of the named classes SHALL be implicitly added as 1000 well if not already present. That is, if the auxiliary class 'x-a' 1001 is a subclass of the class 'x-b', adding 'x-a' to 'objectClass' 1002 causes 'x-b' to be implicitly added (if is not already present). 1003 1004 Servers SHALL restrict modifications of this attribute to prevent 1005 superclasses of remaining 'objectClass' values from being deleted. 1006 That is, if the auxiliary class 'x-a' is a subclass of the auxiliary 1007 1008 1009 1010Zeilenga Standards Track [Page 18] 1011 1012RFC 4512 LDAP Models June 2006 1013 1014 1015 class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b', 1016 an attempt to delete only 'x-b' from the 'objectClass' attribute is 1017 an error. 1018 10193.4. Operational Attributes 1020 1021 Some attributes, termed operational attributes, are used or 1022 maintained by servers for administrative and operational purposes. 1023 As stated in [X.501]: "There are three varieties of operational 1024 attributes: Directory operational attributes, DSA-shared operational 1025 attributes, and DSA-specific operational attributes". 1026 1027 A directory operational attribute is used to represent operational 1028 and/or administrative information in the Directory Information Model. 1029 This includes operational attributes maintained by the server (e.g., 1030 'createTimestamp') as well as operational attributes that hold values 1031 administrated by the user (e.g., 'ditContentRules'). 1032 1033 A DSA-shared operational attribute is used to represent information 1034 of the DSA Information Model that is shared between DSAs. 1035 1036 A DSA-specific operational attribute is used to represent information 1037 of the DSA Information Model that is specific to the DSA (though, in 1038 some cases, may be derived from information shared between DSAs; 1039 e.g., 'namingContexts'). 1040 1041 The DSA Information Model operational attributes are detailed in 1042 [X.501]. 1043 1044 Operational attributes are not normally visible. They are not 1045 returned in search results unless explicitly requested by name. 1046 1047 Not all operational attributes are user modifiable. 1048 1049 Entries may contain, among others, the following operational 1050 attributes: 1051 1052 - creatorsName: the Distinguished Name of the user who added this 1053 entry to the directory, 1054 1055 - createTimestamp: the time this entry was added to the directory, 1056 1057 - modifiersName: the Distinguished Name of the user who last 1058 modified this entry, and 1059 1060 - modifyTimestamp: the time this entry was last modified. 1061 1062 1063 1064 1065 1066Zeilenga Standards Track [Page 19] 1067 1068RFC 4512 LDAP Models June 2006 1069 1070 1071 Servers SHOULD maintain the 'creatorsName', 'createTimestamp', 1072 'modifiersName', and 'modifyTimestamp' attributes for all entries of 1073 the DIT. 1074 10753.4.1. 'creatorsName' 1076 1077 This attribute appears in entries that were added using the protocol 1078 (e.g., using the Add operation). The value is the distinguished name 1079 of the creator. 1080 1081 ( 2.5.18.3 NAME 'creatorsName' 1082 EQUALITY distinguishedNameMatch 1083 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1084 SINGLE-VALUE NO-USER-MODIFICATION 1085 USAGE directoryOperation ) 1086 1087 The 'distinguishedNameMatch' matching rule and the DistinguishedName 1088 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. 1089 10903.4.2. 'createTimestamp' 1091 1092 This attribute appears in entries that were added using the protocol 1093 (e.g., using the Add operation). The value is the time the entry was 1094 added. 1095 1096 ( 2.5.18.1 NAME 'createTimestamp' 1097 EQUALITY generalizedTimeMatch 1098 ORDERING generalizedTimeOrderingMatch 1099 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1100 SINGLE-VALUE NO-USER-MODIFICATION 1101 USAGE directoryOperation ) 1102 1103 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' 1104 matching rules and the GeneralizedTime 1105 (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517]. 1106 11073.4.3. 'modifiersName' 1108 1109 This attribute appears in entries that have been modified using the 1110 protocol (e.g., using the Modify operation). The value is the 1111 distinguished name of the last modifier. 1112 1113 ( 2.5.18.4 NAME 'modifiersName' 1114 EQUALITY distinguishedNameMatch 1115 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1116 SINGLE-VALUE NO-USER-MODIFICATION 1117 USAGE directoryOperation ) 1118 1119 1120 1121 1122Zeilenga Standards Track [Page 20] 1123 1124RFC 4512 LDAP Models June 2006 1125 1126 1127 The 'distinguishedNameMatch' matching rule and the DistinguishedName 1128 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. 1129 11303.4.4. 'modifyTimestamp' 1131 1132 This attribute appears in entries that have been modified using the 1133 protocol (e.g., using the Modify operation). The value is the time 1134 the entry was last modified. 1135 1136 ( 2.5.18.2 NAME 'modifyTimestamp' 1137 EQUALITY generalizedTimeMatch 1138 ORDERING generalizedTimeOrderingMatch 1139 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1140 SINGLE-VALUE NO-USER-MODIFICATION 1141 USAGE directoryOperation ) 1142 1143 The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' 1144 matching rules and the GeneralizedTime 1145 (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517]. 1146 11473.4.5. 'structuralObjectClass' 1148 1149 This attribute indicates the structural object class of the entry. 1150 1151 ( 2.5.21.9 NAME 'structuralObjectClass' 1152 EQUALITY objectIdentifierMatch 1153 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 1154 SINGLE-VALUE NO-USER-MODIFICATION 1155 USAGE directoryOperation ) 1156 1157 The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER 1158 (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517]. 1159 11603.4.6. 'governingStructureRule' 1161 1162 This attribute indicates the structure rule governing the entry. 1163 1164 ( 2.5.21.10 NAME 'governingStructureRule' 1165 EQUALITY integerMatch 1166 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 1167 SINGLE-VALUE NO-USER-MODIFICATION 1168 USAGE directoryOperation ) 1169 1170 The 'integerMatch' matching rule and INTEGER 1171 (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517]. 1172 1173 1174 1175 1176 1177 1178Zeilenga Standards Track [Page 21] 1179 1180RFC 4512 LDAP Models June 2006 1181 1182 11834. Directory Schema 1184 1185 As defined in [X.501]: 1186 1187 The Directory Schema is a set of definitions and constraints 1188 concerning the structure of the DIT, the possible ways entries are 1189 named, the information that can be held in an entry, the 1190 attributes used to represent that information and their 1191 organization into hierarchies to facilitate search and retrieval 1192 of the information and the ways in which values of attributes may 1193 be matched in attribute value and matching rule assertions. 1194 1195 NOTE 1 - The schema enables the Directory system to, for example: 1196 1197 - prevent the creation of subordinate entries of the wrong 1198 object-class (e.g., a country as a subordinate of a person); 1199 1200 - prevent the addition of attribute-types to an entry 1201 inappropriate to the object-class (e.g., a serial number to a 1202 person's entry); 1203 1204 - prevent the addition of an attribute value of a syntax not 1205 matching that defined for the attribute-type (e.g., a printable 1206 string to a bit string). 1207 1208 Formally, the Directory Schema comprises a set of: 1209 1210 a) Name Form definitions that define primitive naming relations 1211 for structural object classes; 1212 1213 b) DIT Structure Rule definitions that define the names that 1214 entries may have and the ways in which the entries may be 1215 related to one another in the DIT; 1216 1217 c) DIT Content Rule definitions that extend the specification of 1218 allowable attributes for entries beyond those indicated by the 1219 structural object classes of the entries; 1220 1221 d) Object Class definitions that define the basic set of mandatory 1222 and optional attributes that shall be present, and may be 1223 present, respectively, in an entry of a given class, and which 1224 indicate the kind of object class that is being defined; 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234Zeilenga Standards Track [Page 22] 1235 1236RFC 4512 LDAP Models June 2006 1237 1238 1239 e) Attribute Type definitions that identify the object identifier 1240 by which an attribute is known, its syntax, associated matching 1241 rules, whether it is an operational attribute and if so its 1242 type, whether it is a collective attribute, whether it is 1243 permitted to have multiple values and whether or not it is 1244 derived from another attribute type; 1245 1246 f) Matching Rule definitions that define matching rules. 1247 1248 And in LDAP: 1249 1250 g) LDAP Syntax definitions that define encodings used in LDAP. 1251 12524.1. Schema Definitions 1253 1254 Schema definitions in this section are described using ABNF and rely 1255 on the common productions specified in Section 1.2 as well as these: 1256 1257 noidlen = numericoid [ LCURLY len RCURLY ] 1258 len = number 1259 1260 oids = oid / ( LPAREN WSP oidlist WSP RPAREN ) 1261 oidlist = oid *( WSP DOLLAR WSP oid ) 1262 1263 extensions = *( SP xstring SP qdstrings ) 1264 xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE ) 1265 1266 qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN ) 1267 qdescrlist = [ qdescr *( SP qdescr ) ] 1268 qdescr = SQUOTE descr SQUOTE 1269 1270 qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN ) 1271 qdstringlist = [ qdstring *( SP qdstring ) ] 1272 qdstring = SQUOTE dstring SQUOTE 1273 dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string 1274 1275 QQ = ESC %x32 %x37 ; "\27" 1276 QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c" 1277 1278 ; Any UTF-8 encoded Unicode character 1279 ; except %x27 ("\'") and %x5C ("\") 1280 QUTF8 = QUTF1 / UTFMB 1281 1282 ; Any ASCII character except %x27 ("\'") and %x5C ("\") 1283 QUTF1 = %x00-26 / %x28-5B / %x5D-7F 1284 1285 Schema definitions in this section also share a number of common 1286 terms. 1287 1288 1289 1290Zeilenga Standards Track [Page 23] 1291 1292RFC 4512 LDAP Models June 2006 1293 1294 1295 The NAME field provides a set of short names (descriptors) that are 1296 to be used as aliases for the OID. 1297 1298 The DESC field optionally allows a descriptive string to be provided 1299 by the directory administrator and/or implementor. While 1300 specifications may suggest a descriptive string, there is no 1301 requirement that the suggested (or any) descriptive string be used. 1302 1303 The OBSOLETE field, if present, indicates the element is not active. 1304 1305 Implementors should note that future versions of this document may 1306 expand these definitions to include additional terms. Terms whose 1307 identifier begins with "X-" are reserved for private experiments and 1308 are followed by <SP> and <qdstrings> tokens. 1309 13104.1.1. Object Class Definitions 1311 1312 Object Class definitions are written according to the ABNF: 1313 1314 ObjectClassDescription = LPAREN WSP 1315 numericoid ; object identifier 1316 [ SP "NAME" SP qdescrs ] ; short names (descriptors) 1317 [ SP "DESC" SP qdstring ] ; description 1318 [ SP "OBSOLETE" ] ; not active 1319 [ SP "SUP" SP oids ] ; superior object classes 1320 [ SP kind ] ; kind of class 1321 [ SP "MUST" SP oids ] ; attribute types 1322 [ SP "MAY" SP oids ] ; attribute types 1323 extensions WSP RPAREN 1324 1325 kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" 1326 1327 where: 1328 <numericoid> is object identifier assigned to this object class; 1329 NAME <qdescrs> are short names (descriptors) identifying this 1330 object class; 1331 DESC <qdstring> is a short descriptive string; 1332 OBSOLETE indicates this object class is not active; 1333 SUP <oids> specifies the direct superclasses of this object class; 1334 the kind of object class is indicated by one of ABSTRACT, 1335 STRUCTURAL, or AUXILIARY (the default is STRUCTURAL); 1336 MUST and MAY specify the sets of required and allowed attribute 1337 types, respectively; and 1338 <extensions> describe extensions. 1339 1340 1341 1342 1343 1344 1345 1346Zeilenga Standards Track [Page 24] 1347 1348RFC 4512 LDAP Models June 2006 1349 1350 13514.1.2. Attribute Types 1352 1353 Attribute Type definitions are written according to the ABNF: 1354 1355 AttributeTypeDescription = LPAREN WSP 1356 numericoid ; object identifier 1357 [ SP "NAME" SP qdescrs ] ; short names (descriptors) 1358 [ SP "DESC" SP qdstring ] ; description 1359 [ SP "OBSOLETE" ] ; not active 1360 [ SP "SUP" SP oid ] ; supertype 1361 [ SP "EQUALITY" SP oid ] ; equality matching rule 1362 [ SP "ORDERING" SP oid ] ; ordering matching rule 1363 [ SP "SUBSTR" SP oid ] ; substrings matching rule 1364 [ SP "SYNTAX" SP noidlen ] ; value syntax 1365 [ SP "SINGLE-VALUE" ] ; single-value 1366 [ SP "COLLECTIVE" ] ; collective 1367 [ SP "NO-USER-MODIFICATION" ] ; not user modifiable 1368 [ SP "USAGE" SP usage ] ; usage 1369 extensions WSP RPAREN ; extensions 1370 1371 usage = "userApplications" / ; user 1372 "directoryOperation" / ; directory operational 1373 "distributedOperation" / ; DSA-shared operational 1374 "dSAOperation" ; DSA-specific operational 1375 1376 where: 1377 <numericoid> is object identifier assigned to this attribute type; 1378 NAME <qdescrs> are short names (descriptors) identifying this 1379 attribute type; 1380 DESC <qdstring> is a short descriptive string; 1381 OBSOLETE indicates this attribute type is not active; 1382 SUP oid specifies the direct supertype of this type; 1383 EQUALITY, ORDERING, and SUBSTR provide the oid of the equality, 1384 ordering, and substrings matching rules, respectively; 1385 SYNTAX identifies value syntax by object identifier and may suggest 1386 a minimum upper bound; 1387 SINGLE-VALUE indicates attributes of this type are restricted to a 1388 single value; 1389 COLLECTIVE indicates this attribute type is collective 1390 [X.501][RFC3671]; 1391 NO-USER-MODIFICATION indicates this attribute type is not user 1392 modifiable; 1393 USAGE indicates the application of this attribute type; and 1394 <extensions> describe extensions. 1395 1396 Each attribute type description must contain at least one of the SUP 1397 or SYNTAX fields. If no SYNTAX field is provided, the attribute type 1398 description takes its value from the supertype. 1399 1400 1401 1402Zeilenga Standards Track [Page 25] 1403 1404RFC 4512 LDAP Models June 2006 1405 1406 1407 If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING 1408 fields, if not specified, take their value from the supertype. 1409 1410 Usage of userApplications, the default, indicates that attributes of 1411 this type represent user information. That is, they are user 1412 attributes. 1413 1414 A usage of directoryOperation, distributedOperation, or dSAOperation 1415 indicates that attributes of this type represent operational and/or 1416 administrative information. That is, they are operational 1417 attributes. 1418 1419 directoryOperation usage indicates that the attribute of this type is 1420 a directory operational attribute. distributedOperation usage 1421 indicates that the attribute of this type is a DSA-shared usage 1422 operational attribute. dSAOperation usage indicates that the 1423 attribute of this type is a DSA-specific operational attribute. 1424 1425 COLLECTIVE requires usage userApplications. Use of collective 1426 attribute types in LDAP is discussed in [RFC3671]. 1427 1428 NO-USER-MODIFICATION requires an operational usage. 1429 1430 Note that the <AttributeTypeDescription> does not list the matching 1431 rules that can be used with that attribute type in an extensibleMatch 1432 search filter [RFC4511]. This is done using the 'matchingRuleUse' 1433 attribute described in Section 4.1.4. 1434 1435 This document refines the schema description of X.501 by requiring 1436 that the SYNTAX field in an <AttributeTypeDescription> be a string 1437 representation of an object identifier for the LDAP string syntax 1438 definition, with an optional indication of the suggested minimum 1439 bound of a value of this attribute. 1440 1441 A suggested minimum upper bound on the number of characters in a 1442 value with a string-based syntax, or the number of bytes in a value 1443 for all other syntaxes, may be indicated by appending this bound 1444 count inside of curly braces following the syntax's OBJECT IDENTIFIER 1445 in an Attribute Type Description. This bound is not part of the 1446 syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests 1447 that server implementations should allow a string to be 64 characters 1448 long, although they may allow longer strings. Note that a single 1449 character of the Directory String syntax may be encoded in more than 1450 one octet since UTF-8 [RFC3629] is a variable-length encoding. 1451 1452 1453 1454 1455 1456 1457 1458Zeilenga Standards Track [Page 26] 1459 1460RFC 4512 LDAP Models June 2006 1461 1462 14634.1.3. Matching Rules 1464 1465 Matching rules are used in performance of attribute value assertions, 1466 such as in performance of a Compare operation. They are also used in 1467 evaluating search filters, determining which individual values are to 1468 be added or deleted during performance of a Modify operation, and in 1469 comparing distinguished names. 1470 1471 Each matching rule is identified by an object identifier (OID) and, 1472 optionally, one or more short names (descriptors). 1473 1474 Matching rule definitions are written according to the ABNF: 1475 1476 MatchingRuleDescription = LPAREN WSP 1477 numericoid ; object identifier 1478 [ SP "NAME" SP qdescrs ] ; short names (descriptors) 1479 [ SP "DESC" SP qdstring ] ; description 1480 [ SP "OBSOLETE" ] ; not active 1481 SP "SYNTAX" SP numericoid ; assertion syntax 1482 extensions WSP RPAREN ; extensions 1483 1484 where: 1485 <numericoid> is object identifier assigned to this matching rule; 1486 NAME <qdescrs> are short names (descriptors) identifying this 1487 matching rule; 1488 DESC <qdstring> is a short descriptive string; 1489 OBSOLETE indicates this matching rule is not active; 1490 SYNTAX identifies the assertion syntax (the syntax of the assertion 1491 value) by object identifier; and 1492 <extensions> describe extensions. 1493 14944.1.4. Matching Rule Uses 1495 1496 A matching rule use lists the attribute types that are suitable for 1497 use with an extensibleMatch search filter. 1498 1499 Matching rule use descriptions are written according to the following 1500 ABNF: 1501 1502 MatchingRuleUseDescription = LPAREN WSP 1503 numericoid ; object identifier 1504 [ SP "NAME" SP qdescrs ] ; short names (descriptors) 1505 [ SP "DESC" SP qdstring ] ; description 1506 [ SP "OBSOLETE" ] ; not active 1507 SP "APPLIES" SP oids ; attribute types 1508 extensions WSP RPAREN ; extensions 1509 1510 1511 1512 1513 1514Zeilenga Standards Track [Page 27] 1515 1516RFC 4512 LDAP Models June 2006 1517 1518 1519 where: 1520 <numericoid> is the object identifier of the matching rule 1521 associated with this matching rule use description; 1522 NAME <qdescrs> are short names (descriptors) identifying this 1523 matching rule use; 1524 DESC <qdstring> is a short descriptive string; 1525 OBSOLETE indicates this matching rule use is not active; 1526 APPLIES provides a list of attribute types the matching rule 1527 applies to; and 1528 <extensions> describe extensions. 1529 15304.1.5. LDAP Syntaxes 1531 1532 LDAP Syntaxes of (attribute and assertion) values are described in 1533 terms of ASN.1 [X.680] and, optionally, have an octet string encoding 1534 known as the LDAP-specific encoding. Commonly, the LDAP-specific 1535 encoding is constrained to a string of Unicode [Unicode] characters 1536 in UTF-8 [RFC3629] form. 1537 1538 Each LDAP syntax is identified by an object identifier (OID). 1539 1540 LDAP syntax definitions are written according to the ABNF: 1541 1542 SyntaxDescription = LPAREN WSP 1543 numericoid ; object identifier 1544 [ SP "DESC" SP qdstring ] ; description 1545 extensions WSP RPAREN ; extensions 1546 1547 where: 1548 <numericoid> is the object identifier assigned to this LDAP syntax; 1549 DESC <qdstring> is a short descriptive string; and 1550 <extensions> describe extensions. 1551 15524.1.6. DIT Content Rules 1553 1554 A DIT content rule is a "rule governing the content of entries of a 1555 particular structural object class" [X.501]. 1556 1557 For DIT entries of a particular structural object class, a DIT 1558 content rule specifies which auxiliary object classes the entries are 1559 allowed to belong to and which additional attributes (by type) are 1560 required, allowed, or not allowed to appear in the entries. 1561 1562 The list of precluded attributes cannot include any attribute listed 1563 as mandatory in the rule, the structural object class, or any of the 1564 allowed auxiliary object classes. 1565 1566 1567 1568 1569 1570Zeilenga Standards Track [Page 28] 1571 1572RFC 4512 LDAP Models June 2006 1573 1574 1575 Each content rule is identified by the object identifier, as well as 1576 any short names (descriptors), of the structural object class it 1577 applies to. 1578 1579 An entry may only belong to auxiliary object classes listed in the 1580 governing content rule. 1581 1582 An entry must contain all attributes required by the object classes 1583 the entry belongs to as well as all attributes required by the 1584 governing content rule. 1585 1586 An entry may contain any non-precluded attributes allowed by the 1587 object classes the entry belongs to as well as all attributes allowed 1588 by the governing content rule. 1589 1590 An entry cannot include any attribute precluded by the governing 1591 content rule. 1592 1593 An entry is governed by (if present and active in the subschema) the 1594 DIT content rule that applies to the structural object class of the 1595 entry (see Section 2.4.2). If no active rule is present for the 1596 entry's structural object class, the entry's content is governed by 1597 the structural object class (and possibly other aspects of user and 1598 system schema). DIT content rules for superclasses of the structural 1599 object class of an entry are not applicable to that entry. 1600 1601 DIT content rule descriptions are written according to the ABNF: 1602 1603 DITContentRuleDescription = LPAREN WSP 1604 numericoid ; object identifier 1605 [ SP "NAME" SP qdescrs ] ; short names (descriptors) 1606 [ SP "DESC" SP qdstring ] ; description 1607 [ SP "OBSOLETE" ] ; not active 1608 [ SP "AUX" SP oids ] ; auxiliary object classes 1609 [ SP "MUST" SP oids ] ; attribute types 1610 [ SP "MAY" SP oids ] ; attribute types 1611 [ SP "NOT" SP oids ] ; attribute types 1612 extensions WSP RPAREN ; extensions 1613 1614 where: 1615 <numericoid> is the object identifier of the structural object 1616 class associated with this DIT content rule; 1617 NAME <qdescrs> are short names (descriptors) identifying this DIT 1618 content rule; 1619 DESC <qdstring> is a short descriptive string; 1620 OBSOLETE indicates this DIT content rule use is not active; 1621 AUX specifies a list of auxiliary object classes that entries 1622 subject to this DIT content rule may belong to; 1623 1624 1625 1626Zeilenga Standards Track [Page 29] 1627 1628RFC 4512 LDAP Models June 2006 1629 1630 1631 MUST, MAY, and NOT specify lists of attribute types that are 1632 required, allowed, or precluded, respectively, from appearing 1633 in entries subject to this DIT content rule; and 1634 <extensions> describe extensions. 1635 16364.1.7. DIT Structure Rules and Name Forms 1637 1638 It is sometimes desirable to regulate where object and alias entries 1639 can be placed in the DIT and how they can be named based upon their 1640 structural object class. 1641 16424.1.7.1. DIT Structure Rules 1643 1644 A DIT structure rule is a "rule governing the structure of the DIT by 1645 specifying a permitted superior to subordinate entry relationship. A 1646 structure rule relates a name form, and therefore a structural object 1647 class, to superior structure rules. This permits entries of the 1648 structural object class identified by the name form to exist in the 1649 DIT as subordinates to entries governed by the indicated superior 1650 structure rules" [X.501]. 1651 1652 DIT structure rule descriptions are written according to the ABNF: 1653 1654 DITStructureRuleDescription = LPAREN WSP 1655 ruleid ; rule identifier 1656 [ SP "NAME" SP qdescrs ] ; short names (descriptors) 1657 [ SP "DESC" SP qdstring ] ; description 1658 [ SP "OBSOLETE" ] ; not active 1659 SP "FORM" SP oid ; NameForm 1660 [ SP "SUP" ruleids ] ; superior rules 1661 extensions WSP RPAREN ; extensions 1662 1663 ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN ) 1664 ruleidlist = ruleid *( SP ruleid ) 1665 ruleid = number 1666 1667 where: 1668 <ruleid> is the rule identifier of this DIT structure rule; 1669 NAME <qdescrs> are short names (descriptors) identifying this DIT 1670 structure rule; 1671 DESC <qdstring> is a short descriptive string; 1672 OBSOLETE indicates this DIT structure rule use is not active; 1673 FORM is specifies the name form associated with this DIT structure 1674 rule; 1675 SUP identifies superior rules (by rule id); and 1676 <extensions> describe extensions. 1677 1678 1679 1680 1681 1682Zeilenga Standards Track [Page 30] 1683 1684RFC 4512 LDAP Models June 2006 1685 1686 1687 If no superior rules are identified, the DIT structure rule applies 1688 to an autonomous administrative point (e.g., the root vertex of the 1689 subtree controlled by the subschema) [X.501]. 1690 16914.1.7.2. Name Forms 1692 1693 A name form "specifies a permissible RDN for entries of a particular 1694 structural object class. A name form identifies a named object class 1695 and one or more attribute types to be used for naming (i.e., for the 1696 RDN). Name forms are primitive pieces of specification used in the 1697 definition of DIT structure rules" [X.501]. 1698 1699 Each name form indicates the structural object class to be named, a 1700 set of required attribute types, and a set of allowed attribute 1701 types. A particular attribute type cannot be in both sets. 1702 1703 Entries governed by the form must be named using a value from each 1704 required attribute type and zero or more values from the allowed 1705 attribute types. 1706 1707 Each name form is identified by an object identifier (OID) and, 1708 optionally, one or more short names (descriptors). 1709 1710 Name form descriptions are written according to the ABNF: 1711 1712 NameFormDescription = LPAREN WSP 1713 numericoid ; object identifier 1714 [ SP "NAME" SP qdescrs ] ; short names (descriptors) 1715 [ SP "DESC" SP qdstring ] ; description 1716 [ SP "OBSOLETE" ] ; not active 1717 SP "OC" SP oid ; structural object class 1718 SP "MUST" SP oids ; attribute types 1719 [ SP "MAY" SP oids ] ; attribute types 1720 extensions WSP RPAREN ; extensions 1721 1722 where: 1723 <numericoid> is object identifier that identifies this name form; 1724 NAME <qdescrs> are short names (descriptors) identifying this name 1725 form; 1726 DESC <qdstring> is a short descriptive string; 1727 OBSOLETE indicates this name form is not active; 1728 OC identifies the structural object class this rule applies to, 1729 MUST and MAY specify the sets of required and allowed, 1730 respectively, naming attributes for this name form; and 1731 <extensions> describe extensions. 1732 1733 All attribute types in the required ("MUST") and allowed ("MAY") 1734 lists shall be different. 1735 1736 1737 1738Zeilenga Standards Track [Page 31] 1739 1740RFC 4512 LDAP Models June 2006 1741 1742 17434.2. Subschema Subentries 1744 1745 Subschema (sub)entries are used for administering information about 1746 the directory schema. A single subschema (sub)entry contains all 1747 schema definitions (see Section 4.1) used by entries in a particular 1748 part of the directory tree. 1749 1750 Servers that follow X.500(93) models SHOULD implement subschema using 1751 the X.500 subschema mechanisms (as detailed in Section 12 of 1752 [X.501]), so these are not ordinary object entries but subentries 1753 (see Section 3.2). LDAP clients SHOULD NOT assume that servers 1754 implement any of the other aspects of X.500 subschema. 1755 1756 Servers MAY allow subschema modification. Procedures for subschema 1757 modification are discussed in Section 14.5 of [X.501]. 1758 1759 A server that masters entries and permits clients to modify these 1760 entries SHALL implement and provide access to these subschema 1761 (sub)entries including providing a 'subschemaSubentry' attribute in 1762 each modifiable entry. This is so clients may discover the 1763 attributes and object classes that are permitted to be present. It 1764 is strongly RECOMMENDED that all other servers implement this as 1765 well. 1766 1767 The value of the 'subschemaSubentry' attribute is the name of the 1768 subschema (sub)entry holding the subschema controlling the entry. 1769 1770 ( 2.5.18.10 NAME 'subschemaSubentry' 1771 EQUALITY distinguishedNameMatch 1772 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1773 SINGLE-VALUE NO-USER-MODIFICATION 1774 USAGE directoryOperation ) 1775 1776 The 'distinguishedNameMatch' matching rule and the DistinguishedName 1777 (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517]. 1778 1779 Subschema is held in (sub)entries belonging to the subschema 1780 auxiliary object class. 1781 1782 ( 2.5.20.1 NAME 'subschema' AUXILIARY 1783 MAY ( dITStructureRules $ nameForms $ ditContentRules $ 1784 objectClasses $ attributeTypes $ matchingRules $ 1785 matchingRuleUse ) ) 1786 1787 The 'ldapSyntaxes' operational attribute may also be present in 1788 subschema entries. 1789 1790 1791 1792 1793 1794Zeilenga Standards Track [Page 32] 1795 1796RFC 4512 LDAP Models June 2006 1797 1798 1799 Servers MAY provide additional attributes (described in other 1800 documents) in subschema (sub)entries. 1801 1802 Servers SHOULD provide the attributes 'createTimestamp' and 1803 'modifyTimestamp' in subschema (sub)entries, in order to allow 1804 clients to maintain their caches of schema information. 1805 1806 The following subsections provide attribute type definitions for each 1807 of schema definition attribute types. 1808 18094.2.1. 'objectClasses' 1810 1811 This attribute holds definitions of object classes. 1812 1813 ( 2.5.21.6 NAME 'objectClasses' 1814 EQUALITY objectIdentifierFirstComponentMatch 1815 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 1816 USAGE directoryOperation ) 1817 1818 The 'objectIdentifierFirstComponentMatch' matching rule and the 1819 ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are 1820 defined in [RFC4517]. 1821 18224.2.2. 'attributeTypes' 1823 1824 This attribute holds definitions of attribute types. 1825 1826 ( 2.5.21.5 NAME 'attributeTypes' 1827 EQUALITY objectIdentifierFirstComponentMatch 1828 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 1829 USAGE directoryOperation ) 1830 1831 The 'objectIdentifierFirstComponentMatch' matching rule and the 1832 AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are 1833 defined in [RFC4517]. 1834 18354.2.3. 'matchingRules' 1836 1837 This attribute holds definitions of matching rules. 1838 1839 ( 2.5.21.4 NAME 'matchingRules' 1840 EQUALITY objectIdentifierFirstComponentMatch 1841 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 1842 USAGE directoryOperation ) 1843 1844 The 'objectIdentifierFirstComponentMatch' matching rule and the 1845 MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are 1846 defined in [RFC4517]. 1847 1848 1849 1850Zeilenga Standards Track [Page 33] 1851 1852RFC 4512 LDAP Models June 2006 1853 1854 18554.2.4 'matchingRuleUse' 1856 1857 This attribute holds definitions of matching rule uses. 1858 1859 ( 2.5.21.8 NAME 'matchingRuleUse' 1860 EQUALITY objectIdentifierFirstComponentMatch 1861 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 1862 USAGE directoryOperation ) 1863 1864 The 'objectIdentifierFirstComponentMatch' matching rule and the 1865 MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are 1866 defined in [RFC4517]. 1867 18684.2.5. 'ldapSyntaxes' 1869 1870 This attribute holds definitions of LDAP syntaxes. 1871 1872 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' 1873 EQUALITY objectIdentifierFirstComponentMatch 1874 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 1875 USAGE directoryOperation ) 1876 1877 The 'objectIdentifierFirstComponentMatch' matching rule and the 1878 SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined 1879 in [RFC4517]. 1880 18814.2.6. 'dITContentRules' 1882 1883 This attribute lists DIT Content Rules that are present in the 1884 subschema. 1885 1886 ( 2.5.21.2 NAME 'dITContentRules' 1887 EQUALITY objectIdentifierFirstComponentMatch 1888 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 1889 USAGE directoryOperation ) 1890 1891 The 'objectIdentifierFirstComponentMatch' matching rule and the 1892 DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are 1893 defined in [RFC4517]. 1894 1895 1896 1897 1898 1899 1900 1901 1902 1903 1904 1905 1906Zeilenga Standards Track [Page 34] 1907 1908RFC 4512 LDAP Models June 2006 1909 1910 19114.2.7. 'dITStructureRules' 1912 1913 This attribute lists DIT Structure Rules that are present in the 1914 subschema. 1915 1916 ( 2.5.21.1 NAME 'dITStructureRules' 1917 EQUALITY integerFirstComponentMatch 1918 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 1919 USAGE directoryOperation ) 1920 1921 The 'integerFirstComponentMatch' matching rule and the 1922 DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax 1923 are defined in [RFC4517]. 1924 19254.2.8 'nameForms' 1926 1927 This attribute lists Name Forms that are in force. 1928 1929 ( 2.5.21.7 NAME 'nameForms' 1930 EQUALITY objectIdentifierFirstComponentMatch 1931 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 1932 USAGE directoryOperation ) 1933 1934 The 'objectIdentifierFirstComponentMatch' matching rule and the 1935 NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are 1936 defined in [RFC4517]. 1937 19384.3. 'extensibleObject' object class 1939 1940 The 'extensibleObject' auxiliary object class allows entries that 1941 belong to it to hold any user attribute. The set of allowed 1942 attribute types of this object class is implicitly the set of all 1943 attribute types of userApplications usage. 1944 1945 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 1946 SUP top AUXILIARY ) 1947 1948 The mandatory attributes of the other object classes of this entry 1949 are still required to be present, and any precluded attributes are 1950 still not allowed to be present. 1951 19524.4. Subschema Discovery 1953 1954 To discover the DN of the subschema (sub)entry holding the subschema 1955 controlling a particular entry, a client reads that entry's 1956 'subschemaSubentry' operational attribute. To read schema attributes 1957 from the subschema (sub)entry, clients MUST issue a Search operation 1958 [RFC4511] where baseObject is the DN of the subschema (sub)entry, 1959 1960 1961 1962Zeilenga Standards Track [Page 35] 1963 1964RFC 4512 LDAP Models June 2006 1965 1966 1967 scope is baseObject, filter is "(objectClass=subschema)" [RFC4515], 1968 and the attributes field lists the names of the desired schema 1969 attributes (as they are operational). Note: the 1970 "(objectClass=subschema)" filter allows LDAP servers that gateway to 1971 X.500 to detect that subentry information is being requested. 1972 1973 Clients SHOULD NOT assume that a published subschema is complete, 1974 that the server supports all of the schema elements it publishes, or 1975 that the server does not support an unpublished element. 1976 19775. DSA (Server) Informational Model 1978 1979 The LDAP protocol assumes there are one or more servers that jointly 1980 provide access to a Directory Information Tree (DIT). The server 1981 holding the original information is called the "master" (for that 1982 information). Servers that hold copies of the original information 1983 are referred to as "shadowing" or "caching" servers. 1984 1985 1986 As defined in [X.501]: 1987 1988 context prefix: The sequence of RDNs leading from the Root of the 1989 DIT to the initial vertex of a naming context; corresponds to 1990 the distinguished name of that vertex. 1991 1992 naming context: A subtree of entries held in a single master DSA. 1993 1994 That is, a naming context is the largest collection of entries, 1995 starting at an entry that is mastered by a particular server, and 1996 including all its subordinates and their subordinates, down to the 1997 entries that are mastered by different servers. The context prefix 1998 is the name of the initial entry. 1999 2000 The root of the DIT is a DSA-specific Entry (DSE) and not part of any 2001 naming context (or any subtree); each server has different attribute 2002 values in the root DSE. 2003 20045.1. Server-Specific Data Requirements 2005 2006 An LDAP server SHALL provide information about itself and other 2007 information that is specific to each server. This is represented as 2008 a group of attributes located in the root DSE, which is named with 2009 the DN with zero RDNs (whose [RFC4514] representation is as the 2010 zero-length string). 2011 2012 These attributes are retrievable, subject to access control and other 2013 restrictions, if a client performs a Search operation [RFC4511] with 2014 an empty baseObject, scope of baseObject, the filter 2015 2016 2017 2018Zeilenga Standards Track [Page 36] 2019 2020RFC 4512 LDAP Models June 2006 2021 2022 2023 "(objectClass=*)" [RFC4515], and the attributes field listing the 2024 names of the desired attributes. It is noted that root DSE 2025 attributes are operational and, like other operational attributes, 2026 are not returned in search requests unless requested by name. 2027 2028 The root DSE SHALL NOT be included if the client performs a subtree 2029 search starting from the root. 2030 2031 Servers may allow clients to modify attributes of the root DSE, where 2032 appropriate. 2033 2034 The following attributes of the root DSE are defined below. 2035 Additional attributes may be defined in other documents. 2036 2037 - altServer: alternative servers; 2038 2039 - namingContexts: naming contexts; 2040 2041 - supportedControl: recognized LDAP controls; 2042 2043 - supportedExtension: recognized LDAP extended operations; 2044 2045 - supportedFeatures: recognized LDAP features; 2046 2047 - supportedLDAPVersion: LDAP versions supported; and 2048 2049 - supportedSASLMechanisms: recognized Simple Authentication and 2050 Security Layers (SASL) [RFC4422] mechanisms. 2051 2052 The values provided for these attributes may depend on session- 2053 specific and other factors. For example, a server supporting the 2054 SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's 2055 identity has been established by a lower level. See [RFC4513]. 2056 2057 The root DSE may also include a 'subschemaSubentry' attribute. If it 2058 does, the attribute refers to the subschema (sub)entry holding the 2059 schema controlling the root DSE. Clients SHOULD NOT assume that this 2060 subschema (sub)entry controls other entries held by the server. 2061 General subschema discovery procedures are provided in Section 4.4. 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074Zeilenga Standards Track [Page 37] 2075 2076RFC 4512 LDAP Models June 2006 2077 2078 20795.1.1. 'altServer' 2080 2081 The 'altServer' attribute lists URIs referring to alternative servers 2082 that may be contacted when this server becomes unavailable. URIs for 2083 servers implementing the LDAP are written according to [RFC4516]. 2084 Other kinds of URIs may be provided. If the server does not know of 2085 any other servers that could be used, this attribute will be absent. 2086 Clients may cache this information in case their preferred server 2087 later becomes unavailable. 2088 2089 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' 2090 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 2091 USAGE dSAOperation ) 2092 2093 The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in 2094 [RFC4517]. 2095 20965.1.2. 'namingContexts' 2097 2098 The 'namingContexts' attribute lists the context prefixes of the 2099 naming contexts the server masters or shadows (in part or in whole). 2100 If the server is a first-level DSA [X.501], it should list (in 2101 addition) an empty string (indicating the root of the DIT). If the 2102 server does not master or shadow any information (e.g., it is an LDAP 2103 gateway to a public X.500 directory) this attribute will be absent. 2104 If the server believes it masters or shadows the entire directory, 2105 the attribute will have a single value, and that value will be the 2106 empty string (indicating the root of the DIT). 2107 2108 This attribute may be used, for example, to select a suitable entry 2109 name for subsequent operations with this server. 2110 2111 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' 2112 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2113 USAGE dSAOperation ) 2114 2115 The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is 2116 defined in [RFC4517]. 2117 21185.1.3. 'supportedControl' 2119 2120 The 'supportedControl' attribute lists object identifiers identifying 2121 the request controls [RFC4511] the server supports. If the server 2122 does not support any request controls, this attribute will be absent. 2123 Object identifiers identifying response controls need not be listed. 2124 2125 Procedures for registering object identifiers used to discovery of 2126 protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. 2127 2128 2129 2130Zeilenga Standards Track [Page 38] 2131 2132RFC 4512 LDAP Models June 2006 2133 2134 2135 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' 2136 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 2137 USAGE dSAOperation ) 2138 2139 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is 2140 defined in [RFC4517]. 2141 21425.1.4. 'supportedExtension' 2143 2144 The 'supportedExtension' attribute lists object identifiers 2145 identifying the extended operations [RFC4511] that the server 2146 supports. If the server does not support any extended operations, 2147 this attribute will be absent. 2148 2149 An extended operation generally consists of an extended request and 2150 an extended response but may also include other protocol data units 2151 (such as intermediate responses). The object identifier assigned to 2152 the extended request is used to identify the extended operation. 2153 Other object identifiers used in the extended operation need not be 2154 listed as values of this attribute. 2155 2156 Procedures for registering object identifiers used to discovery of 2157 protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. 2158 2159 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' 2160 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 2161 USAGE dSAOperation ) 2162 2163 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is 2164 defined in [RFC4517]. 2165 21665.1.5. 'supportedFeatures' 2167 2168 The 'supportedFeatures' attribute lists object identifiers 2169 identifying elective features that the server supports. If the 2170 server does not support any discoverable elective features, this 2171 attribute will be absent. 2172 2173 ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures' 2174 EQUALITY objectIdentifierMatch 2175 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 2176 USAGE dSAOperation ) 2177 2178 Procedures for registering object identifiers used to discovery of 2179 protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520]. 2180 2181 The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and 2182 objectIdentifierMatch matching rule are defined in [RFC4517]. 2183 2184 2185 2186Zeilenga Standards Track [Page 39] 2187 2188RFC 4512 LDAP Models June 2006 2189 2190 21915.1.6. 'supportedLDAPVersion' 2192 2193 The 'supportedLDAPVersion' attribute lists the versions of LDAP that 2194 the server supports. 2195 2196 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' 2197 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 2198 USAGE dSAOperation ) 2199 2200 The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in 2201 [RFC4517]. 2202 22035.1.7. 'supportedSASLMechanisms' 2204 2205 The 'supportedSASLMechanisms' attribute lists the SASL mechanisms 2206 [RFC4422] that the server recognizes and/or supports [RFC4513]. The 2207 contents of this attribute may depend on the current session state. 2208 If the server does not support any SASL mechanisms, this attribute 2209 will not be present. 2210 2211 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' 2212 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2213 USAGE dSAOperation ) 2214 2215 The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is 2216 defined in [RFC4517]. 2217 22186. Other Considerations 2219 22206.1. Preservation of User Information 2221 2222 Syntaxes may be defined that have specific value and/or value form 2223 (representation) preservation requirements. For example, a syntax 2224 containing digitally signed data can mandate that the server preserve 2225 both the value and form of value presented to ensure that the 2226 signature is not invalidated. 2227 2228 Where such requirements have not been explicitly stated, servers 2229 SHOULD preserve the value of user information but MAY return the 2230 value in a different form. And where a server is unable (or 2231 unwilling) to preserve the value of user information, the server 2232 SHALL ensure that an equivalent value (per Section 2.3) is returned. 2233 2234 2235 2236 2237 2238 2239 2240 2241 2242Zeilenga Standards Track [Page 40] 2243 2244RFC 4512 LDAP Models June 2006 2245 2246 22476.2. Short Names 2248 2249 Short names, also known as descriptors, are used as more readable 2250 aliases for object identifiers and are used to identify various 2251 schema elements. However, it is not expected that LDAP 2252 implementations with human user interface would display these short 2253 names (or the object identifiers they refer to) to the user. 2254 Instead, they would most likely be performing translations (such as 2255 expressing the short name in one of the local national languages). 2256 For example, the short name "st" (stateOrProvinceName) might be 2257 displayed to a German-speaking user as "Land". 2258 2259 The same short name might have different meaning in different 2260 subschemas, and, within a particular subschema, the same short name 2261 might refer to different object identifiers each identifying a 2262 different kind of schema element. 2263 2264 Implementations MUST be prepared that the same short name might be 2265 used in a subschema to refer to the different kinds of schema 2266 elements. That is, there might be an object class 'x-fubar' and an 2267 attribute type 'x-fubar' in a subschema. 2268 2269 Implementations MUST be prepared that the same short name might be 2270 used in the different subschemas to refer to the different schema 2271 elements. That is, there might be two matching rules 'x-fubar', each 2272 in different subschemas. 2273 2274 Procedures for registering short names (descriptors) are detailed in 2275 BCP 64, RFC 4520 [RFC4520]. 2276 22776.3. Cache and Shadowing 2278 2279 Some servers may hold cache or shadow copies of entries, which can be 2280 used to answer search and comparison queries, but will return 2281 referrals or contact other servers if modification operations are 2282 requested. Servers that perform shadowing or caching MUST ensure 2283 that they do not violate any access control constraints placed on the 2284 data by the originating server. 2285 2286 2287 2288 2289 2290 2291 2292 2293 2294 2295 2296 2297 2298Zeilenga Standards Track [Page 41] 2299 2300RFC 4512 LDAP Models June 2006 2301 2302 23037. Implementation Guidelines 2304 23057.1. Server Guidelines 2306 2307 Servers MUST recognize all names of attribute types and object 2308 classes defined in this document but, unless stated otherwise, need 2309 not support the associated functionality. Servers SHOULD recognize 2310 all the names of attribute types and object classes defined in 2311 Section 3 and 4, respectively, of [RFC4519]. 2312 2313 Servers MUST ensure that entries conform to user and system schema 2314 rules or other data model constraints. 2315 2316 Servers MAY support DIT Content Rules. Servers MAY support DIT 2317 Structure Rules and Name Forms. 2318 2319 Servers MAY support alias entries. 2320 2321 Servers MAY support the 'extensibleObject' object class. 2322 2323 Servers MAY support subentries. If so, they MUST do so in accordance 2324 with [RFC3672]. Servers that do not support subentries SHOULD use 2325 object entries to mimic subentries as detailed in Section 3.2. 2326 2327 Servers MAY implement additional schema elements. Servers SHOULD 2328 provide definitions of all schema elements they support in subschema 2329 (sub)entries. 2330 23317.2. Client Guidelines 2332 2333 In the absence of prior agreements with servers, clients SHOULD NOT 2334 assume that servers support any particular schema elements beyond 2335 those referenced in Section 7.1. The client can retrieve subschema 2336 information as described in Section 4.4. 2337 2338 Clients MUST NOT display or attempt to decode a value as ASN.1 if the 2339 value's syntax is not known. Clients MUST NOT assume the LDAP- 2340 specific string encoding is restricted to a UTF-8 encoded string of 2341 Unicode characters or any particular subset of Unicode (such as a 2342 printable subset) unless such restriction is explicitly stated. 2343 Clients SHOULD NOT send attribute values in a request that are not 2344 valid according to the syntax defined for the attributes. 2345 2346 2347 2348 2349 2350 2351 2352 2353 2354Zeilenga Standards Track [Page 42] 2355 2356RFC 4512 LDAP Models June 2006 2357 2358 23598. Security Considerations 2360 2361 Attributes of directory entries are used to provide descriptive 2362 information about the real-world objects they represent, which can be 2363 people, organizations, or devices. Most countries have privacy laws 2364 regarding the publication of information about people. 2365 2366 General security considerations for accessing directory information 2367 with LDAP are discussed in [RFC4511] and [RFC4513]. 2368 23699. IANA Considerations 2370 2371 The Internet Assigned Numbers Authority (IANA) has updated the LDAP 2372 descriptors registry as indicated in the following template: 2373 2374 Subject: Request for LDAP Descriptor Registration Update 2375 Descriptor (short name): see comment 2376 Object Identifier: see comment 2377 Person & email address to contact for further information: 2378 Kurt Zeilenga <kurt@OpenLDAP.org> 2379 Usage: see comment 2380 Specification: RFC 4512 2381 Author/Change Controller: IESG 2382 Comments: 2383 2384 The following descriptors (short names) has been added to 2385 the registry. 2386 2387 NAME Type OID 2388 ------------------------ ---- ----------------- 2389 governingStructureRule A 2.5.21.10 2390 structuralObjectClass A 2.5.21.9 2391 2392 The following descriptors (short names) have been updated to 2393 refer to this RFC. 2394 2395 NAME Type OID 2396 ------------------------ ---- ----------------- 2397 alias O 2.5.6.1 2398 aliasedObjectName A 2.5.4.1 2399 altServer A 1.3.6.1.4.1.1466.101.120.6 2400 attributeTypes A 2.5.21.5 2401 createTimestamp A 2.5.18.1 2402 creatorsName A 2.5.18.3 2403 dITContentRules A 2.5.21.2 2404 dITStructureRules A 2.5.21.1 2405 extensibleObject O 1.3.6.1.4.1.1466.101.120.111 2406 ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16 2407 2408 2409 2410Zeilenga Standards Track [Page 43] 2411 2412RFC 4512 LDAP Models June 2006 2413 2414 2415 matchingRuleUse A 2.5.21.8 2416 matchingRules A 2.5.21.4 2417 modifiersName A 2.5.18.4 2418 modifyTimestamp A 2.5.18.2 2419 nameForms A 2.5.21.7 2420 namingContexts A 1.3.6.1.4.1.1466.101.120.5 2421 objectClass A 2.5.4.0 2422 objectClasses A 2.5.21.6 2423 subschema O 2.5.20.1 2424 subschemaSubentry A 2.5.18.10 2425 supportedControl A 1.3.6.1.4.1.1466.101.120.13 2426 supportedExtension A 1.3.6.1.4.1.1466.101.120.7 2427 supportedFeatures A 1.3.6.1.4.1.4203.1.3.5 2428 supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15 2429 supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14 2430 top O 2.5.6.0 2431 243210. Acknowledgements 2433 2434 This document is based in part on RFC 2251 by M. Wahl, T. Howes, and 2435 S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and 2436 RFC 2556 by M. Wahl, all products of the IETF Access, Searching and 2437 Indexing of Directories (ASID) Working Group. This document is also 2438 based in part on "The Directory: Models" [X.501], a product of the 2439 International Telephone Union (ITU). Additional text was borrowed 2440 from RFC 2253 by M. Wahl, T. Howes, and S. Kille. 2441 2442 This document is a product of the IETF LDAP Revision (LDAPBIS) 2443 Working Group. 2444 2445 2446 2447 2448 2449 2450 2451 2452 2453 2454 2455 2456 2457 2458 2459 2460 2461 2462 2463 2464 2465 2466Zeilenga Standards Track [Page 44] 2467 2468RFC 4512 LDAP Models June 2006 2469 2470 247111. Normative References 2472 2473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2474 Requirement Levels", BCP 14, RFC 2119, March 1997. 2475 2476 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2477 10646", STD 63, RFC 3629, November 2003. 2478 2479 [RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight 2480 Directory Access Protocol (LDAP)", RFC 3671, December 2481 2003. 2482 2483 [RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory 2484 Access Protocol (LDAP)", RFC 3672, December 2003. 2485 2486 [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2487 Specifications: ABNF", RFC 4234, October 2005. 2488 2489 [RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 2490 Authentication and Security Layer (SASL)", RFC 4422, 2491 June 2006. 2492 2493 [RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access 2494 Protocol (LDAP): Technical Specification Road Map", RFC 2495 4510, June 2006. 2496 2497 [RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access 2498 Protocol (LDAP): The Protocol", RFC 4511, June 2006. 2499 2500 [RFC4513] Harrison, R., Ed., "Lightweight Directory Access 2501 Protocol (LDAP): Authentication Methods and Security 2502 Mechanisms", RFC 4513, June 2006. 2503 2504 [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access 2505 Protocol (LDAP): String Representation of Distinguished 2506 Names", RFC 4514, June 2006. 2507 2508 [RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory 2509 Access Protocol (LDAP): String Representation of Search 2510 Filters", RFC 4515, June 2006. 2511 2512 [RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory 2513 Access Protocol (LDAP): Uniform Resource Locator", RFC 2514 4516, June 2006. 2515 2516 [RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol 2517 (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2518 2006. 2519 2520 2521 2522Zeilenga Standards Track [Page 45] 2523 2524RFC 4512 LDAP Models June 2006 2525 2526 2527 [RFC4519] Sciberras, A., Ed., "Lightweight Directory Access 2528 Protocol (LDAP): Schema for User Applications", RFC 2529 4519, June 2006. 2530 2531 [RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority 2532 (IANA) Considerations for the Lightweight Directory 2533 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006. 2534 2535 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 2536 3.2.0" is defined by "The Unicode Standard, Version 2537 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 2538 61633-5), as amended by the "Unicode Standard Annex 2539 #27: Unicode 3.1" 2540 (http://www.unicode.org/reports/tr27/) and by the 2541 "Unicode Standard Annex #28: Unicode 3.2" 2542 (http://www.unicode.org/reports/tr28/). 2543 2544 [X.500] International Telecommunication Union - 2545 Telecommunication Standardization Sector, "The 2546 Directory -- Overview of concepts, models and 2547 services," X.500(1993) (also ISO/IEC 9594-1:1994). 2548 2549 [X.501] International Telecommunication Union - 2550 Telecommunication Standardization Sector, "The 2551 Directory -- Models," X.501(1993) (also ISO/IEC 9594- 2552 2:1994). 2553 2554 [X.680] International Telecommunication Union - 2555 Telecommunication Standardization Sector, "Abstract 2556 Syntax Notation One (ASN.1) - Specification of Basic 2557 Notation", X.680(2002) (also ISO/IEC 8824-1:2002). 2558 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2576 2577 2578Zeilenga Standards Track [Page 46] 2579 2580RFC 4512 LDAP Models June 2006 2581 2582 2583Appendix A. Changes 2584 2585 This appendix is non-normative. 2586 2587 This document amounts to nearly a complete rewrite of portions of RFC 2588 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve 2589 overall clarity of technical specification. This appendix provides a 2590 summary of substantive changes made to the portions of these 2591 documents incorporated into this document. Readers should consult 2592 [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of 2593 remaining portions of these documents. 2594 2595A.1. Changes to RFC 2251 2596 2597 This document incorporates from RFC 2251, Sections 3.2 and 3.4, and 2598 portions of Sections 4 and 6 as summarized below. 2599 2600A.1.1. Section 3.2 of RFC 2251 2601 2602 Section 3.2 of RFC 2251 provided a brief introduction to the X.500 2603 data model, as used by LDAP. The previous specification relied on 2604 [X.501] but lacked clarity in how X.500 models are adapted for use by 2605 LDAP. This document describes the X.500 data models, as used by 2606 LDAP, in greater detail, especially in areas where adaptation is 2607 needed. 2608 2609 Section 3.2.1 of RFC 2251 described an attribute as "a type with one 2610 or more associated values". In LDAP, an attribute is better 2611 described as an attribute description, a type with zero or more 2612 options, and one or more associated values. 2613 2614 Section 3.2.2 of RFC 2251 mandated that subschema subentries contain 2615 objectClasses and attributeTypes attributes, yet X.500(93) treats 2616 these attributes as optional. While generally all implementations 2617 that support X.500(93) subschema mechanisms will provide both of 2618 these attributes, it is not absolutely required for interoperability 2619 that all servers do. The mandate was removed for consistency with 2620 X.500(93). The subschema discovery mechanism was also clarified to 2621 indicate that subschema controlling an entry is obtained by reading 2622 the (sub)entry referred to by that entry's 'subschemaSubentry' 2623 attribute. 2624 2625 2626 2627 2628 2629 2630 2631 2632 2633 2634Zeilenga Standards Track [Page 47] 2635 2636RFC 4512 LDAP Models June 2006 2637 2638 2639A.1.2. Section 3.4 of RFC 2251 2640 2641 Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". 2642 This material, with changes, was incorporated in Section 5.1 of this 2643 document. 2644 2645 Changes: 2646 2647 - Clarify that attributes of the root DSE are subject to "other 2648 restrictions" in addition to access controls. 2649 2650 - Clarify that only recognized extended requests need to be 2651 enumerated 'supportedExtension'. 2652 2653 - Clarify that only recognized request controls need to be enumerated 2654 'supportedControl'. 2655 2656 - Clarify that root DSE attributes are operational and, like other 2657 operational attributes, will not be returned in search requests 2658 unless requested by name. 2659 2660 - Clarify that not all root DSE attributes are user modifiable. 2661 2662 - Remove inconsistent text regarding handling of the 2663 'subschemaSubentry' attribute within the root DSE. The previous 2664 specification stated that the 'subschemaSubentry' attribute held in 2665 the root DSE referred to "subschema entries (or subentries) known 2666 by this server". This is inconsistent with the attribute's 2667 intended use as well as its formal definition as a single valued 2668 attribute [X.501]. It is also noted that a simple (possibly 2669 incomplete) list of subschema (sub)entries is not terribly useful. 2670 This document (in Section 5.1) specifies that the 2671 'subschemaSubentry' attribute of the root DSE refers to the 2672 subschema controlling the root DSE. It is noted that the general 2673 subschema discovery mechanism remains available (see Section 4.4 of 2674 this document). 2675 2676A.1.3. Section 4 of RFC 2251 2677 2678 Portions of Section 4 of RFC 2251 detailing aspects of the 2679 information model used by LDAP were incorporated in this document, 2680 including: 2681 2682 - Restriction of distinguished values to attributes whose 2683 descriptions have no options (from Section 4.1.3); 2684 2685 2686 2687 2688 2689 2690Zeilenga Standards Track [Page 48] 2691 2692RFC 4512 LDAP Models June 2006 2693 2694 2695 - Data model aspects of Attribute Types (from Section 4.1.4), 2696 Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8), 2697 Matching Rule Identifier (from 4.1.9); and 2698 2699 - User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7). 2700 2701 Clarifications to these portions include: 2702 2703 - Subtyping and AttributeDescriptions with options. 2704 2705A.1.4. Section 6 of RFC 2251 2706 2707 The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 2708 where incorporated into this document. 2709 2710A.2. Changes to RFC 2252 2711 2712 This document incorporates Sections 4, 5, and 7 from RFC 2252. 2713 2714A.2.1. Section 4 of RFC 2252 2715 2716 The specification was updated to use Augmented BNF [RFC4234]. The 2717 string representation of an OBJECT IDENTIFIER was tightened to 2718 disallow leading zeros as described in RFC 2252. 2719 2720 The <descr> syntax was changed to disallow semicolon (U+003B) 2721 characters in order to appear to be consistent its natural language 2722 specification "descr is the syntactic representation of an object 2723 descriptor, which consists of letters and digits, starting with a 2724 letter". In a related change, the statement "an AttributeDescription 2725 can be used as the value in a NAME part of an 2726 AttributeTypeDescription" was deleted. RFC 2252 provided no 2727 specification of the semantics of attribute options appearing in NAME 2728 fields. 2729 2730 RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred 2731 over the <numericoid> form. However, <descr> form can be ambiguous. 2732 To address this issue, the imperative was replaced with a statement 2733 (in Section 1.4) that while the <descr> form is generally preferred, 2734 <numericoid> should be used where an unambiguous <descr> is not 2735 available. Additionally, an expanded discussion of descriptor issues 2736 is in Section 6.2 ("Short Names"). 2737 2738 The ABNF for a quoted string (qdstring) was updated to reflect 2739 support for the escaping mechanism described in Section 4.3 of RFC 2740 2252. 2741 2742 2743 2744 2745 2746Zeilenga Standards Track [Page 49] 2747 2748RFC 4512 LDAP Models June 2006 2749 2750 2751A.2.2. Section 5 of RFC 2252 2752 2753 Definitions of operational attributes provided in Section 5 of RFC 2754 2252 where incorporated into this document. 2755 2756 The 'namingContexts' description was clarified. A first-level DSA 2757 should publish, in addition to other values, "" indicating the root 2758 of the DIT. 2759 2760 The 'altServer' description was clarified. It may hold any URI. 2761 2762 The 'supportedExtension' description was clarified. A server need 2763 only list the OBJECT IDENTIFIERs associated with the extended 2764 requests of the extended operations it recognizes. 2765 2766 The 'supportedControl' description was clarified. A server need only 2767 list the OBJECT IDENTIFIERs associated with the request controls it 2768 recognizes. 2769 2770 Descriptions for the 'structuralObjectClass' and 2771 'governingStructureRule' operational attribute types were added. 2772 2773 The attribute definition of 'subschemaSubentry' was corrected to list 2774 the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order. 2775 2776A.2.3. Section 7 of RFC 2252 2777 2778 Section 7 of RFC 2252 provides definitions of the 'subschema' and 2779 'extensibleObject' object classes. These definitions where 2780 integrated into Section 4.2 and Section 4.3 of this document, 2781 respectively. Section 7 of RFC 2252 also contained the object class 2782 implementation requirement. This was incorporated into Section 7 of 2783 this document. 2784 2785 The specification of 'extensibleObject' was clarified regarding how 2786 it interacts with precluded attributes. 2787 2788A.3. Changes to RFC 2256 2789 2790 This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2791 2256. 2792 2793 Section 5.1 of RFC 2256 provided the definition of the 'objectClass' 2794 attribute type. This was integrated into Section 2.4.1 of this 2795 document. The statement "One of the values is either 'top' or 2796 'alias'" was replaced with statement that one of the values is 'top' 2797 as entries belonging to 'alias' also belong to 'top'. 2798 2799 2800 2801 2802Zeilenga Standards Track [Page 50] 2803 2804RFC 4512 LDAP Models June 2006 2805 2806 2807 Section 5.2 of RFC 2256 provided the definition of the 2808 'aliasedObjectName' attribute type. This was integrated into Section 2809 2.6.2 of this document. 2810 2811 Section 7.1 of RFC 2256 provided the definition of the 'top' object 2812 class. This was integrated into Section 2.4.1 of this document. 2813 2814 Section 7.2 of RFC 2256 provided the definition of the 'alias' object 2815 class. This was integrated into Section 2.6.1 of this document. 2816 2817A.4. Changes to RFC 3674 2818 2819 This document made no substantive change to the 'supportedFeatures' 2820 technical specification provided in RFC 3674. 2821 2822Editor's Address 2823 2824 Kurt D. Zeilenga 2825 OpenLDAP Foundation 2826 2827 EMail: Kurt@OpenLDAP.org 2828 2829 2830 2831 2832 2833 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858Zeilenga Standards Track [Page 51] 2859 2860RFC 4512 LDAP Models June 2006 2861 2862 2863Full Copyright Statement 2864 2865 Copyright (C) The Internet Society (2006). 2866 2867 This document is subject to the rights, licenses and restrictions 2868 contained in BCP 78, and except as set forth therein, the authors 2869 retain all their rights. 2870 2871 This document and the information contained herein are provided on an 2872 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2873 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2874 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2875 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2876 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2877 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2878 2879Intellectual Property 2880 2881 The IETF takes no position regarding the validity or scope of any 2882 Intellectual Property Rights or other rights that might be claimed to 2883 pertain to the implementation or use of the technology described in 2884 this document or the extent to which any license under such rights 2885 might or might not be available; nor does it represent that it has 2886 made any independent effort to identify any such rights. Information 2887 on the procedures with respect to rights in RFC documents can be 2888 found in BCP 78 and BCP 79. 2889 2890 Copies of IPR disclosures made to the IETF Secretariat and any 2891 assurances of licenses to be made available, or the result of an 2892 attempt made to obtain a general license or permission for the use of 2893 such proprietary rights by implementers or users of this 2894 specification can be obtained from the IETF on-line IPR repository at 2895 http://www.ietf.org/ipr. 2896 2897 The IETF invites any interested party to bring to its attention any 2898 copyrights, patents or patent applications, or other proprietary 2899 rights that may cover technology that may be required to implement 2900 this standard. Please address the information to the IETF at 2901 ietf-ipr@ietf.org. 2902 2903Acknowledgement 2904 2905 Funding for the RFC Editor function is provided by the IETF 2906 Administrative Support Activity (IASA). 2907 2908 2909 2910 2911 2912 2913 2914Zeilenga Standards Track [Page 52] 2915 2916