idnits 2.17.1 draft-ietf-ldapbis-models-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2279. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2292. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2298), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 50 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 39 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2251, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2252, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (24 October 2004) is 7124 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: 'UTF-8' is mentioned on line 209, but not defined ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- No information found for draft-ietf-ldapbis-bcp64-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BCP64bis' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Roadmap' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' -- No information found for draft-ietf-ldapbis-authmeth-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'AuthMeth' -- No information found for draft-ietf-ldapbis-filter-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Filters' -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-url-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPURL' -- No information found for draft-ietf-sasl-rfc2222bis-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SASL' -- No information found for draft-ietf-ldapbis-syntaxes-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Syntaxes' -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Schema' -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 30 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Editor: Kurt D. Zeilenga 2 Intended Category: Standard Track OpenLDAP Foundation 3 Expires in six months 24 October 2004 4 Obsoletes: RFC 2251, RFC 2252, RFC 2256 6 LDAP: Directory Information Models 7 9 Status of this Memo 11 This document is intended to be published as a Standard Track RFC. 12 Distribution of this memo is unlimited. Technical discussion of this 13 document will take place on the IETF LDAP Revision Working Group 14 mailing list . Please send editorial 15 comments directly to the editor . 17 By submitting this Internet-Draft, I accept the provisions of Section 18 4 of RFC 3667. By submitting this Internet-Draft, I certify that any 19 applicable patent or other IPR claims of which I am aware have been 20 disclosed, or will be disclosed, and any of which I become aware will 21 be disclosed, in accordance with RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering Task 24 Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference material 30 or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 . The list of 34 Internet-Draft Shadow Directories can be accessed at 35 . 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Please see the Full Copyright section near the end of this document 40 for more information. 42 Abstract 44 The Lightweight Directory Access Protocol (LDAP) is an Internet 45 protocol for accessing distributed directory services which act in 46 accordance with X.500 data and service models. This document 47 describes the X.500 Directory Information Models, as used in LDAP. 49 Table of Contents 51 Status of this Memo 1 52 Abstract 2 53 Table of Contents 54 1. Introduction 3 55 1.1. Relationship to Other LDAP Specifications 56 1.2. Relationship to X.501 4 57 1.3. Conventions 58 1.4. Common ABNF Productions 59 2. Model of Directory User Information 6 60 2.1. The Directory Information Tree 7 61 2.2. Structure of an Entry 62 2.3. Naming of Entries 8 63 2.4. Object Classes 9 64 2.5. Attribute Descriptions 12 65 2.6. Alias Entries 15 66 3. Directory Administrative and Operational Information 17 67 3.1. Subtrees 68 3.2. Subentries 69 3.3. The 'objectClass' attribute 18 70 3.4. Operational attributes 19 71 4. Directory Schema 20 72 4.1. Schema Definitions 23 73 4.2. Subschema Subentries 30 74 4.3. 'extensibleObject' 35 75 4.4. Subschema Discovery 76 5. DSA (Server) Informational Model 36 77 5.1. Server-specific Data Requirements 78 6. Other Considerations 39 79 6.1. Preservation of User Information 40 80 6.2. Short Names 81 6.3. Cache and Shadowing 41 82 7. Implementation Guidelines 83 7.1. Server Guidelines 84 7.2. Client Guidelines 85 8. Security Considerations 42 86 9. IANA Considerations 87 10. Acknowledgments 43 88 11. Editor's Address 89 12. References 44 90 12.1. Normative References 91 12.2. Informative References 45 92 Appendix A. Changes 93 Intellectual Property Rights 50 94 Full Copyright 96 1. Introduction 98 This document discusses the X.500 Directory Information Models 99 [X.501], as used by the Lightweight Directory Access Protocol (LDAP) 100 [Roadmap]. 102 The Directory is "a collection of open systems cooperating to provide 103 directory services" [X.500]. The information held in the Directory is 104 collectively known as the Directory Information Base (DIB). A 105 Directory user, which may be a human or other entity, accesses the 106 Directory through a client (or Directory User Agent (DUA)). The 107 client, on behalf of the directory user, interacts with one or more 108 servers (or Directory System Agents (DSA)). A server holds a fragment 109 of the DIB. 111 The DIB contains two classes of information: 113 1) user information (e.g., information provided and administrated 114 by users). Section 2 describes the Model of User Information. 116 2) administrative and operational information (e.g., information 117 used to administer and/or operate the directory). Section 3 118 describes the model of Directory Administrative and Operational 119 Information. 121 These two models, referred to as the generic Directory Information 122 Models, describe how information is represented in the Directory. 123 These generic models provide a framework for other information models. 124 Section 4 discusses the subschema information model and subschema 125 discovery. Section 5 discusses the DSA (Server) Informational Model. 127 Other X.500 information models, such as access control distribution 128 knowledge, and replication knowledge information models, may be 129 adapted for use in LDAP. Specification of how these models apply to 130 LDAP is left to future documents. 132 1.1. Relationship to Other LDAP Specifications 134 This document is a integral part of the LDAP technical specification 135 [Roadmap] which obsoletes the previously defined LDAP technical 136 specification, RFC 3377, in its entirety. 138 This document obsoletes RFC 2251 sections 3.2 and 3.4, as well as 139 portions of sections 4 and 6. Appendix A.1 summaries changes to these 140 sections. The remainder of RFC 2251 is obsoleted by the [Protocol], 141 [AuthMeth], and [Roadmap] documents. 143 This document obsoletes RFC 2252 sections 4, 5 and 7. Appendix A.2 144 summaries changes to these sections. The remainder of RFC 2252 is 145 obsoleted by [Syntaxes]. 147 This document obsoletes RFC 2256 sections 5.1, 5.2, 7.1 and 7.2. 148 Appendix A.3 summarizes changes to these sections. The remainder of 149 RFC 2256 is obsoleted by [Schema] and [Syntaxes]. 151 1.2. Relationship to X.501 153 This document includes material, with and without adaptation, from 154 [X.501]. The material in this document takes precedence over that in 155 [X.501]. 157 1.3. Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in BCP 14 [RFC2119]. 163 Schema definitions are provided using LDAP description formats (as 164 defined in Section 4.1). Definitions provided here are formatted 165 (line wrapped) for readability. Matching rules and LDAP syntaxes 166 referenced in these definitions are specified in [Syntaxes]. 168 1.4. Common ABNF Productions 170 A number of syntaxes in this document are described using Augmented 171 Backus-Naur Form (ABNF) [RFC2234]. These syntaxes (as well as a 172 number of syntaxes defined in other documents) rely on the following 173 common productions: 175 keystring = leadkeychar *keychar 176 leadkeychar = ALPHA 177 keychar = ALPHA / DIGIT / HYPHEN 178 number = DIGIT / ( LDIGIT 1*DIGIT ) 180 ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z" 181 DIGIT = %x30 / LDIGIT ; "0"-"9" 182 LDIGIT = %x31-39 ; "1"-"9" 183 HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f" 185 SP = 1*SPACE ; one or more " " 186 WSP = 0*SPACE ; zero or more " " 188 NULL = %x00 ; null (0) 189 SPACE = %x20 ; space (" ") 190 DQUOTE = %x22 ; quote (""") 191 SHARP = %x23 ; octothorpe (or sharp sign) ("#") 192 DOLLAR = %x24 ; dollar sign ("$") 193 SQUOTE = %x27 ; single quote ("'") 194 LPAREN = %x28 ; left paren ("(") 195 RPAREN = %x29 ; right paren (")") 196 PLUS = %x2B ; plus sign ("+") 197 COMMA = %x2C ; comma (",") 198 HYPHEN = %x2D ; hyphen ("-") 199 DOT = %x2E ; period (".") 200 SEMI = %x3B ; semicolon (";") 201 LANGLE = %x3C ; left angle bracket ("<") 202 EQUALS = %x3D ; equals sign ("=") 203 RANGLE = %x3E ; right angle bracket (">") 204 ESC = %x5C ; backslash ("\") 205 USCORE = %x5F ; underscore ("_") 206 LCURLY = %x7B ; left curly brace "{" 207 RCURLY = %x7D ; right curly brace "}" 209 ; Any UTF-8 [UTF-8] encoded Unicode [Unicode] character 210 UTF8 = UTF1 / UTFMB 211 UTFMB = UTF2 / UTF3 / UTF4 212 UTF0 = %x80-BF 213 UTF1 = %x00-7F 214 UTF2 = %xC2-DF UTF0 215 UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) / 216 %xED %x80-9F UTF0 / %xEE-EF 2(UTF0) 217 UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) / 218 %xF4 %x80-8F 2(UTF0) 220 OCTET = %x00-FF ; Any octet (8-bit data unit) 222 Object identifiers (OIDs) [X.680] are represented in LDAP using a 223 dot-decimal format conforming to the ABNF: 225 numericoid = number 1*( DOT number ) 227 Short names, also known as descriptors, are used as more readable 228 aliases for object identifiers. Short names are case insensitive and 229 conform to the ABNF: 231 descr = keystring 233 Where either an object identifier or a short name may be specified, 234 the following production is used: 236 oid = descr / numericoid 238 While the form is generally preferred when the usage is 239 restricted to short names referring to object identifiers which 240 identify like kinds of objects (e.g., attribute type descriptions, 241 matching rule descriptions, object class descriptions), the 242 form should be used when the object identifiers may 243 identify multiple kinds of objects or when an unambiguous short name 244 (descriptor) is not available. 246 Implementations SHOULD treat short names (descriptors) used in an 247 ambiguous manner (as discussed above) as unrecognized. 249 Short Names (descriptors) are discussed further in Section 6.2. 251 2. Model of Directory User Information 253 As [X.501] states: 255 The purpose of the Directory is to hold, and provide access to, 256 information about objects of interest (objects) in some 'world'. 257 An object can be anything which is identifiable (can be named). 259 An object class is an identified family of objects, or conceivable 260 objects, which share certain characteristics. Every object belongs 261 to at least one class. An object class may be a subclass of other 262 object classes, in which case the members of the former class, the 263 subclass, are also considered to be members of the latter classes, 264 the superclasses. There may be subclasses of subclasses, etc., to 265 an arbitrary depth. 267 A directory entry, a named collection of information, is the basic 268 unit of information held in the Directory. There are multiple kinds 269 of directory entries. 271 An object entry represents a particular object. An alias entry 272 provides alternative naming. A subentry holds administrative and/or 273 operational information. 275 The set of entries representing the DIB are organized hierarchically 276 in a tree structure known as the Directory Information Tree (DIT). 278 Section 2.1 describes the Directory Information Tree 279 Section 2.2 discusses the structure of entries. 280 Section 2.3 discusses naming of entries. 281 Section 2.4 discusses object classes. 282 Section 2.5 discusses attribute descriptions. 283 Section 2.6 discusses alias entries. 285 2.1. The Directory Information Tree 287 As noted above, the DIB is composed of a set of entries organized 288 hierarchically in a tree structure known as the Directory Information 289 Tree (DIT). Specifically, a tree where vertices are the entries. 291 The arcs between vertices define relations between entries. If an arc 292 exists from X to Y, then the entry at X is the immediate superior of Y 293 and Y is the immediate subordinate of X. An entry's superiors are the 294 entry's immediate superior and its superiors. An entry's subordinates 295 are all of its immediate subordinates and their subordinates. 297 Similarly, the superior/subordinate relationship between object 298 entries can be used to derive a relation between the objects they 299 represent. DIT structure rules can be used to govern relationships 300 between objects. 302 Note: An entry's immediate superior is also known as the entry's 303 parent and an entry's immediate subordinate is also known as the 304 entry's child. Entries which have the same parent are known as 305 siblings. 307 2.2. Structure of an Entry 309 An entry consists of a set of attributes which hold information about 310 the object which the entry represents. Some attributes represent user 311 information and are called user attributes. Other attributes 312 represent operational and/or administrative information and are called 313 operational attributes. 315 An attribute is an attribute description (a type and zero or more 316 options) with one or more associated values. An attribute is often 317 referred to by its attribute description. For example, the 318 'givenName' attribute is the attribute which consists of the attribute 319 description 'givenName' (the 'givenName' attribute type [Schema] and 320 zero options) and one or more associated values. 322 The attribute type governs whether the attribute can have multiple 323 values, the syntax and matching rules used to construct and compare 324 values of that attribute, and other functions. Options indicate 325 subtypes and other functions. 327 Attribute values conform to the defined syntax of the attribute type. 329 No two values of an attribute may be equivalent. Two values are 330 considered equivalent only if they would match according to the 331 equality matching rule of the attribute type. If the attribute type 332 is defined with no equality matching rule, two values are equivalent 333 if and only if they are identical. (See 2.5.1 for other 334 restrictions.) 336 For example, a 'givenName' attribute can have more than one value, 337 they must be Directory Strings, and they are case insensitive. A 338 'givenName' attribute cannot hold both "John" and "JOHN" as these are 339 equivalent values per the equality matching rule of the attribute 340 type. 342 When an attribute is used for naming of the entry, one and only one 343 value of the attribute is used in forming the Relative Distinguished 344 Name. This value is known as a distinguished value. 346 2.3. Naming of Entries 348 2.3.1. Relative Distinguished Names 350 Each entry is named relative to its immediate superior. This relative 351 name, known as its Relative Distinguished Name (RDN) [X.501], is 352 composed of an unordered set of one or more attribute value assertions 353 (AVA) consisting of an attribute description with zero options and an 354 attribute value. These AVAs are chosen to match attribute values 355 (each a distinguished value) of the entry. 357 An entry's relative distinguished name must be unique among all 358 immediate subordinates of the entry's immediate superior (i.e., all 359 siblings). 361 The following are examples of string representations of RDNs [LDAPDN]: 363 UID=12345 364 OU=Engineering 365 CN=Kurt Zeilenga+L=Redwood Shores 367 The last is an example of a multi-valued RDN. That is, an RDN 368 composed of multiple AVAs. 370 2.3.2. Distinguished Names 372 An entry's fully qualified name, known as its Distinguished Name (DN) 373 [X.501], is the concatenation of its RDN and its immediate superior's 374 DN. A Distinguished Name unambiguously refers to an entry in the 375 tree. The following are examples of string representations of DNs 376 [LDAPDN]: 378 UID=nobody@example.com,DC=example,DC=com 379 CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US 381 2.3.3. Alias Names 383 An alias, or alias name, is "an name for an object, provided by the 384 use of alias entries" [X.501]. Alias entries are described in Section 385 2.6. 387 2.4. Object Classes 389 An object class is "an identified family of objects (or conceivable 390 objects) which share certain characteristics" [X.501]. 392 As defined in [X.501]: 394 Object classes are used in the Directory for a number of purposes: 396 - describing and categorising objects and the entries that 397 correspond to these objects; 399 - where appropriate, controlling the operation of the Directory; 401 - regulating, in conjunction with DIT structure rule 402 specifications, the position of entries in the DIT; 404 - regulating, in conjunction with DIT content rule 405 specifications, the attributes that are contained in entries; 407 - identifying classes of entry that are to be associated with a 408 particular policy by the appropriate administrative authority. 410 An object class (a subclass) may be derived from an object class 411 (its direct superclass) which is itself derived from an even more 412 generic object class. For structural object classes, this process 413 stops at the most generic object class, 'top' (defined in Section 414 2.4.1). An ordered set of superclasses up to the most superior 415 object class of an object class is its superclass chain. 417 An object class may be derived from two or more direct 418 superclasses (superclasses not part of the same superclass chain). 419 This feature of subclassing is termed multiple inheritance. 421 Each object class identifies the set of attributes required to be 422 present in entries belonging to the class and the set of attributes 423 allowed to be present in entries belonging to the class. As an entry 424 of a class must meet the requirements of each class it belongs to, it 425 can be said that an object class inherits the sets of allowed and 426 required attributes from its superclasses. A subclass can identify an 427 attribute allowed by its superclass as being required. If an 428 attribute is a member of both sets, it is required to be present. 430 Each object class is defined to be one of three kinds of object 431 classes: Abstract, Structural, or Auxiliary. 433 Each object class is identified by an object identifier (OID) and, 434 optionally, one or more short names (descriptors). 436 2.4.1. Abstract Object Classes 438 An abstract object class, as the name implies, provides a base of 439 characteristics from which other object classes can be defined to 440 inherit from. An entry cannot belong to an abstract object class 441 unless it belongs to a structural or auxiliary class which inherits 442 from that abstract class. 444 Abstract object classes can not derive from structural nor auxiliary 445 object classes. 447 All structural object classes derive (directly or indirectly) from the 448 'top' abstract object class. Auxiliary object classes do not 449 necessarily derive from 'top'. 451 The following is the object class definition (see Section 4.1.1) for 452 the 'top' object class: 454 ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass ) 456 All entries belong to the 'top' abstract object class. 458 2.4.2. Structural Object Classes 460 As stated in [X.501]: 462 An object class defined for use in the structural specification of 463 the DIT is termed a structural object class. Structural object 464 classes are used in the definition of the structure of the names 465 of the objects for compliant entries. 467 An object or alias entry is characterised by precisely one 468 structural object class superclass chain which has a single 469 structural object class as the most subordinate object class. 470 This structural object class is referred to as the structural 471 object class of the entry. 473 Structural object classes are related to associated entries: 475 - an entry conforming to a structural object class shall 476 represent the real-world object constrained by the object 477 class; 479 - DIT structure rules only refer to structural object classes; 480 the structural object class of an entry is used to specify the 481 position of the entry in the DIT; 483 - the structural object class of an entry is used, along with an 484 associated DIT content rule, to control the content of an 485 entry. 487 The structural object class of an entry shall not be changed. 489 Each structural object class is a (direct or indirect) subclass of the 490 'top' abstract object class. 492 Structural object classes cannot subclass auxiliary object classes. 494 Each entry is said to belong to its structural object class as well as 495 all classes in its structural object class's superclass chain. 497 2.4.3. Auxiliary Object Classes 499 Auxiliary object classes are used to augment the characteristics of 500 entries. They are commonly used to augment the sets of attributes 501 required and allowed to be present in an entry. They can be used to 502 describe entries or classes of entries. 504 Auxiliary object classes cannot subclass structural object classes. 506 An entry can belong to any subset of the set of auxiliary object 507 classes allowed by the DIT content rule associated with the structural 508 object class of the entry. If no DIT content rule is associated with 509 the structural object class of the entry, the entry cannot belong to 510 any auxiliary object class. 512 The set of auxiliary object classes which an entry belongs to can 513 change over time. 515 2.5. Attribute Descriptions 517 An attribute description is composed of an attribute type (see Section 518 2.5.1) and a set of zero or more attribute options (see Section 519 2.5.2). 521 An attribute description is represented by the ABNF: 523 attributedescription = attributetype options 524 attributetype = oid 525 options = *( SEMI option ) 526 option = 1*keychar 528 where identifies the attribute type and each