idnits 2.17.1 draft-ietf-asid-ldapv3-protocol-09.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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 43 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 68 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** 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 120: '...e distinguished name (RDN), which MUST...' RFC 2119 keyword, line 134: '...ing or shadowing MUST ensure that they...' RFC 2119 keyword, line 168: '... Each entry MUST have an objectClass...' RFC 2119 keyword, line 187: '... Servers MUST NOT permit clients to ...' RFC 2119 keyword, line 195: '... Entries MAY contain, among others, ...' (136 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 29 has weird spacing: '...listing conta...' -- 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 (November 1997) is 9631 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? '10' on line 2180 looks like a reference -- Missing reference section? '1' on line 2176 looks like a reference -- Missing reference section? '2' on line 2114 looks like a reference -- Missing reference section? '5' on line 2098 looks like a reference -- Missing reference section? '6' on line 2099 looks like a reference -- Missing reference section? '3' on line 2115 looks like a reference -- Missing reference section? '11' on line 2181 looks like a reference -- Missing reference section? '0' on line 2175 looks like a reference -- Missing reference section? '13' on line 1892 looks like a reference -- Missing reference section? '14' on line 1895 looks like a reference -- Missing reference section? '4' on line 2116 looks like a reference -- Missing reference section? '8' on line 2101 looks like a reference -- Missing reference section? '9' on line 2102 looks like a reference -- Missing reference section? '7' on line 2100 looks like a reference -- Missing reference section? 'APPLICATION 0' on line 2056 looks like a reference -- Missing reference section? '12' on line 1889 looks like a reference -- Missing reference section? 'APPLICATION 1' on line 2070 looks like a reference -- Missing reference section? 'APPLICATION 2' on line 2074 looks like a reference -- Missing reference section? 'APPLICATION 3' on line 2075 looks like a reference -- Missing reference section? 'APPLICATION 4' on line 2118 looks like a reference -- Missing reference section? 'APPLICATION 19' on line 2126 looks like a reference -- Missing reference section? 'APPLICATION 5' on line 2128 looks like a reference -- Missing reference section? 'APPLICATION 6' on line 2129 looks like a reference -- Missing reference section? 'APPLICATION 7' on line 2142 looks like a reference -- Missing reference section? 'APPLICATION 8' on line 2144 looks like a reference -- Missing reference section? 'APPLICATION 9' on line 2152 looks like a reference -- Missing reference section? 'APPLICATION 10' on line 2154 looks like a reference -- Missing reference section? 'APPLICATION 11' on line 2156 looks like a reference -- Missing reference section? 'APPLICATION 12' on line 2158 looks like a reference -- Missing reference section? 'APPLICATION 13' on line 2164 looks like a reference -- Missing reference section? 'APPLICATION 14' on line 2166 looks like a reference -- Missing reference section? 'APPLICATION 15' on line 2170 looks like a reference -- Missing reference section? 'APPLICATION 16' on line 2172 looks like a reference -- Missing reference section? 'APPLICATION 23' on line 2174 looks like a reference -- Missing reference section? 'APPLICATION 24' on line 2178 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 37 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Wahl 3 INTERNET-DRAFT Critical Angle Inc. 4 Replaces: RFC 1777 T. Howes 5 Netscape Communications Corp. 6 S. Kille 7 Isode Limited 8 Expires in six months from November 1997 9 Intended Category: Standards Track 11 Lightweight Directory Access Protocol (v3) 12 14 Table of Contents - see end of document. 16 1. Status of this Memo 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 20 its working groups. Note that other groups may also distribute working 21 documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 31 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 33 2. Abstract 35 The protocol described in this document is designed to provide access 36 to directories supporting the X.500 models, while not incurring the 37 resource requirements of the X.500 Directory Access Protocol (DAP). 38 This protocol is specifically targeted at management applications and 39 browser applications that provide read/write interactive access to 40 directories. When used with a directory supporting the X.500 41 protocols, it is intended to be a complement to the X.500 DAP. 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document 45 are to be interpreted as described in RFC 2119 [10]. 47 Key aspects of this version of LDAP are: 49 - All protocol elements of LDAPv2 (RFC 1777) are supported. The 50 protocol is carried directly over TCP or other transport, bypassing 51 much of the session/presentation overhead of X.500 DAP. 53 - Most protocol data elements can be encoded as ordinary strings 54 (e.g., Distinguished Names). 56 - Referrals to other servers may be returned. 58 - SASL mechanisms may be used with LDAP to provide association 59 security services. 61 - Attribute values and Distinguished Names have been internationalized 62 through the use of the ISO 10646 character set. 64 - The protocol can be extended to support new operations, and controls 65 may be used to extend existing operations. 67 - Schema is published in the directory for use by clients. 69 3. Models 71 Interest in X.500 [1] directory technologies in the Internet has led 72 to efforts to reduce the high cost of entry associated with use of 73 these technologies. This document continues the efforts to define 74 directory protocol alternatives, updating the LDAP [2] protocol 75 specification. 77 3.1. Protocol Model 79 The general model adopted by this protocol is one of clients 80 performing protocol operations against servers. In this model, a 81 client transmits a protocol request describing the operation to be 82 performed to a server. The server is then responsible for performing 83 the necessary operation(s) in the directory. Upon completion of 84 the operation(s), the server returns a response containing any results 85 or errors to the requesting client. 87 In keeping with the goal of easing the costs associated with use of 88 the directory, it is an objective of this protocol to minimize the 89 complexity of clients so as to facilitate widespread deployment of 90 applications capable of using the directory. 92 Note that although servers are required to return responses whenever 93 such responses are defined in the protocol, there is no requirement 94 for synchronous behavior on the part of either clients or servers. 95 Requests and responses for multiple operations may be exchanged 96 between a client and server in any order, provided the client 97 eventually receives a response for every request that requires one. 99 In LDAP versions 1 and 2, no provision was made for protocol servers 100 returning referrals to clients. However, for improved performance and 101 distribution this version of the protocol permits servers to return to 102 clients referrals to other servers. This allows servers to offload 103 the work of contacting other servers to progress operations. 105 Note that the core protocol operations defined in this document can be 106 mapped to a strict subset of the X.500(1997) directory abstract 107 service, so it can be cleanly provided by the DAP. However there is 108 not a one-to-one mapping between LDAP protocol operations and DAP 109 operations: server implementations acting as a gateway to X.500 110 directories may need to make multiple DAP requests. 112 3.2. Data Model 114 This section provides a brief introduction to the X.500 data model, as 115 used by LDAP. 117 The LDAP protocol assumes there are one or more servers which jointly 118 provide access to a Directory Information Tree (DIT). The tree is 119 made up of entries. Entries have names: one or more attribute values 120 from the entry form its relative distinguished name (RDN), which MUST 121 be unique among all its siblings. The concatenation of the relative 122 distinguished names of the sequence of entries from a particular 123 entry to an immediate subordinate of the root of the tree forms that 124 entry's Distinguished Name (DN), which is unique in the tree. An 125 example of a Distinguished Name is 127 CN=Steve Kille, O=Isode Limited, C=GB 129 Some servers may hold cache or shadow copies of entries, which can be 130 used to answer search and comparison queries, but will return 131 referrals or contact other servers if modification operations are 132 requested. 134 Servers which perform caching or shadowing MUST ensure that they do 135 not violate any access control constraints placed on the data by the 136 originating server. 138 The largest collection of entries, starting at an entry that is 139 mastered by a particular server, and including all its subordinates 140 and their subordinates, down to the entries which are mastered by 141 different servers, is termed a naming context. The root of the DIT 142 is a DSA-specific Entry (DSE) and not part of any naming context: 143 each server has different attribute values in the root DSE. (DSA is 144 an X.500 term for the directory server). 146 3.2.1. Attributes of Entries 148 Entries consist of a set of attributes. An attribute is a type with 149 one or more associated values. The attribute type is identified by a 150 short descriptive name and an OID (object identifier). The attribute 151 type governs whether there can be more than one value of an 152 attribute of that type in an entry, the syntax to which the values 153 must conform, the kinds of matching which can be performed on values 154 of that attribute, and other functions. 156 An example of an attribute is "mail". There may be one or more values 157 of this attribute, they must be IA5 (ASCII) strings, and they are 158 case insensitive (e.g. "foo@bar.com" will match "FOO@BAR.COM"). 160 Schema is the collection of attribute type definitions, object class 161 definitions and other information which a server uses to determine 162 how to match a filter or attribute value assertion (in a compare 163 operation) against the attributes of an entry, and whether to permit 164 add and modify operations. The definition of schema for use with 165 LDAP is given in [5] and [6]. Additional schema elements may be 166 defined in other documents. 168 Each entry MUST have an objectClass attribute. The objectClass 169 attribute specifies the object classes of an entry, which along with 170 the system and user schema determine the permitted attributes of an 171 entry. Values of this attribute may be modified by clients, but the 172 objectClass attribute cannot be removed. Servers may restrict the 173 modifications of this attribute to prevent the basic structural 174 class of the entry from being changed (e.g. one cannot change a 175 person into a country). When creating an entry or adding an 176 objectClass value to an entry, all superclasses of the named classes 177 are implicitly added as well if not already present, and the client 178 must supply values for any mandatory attributes of new superclasses. 180 Some attributes, termed operational attributes, are used by servers 181 for administering the directory system itself. They are not returned 182 in search results unless explicitly requested by name. Attributes 183 which are not operational, such as "mail", will have their schema and 184 syntax constraints enforced by servers, but servers will generally 185 not make use of their values. 187 Servers MUST NOT permit clients to add attributes to an entry unless 188 those attributes are permitted by the object class definitions, the 189 schema controlling that entry (specified in the subschema - see 190 below), or are operational attributes known to that server and used 191 for administrative purposes. Note that there is a particular 192 objectClass 'extensibleObject' defined in [5] which permits all user 193 attributes to be present in an entry. 195 Entries MAY contain, among others, the following operational 196 attributes, defined in [5]. These attributes are maintained 197 automatically by the server and are not modifiable by clients: 199 - creatorsName: the Distinguished Name of the user who added this 200 entry to the directory. 202 - createTimestamp: the time this entry was added to the directory. 204 - modifiersName: the Distinguished Name of the user who last modified 205 this entry. 207 - modifyTimestamp: the time this entry was last modified. 209 - subschemaSubentry: the Distinguished Name of the subschema entry 210 (or subentry) which controls the schema for this entry. 212 3.2.2. Subschema Entries and Subentries 214 Subschema entries are used for administering information about the 215 directory schema, in particular the object classes and attribute types 216 supported by directory servers. A single subschema entry contains 217 all schema definitions used by entries in a particular part of the 218 directory tree. 220 Servers which follow X.500(93) models SHOULD implement subschema 221 using the X.500 subschema mechanisms, and so these subschemas are not 222 ordinary entries. LDAP clients SHOULD NOT assume that servers 223 implement any of the other aspects of X.500 subschema. 224 A server which masters entries and permits clients to modify these 225 entries MUST implement and provide access to these subschema entries, 226 so that its clients may discover the attributes and object classes 227 which are permitted to be present. It is strongly recommended that 228 all other servers implement this as well. 230 The following four attributes MUST be present in all subschema 231 entries: 233 - cn: this attribute MUST be used to form the RDN of the subschema 234 entry. 236 - objectClass: the attribute MUST have at least the values "top" and 237 "subschema". 239 - objectClasses: each value of this attribute specifies an object 240 class known to the server. 242 - attributeTypes: each value of this attribute specifies an attribute 243 type known to the server. 245 These are defined in [5]. Other attributes MAY be present in subschema 246 entries, to reflect additional supported capabilities. These include 247 matchingRules, matchingRuleUse, dITStructureRules, dITContentRules, 248 nameForms and ldapSyntaxes. 250 Servers SHOULD provide the attributes createTimestamp and 251 modifyTimestamp in subschema entries, in order to allow clients to 252 maintain their caches of schema information. 254 Clients MUST only retrieve attributes from a subschema entry by 255 requesting a base object search of the entry, where the search filter 256 is "(objectClass=subschema)". (This will allow LDAPv3 servers which 257 gateway to X.500(93) to detect that subentry information is being 258 requested.) 260 3.3. Relationship to X.500 262 This document defines LDAP in terms of X.500 as an X.500 access 263 mechanism. An LDAP server MUST act in accordance with the 264 X.500(1993) series of ITU recommendations when providing the service. 265 However, it is not required that an LDAP server make use of any X.500 266 protocols in providing this service, e.g. LDAP can be mapped onto any 267 other directory system so long as the X.500 data and service model as 268 used in LDAP is not violated in the LDAP interface. 270 3.4. Server-specific Data Requirements 272 An LDAP server MUST provide information about itself and other 273 information that is specific to each server. This is represented as 274 a group of attributes located in the root DSE (DSA-Specific Entry), 275 which is named with the zero-length LDAPDN. These attributes 276 are retrievable if a client performs a base object search of the 277 root with filter "(objectClass=*)", however they are subject to 278 access control restrictions. 279 The root DSE MUST NOT be included if the client performs a subtree 280 search starting from the root. 282 Servers may allow clients to modify these attributes. 284 The following attributes of the root DSE are defined in section 5 285 of [5]. Additional attributes may be defined in other documents. 287 - namingContexts: naming contexts held in the server. Naming contexts 288 are defined in section 17 of X.501 [6]. 290 - subschemaSubentry: subschema entries (or subentries) known by this 291 server. 293 - altServer: alternative servers in case this one is later 294 unavailable. 296 - supportedExtension: list of supported extended operations. 298 - supportedControl: list of supported controls. 300 - supportedSASLMechanisms: list of supported SASL security features. 302 - supportedLDAPVersion: LDAP versions implemented by the server. 304 If the server does not master entries and does not know the locations 305 of schema information, the subschemaSubentry attribute is not present 306 in the root DSE. If the server masters directory entries under one or 307 more schema rules, there may be any number of values of the 308 subschemaSubentry attribute in the root DSE. 310 4. Elements of Protocol 312 The LDAP protocol is described using Abstract Syntax Notation 1 313 (ASN.1) [3], and is typically transferred using a subset of ASN.1 314 Basic Encoding Rules [11]. In order to support future extensions to 315 this protocol, clients and servers MUST ignore elements of SEQUENCE 316 encodings whose tags they do not recognize. 318 Note that unlike X.500, each change to the LDAP protocol other than 319 through the extension mechanisms will have a different version 320 number. A client will indicate the version it supports as part of 321 the bind request, described in section 4.2. If a client has not sent 322 a bind, the server MUST assume that version 3 is supported in the 323 client (since version 2 required that the client bind first). 325 Clients may determine the protocol version a server supports by 326 reading the supportedLDAPVersion attribute from the root DSE. 327 Servers which implement version 3 or later versions MUST provide this 328 attribute. Servers which only implement version 2 may not provide 329 this attribute. 331 4.1. Common Elements 333 This section describes the LDAPMessage envelope PDU (Protocol Data 334 Unit) format, as well as data type definitions which are used in the 335 protocol operations. 337 4.1.1. Message Envelope 339 For the purposes of protocol exchanges, all protocol operations are 340 encapsulated in a common envelope, the LDAPMessage, which is defined 341 as follows: 343 LDAPMessage ::= SEQUENCE { 344 messageID MessageID, 345 protocolOp CHOICE { 346 bindRequest BindRequest, 347 bindResponse BindResponse, 348 unbindRequest UnbindRequest, 349 searchRequest SearchRequest, 350 searchResEntry SearchResultEntry, 351 searchResDone SearchResultDone, 352 searchResRef SearchResultReference, 353 modifyRequest ModifyRequest, 354 modifyResponse ModifyResponse, 355 addRequest AddRequest, 356 addResponse AddResponse, 357 delRequest DelRequest, 358 delResponse DelResponse, 359 modDNRequest ModifyDNRequest, 360 modDNResponse ModifyDNResponse, 361 compareRequest CompareRequest, 362 compareResponse CompareResponse, 363 abandonRequest AbandonRequest, 364 extendedReq ExtendedRequest, 365 extendedResp ExtendedResponse }, 366 controls [0] Controls OPTIONAL } 368 MessageID ::= INTEGER (0 .. maxInt) 370 maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- 372 The function of the LDAPMessage is to provide an envelope containing 373 common fields required in all protocol exchanges. At this time the 374 only common fields are the message ID and the controls. 376 If the server receives a PDU from the client in which the LDAPMessage 377 SEQUENCE tag cannot be recognized, the messageID cannot be parsed, 378 the tag of the protocolOp is not recognized as a request, or the 379 encoding structures or lengths of data fields are found to be 380 incorrect, then the server MUST return the notice of disconnection 381 described in section 4.4.1, with resultCode protocolError, and 382 immediately close the connection. In other cases that the server 383 cannot parse the request received by the client, the server MUST 384 return an appropriate response to the request, with the resultCode 385 set to protocolError. 387 If the client receives a PDU from the server which cannot be parsed, 388 the client may discard the PDU, or may abruptly close the connection. 390 The ASN.1 type Controls is defined in section 4.1.12. 392 4.1.1.1. Message ID 394 All LDAPMessage envelopes encapsulating responses contain the 395 messageID value of the corresponding request LDAPMessage. 397 The message ID of a request MUST have a value different from the 398 values of any other requests outstanding in the LDAP session of which 399 this message is a part. 401 A client MUST NOT send a second request with the same message ID as 402 an earlier request on the same connection if the client has not 403 received the final response from the earlier request. Otherwise the 404 behavior is undefined. Typical clients increment a counter for each 405 request. 407 A client MUST NOT reuse the message id of an abandonRequest or of the 408 abandoned operation until it has received a response from the server 409 for another request invoked subsequent to the abandonRequest, as the 410 abandonRequest itself does not have a response. 412 4.1.2. String Types 414 The LDAPString is a notational convenience to indicate that, although 415 strings of LDAPString type encode as OCTET STRING types, the ISO 10646 416 [13] character set (a superset of Unicode) is used, encoded following 417 the UTF-8 algorithm [14]. Note that in the UTF-8 algorithm characters 418 which are the same as ASCII (0x0000 through 0x007F) are represented 419 as that same ASCII character in a single byte. The other byte values 420 are used to form a variable-length encoding of an arbitrary character. 422 LDAPString ::= OCTET STRING 424 The LDAPOID is a notational convenience to indicate that the permitted 425 value of this string is a (UTF-8 encoded) dotted-decimal 426 representation of an OBJECT IDENTIFIER. 428 LDAPOID ::= OCTET STRING 430 For example, 432 1.3.6.1.4.1.1466.1.2.3 434 4.1.3. Distinguished Name and Relative Distinguished Name 436 An LDAPDN and a RelativeLDAPDN are respectively defined to be the 437 representation of a Distinguished Name and a Relative Distinguished 438 Name after encoding according to the specification in [4], such that 440 ::= 442 ::= 444 where and are as defined in [4]. 446 LDAPDN ::= LDAPString 448 RelativeLDAPDN ::= LDAPString 450 Only Attribute Types can be present in a relative distinguished name 451 component; the options of Attribute Descriptions (next section) 452 MUST NOT be used in specifying distinguished names. 454 4.1.4. Attribute Type 456 An AttributeType takes on as its value the textual string associated 457 with that AttributeType in its specification. 459 AttributeType ::= LDAPString 461 Each attribute type has a unique OBJECT IDENTIFIER which has been 462 assigned to it. This identifier may be written as decimal digits 463 with components separated by periods, e.g. "2.5.4.10". 465 A specification may also assign one or more textual names for an 466 attribute type. These names MUST begin with a letter, and only 467 contain ASCII letters, digit characters and hyphens. They are case 468 insensitive. (These ASCII characters are identical to ISO 10646 469 characters whose UTF-8 encoding is a single byte between 0x00 and 470 0x7F.) 472 If the server has a textual name for an attribute type, it MUST use 473 a textual name for attributes returned in search results. The dotted- 474 decimal OBJECT IDENTIFIER is only used if there is no textual name 475 for an attribute type. 477 Attribute type textual names are non-unique, as two different 478 specifications (neither in standards track RFCs) may choose the same 479 name. 481 A server which masters or shadows entries SHOULD list all the 482 attribute types it supports in the subschema entries, using the 483 attributeTypes attribute. Servers which support an open-ended set of 484 attributes SHOULD include at least the attributeTypes value for the 485 'objectClass' attribute. Clients MAY retrieve the attributeTypes 486 value from subschema entries in order to obtain the OBJECT IDENTIFIER 487 and other information associated with attribute types. 489 Some attribute type names which are used in this version of LDAP are 490 described in [5]. Servers may implement additional attribute types. 492 4.1.5. Attribute Description 494 An AttributeDescription is a superset of the definition of the 495 AttributeType. It has the same ASN.1 definition, but allows 496 additional options to be specified. They are also case insensitive. 498 AttributeDescription ::= LDAPString 500 A value of AttributeDescription is based on the following BNF: 502 ::= [ ";" ] 504 ::=