idnits 2.17.1 draft-zeilenga-ldapv3bis-rfc2251-00.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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 document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([10]), 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 151: '...e distinguished name (RDN), which MUST...' RFC 2119 keyword, line 169: '...ing or shadowing MUST ensure that they...' RFC 2119 keyword, line 218: '... Each entry MUST have an objectClass ...' RFC 2119 keyword, line 258: '... Servers MUST NOT permit clients to a...' RFC 2119 keyword, line 268: '... Entries MAY contain, among others, t...' (152 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 2360 has weird spacing: '...for the purpo...' -- 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 (4 July 2000) is 8696 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? 'RFC2251' on line 42 looks like a reference -- Missing reference section? '10' on line 2320 looks like a reference -- Missing reference section? '1' on line 2292 looks like a reference -- Missing reference section? '2' on line 2295 looks like a reference -- Missing reference section? '5' on line 2305 looks like a reference -- Missing reference section? '6' on line 2309 looks like a reference -- Missing reference section? '3' on line 2298 looks like a reference -- Missing reference section? '11' on line 2323 looks like a reference -- Missing reference section? '0' on line 2128 looks like a reference -- Missing reference section? '13' on line 2329 looks like a reference -- Missing reference section? '14' on line 2333 looks like a reference -- Missing reference section? '4' on line 2301 looks like a reference -- Missing reference section? 'RFC 1823' on line 953 looks like a reference -- Missing reference section? '8' on line 2314 looks like a reference -- Missing reference section? '9' on line 2317 looks like a reference -- Missing reference section? '7' on line 2311 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 1114 looks like a reference -- Missing reference section? '12' on line 2326 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 1244 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 1313 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 1399 looks like a reference -- Missing reference section? 'APPLICATION 4' on line 1621 looks like a reference -- Missing reference section? 'APPLICATION 19' on line 1634 looks like a reference -- Missing reference section? 'APPLICATION 5' on line 1636 looks like a reference -- Missing reference section? 'APPLICATION 6' on line 1800 looks like a reference -- Missing reference section? 'APPLICATION 7' on line 1845 looks like a reference -- Missing reference section? 'APPLICATION 8' on line 1891 looks like a reference -- Missing reference section? 'APPLICATION 9' on line 1943 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 1953 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 1964 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 1977 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 2002 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 2035 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 2050 looks like a reference -- Missing reference section? 'APPLICATION 16' on line 2069 looks like a reference -- Missing reference section? 'APPLICATION 23' on line 2127 looks like a reference -- Missing reference section? 'APPLICATION 24' on line 2142 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 39 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Kurt D. Zeilenga 3 Intended Category: Standard Track OpenLDAP Foundation 4 Expires: 4 January 2001 4 July 2000 6 LDAPv3bis Suggestions: 7 Lightweight Directory Access Protocol (v3) 8 10 Status of Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document. 17 Distribution of this memo is unlimited. Technical discussion of this 18 document will take place on the IETF LDAP Extension Working Group 19 mailing list . Please send editorial 20 comments directly to the author . 22 Internet-Drafts are working documents of the Internet Engineering Task 23 Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 32 Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 34 Copyright 2000, The Internet Society. All Rights Reserved. 36 Please see the Copyright section near the end of this document for 37 more information. 39 Forward 41 This Internet Draft suggests a number of updates to "Lightweight 42 Directory Access Protocol (v3)" [RFC2251]. This document is not 43 intended to be published as an RFC but used to identify LDAPv3bis work 44 items. 46 The remainer of this documents incorporates the substantive portion of 47 RFC 2251 text (less status of memo, appendices, etc). Comments and 48 suggested updates to this text are inserted as inline notes prefixed 49 with '//'. 51 // Start RFC-2251 text 53 2. Abstract 55 The protocol described in this document is designed to provide access 56 to directories supporting the X.500 models, while not incurring the 57 resource requirements of the X.500 Directory Access Protocol (DAP). 58 This protocol is specifically targeted at management applications and 59 browser applications that provide read/write interactive access to 60 directories. When used with a directory supporting the X.500 61 protocols, it is intended to be a complement to the X.500 DAP. 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 65 to be interpreted as described in RFC 2119 [10]. 67 Key aspects of this version of LDAP are: 69 - All protocol elements of LDAPv2 (RFC 1777) are supported. The 70 protocol is carried directly over TCP or other transport, bypassing 71 much of the session/presentation overhead of X.500 DAP. 73 // Note that LDAPv3 and LDAPv2 are cannot generally coexist 74 // in the real world due to inconsistent implementation of 75 // LDAPv2 (in particular, character set requirements). 77 - Most protocol data elements can be encoded as ordinary strings 78 (e.g., Distinguished Names). 80 - Referrals to other servers may be returned. 82 // s/servers/directory servers or services/ 84 - SASL mechanisms may be used with LDAP to provide association 85 security services. 87 - Attribute values and Distinguished Names have been internationalized 88 through the use of the ISO 10646 character set. 90 - The protocol can be extended to support new operations, and controls 91 may be used to extend existing operations. 93 - Schema is published in the directory for use by clients. 95 3. Models 96 Interest in X.500 [1] directory technologies in the Internet has led 97 to efforts to reduce the high cost of entry associated with use of 98 these technologies. This document continues the efforts to define 99 directory protocol alternatives, updating the LDAP [2] protocol 100 specification. 102 3.1. Protocol Model 104 The general model adopted by this protocol is one of clients 105 performing protocol operations against servers. In this model, a 106 client transmits a protocol request describing the operation to be 107 performed to a server. The server is then responsible for performing 108 the necessary operation(s) in the directory. Upon completion of the 109 operation(s), the server returns a response containing any results or 110 errors to the requesting client. 112 In keeping with the goal of easing the costs associated with use of 113 the directory, it is an objective of this protocol to minimize the 114 complexity of clients so as to facilitate widespread deployment of 115 applications capable of using the directory. 117 Note that although servers are required to return responses whenever 118 such responses are defined in the protocol, there is no requirement 119 for synchronous behavior on the part of either clients or servers. 120 Requests and responses for multiple operations may be exchanged 121 between a client and server in any order, provided the client 122 eventually receives a response for every request that requires one. 124 In LDAP versions 1 and 2, no provision was made for protocol servers 125 returning referrals to clients. However, for improved performance and 126 distribution this version of the protocol permits servers to return to 127 clients referrals to other servers. This allows servers to offload 128 the work of contacting other servers to progress operations. 130 // note that this offloading is increases the complexity of clients 132 Note that the core protocol operations defined in this document can be 133 mapped to a strict subset of the X.500(1997) directory abstract 134 service, so it can be cleanly provided by the DAP. However there is 135 not a one-to-one mapping between LDAP protocol operations and DAP 136 operations: server implementations acting as a gateway to X.500 137 directories may need to make multiple DAP requests. 139 3.2. Data Model 141 This section provides a brief introduction to the X.500 data model, as 142 used by LDAP. 144 // This section could be moved to a separate document which more 145 // fully described the data model used by LDAP as well as pointing 146 // out differences between the LDAP and X.500 data models. 148 The LDAP protocol assumes there are one or more servers which jointly 149 provide access to a Directory Information Tree (DIT). The tree is 150 made up of entries. Entries have names: one or more attribute values 151 from the entry form its relative distinguished name (RDN), which MUST 152 be unique among all its siblings. The concatenation of the relative 153 distinguished names of the sequence of entries from a particular entry 154 to an immediate subordinate of the root of the tree forms that entry's 155 Distinguished Name (DN), which is unique in the tree. An example of a 156 Distinguished Name is 158 CN=Steve Kille, O=Isode Limited, C=GB 160 // suggest using DC naming to promote DNS based service location 161 // uid=jdoe, dc=Example, dc=COM 162 // as no global infrastructure exists to support geopolitical naming 164 Some servers may hold cache or shadow copies of entries, which can be 165 used to answer search and comparison queries, but will return 166 referrals or contact other servers if modification operations are 167 requested. 169 Servers which perform caching or shadowing MUST ensure that they do 170 not violate any access control constraints placed on the data by the 171 originating server. 173 The largest collection of entries, starting at an entry that is 174 mastered by a particular server, and including all its subordinates 175 and their subordinates, down to the entries which are mastered by 176 different servers, is termed a naming context. The root of the DIT is 177 a DSA-specific Entry (DSE) and not part of any naming context: each 178 server has different attribute values in the root DSE. (DSA is an 179 X.500 term for the directory server). 181 3.2.1. Attributes of Entries 183 Entries consist of a set of attributes. 185 // a non-empty set ... 187 An attribute is a type with one or more associated values. The 188 attribute type is identified by a short descriptive name and an OID 189 (object identifier). 191 // Attributes can have multiple names: 193 // s/a short descriptive name/short descriptive names/ 194 // These names are not globally unique. Suggest replace with: 195 // The attribute is identified by an OID (object identifier) but 196 // usually referred to by one of the attributes types short 197 // descriptive names. 199 The attribute type governs whether there can be more than one value of 200 an attribute of that type in an entry, the syntax to which the values 201 must conform, the kinds of matching which can be performed on values 202 of that attribute, and other functions. 204 An example of an attribute is "mail". There may be one or more values 205 of this attribute, they must be IA5 (ASCII) strings, and they are case 206 insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). 208 // s/bar.com/example.com/ 210 Schema is the collection of attribute type definitions, object class 211 definitions and other information which a server uses to determine how 212 to match a filter or attribute value assertion (in a compare 213 operation) against the attributes of an entry, and whether to permit 214 add and modify operations. The definition of schema for use with LDAP 215 is given in [5] and [6]. Additional schema elements may be defined in 216 other documents. 218 Each entry MUST have an objectClass attribute. The objectClass 219 attribute specifies the object classes of an entry, which along with 220 the system and user schema determine the permitted attributes of an 221 entry. 223 // system and user? 224 // Suggest s/system and user schema/the controlling/ 226 Values of this attribute may be modified by clients, but the 227 objectClass attribute cannot be removed. Servers may restrict the 228 modifications of this attribute to prevent the basic structural class 229 of the entry from being changed (e.g. one cannot change a person into 230 a country). When creating an entry or adding an objectClass value to 231 an entry, all superclasses of the named classes are implicitly added 232 as well if not already present, and the client must supply values for 233 any mandatory attributes of new superclasses. 235 // Does this require the server to modify the value of 236 // objectClass to include superclasses such that when 237 // entry is later returned with complete list? 239 Some attributes, termed operational attributes, are used by servers 240 for administering the directory system itself. They are not returned 241 in search results unless explicitly requested by name. Attributes 243 // s/requested by name/requested/ 244 // per zeilenga-ldapv3bis-opattrs I-D 246 which are not operational, such as "mail", will have their schema and 247 syntax constraints enforced by servers, but servers will generally not 248 make use of their values. 250 // The clause "will have their schema and syntax constraints 251 // enforced by servers" in this sentence, it implies that 252 // operational attributes don't have to conform to schema 253 // and syntax constraints. Suggest the clause be 254 // from this sentence and an additional sentence be added: 255 // "The server shall enforce schema and syntax constraints 256 // upon all attribute types." 258 Servers MUST NOT permit clients to add attributes to an entry unless 259 those attributes are permitted by the object class definitions, the 260 schema controlling that entry (specified in the subschema - see 261 below), or are operational attributes known to that server and used 262 for administrative purposes. Note that there is a particular 263 objectClass 'extensibleObject' defined in [5] which permits all user 264 attributes to be present in an entry. 266 // s/permits all user attributes/permits all defined user attributes/ 268 Entries MAY contain, among others, the following operational 269 attributes, defined in [5]. These attributes are maintained 270 automatically by the server and are not modifiable by clients: 272 - creatorsName: the Distinguished Name of the user who added this 273 entry to the directory. 275 - createTimestamp: the time this entry was added to the directory. 277 - modifiersName: the Distinguished Name of the user who last modified 278 this entry. 280 - modifyTimestamp: the time this entry was last modified. 282 - subschemaSubentry: the Distinguished Name of the subschema entry 283 (or subentry) which controls the schema for this entry. 285 3.2.2. Subschema Entries and Subentries 287 Subschema entries are used for administering information about the 288 directory schema, in particular the object classes and attribute types 289 supported by directory servers. A single subschema entry contains all 290 schema definitions used by entries in a particular part of the 291 directory tree. 293 Servers which follow X.500(93) models SHOULD implement subschema using 294 the X.500 subschema mechanisms, and so these subschemas are not 295 ordinary entries. 297 // Are not all servers are required to implemented X.500(93) 298 // models per 3.3? 300 LDAP clients SHOULD NOT assume that servers implement any of the other 301 aspects of X.500 subschema. 303 // Which aspects of the X.500 subschema may clients assume servers 304 // implement? 306 A server which masters entries and permits clients to modify these 307 entries MUST implement and provide access to these subschema entries, 308 so that its clients may discover the attributes and object classes 309 which are permitted to be present. It is strongly recommended that all 310 other servers implement this as well. 312 // The above should be reworded such that all servers SHOULD publish 313 // subschema for readable entries and MUST publish subschema for 314 // all entries which may be updated. 316 // Insert formal specification for objectclass subschema here or 317 // in related RFC. 318 // Address differences between objectclass subentry and 319 // LDAPSubentry. Address entry (or subentry) issues. 321 The following four attributes MUST be present in all subschema 322 entries: 324 - cn: this attribute MUST be used to form the RDN of the subschema 325 entry. 327 // s/MUST/SHOULD/ to allow servers to avoid naming conflicts 329 - objectClass: the attribute MUST have at least the values "top" and 330 "subschema". 332 - objectClasses: each value of this attribute specifies an object 333 class known to the server. 335 - attributeTypes: each value of this attribute specifies an attribute 336 type known to the server. 338 These are defined in [5]. Other attributes MAY be present in subschema 339 entries, to reflect additional supported capabilities. 341 These include matchingRules, matchingRuleUse, dITStructureRules, 342 dITContentRules, nameForms and ldapSyntaxes. 344 Servers SHOULD provide the attributes createTimestamp and 345 modifyTimestamp in subschema entries, in order to allow clients to 346 maintain their caches of schema information. 348 Clients MUST only retrieve attributes from a subschema entry by 349 requesting a base object search of the entry, where the search filter 350 is "(objectClass=subschema)". (This will allow LDAPv3 servers which 351 gateway to X.500(93) to detect that subentry information is being 352 requested.) 354 // Additional information should be added clarifying how to 355 // locate the subschema subentry controlling an existing entry: 356 // by examining the subschemaSubentry attribute of the entry 357 // locate the subschema subentry which would control an 358 // newly added entry 359 // by examining the subschemaSubentry attribute of the entry 360 // at the root of the naming context. 361 // Additionally, 362 // no mechanism is obtaining necessary subschema for 363 // creating the entry at the root of a naming context. 364 // (chicken and egg problem) 366 // Additionally, a client MUST NOT assume the subschemaSubentry 367 // value applies to any entry other than the Root DSE itself. 368 // See notes regarding Root DSE subschemaSubentry below. 370 3.3. Relationship to X.500 372 This document defines LDAP in terms of X.500 as an X.500 access 373 mechanism. An LDAP server MUST act in accordance with the X.500(1993) 374 series of ITU recommendations when providing the service. 376 // s/MUST/SHOULD/ 377 // 378 // a) The above requirement is ambiguous (all X.500 rec.?) 379 // b) The above requirement is too limiting (disallows servers 380 // from using X.500(1997) recommendations) 381 // c) The above requirement is not necessary to ensure 382 // interoperability between protocol peers (per RFC 2119). 383 // d) This MUST takes precedence over any SHOULD or MAY in 384 // this or other LDAPv3 specification. 386 However, it is not required that an LDAP server make use of any X.500 387 protocols in providing this service, e.g. LDAP can be mapped onto any 388 other directory system so long as the X.500 data and service model as 389 used in LDAP is not violated in the LDAP interface. 391 // This paragraph appears to allow variance in contraction to 392 // the above MUST. Suggest this section be reworded to allow 393 // this protocol to be used with a wide range of directory 394 // systems as long as the LDAP interface is not violated. 396 3.4. Server-specific Data Requirements 398 An LDAP server MUST provide information about itself and other 399 information that is specific to each server. This is represented as a 400 group of attributes located in the root DSE (DSA-Specific Entry), 401 which is named with the zero-length LDAPDN. 403 These attributes are retrievable if a client performs a base object 404 search of the root with filter "(objectClass=*)", 406 // which objectclass(es) are present? if no objectclass, 407 // then client should use an filter which always evaluates 408 // to true. 410 however they are subject to access control restrictions. The root DSE 411 MUST NOT be included if the client performs a subtree search starting 412 from the root. 414 // Many of attributes contained within the root DSE are 415 // operational and hence only returned if requested. 416 // 417 // Servers SHOULD support compare operations upon attributes 418 // of the root DSE. 420 Servers may allow clients to modify these attributes. 422 The following attributes of the root DSE are defined in section 5 of 423 [5]. Additional attributes may be defined in other documents. 425 - namingContexts: naming contexts held in the server. Naming contexts 426 are defined in section 17 of X.501 [6]. 428 // naming contexts were defined above in 3.2. 430 - subschemaSubentry: subschema entries (or subentries) known by this 431 server. 433 // To allow publication of location of subschema entry controlling 434 // root DSE itself and to conform to attribute type's syntax 435 // (single valued) replace above with: 436 // - subschemaSubentry: subschema entry (or subentry) controlling 437 // the root DSE. 438 // See note above regarding locating controlling subschema 440 - altServer: alternative servers in case this one is later 441 unavailable. 443 - supportedExtension: list of supported extended operations. 445 - supportedControl: list of supported controls. 447 - supportedSASLMechanisms: list of supported SASL security features. 449 // s/security features/mechanisms/ 451 - supportedLDAPVersion: LDAP versions implemented by the server. 453 If the server does not master entries and does not know the locations 454 of schema information, the subschemaSubentry attribute is not present 455 in the root DSE. If the server masters directory entries under one or 456 more schema rules, there may be any number of values of the 457 subschemaSubentry attribute in the root DSE. 459 // This paragraph suggests a mechanism for schema discovery 460 // which: 461 // 1) disallows discovery of the root DSE controlling schema 462 // 2) violates the constraints upon subschemaSubentry 463 // 3) is inadequate (only works if DSA has single subschema 464 // which applies to all entries). 465 // 466 // Suggest the above paragraph be replaced with: 467 // 468 // -- subschemaSubentry: the DN of the entry (or subentry) 469 // containing the subschema which controls the root DSE 470 // itself. 471 // 472 // Note: Clients should use the mechanism described in X.Y 473 // to for locating controlling subschema of other entries. 474 // 475 // (as described above). 477 4. Elements of Protocol 479 The LDAP protocol is described using Abstract Syntax Notation 1 480 (ASN.1) [3], and is typically transferred using a subset of ASN.1 481 Basic Encoding Rules [11]. 483 // typically? The protocol is transferred using the subset 484 // of BER known as the Data Encoding Rules. (or does this 485 // belong below). 487 In order to support future extensions to this protocol, clients and 488 servers MUST ignore elements of SEQUENCE encodings whose tags they do 489 not recognize. 491 Note that unlike X.500, each change to the LDAP protocol other than 492 through the extension mechanisms will have a different version number. 493 A client will indicate the version it supports as part of the bind 494 request, described in section 4.2. If a client has not sent a bind, 495 the server MUST assume that version 3 is supported in the client 496 (since version 2 required that the client bind first). 498 Clients may determine the protocol version a server supports by 499 reading the supportedLDAPVersion attribute from the root DSE. Servers 500 which implement version 3 or later versions MUST provide this 501 attribute. Servers which only implement version 2 may not provide 502 this attribute. 504 // or provide a root DSE. 506 4.1. Common Elements 508 This section describes the LDAPMessage envelope PDU (Protocol Data 509 Unit) format, as well as data type definitions which are used in the 510 protocol operations. 512 4.1.1. Message Envelope 514 For the purposes of protocol exchanges, all protocol operations are 515 encapsulated in a common envelope, the LDAPMessage, which is defined 516 as follows: 518 LDAPMessage ::= SEQUENCE { 519 messageID MessageID, 520 protocolOp CHOICE { 521 bindRequest BindRequest, 522 bindResponse BindResponse, 523 unbindRequest UnbindRequest, 524 searchRequest SearchRequest, 525 searchResEntry SearchResultEntry, 526 searchResDone SearchResultDone, 527 searchResRef SearchResultReference, 528 modifyRequest ModifyRequest, 529 modifyResponse ModifyResponse, 530 addRequest AddRequest, 531 addResponse AddResponse, 532 delRequest DelRequest, 533 delResponse DelResponse, 534 modDNRequest ModifyDNRequest, 535 modDNResponse ModifyDNResponse, 536 compareRequest CompareRequest, 537 compareResponse CompareResponse, 538 abandonRequest AbandonRequest, 539 extendedReq ExtendedRequest, 540 extendedResp ExtendedResponse }, 542 // Added ExtendedPartialResponse 543 // Add note below that this CHOICE may be extended. 545 controls [0] Controls OPTIONAL } 547 MessageID ::= INTEGER (0 .. maxInt) 549 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 551 The function of the LDAPMessage is to provide an envelope containing 552 common fields required in all protocol exchanges. At this time the 553 only common fields are the message ID and the controls. 555 If the server receives a PDU from the client in which the LDAPMessage 556 SEQUENCE tag cannot be recognized, the messageID cannot be parsed, the 557 tag of the protocolOp is not recognized as a request, or the encoding 558 structures or lengths of data fields are found to be incorrect, then 559 the server MUST return the notice of disconnection described in 560 section 4.4.1, with resultCode protocolError, and immediately close 561 the connection. In other cases that the server cannot parse the 562 request received by the client, the server MUST return an appropriate 563 response to the request, with the resultCode set to protocolError. 565 If the client receives a PDU from the server which cannot be parsed, 566 the client may discard the PDU, or may abruptly close the connection. 568 The ASN.1 type Controls is defined in section 4.1.12. 570 4.1.1.1. Message ID 572 All LDAPMessage envelopes encapsulating responses contain the 573 messageID value of the corresponding request LDAPMessage. 575 // Add: 576 // Unsolicited notifications, as defined in section 4.4, 577 // MUST have a zero valued message ID. 579 The message ID of a request MUST have a value different from the 580 values of any other requests outstanding in the LDAP session of which 581 this message is a part. 583 // s/a value/a non-zero value/ 584 // a zero value request would generate responses which cannot 585 // easily be distinguished from unsolicited notifications. 587 A client MUST NOT send a second request with the same message ID as an 588 earlier request on the same connection if the client has not received 589 the final response from the earlier request. Otherwise the behavior 590 is undefined. Typical clients increment a counter for each request. 592 A client MUST NOT reuse the message id of an abandonRequest or of the 593 abandoned operation until it has received a response from the server 594 for another request invoked subsequent to the abandonRequest, as the 595 abandonRequest itself does not have a response. 597 // This implies that a server must defer responding to requests 598 // received after an abandon request until after it processed 599 // the abandon request (or completed the operation to be 600 // abandon). 602 4.1.2. String Types 604 The LDAPString is a notational convenience to indicate that, although 605 strings of LDAPString type encode as OCTET STRING types, the ISO 10646 606 [13] character set (a superset of Unicode) is used, encoded following 607 the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm characters 608 which are the same as ASCII (0x0000 through 0x007F) are represented as 609 that same ASCII character in a single byte. The other 611 // s/byte/octet 613 byte values are used to form a variable-length encoding of an 615 // s/byte/octet 617 arbitrary character. 619 LDAPString ::= OCTET STRING 621 The LDAPOID is a notational convenience to indicate that the permitted 622 value of this string is a (UTF-8 encoded) dotted-decimal 623 representation of an OBJECT IDENTIFIER. 625 // A formal, definitive specification for the dotted-decimal 626 // representation should be provided here and then referenced 627 // as needed below and in related documents. 629 LDAPOID ::= OCTET STRING 631 For example, 633 1.3.6.1.4.1.1466.1.2.3 635 4.1.3. Distinguished Name and Relative Distinguished Name 637 An LDAPDN and a RelativeLDAPDN are respectively defined to be the 638 representation of a Distinguished Name and a Relative Distinguished 639 Name after encoding according to the specification in [4], such that 641 ::= 643 ::= 645 where and are as defined in [4]. 647 LDAPDN ::= LDAPString 649 RelativeLDAPDN ::= LDAPString 651 Only Attribute Types can be present in a relative distinguished name 652 component; the options of Attribute Descriptions (next section) MUST 653 NOT be used in specifying distinguished names. 655 4.1.4. Attribute Type 657 An AttributeType takes on as its value the textual string associated 658 with that AttributeType in its specification. 660 AttributeType ::= LDAPString 662 Each attribute type has a unique OBJECT IDENTIFIER which has been 663 assigned to it. This identifier may be written as decimal digits with 664 components separated by periods, e.g. "2.5.4.10". 666 // refer to formal dotted-decimal spec. 668 A specification may also assign one or more textual names for an 669 attribute type. These names MUST begin with a letter, and only 670 contain ASCII letters, digit characters and hyphens. They are case 671 insensitive. (These ASCII characters are identical to ISO 10646 672 characters whose UTF-8 encoding is a single byte between 0x00 and 673 0x7F.) 675 // s/byte/octet/ 677 If the server has a textual name for an attribute type, it MUST use a 678 textual name for attributes returned in search results. The dotted- 679 decimal OBJECT IDENTIFIER is only used if there is no textual name for 680 an attribute type. 682 Attribute type textual names are non-unique, as two different 683 specifications (neither in standards track RFCs) may choose the same 684 name. 686 // Given that textual names are non-unique, a server MUST be allowed 687 // to respond with a OID of the attribute type where it's names are 688 // known to non-unique in the controlling subschema. OR require 689 // names of schema elements must be unique within a particular 690 // subschema. 692 A server which masters or shadows entries SHOULD list all the 693 attribute types it supports in the subschema entries, using the 694 attributeTypes attribute. Servers which support an open-ended set of 695 attributes SHOULD include at least the attributeTypes value for the 696 'objectClass' attribute. Clients MAY retrieve the attributeTypes value 697 from subschema entries in order to obtain the OBJECT IDENTIFIER and 698 other information associated with attribute types. 700 Some attribute type names which are used in this version of LDAP are 701 described in [5]. Servers may implement additional attribute types. 703 4.1.5. Attribute Description 705 An AttributeDescription is a superset of the definition of the 706 AttributeType. It has the same ASN.1 definition, but allows 707 additional options to be specified. They are also case insensitive. 709 AttributeDescription ::= LDAPString 711 A value of AttributeDescription is based on the following BNF: 713 ::= [ ";" ] 715 ::=