idnits 2.17.1 draft-ietf-ldapbis-protocol-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 41 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 54 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope ENUMERATED {' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC1777], [RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 242: '...e distinguished name (RDN), which MUST...' RFC 2119 keyword, line 256: '...ing or shadowing MUST ensure that they...' RFC 2119 keyword, line 292: '... Each entry MUST have an objectClass...' RFC 2119 keyword, line 311: '... Servers MUST NOT permit clients to ...' RFC 2119 keyword, line 319: '... Entries MAY contain, among others, ...' (174 more instances...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: - Change "MUST ignore elements of SEQUENCE encodings whose tags they do not recognize" to "MUST ignore tagged elements of SEQUENCE encodings that they do not recognize" in the first paragraph. - Change "version 2 may not provide this attribute." to "version 2 MAY NOT provide this attribute, or a root DSE." in the third paragraph. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2001) is 8228 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2026' on line 13 looks like a reference -- Missing reference section? 'RFC2119' on line 2112 looks like a reference -- Missing reference section? 'RFC1777' on line 2103 looks like a reference -- Missing reference section? 'RFC2252' on line 2725 looks like a reference -- Missing reference section? '0' on line 2419 looks like a reference -- Missing reference section? 'ISO10646' on line 2085 looks like a reference -- Missing reference section? 'RFC2044' on line 2109 looks like a reference -- Missing reference section? 'RFC2253' on line 2125 looks like a reference -- Missing reference section? '5' on line 2723 looks like a reference -- Missing reference section? '3' on line 2355 looks like a reference -- Missing reference section? 'RFC2255' on line 2129 looks like a reference -- Missing reference section? 'RFC2396' on line 2134 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 2292 looks like a reference -- Missing reference section? 'RFC2222' on line 2115 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 2306 looks like a reference -- Missing reference section? '7' on line 2340 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 2310 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 2312 looks like a reference -- Missing reference section? '1' on line 2420 looks like a reference -- Missing reference section? '2' on line 2354 looks like a reference -- Missing reference section? '4' on line 2356 looks like a reference -- Missing reference section? '6' on line 2339 looks like a reference -- Missing reference section? '8' on line 2341 looks like a reference -- Missing reference section? '9' on line 2342 looks like a reference -- Missing reference section? 'APPLICATION 4' on line 2358 looks like a reference -- Missing reference section? 'APPLICATION 19' on line 2366 looks like a reference -- Missing reference section? 'APPLICATION 5' on line 2368 looks like a reference -- Missing reference section? 'APPLICATION 6' on line 2370 looks like a reference -- Missing reference section? 'APPLICATION 7' on line 2386 looks like a reference -- Missing reference section? 'APPLICATION 8' on line 2388 looks like a reference -- Missing reference section? 'APPLICATION 9' on line 2396 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 2398 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 2400 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 2402 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 2408 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 2410 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 2414 looks like a reference -- Missing reference section? 'APPLICATION 16' on line 2416 looks like a reference -- Missing reference section? 'APPLICATION 23' on line 2418 looks like a reference -- Missing reference section? 'APPLICATION 24' on line 2422 looks like a reference -- Missing reference section? '10' on line 2424 looks like a reference -- Missing reference section? '11' on line 2425 looks like a reference -- Missing reference section? 'RFC1823' on line 2106 looks like a reference -- Missing reference section? 'RFC2234' on line 2118 looks like a reference -- Missing reference section? 'RFC2829' on line 2875 looks like a reference -- Missing reference section? 'RFC2830' on line 2869 looks like a reference -- Missing reference section? 'RFC 1823' on line 2731 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 50 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet-Draft Editor: J. Sermersheim 3 Intended Category: Standard Track Novell, Inc 4 Document: draft-ietf-ldapbis-protocol-03.txt October 2001 5 Obsoletes: RFC 2251 7 Lightweight Directory Access Protocol (v3) 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Distribution of this memo is unlimited. Technical discussion of this 29 document will take place on the IETF LDAP Revision Working Group 30 (LDAPbis) mailing list . Please send 31 editorial comments directly to the editor . 33 Table of Contents 35 1. Status of this Memo..............................................1 36 2. Abstract.........................................................3 37 3. Models...........................................................4 38 3.1. Protocol Model.................................................4 39 3.2. Data Model.....................................................5 40 3.2.1. Attributes of Entries........................................5 41 3.2.2. Subschema Entries and Subentries.............................7 42 3.3. Relationship to X.500..........................................7 43 3.4. Server-specific Data Requirements..............................8 44 4. Elements of Protocol.............................................8 45 4.1. Common Elements................................................9 46 4.1.1. Message Envelope.............................................9 47 4.1.1.1. Message ID................................................10 48 4.1.2. String Types................................................10 49 4.1.3. Distinguished Name and Relative Distinguished Name..........11 50 4.1.4. Attribute Type..............................................11 51 4.1.5. Attribute Description.......................................12 52 4.1.5.1. Binary Option.............................................13 53 4.1.6. Attribute Value.............................................13 55 Lightweight Directory Access Protocol Version 3 57 4.1.7. Attribute Value Assertion...................................14 58 4.1.8. Attribute...................................................14 59 4.1.9. Matching Rule Identifier....................................14 60 4.1.10. Result Message.............................................15 61 4.1.11. Referral...................................................17 62 4.1.12. Controls...................................................18 63 4.2. Bind Operation................................................19 64 4.2.1. Sequencing of the Bind Request..............................20 65 4.2.2. Authentication and Other Security Services..................20 66 4.2.3. Bind Response...............................................21 67 4.3. Unbind Operation..............................................22 68 4.4. Unsolicited Notification......................................22 69 4.4.1. Notice of Disconnection.....................................23 70 4.5. Search Operation..............................................23 71 4.5.1. Search Request..............................................23 72 4.5.2. Search Result...............................................27 73 4.5.3. Continuation References in the Search Result................28 74 4.6. Modify Operation..............................................30 75 4.7. Add Operation.................................................31 76 4.8. Delete Operation..............................................32 77 4.9. Modify DN Operation...........................................33 78 4.10. Compare Operation............................................34 79 4.11. Abandon Operation............................................34 80 4.12. Extended Operation...........................................35 81 5. Protocol Element Encodings and Transfer.........................36 82 5.1. Mapping Onto BER-based Transport Services.....................36 83 5.2. Transfer Protocols............................................36 84 5.2.1. Transmission Control Protocol (TCP).........................36 85 6. Implementation Guidelines.......................................36 86 6.1. Server Implementations........................................36 87 6.2. Client Implementations........................................37 88 7. Security Considerations.........................................37 89 8. Acknowledgements................................................37 90 9. Bibliography....................................................38 91 10. Editor's Address...............................................39 92 Appendix A - Complete ASN.1 Definition.............................40 93 Appendix B - Change History........................................45 94 B.1 Editorial......................................................45 95 B.2 Section 1......................................................45 96 B.3 Section 9......................................................45 97 B.4 Section 4.1.6..................................................45 98 B.5 Section 4.1.7..................................................45 99 B.6 Sections 4.2, 4.9, 4.10........................................45 100 B.7 Sections 4.5 and Appendix A....................................46 101 B.8 Section 3.4....................................................46 102 B.9 Section 4.1.12.................................................46 103 B.10 Section 4.2...................................................46 104 B.11 Section 4.2.(various).........................................46 105 B.12 Section 4.2.2.................................................46 106 B.13 Section 4.5.2.................................................46 107 B.14 Section 4.....................................................46 108 B.15 Section 4.1.8.................................................47 109 B.17 Section 4.1.11................................................47 110 B.18 Section 4.1.12................................................47 112 Lightweight Directory Access Protocol Version 3 114 B.19 Section 4.4...................................................47 115 B.20 Section 4.5.1.................................................47 116 B.21 Section 4.5.3.................................................48 117 B.22 Section 4.6...................................................48 118 B.23 Section 4.7...................................................48 119 B.24 Section 4.11..................................................48 120 Appendix C - Outstanding Work Items................................48 121 C.1 Integrate result codes draft...................................48 122 C.2 Section 3.1....................................................48 123 C.3 Section 4......................................................48 124 C.4 Section 4.1.1..................................................49 125 C.5 Section 4.1.1.1................................................49 126 C.6 Section 4.1.2..................................................49 127 C.7 Section 4.1.4..................................................49 128 C.8 Section 4.1.5..................................................49 129 C.9 Section 4.1.5.1................................................49 130 C.11 Section 4.1.7.................................................50 131 C.13 Section 4.1.11................................................50 132 C.14 Section 4.1.12................................................50 133 C.15 Section 4.2...................................................50 134 C.17 Section 4.2.2.................................................50 135 C.18 Section 4.2.3.................................................50 136 C.19 Section 4.3...................................................51 137 C.20 Section 4.4...................................................51 138 C.21 Section 4.5.1.................................................51 139 C.22 Section 4.5.2.................................................51 140 C.23 Section 4.5.3.................................................51 141 C.24 Section 4.5.3.1...............................................51 142 C.25 Section 4.6...................................................51 143 C.26 Section 4.7...................................................52 144 C.27 Section 4.10..................................................52 145 C.28 Section 4.11..................................................52 146 C.29 Section 4.12..................................................52 147 C.30 Section 5.1...................................................52 148 C.31 Section 5.2.1.................................................52 149 C.32 Section 6.1...................................................52 150 C.33 Section 7.....................................................52 152 2. Abstract 154 The protocol described in this document is designed to provide access 155 to directories supporting the [X.500] models, while not incurring the 156 resource requirements of the X.500 Directory Access Protocol (DAP). 157 This protocol is specifically targeted at management applications and 158 browser applications that provide read/write interactive access to 159 directories. When used with a directory supporting the X.500 160 protocols, it is intended to be a complement to the X.500 DAP. 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 164 to be interpreted as described in [RFC2119]. 166 Key aspects of this version of LDAP are: 168 Lightweight Directory Access Protocol Version 3 170 - All protocol elements of LDAPv2 [RFC1777] are supported. The 171 protocol is carried directly over TCP or other transport, 172 bypassing much of the session/presentation overhead of X.500 DAP. 174 - Most protocol data elements can be encoded as ordinary strings 175 (e.g., Distinguished Names). 177 - Referrals to other servers may be returned. 179 - SASL mechanisms may be used with LDAP to provide association 180 security services. 182 - Attribute values and Distinguished Names have been 183 internationalized through the use of the ISO 10646 character set. 185 - The protocol can be extended to support new operations, and 186 controls may be used to extend existing operations. 188 - Schema is published in the directory to be used by clients. 190 3. Models 192 Interest in X.500 directory technologies in the Internet has led to 193 efforts to reduce the high cost of entry associated with use of these 194 technologies. This document continues the efforts to define directory 195 protocol alternatives, updating the LDAPv2 protocol specification. 197 3.1. Protocol Model 199 The general model adopted by this protocol is one of clients 200 performing protocol operations against servers. In this model, a 201 client transmits a protocol request describing the operation to be 202 performed to a server. The server is then responsible for performing 203 the necessary operation(s) in the directory. Upon completion of the 204 operation(s), the server returns a response containing any results or 205 errors to the requesting client. 207 In keeping with the goal of easing the costs associated with use of 208 the directory, it is an objective of this protocol to minimize the 209 complexity of clients so as to facilitate widespread deployment of 210 applications capable of using the directory. 212 Note that although servers are required to return responses whenever 213 such responses are defined in the protocol, there is no requirement 214 for synchronous behavior on the part of either clients or servers. 215 Requests and responses for multiple operations may be exchanged 216 between a client and server in any order, provided the client 217 eventually receives a response for every request that requires one. 219 In LDAP versions 1 and 2, no provision was made for protocol servers 220 returning referrals to clients. However, for improved performance and 221 distribution, this version of the protocol permits servers to return 222 to clients, referrals to other servers. This allows servers to 223 offload the work of contacting other servers to progress operations. 225 Lightweight Directory Access Protocol Version 3 227 Note that the core protocol operations defined in this document can 228 be mapped to a strict subset of the X.500(1997) directory abstract 229 service, so it can be cleanly provided by the DAP. However there is 230 not a one-to-one mapping between LDAP protocol operations and DAP 231 operations: server implementations acting as a gateway to X.500 232 directories may need to make multiple DAP requests. 234 3.2. Data Model 236 This section provides a brief introduction to the X.500 data model, 237 as used by LDAP. 239 The LDAP protocol assumes there are one or more servers which jointly 240 provide access to a Directory Information Tree (DIT). The tree is 241 made up of entries. Entries have names: one or more attribute values 242 from the entry form its relative distinguished name (RDN), which MUST 243 be unique among all its siblings. The concatenation of the relative 244 distinguished names of the sequence of entries from a particular 245 entry to an immediate subordinate of the root of the tree forms that 246 entry's Distinguished Name (DN), which is unique in the tree. An 247 example of a Distinguished Name is: 249 CN=Steve Kille, O=Isode Limited, C=GB 251 Some servers may hold cache or shadow copies of entries, which can be 252 used to answer search and comparison queries, but will return 253 referrals or contact other servers if modification operations are 254 requested. 256 Servers that perform caching or shadowing MUST ensure that they do 257 not violate any access control constraints placed on the data by the 258 originating server. 260 The largest collection of entries, starting at an entry that is 261 mastered by a particular server, and including all its subordinates 262 and their subordinates, down to the entries which are mastered by 263 different servers, is termed a naming context. The root of the DIT is 264 a DSA-specific Entry (DSE) and not part of any naming context: each 265 server has different attribute values in the root DSE. (DSA is an 266 X.500 term for the directory server). 268 3.2.1. Attributes of Entries 270 Entries consist of a set of attributes. An attribute is a type with 271 one or more associated values. The attribute type is identified by a 272 short descriptive name and an OID (object identifier). The attribute 273 type governs whether there can be more than one value of an attribute 274 of that type in an entry, the syntax to which the values must 275 conform, the kinds of matching which can be performed on values of 276 that attribute, and other functions. 278 Lightweight Directory Access Protocol Version 3 280 An example of an attribute is "mail". There may be one or more values 281 of this attribute, they must be IA5 (ASCII) strings, and they are 282 case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). 284 Schema is the collection of attribute type definitions, object class 285 definitions and other information which a server uses to determine 286 how to match a filter or attribute value assertion (in a compare 287 operation) against the attributes of an entry, and whether to permit 288 add and modify operations. The definition of schema for use with LDAP 289 is given in [RFC2252] and [X.501]. Additional schema elements may be 290 defined in other documents. 292 Each entry MUST have an objectClass attribute. The objectClass 293 attribute specifies the object classes of an entry, which along with 294 the system and user schema determine the permitted attributes of an 295 entry. Values of this attribute may be modified by clients, but the 296 objectClass attribute cannot be removed. Servers may restrict the 297 modifications of this attribute to prevent the basic structural class 298 of the entry from being changed (e.g. one cannot change a person into 299 a country). When creating an entry or adding an objectClass value to 300 an entry, all superclasses of the named classes are implicitly added 301 as well if not already present, and the client must supply values for 302 any mandatory attributes of new superclasses. 304 Some attributes, termed operational attributes, are used by servers 305 for administering the directory system itself. They are not returned 306 in search results unless explicitly requested by name. Attributes 307 which are not operational, such as "mail", will have their schema and 308 syntax constraints enforced by servers, but servers will generally 309 not make use of their values. 311 Servers MUST NOT permit clients to add attributes to an entry unless 312 those attributes are permitted by the object class definitions, the 313 schema controlling that entry (specified in the subschema � see 314 below), or are operational attributes known to that server and used 315 for administrative purposes. Note that there is a particular 316 objectClass 'extensibleObject' defined in [RFC2252] which permits all 317 user attributes to be present in an entry. 319 Entries MAY contain, among others, the following operational 320 attributes, defined in [RFC2252]. These attributes are maintained 321 automatically by the server and are not modifiable by clients: 323 - creatorsName: the Distinguished Name of the user who added this 324 entry to the directory. 326 - createTimestamp: the time this entry was added to the directory. 328 - modifiersName: the Distinguished Name of the user who last 329 modified this entry. 331 - modifyTimestamp: the time this entry was last modified. 333 Lightweight Directory Access Protocol Version 3 335 - subschemaSubentry: the Distinguished Name of the subschema entry 336 (or subentry) which controls the schema for this entry. 338 3.2.2. Subschema Entries and Subentries 340 Subschema entries are used for administering information about the 341 directory schema, in particular the object classes and attribute 342 types supported by directory servers. A single subschema entry 343 contains all schema definitions used by entries in a particular part 344 of the directory tree. 346 Servers which follow X.500(93) models SHOULD implement subschema 347 using the X.500 subschema mechanisms, and so these subschemas are not 348 ordinary entries. LDAP clients SHOULD NOT assume that servers 349 implement any of the other aspects of X.500 subschema. A server which 350 masters entries and permits clients to modify these entries MUST 351 implement and provide access to these subschema entries, so that its 352 clients may discover the attributes and object classes which are 353 permitted to be present. It is strongly recommended that all other 354 servers implement this as well. 356 The following four attributes MUST be present in all subschema 357 entries: 359 - cn: this attribute MUST be used to form the RDN of the subschema 360 entry. 362 - objectClass: the attribute MUST have at least the values "top" and 363 "subschema". 365 - objectClasses: each value of this attribute specifies an object 366 class known to the server. 368 - attributeTypes: each value of this attribute specifies an 369 attribute type known to the server. 371 These are defined in [RFC2252]. Other attributes MAY be present in 372 subschema entries, to reflect additional supported capabilities. 374 These include matchingRules, matchingRuleUse, dITStructureRules, 375 dITContentRules, nameForms and ldapSyntaxes. 377 Servers SHOULD provide the attributes createTimestamp and 378 modifyTimestamp in subschema entries, in order to allow clients to 379 maintain their caches of schema information. 381 Clients MUST only retrieve attributes from a subschema entry by 382 requesting a base object search of the entry, where the search filter 383 is "(objectClass=subschema)". This will allow LDAPv3 servers which 384 gateway to X.500(93) to detect that subentry information is being 385 requested. 387 3.3. Relationship to X.500 389 Lightweight Directory Access Protocol Version 3 391 This document defines LDAP in terms of X.500 as an X.500 access 392 mechanism. An LDAP server MUST act in accordance with the X.500(1993) 393 series of ITU recommendations when providing the service. However, it 394 is not required that an LDAP server make use of any X.500 protocols 395 in providing this service, e.g. LDAP can be mapped onto any other 396 directory system so long as the X.500 data and service model as used 397 in LDAP is not violated in the LDAP interface. 399 3.4. Server-specific Data Requirements 401 An LDAP server MUST provide information about itself and other 402 information that is specific to each server. This is represented as a 403 group of attributes located in the root DSE (DSA-Specific Entry), 404 which is named with the zero-length LDAPDN. These attributes are 405 retrievable if a client performs a base object search of the root 406 with filter "(objectClass=*)", however they are subject to access 407 control restrictions. The root DSE MUST NOT be included if the client 408 performs a subtree search starting from the root. 410 Servers may allow clients to modify these attributes. 412 The following attributes of the root DSE are defined in section 5 of 413 [RFC2252]. Additional attributes may be defined in other documents. 415 - namingContexts: naming contexts held in the server. Naming 416 contexts are defined in section 17 of [X.501]. 418 - subschemaSubentry: subschema entry (or subentry) holding the 419 schema for the root DSE. 421 - altServer: alternative servers in case this one is later 422 unavailable. 424 - supportedExtension: list of supported extended operations. 426 - supportedControl: list of supported controls. 428 - supportedSASLMechanisms: list of supported SASL security features. 430 - supportedLDAPVersion: LDAP versions implemented by the server. 432 If the server does not master entries and does not know the locations 433 of schema information, the subschemaSubentry attribute is not present 434 in the root DSE. If the server masters directory entries under one or 435 more schema rules, the schema for each entry is found by reading the 436 subschemaSubentry attribute for that entry. 438 4. Elements of Protocol 440 The LDAP protocol is described using Abstract Syntax Notation 1 441 (ASN.1) [X.680], and is transferred using a subset of ASN.1 Basic 442 Encoding Rules [X.690] In order to support future extensions to this 443 protocol, clients and servers MUST ignore elements of SEQUENCE 445 Lightweight Directory Access Protocol Version 3 447 encodings whose tags they do not recognize. Section 5.1 specifies the 448 encoding rules for the LDAP protocol. 450 Note that unlike X.500, each change to the LDAP protocol other than 451 through the extension mechanisms will have a different version 452 number. A client will indicate the version it supports as part of the 453 bind request, described in section 4.2. If a client has not sent a 454 bind, the server MUST assume that version 3 or later is supported in 455 the client (since version 2 required that the client bind first). 457 Clients may determine the protocol versions a server supports by 458 reading the supportedLDAPVersion attribute from the root DSE. Servers 459 which implement version 3 or later versions MUST provide this 460 attribute. Servers which only implement version 2 may not provide 461 this attribute. 463 4.1. Common Elements 465 This section describes the LDAPMessage envelope PDU (Protocol Data 466 Unit) format, as well as data type definitions, which are used in the 467 protocol operations. 469 4.1.1. Message Envelope 471 For the purposes of protocol exchanges, all protocol operations are 472 encapsulated in a common envelope, the LDAPMessage, which is defined 473 as follows: 475 LDAPMessage ::= SEQUENCE { 476 messageID MessageID, 477 protocolOp CHOICE { 478 bindRequest BindRequest, 479 bindResponse BindResponse, 480 unbindRequest UnbindRequest, 481 searchRequest SearchRequest, 482 searchResEntry SearchResultEntry, 483 searchResDone SearchResultDone, 484 searchResRef SearchResultReference, 485 modifyRequest ModifyRequest, 486 modifyResponse ModifyResponse, 487 addRequest AddRequest, 488 addResponse AddResponse, 489 delRequest DelRequest, 490 delResponse DelResponse, 491 modDNRequest ModifyDNRequest, 492 modDNResponse ModifyDNResponse, 493 compareRequest CompareRequest, 494 compareResponse CompareResponse, 495 abandonRequest AbandonRequest, 496 extendedReq ExtendedRequest, 497 extendedResp ExtendedResponse }, 498 controls [0] Controls OPTIONAL } 500 MessageID ::= INTEGER (0 .. maxInt) 502 Lightweight Directory Access Protocol Version 3 504 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 506 The function of the LDAPMessage is to provide an envelope containing 507 common fields required in all protocol exchanges. At this time the 508 only common fields are the message ID and the controls. 510 If the server receives a PDU from the client in which the LDAPMessage 511 SEQUENCE tag cannot be recognized, the messageID cannot be parsed, 512 the tag of the protocolOp is not recognized as a request, or the 513 encoding structures or lengths of data fields are found to be 514 incorrect, then the server MUST return the notice of disconnection 515 described in section 4.4.1, with resultCode protocolError, and 516 immediately close the connection. In other cases that the server 517 cannot parse the request received by the client, the server MUST 518 return an appropriate response to the request, with the resultCode 519 set to protocolError. 521 If the client receives a PDU from the server, which cannot be parsed, 522 the client may discard the PDU, or may abruptly close the connection. 524 The ASN.1 type Controls is defined in section 4.1.12. 526 4.1.1.1. Message ID 528 All LDAPMessage envelopes encapsulating responses contain the 529 messageID value of the corresponding request LDAPMessage. 531 The message ID of a request MUST have a value different from the 532 values of any other requests outstanding in the LDAP session of which 533 this message is a part. 535 A client MUST NOT send a second request with the same message ID as 536 an earlier request on the same connection if the client has not 537 received the final response from the earlier request. Otherwise the 538 behavior is undefined. Typical clients increment a counter for each 539 request. 541 A client MUST NOT reuse the message id of an abandonRequest or of the 542 abandoned operation until it has received a response from the server 543 for another request invoked subsequent to the abandonRequest, as the 544 abandonRequest itself does not have a response. 546 4.1.2. String Types 548 The LDAPString is a notational convenience to indicate that, although 549 strings of LDAPString type encode as OCTET STRING types, the 550 [ISO10646] character set (a superset of Unicode) is used, encoded 551 following the UTF-8 algorithm [RFC2044]. Note that in the UTF-8 552 algorithm characters which are the same as ASCII (0x0000 through 553 0x007F) are represented as that same ASCII character in a single 554 byte. The other byte values are used to form a variable-length 555 encoding of an arbitrary character. 557 Lightweight Directory Access Protocol Version 3 559 LDAPString ::= OCTET STRING 561 The LDAPOID is a notational convenience to indicate that the 562 permitted value of this string is a (UTF-8 encoded) dotted-decimal 563 representation of an OBJECT IDENTIFIER. 565 LDAPOID ::= OCTET STRING 567 For example, 569 1.3.6.1.4.1.1466.1.2.3 571 4.1.3. Distinguished Name and Relative Distinguished Name 573 An LDAPDN and a RelativeLDAPDN are respectively defined to be the 574 representation of a Distinguished Name and a Relative Distinguished 575 Name after encoding according to the specification in [RFC2253], such 576 that: 578 distinguished-name = name 580 relative-distinguished-name = name-component 582 where name and name-component are as defined in [RFC2253]. 584 LDAPDN ::= LDAPString 586 RelativeLDAPDN ::= LDAPString 588 Only Attribute Types can be present in a relative distinguished name 589 component--the options of Attribute Descriptions (next section) MUST 590 NOT be used in specifying distinguished names. 592 4.1.4. Attribute Type 594 An AttributeType takes on as its value the textual string associated 595 with that AttributeType in its specification. 597 AttributeType ::= LDAPString 599 Each attribute type has a unique OBJECT IDENTIFIER which has been 600 assigned to it. This identifier may be written as decimal digits with 601 components separated by periods, e.g. "2.5.4.10". 603 A specification may also assign one or more textual names for an 604 attribute type. These names MUST begin with a letter, and only 605 contain ASCII letters, digit characters and hyphens. They are case 606 insensitive. These ASCII characters are identical to ISO 10646 607 characters whose UTF-8 encoding is a single byte between 0x00 and 608 0x7F. 610 If the server has a textual name for an attribute type, it MUST use a 611 textual name for attributes returned in search results. The dotted- 613 Lightweight Directory Access Protocol Version 3 615 decimal OBJECT IDENTIFIER is only used if there is no textual name 616 for an attribute type. 618 Attribute type textual names are non-unique, as two different 619 specifications (neither in standards track RFCs) may choose the same 620 name. 622 A server which masters or shadows entries SHOULD list all the 623 attribute types it supports in the subschema entries, using the 624 attributeTypes attribute. Servers which support an open-ended set of 625 attributes SHOULD include at least the attributeTypes value for the 626 'objectClass' attribute. Clients MAY retrieve the attributeTypes 627 value from subschema entries in order to obtain the OBJECT IDENTIFIER 628 and other information associated with attribute types. 630 Some attribute type names which are used in this version of LDAP are 631 described in [RFC2252]. Servers may implement additional attribute 632 types. 634 4.1.5. Attribute Description 636 An AttributeDescription is a superset of the definition of the 637 AttributeType. It has the same ASN.1 definition, but allows 638 additional options to be specified. They are also case insensitive. 640 AttributeDescription ::= LDAPString 642 A value of AttributeDescription is based on the following BNF: 644 ::= [ ";" ] 646 ::=