idnits 2.17.1 draft-ietf-ldapbis-syntaxes-02.txt: 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 page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 51) being 62 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 56 pages 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 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([Prot]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 38 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == 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 RFC2252, but the abstract doesn't seem to directly say this. It does mention RFC2252 though, so this could be OK. 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 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 (27 February 2002) is 8093 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: 'Consid' is mentioned on line 736, but not defined ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' -- Possible downref: Non-RFC (?) normative reference: ref. 'Attr' -- Possible downref: Non-RFC (?) normative reference: ref. 'Codes' -- Possible downref: Non-RFC (?) normative reference: ref. 'Fax' -- Possible downref: Non-RFC (?) normative reference: ref. 'IA5' -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG' ** Obsolete normative reference: RFC 1327 (ref. 'Map') (Obsoleted by RFC 2156) -- Possible downref: Non-RFC (?) normative reference: ref. 'Models' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Prot' -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS' -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'User' ** Obsolete normative reference: RFC 2044 (ref. 'UTF-8') (Obsoleted by RFC 2279) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT K. Dally, Editor 2 Intended Category: Standard Track The MITRE Corp. 3 Expires: 27 August 2002 S. Legg 4 Obsoletes: RFC 2252 ADACEL 5 27 February 2002 7 Lightweight Directory Access Protocol (v3): 8 Attribute Syntax Definitions 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC 2026. 16 This document is intended to be, after appropriate review and 17 revision, submitted to the RFC Editor as a Standard Track document. 18 Distribution of this memo is unlimited. Technical discussion of 19 this document will take place on the IETF LDAP Revision Working 20 Group (LDAPbis) mailing list . Please 21 send editorial comments directly to the author . 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet-Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. The list of 33 Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright 2002, The Internet Society. All Rights Reserved. 38 Please see the Copyright section near the end of this document for 39 more information. 41 Abstract 43 The Lightweight Directory Access Protocol (LDAP) [Prot] provides for 44 exchanging AttributeValue fields in protocol. This document defines 45 a set of syntaxes for LDAP, and the rules by which attribute values 46 of these syntaxes are represented in the LDAP protocol. The syntaxes 47 defined in this document are used by this and other documents to 48 define attribute types. In addition, this document defines the set 49 of attribute syntaxes, which LDAP servers support, and other schema 50 elements (required and optional) that are common to all 51 LDAP servers. 53 [Editor's note: This document is a modified version of the text of 54 RFC 2252, in order to bring it up to date. This action is part of 55 the maintenance activity that is needed in order to progress 56 LDAP (v3) to Draft Standard. The changes are described in Annex C 57 of this document. Open items are listed in Annex B. 58 End of Editor's note] 59 Table of Contents 61 Status of this Memo....................................................1 63 Abstract...............................................................2 65 1. Overview...........................................................6 67 2. General Issues.....................................................6 68 2.1 Notation..........................................................6 69 2.2 Syntaxes..........................................................9 70 2.2.1 Syntaxes Implementation Status..................................9 71 2.2.2 Syntax Object Identifiers...................................... 9 72 2.2.3 Syntax Description.............................................10 73 2.2.4 Example........................................................10 74 2.3 Matching Rules...................................................11 75 2.3.1 Matching Rules Implementation Status...........................11 76 2.3.2 Matching Rule Description......................................11 77 2.3.3 Example........................................................12 78 2.4 Attribute Types..................................................12 79 2.4.1 Attribute Types Implementation Status..........................12 80 2.4.2 Attribute Types Description....................................13 81 2.4.3 Example........................................................15 82 2.5 Object Classes...................................................15 83 2.5.1 Object Classes Implementation Status...........................15 84 2.5.2 Object Class Description.......................................16 85 2.5.3 Example........................................................16 87 3. Syntaxes..........................................................18 88 3.1 Attribute Type Description.......................................18 89 3.2 Bit String.......................................................18 90 3.3 Boolean..........................................................19 91 3.4 Country String...................................................19 92 3.5 Delivery Method..................................................19 93 3.6 Directory String.................................................20 94 3.7 DIT Content Rule Description.....................................20 95 3.8 DIT Structure Rule Description...................................21 96 3.9 DN...............................................................22 97 3.10 Enhanced Guide...................................................23 98 3.11 Facsimile Telephone Number.......................................23 99 3.12 Fax..............................................................24 100 3.13 Generalized Time.................................................24 101 3.14 Guide............................................................25 102 3.15 IA5 String.......................................................25 103 3.16 Integer..........................................................25 104 3.17 JPEG.............................................................26 105 3.18 LDAP Syntax Description..........................................26 106 3.19 Matching Rule Description........................................26 107 3.20 Matching Rule Use Description....................................26 108 3.21 MHS OR Address...................................................27 109 3.22 Name and Optional UID............................................27 110 3.23 Name Form Description............................................28 111 3.24 Numeric String...................................................29 112 3.25 Object Class Description.........................................29 113 3.26 Octet String.....................................................29 114 3.27 OID..............................................................30 115 3.28 Other Mailbox....................................................30 116 3.29 Postal Address...................................................30 117 3.30 Presentation Address.............................................31 118 3.31 Printable String.................................................33 119 3.32 Substring Assertion .......................................33 120 3.33 Telephone Number.................................................34 121 3.34 Teletex Terminal Identifier......................................34 122 3.35 Telex Number.....................................................34 123 3.36 UTC Time.........................................................35 125 4. Matching Rules....................................................36 126 4.1 bitStringMatch...................................................36 127 4.2 caseExactIA5Match................................................36 128 4.3 caseIgnoreIA5Match...............................................36 129 4.4 caseIgnoreListMatch..............................................36 130 4.5 caseIgnoreMatch..................................................37 131 4.6 caseIgnoreOrderingMatch..........................................37 132 4.7 caseIgnoreSubstringsMatch........................................37 133 4.8 distinguishedNameMatch...........................................37 134 4.9 generalizedTimeMatch.............................................37 135 4.10 generalizedTimeOrderingMatch.....................................38 136 4.11 integerFirstComponentMatch.......................................38 137 4.12 integerMatch.....................................................38 138 4.13 numericStringMatch...............................................38 139 4.14 numericStringSubstringsMatch.....................................38 140 4.15 objectIdentifierFirstComponentMatch..............................39 141 4.16 objectIdentifierMatch............................................39 142 4.17 octetStringMatch.................................................39 143 4.18 presentationAddressMatch.........................................40 144 4.19 protocolInformationMatch.........................................40 145 4.20 telephoneNumberMatch.............................................40 146 4.21 telephoneNumberSubstringsMatch...................................40 147 4.22 uniqueMemberMatch................................................40 149 5. Attribute Types...................................................41 150 5.1 altServer........................................................41 151 5.2 attributeTypes...................................................41 152 5.3 createTimestamp..................................................41 153 5.4 creatorsName.....................................................41 154 5.5 dITContentRules..................................................42 155 5.6 dITStructureRules................................................42 156 5.7 ldapSyntaxes.....................................................42 157 5.8 matchingRules....................................................42 158 5.9 matchingRuleUse..................................................42 159 5.10 modifiersName....................................................43 160 5.11 modifyTimestamp..................................................43 161 5.12 nameForms........................................................43 162 5.13 namingContexts...................................................43 163 5.14 objectClasses....................................................44 164 5.15 subschemaSubentry................................................44 165 5.16 supportedControl.................................................44 166 5.17 supportedExtension...............................................45 167 5.18 supportedLDAPVersion.............................................45 168 5.19 supportedSASLMechanisms..........................................45 170 6. Object Classes....................................................46 171 6.1 Extensible Object Class..........................................46 172 6.2 subschema........................................................46 174 7. Security Considerations...........................................47 175 7.1 Disclosure.......................................................47 176 7.2 Security Information Syntaxes....................................47 177 7.3 Use of Attribute Values in Security Applications.................47 178 7.4 Securing the Directory...........................................47 180 8. Acknowledgements..................................................48 182 9. Author's Address..................................................48 184 10. References........................................................48 185 10.1 Normative.......................................................48 186 10.2 Informative.....................................................49 188 11. Full Copyright Statement..........................................50 190 Annex A Object Identifiers for Syntaxes..............................51 192 Annex B Topics to be Addressed in This Document......................52 194 Annex C Change Log...................................................53 195 1. Overview 197 This document defines the framework for developing schemas for 198 directories accessible via the Lightweight Directory Access 199 Protocol (LDAP) [Prot]. 201 Schema is the collection of attribute type definitions, object class 202 definitions and other information which specify the entries and their 203 contents that a server holds. A server uses schema to determine how 204 to match a filter or attribute value assertion (in a compare 205 operation) against the attributes of an entry, and whether to permit 206 add and modify operations. 208 Therefore, Section 2 states the general requirements and notation 209 for definition of attribute types, object classes, syntaxes and 210 matching rules. 212 Section 3 lists syntaxes, section 4 matching rules, section 5 213 attribute types, and section 6 object classes. 215 Additional documents define schemas for representing real-world 216 objects as directory entries. 218 2. General Issues 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in RFC 2119 [Keywds]. 224 This document describes the syntaxes of data conveyed in an 225 Internet protocol. 227 Attribute Type and Object Class definitions are written in a string 228 representation of the AttributeTypeDescription and 229 ObjectClassDescription data types defined in X.501 [Models]. 230 Implementors are strongly advised to first read the description of 231 how schema is represented in X.500 before reading the rest of this 232 document. 234 2.1 Notation 236 For the purposes of defining the rules for describing attribute 237 syntaxes and other schema elements, the following augmented 238 Backus-Naur Form (ABNF) definitions will be used. They are based on 239 the ABNF styles of RFC 2234 [ABNF]. 241 The schema definitions provided in this document are line-wrapped 242 for readability. 244 The definitions for ALPHA, DIGIT, ldapOID, number, DOT, LDIGIT, and 245 HYPHEN are given in the LDAP protocol specification [Prot]. 247 The definition of OCTET, from [ABNF], is: 249 OCTET = %x00-FF 250 ; 8 bits of data 252 hex-digit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f" / 253 "A" / "B" / "C" / "D" / "E" / "F" 255 k = ALPHA / DIGIT / HYPHEN 257 octetstring = *OCTET 259 p = ALPHA / DIGIT / "'" / "(" / ")" / "+" / "," / HYPHEN / "DOT" / 260 "="/ "/" / ":" / "?" / " " 262 numericstring = 1*DIGIT 264 anhstring = 1*k 266 keystring = ALPHA [ anhstring ] 268 printablestring = 1*p 270 space = 1*" " 272 whsp = [ space ] 274 utf8 = 278 dstring = 1*( utf8 / "''" ) 279 ; escaped utf8 string, each "'" 280 ; appearing in the value to be encoded is 281 ; escaped by a preceding "'" 283 qdstring = "'" dstring "'" 285 qdstringlist = [ qdstring *( space qdstring ) ] 287 qdstrings = qdstring / ( "(" whsp qdstringlist whsp ")" ) 289 In the following ABNF for the string representation of OBJECT 290 IDENTIFIERs, 'descr' is the syntactic representation of an object 291 descriptor, which consists of letters, digits, and hyphens starting 292 with a letter. An OBJECT IDENTIFIER in the numericoid format SHOULD 293 NOT have leading zeroes (e.g., "0.9.3" is permitted but "0.09.3" 294 SHOULD NOT be generated). 296 When 'oid' elements occur in a value, the 'descr' notation option 297 SHOULD be used in preference to the 'numericoid'. An object 298 descriptor is more readable than a numeric OBJECT IDENTIFIER, and a 299 descriptor (where assigned and known by the implementation) SHOULD 300 be used in preference to numeric oids to the greatest extent 301 possible. Examples of object descriptors in LDAP are attribute 302 type, object class, and matching rule names. 304 oid = descr / numericoid 306 descr = keystring 308 numericoid = numericstring *( DOT numericstring ) 310 noidlen = numericoid [ "{" len "}" ] 312 len = numericstring 314 oids = oid / ( "(" space oidlist space ")" ) 315 ; set of oids of either form 317 oidlist = oid *( space "$" space oid ) 319 qdescrs = qdescr / ( "(" whsp qdescrlist whsp ")" ) 320 ; object descriptors used as schema element names 322 qdescrlist = [ qdescr *( whsp qdescr ) ] 324 qdescr = "'" descr "'" 326 xstring = "X-" 1*( ALPHA / HYPHEN / "_" ) 328 extensions = *( space xstring space qdstrings ) 330 Note that while lines have been folded for readability in the 331 definitions of schema elements, (e.g., objectClassDescription 332 attribute), the values transferred in protocol would not contain 333 newlines. 335 In cases where an arbitrary string, not a Distinguished Name or part 336 of one, is used in a value of an attribute, a backslash quoting 337 mechanism is used to escape the following separator symbol 338 character, (such as, "'", "$" or "#") if it occurs in that 339 string. The backslash is followed by a pair of hexadecimal digits 340 representing the next character. A backslash itself in the string 341 which forms part of a larger syntax is always represented as '\5C' 342 or '\5c'. An example is given in section 3.33, postalAddress syntax. 344 Servers are not required to provide the same or any text in the 345 description part of the subschema values they maintain. 347 2.2 Syntaxes 349 This section defines general requirements for LDAP attribute value 350 syntaxes. All documents defining attribute syntaxes for use with 351 LDAP are expected to conform to these requirements. 352 Syntaxes are also defined for matching rules whose assertion value 353 syntax is different from the attribute value syntax. 355 In an LDAP schema, an Object Identifier (OID) is assigned to a 356 syntax definition when the syntax is named. 358 Syntaxes that are currently in use in this specification and the 359 user schema specification [User] are specified in this document in 360 Section 3. The object identifiers for these syntaxes are listed in 361 Annex A, also. 363 In X.501 [Models] and X.520 [Attr], the definition of the syntax is 364 part of the attribute specification and a distinct OID for the syntax 365 is not assigned. As a result, X.501 does not define an attribute for 366 publishing syntaxes explicitly in a subschema entry. 368 In [Prot], the encoding of the LDAP protocol is specified. The 369 protcol encapsulates values of attributes in many places. In this 370 specification, the encoding of the values is specified, as part of 371 each syntax definition. These value encoding rules are termed 372 "native LDAP encoding". The native LDAP encoding of a value is what 373 is transmitted in the protocol, unless a transfer option has been 374 invoked for the value. The transfer option mechanism and the Binary 375 transfer option are defined in [Prot]. 377 The native LDAP encoding of a given attribute syntax always produces 378 octet-aligned values. To the greatest extent possible, the 379 native LDAP encoding of a value is supposed to be usable for display 380 purposes. In particular, encoding rules for attribute syntaxes 381 defining non-binary values are supposed to produce strings that can 382 be displayed with little or no translation by clients implementing 383 LDAP. There are a few cases (e.g., audio) however, when it is not 384 sensible to produce a human-readable representation. 386 2.2.1 Syntaxes Implementation Status 388 Clients and servers need not implement all the syntaxes listed, and 389 MAY implement other syntaxes. 391 Clients MUST NOT assume that the native LDAP encoding of a value of 392 an unrecognized syntax is a human-readable character string. 394 2.2.2 Syntax Object Identifiers 396 Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which 397 are dotted-decimal strings. These are not intended to be displayed 398 to users. Annex A lists the syntaxes that have been defined for 399 LDAP in this document. 401 Other documents define additional syntaxes. However, the 402 definition of additional arbitrary syntaxes is strongly deprecated 403 since it will hinder interoperability. Today's client and server 404 implementations generally do not have the ability to dynamically 405 recognize new syntaxes. In most cases, attributes will be defined 406 with the syntax for directory strings. 408 A suggested minimum upper bound on the number of characters in a 409 value with a string-based syntax, or the number of bytes in a value 410 for all other syntaxes, can be indicated by appending this bound 411 count inside of curly braces following the syntax name's OBJECT 412 IDENTIFIER in an attribute type definition. See the "numericoid" 413 production in paragraph 2.1. Such a bound is not part of the syntax 414 name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that 415 server implementations would allow a string to be 64 characters 416 long, although they can allow longer strings. Note that a single 417 character of the Directory String syntax can be encoded in more than 418 one byte since UTF-8 [UTF-8] is a variable-length encoding. 420 2.2.3 Syntax Description 422 The following ABNF is used in this document to associate a short 423 description (e.g., a name) with a syntax OBJECT IDENTIFIER. The 424 productions for whsp, numericoid, qdescrs and qdstring are given in 425 paragraph 2.1. Implementors, note that future versions of this 426 document could expand this definition to include additional terms. 427 Terms whose identifier begins with "X-" are reserved for private 428 experiments, and MUST be followed by a and a 429 tokens. 431 SyntaxDescription = "(" whsp 432 numericoid 433 [ space "DESC" space qdstring ] 434 extensions 435 whsp ")" 437 Note that the SyntaxDescription ABNF is also the ABNF that defines 438 the native LDAP encoding of values of the LDAP Syntax Description 439 syntax. 441 2.2.4 Example 443 For example, the syntax descripion of the INTEGER syntax for whole 444 number values is: 446 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 448 2.3 Matching Rules 450 The matching rules specified in this document are defined in 451 section 4. 453 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 455 Matching rules are used by servers to compare attribute values 456 against assertion values when performing Search and Compare 457 operations. They are also used to identify the value to be added 458 or deleted when modifying entries, and are used when comparing a 459 purported distinguished name with the name of an entry. 461 Most of the attributes given in this document have an equality 462 matching rule defined. 464 ...An OID is assigned to a matching rule when it is defined. A 465 matching rule definition ought not be changed without having a new 466 OID assigned to it. 468 2.3.1 Matching Rules Implementation Status 470 Servers which support matching rules and the extensibleMatch SHOULD 471 implement all the matching rules in section 4. 473 Servers MUST publish in the matchingRules attribute, the definitions 474 of matching rules referenced by values of the attributeTypes and 475 matchingRuleUse attributes in the same subschema entry. Other 476 unreferenced matching rules MAY be published in the matchingRules 477 attribute. 479 If the server supports the extensibleMatch, then the server MAY use 480 the matchingRuleUse attribute to indicate the applicability of 481 selected matching rules to designated attribute types in an 482 extensibleMatch. 484 2.3.2 Matching Rule Description 486 Matching rule descriptions are written according to the following 487 ABNF. The productions for numericoid, qdescrs, qdstring, oid, and 488 whsp are given in section 2.1. Implementors, note that future 489 versions of this document could expand this ABNF to include 490 additional terms. Terms whose identifier begins with "X-" are 491 reserved for private experiments, and MUST be followed by a 492 and a tokens. 494 MatchingRuleDescription = "(" whsp 495 numericoid 496 [ space "NAME" space qdescrs ] 497 [ space "DESC" space qdstring ] 498 [ space "OBSOLETE" ] 499 space "SYNTAX" space numericoid 500 extensions 501 whsp ")" 503 The first numericoid is the identifier of the MatchingRule being 504 described. 506 Note that the MatchingRuleDescription ABNF is also the ABNF that 507 defines the native LDAP encoding of values of the Matching Rule 508 Description syntax. 510 2.3.3 Example 512 For example, in specifying a server which implements a privately- 513 defined matching rule for performing sound-alike matches on 514 Directory String-valued attributes, the matching rule could be 515 written as (1.1.2.3.4.5 is an example, the OID of an actual matching 516 rule would be different): 518 matchingRule: ( 1.1.2.3.4.5 NAME 'soundAlikeMatch' 519 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 521 This description could be the one included in the subschema entry in 522 the server. If this matching rule could be used with the attributes 523 2.5.4.41 and 2.5.4.15, the following could be the use description 524 present in the subschema entry: 526 matchingRuleUse: ( 1.1.2.3.4.5 APPLIES ( givenName $ surname ) ) 528 A client could then make use of this matching rule by sending a 529 search operation in which the filter is of the extensibleMatch 530 choice, the matchingRule field is "soundAlikeMatch", and the type 531 field is "givenName" or "surName". 533 2.4 Attribute Types 535 Attributes represent the characteristics of the real-world object 536 which an entry represents. The attributes defined in this document 537 are given in section 5. 539 An OID is assigned to an attribute type when it is defined. An 540 attribute type definition ought not be changed without having a new 541 OID assigned to it. 543 2.4.1 Attribute Types Implementation Status 545 Servers MUST publish in the attributeTypes attribute of the same 546 subschema entry, the definitions of attribute types referenced by 547 values of the objectClasses, nameForms, matchingRuleUse and 548 dITContentRules attributes, and attribute types referenced by the 549 SUP field in values of the attributeTypes attribute itself. Other 550 unreferenced attribute types MAY be published in the attributeTypes 551 attribute. 553 Schema developers MUST NOT create attribute type definitions whose 554 names conflict with attribute types defined for use with LDAP in 555 existing standards-track RFCs. See the registry of names of 556 attribute types maintained by IANA [Consid]. 558 All LDAP server implementations MUST recognize the attribute types 559 defined in section 5. 561 Servers MUST maintain values of these attributes in accordance with 562 the definitions in X.501(93): createTimestamp, modifyTimestamp, 563 creatorsName, modifiersName, subschemaSubentry, attributeTypes, 564 objectClasses, matchingRules, and matchingRuleUse. 566 The createTimestamp and creatorsName attributes SHOULD appear 567 in entries which were created using the Add operation. 569 The modifyTimestamp and modifiersName attributes SHOULD appear in 570 entries which have been modified using LDAP update operations. 572 The subschemaSubentry attribute SHOULD appear in all entries. 574 Servers MUST recognize these attribute type names, but it is not 575 required that a server provide values for these attributes, when the 576 attribute corresponds to a feature which the server does not 577 implement: namingContexts, altServer, supportedExtension, 578 supportedControl, supportedSASLMechanisms, and supportedLDAPVersion. 580 Servers MAY use the ldapSyntaxes attribute to list the syntaxes 581 which are implemented. 583 All servers SHOULD recognize these attribute type names, although 584 typically only X.500 servers will implement their functionality: 585 dITStructureRules, nameForms, and ditContentRules. 587 For the status of user schema attribute types, see Section 3 588 of [User]. 590 2.4.2 Attribute Type Description 592 Attribute types are expressed according to the following ABNF. 593 The productions for whsp, numericoid, qdescrs, qdstring, space, 594 oid, and noidlen are given in paragraph 2.1. Implementors, 595 note that future versions of this document could expand this ABNF to 596 include additional terms. Terms which begin with the characters 597 "X-" are reserved for private experiments, and MUST be followed by a 598 and a tokens. 600 AttributeTypeDescription = "(" whsp 601 numericoid 602 [ space "NAME" qdescrs ] 603 [ space "DESC" qdstring ] 604 [ space "OBSOLETE" ] 606 [ space "SUP" space oid ] 607 [ space "EQUALITY" space oid ] 608 [ space "ORDERING" space oid ] 609 [ space "SUBSTR" space oid ] 610 [ space "SYNTAX" space noidlen ] 611 [ space "SINGLE-VALUE" ] 612 [ space "COLLECTIVE" ] 613 [ space "NO-USER-MODIFICATION" ] 614 [ space "USAGE" space AttributeUsage ] 615 extensions 616 whsp ")" 618 The numericoid is the identifier of the AttributeType being 619 described. 621 The NAME string is the string registered with IANA [Consid] and used 622 to identify values and value assertions of the attribute described. 624 The SUP oid is an identifier of the Attribute Type from which the 625 attribute described is derived (i.e., a subtype). 627 The EQUALITY, ORDERING, AND SUBSTR oids name the Matching Rules for 628 the attribute being defined. 630 See section 2.3 for the SYNTAX noidlen explanation. 632 The default setting is "multi-valued" when SINGLE-VALUE is absent. 634 The default setting is "not collective" when COLLECTIVE is absent. 636 The default setting is "user modifiable" when NO-USER-MODIFICATION 637 is absent. 639 The default setting is "userApplication" when USAGE is absent. 641 Servers SHOULD provide at least one of the "SUP" and "SYNTAX" fields 642 for each AttributeTypeDescription. 644 An AttributeDescription (i.e., the means of referring to an attribute 645 in the protocol [Prot]) can be used as the value in a NAME part of 646 an AttributeTypeDescription. Note that these are case insensitive. 648 Note that the AttributeTypeDescription does not list the matching 649 rules which can be used with that attribute type in an 650 extensibleMatch search filter. This is done using the 651 matchingRuleUseDescription described in section 3.24. 653 This document refines the schema description of X.501 [Models] by 654 requiring that the syntax field in an AttributeTypeDescription be a 655 string representation of an OBJECT IDENTIFIER for the LDAP string 656 syntax definition, and a possible indication of the maximum length 657 of a value of this attribute (defined in section 2.2.2). 659 Note that the AttributeTypeDescription ABNF is also the ABNF that 660 defines the Attribute Type Description syntax. 662 2.4.3 Example 664 For example, it would be useful for the directory to know when an 665 entry was put into the directory. The following definition is an 666 Attribute Type Description that could be used to specify such 667 an attribute. 669 ( 2.5.18.1 NAME 'createTimestamp' 670 EQUALITY generalizedTimeMatch 671 ORDERING generalizedTimeOrderingMatch 672 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 673 SINGLE-VALUE 674 NO-USER-MODIFICATION 675 USAGE directoryOperation ) 677 The SYNTAX oid indicates the Generalized Time syntax. 679 2.5 Object Classes 681 Object classes are used to categorize the kinds of entries stored in 682 the directory and to determine what attributes are contained in 683 those entries. 685 In general, every entry is defined in terms of an abstract class 686 ("top"), at least one structural object class, and zero or more 687 auxiliary object classes. 689 Whether an object class is abstract, structural, or auxiliary is 690 defined when the object class OID is assigned. An object class 691 definition ought not be changed without having a new identifier 692 assigned to it. 694 2.5.1 Object Classes Implementation Status 696 Servers SHOULD implement the subschema object class. 698 Implementing the extensibleObject object class is OPTIONAL. 700 Servers MUST publish in the objectClasses attribute of the same 701 subschema entry, the definitions of object classes referenced by 702 values of the nameForms and dITContentRules attributes, and object 703 classes referenced by the SUP field in values of the objectClasses 704 attribute itself. Other unreferenced object classes MAY be 705 published in the objectClasses attribute. 707 Schema developers MUST NOT create object class definitions whose 708 names conflict with object classes defined for use with LDAP in 709 existing standards-track RFCs. See the registry of names of Object 710 Classes maintained by IANA [Consid]. 712 2.5.2 Object Class Description 714 Object class descriptions are written according to the following 715 ABNF. The productions for whsp, numericoid, qdescrs, qdstring, 716 space, and oids are given in section 2.1. Implementors, note that 717 future versions of this document could expand this definition to 718 include additional terms. Terms whose identifier begins with 719 "X-" are reserved for private experiments, and MUST be followed by a 720 and a tokens. 722 ObjectClassDescription = "(" whsp 723 numericoid 724 [ space "NAME" space qdescrs ] 725 [ space "DESC" space qdstring ] 726 [ space "OBSOLETE" ] 727 [ space "SUP" space oids ] 728 [ space ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) ] 729 [ space "MUST" space oids ] 730 [ space "MAY" space oids ] ; AttributeTypes 731 extensions 732 whsp ")" 734 The numericoid is the identifier of the ObjectClass being described. 736 The NAME string is the string registered with IANA [Consid] and used 737 to identify instances of the ObjectClass described. 739 The SUP oids are the identifiers of the Object Classes which are the 740 superclasses (object classes) of the Object Class defined. 742 The default setting is "structural" when ABSTRACT, STRUCTURAL, and 743 AUXILIARY are absent. 745 The MUST oids identify the Attribute Types that are required to have 746 values in every instance of the Object Class. 748 The MAY oids identify Attribute Types that can appear, as 749 appropriate, in an instance of the Object Class. 751 2.5.3 Example 753 For example, information about an employee with respect to their 754 job is useful in an application which queries the directory. The 755 same pieces of information are needed in several kinds of entries, 756 such as manager, part-time, and exempt employees. An auxiliary 757 object class could be developed to be included in the structural 758 object classes that represent the different kinds of employees. The 759 pieces of information could be: name of the last training course 760 attended, how many courses has the employee taken, category of 761 training program. The types of information could be named the 762 lastCourse, coursesCount, program attributes, respectively. The 763 following could be the description of an auxiliary object class that 764 provides for inclusion of the training information in different 765 kinds of entries. (The OID is artificial.) 767 ( 1.1.3.170.2.65 NAME 'trainingInfo' 768 AUXILIARY 769 MUST program 770 MAY ( lastCourse $ coursesCount ) ) 772 3. Syntaxes 774 3.1 Attribute Type Description 776 A value in this syntax is a definition of an attribute type 777 according to the ABNF given in paragraph 2.4.2. The native LDAP 778 encoding is the character codes in UTF-8 which correspond to the 779 characters in the definition. 781 This syntax is the form in which schema attribute types are 782 published in the directory in a subentry. The following syntax 783 description gives the OID assigned to this syntax: 785 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 787 For example, this is the definition from [User] of the 788 businessCategory attribute type: 790 ( 2.5.4.15 NAME 'businessCategory' 791 EQUALITY caseIgnoreMatch 792 SUBSTR caseIgnoreSubstringsMatch 793 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) 795 The syntax type for the businessCategory Attribute Type is Directory 796 String. 798 This example definition is a value of the Attribute Type Description 799 syntax. The native LDAP encoding of this value is the definition 800 itself. 802 3.2 Bit String 804 A value in this syntax is a value of the BIT STRING data type from 805 ASN.1 [ASN1]. The following syntax description gives the OID 806 assigned to this syntax: 808 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 810 The native LDAP encoding of a value is the following ABNF: 812 bitstring = "'" *binary-digit "'B" 814 binary-digit = "0" / "1" 816 Example: '0101111101'B 818 3.3 Boolean 820 A value in this syntax is a value of the BOOLEAN data type from 821 ASN.1 [ASN1]. That is, there are exactly two values: one value 822 representing logically true, and the other representing logically 823 false. The following syntax description gives the OID assigned to 824 this syntax: 826 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 828 The native LDAP encoding of a value is the following ABNF: 830 boolean = "TRUE" / "FALSE" 832 3.4 Country String 834 A value in this syntax is two ASN.1 printable string characters 835 representing a country. The permitted values are as listed in 836 ISO 3166 [Codes]. The following syntax description gives the OID 837 assigned to this syntax: 839 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 841 The native LDAP encoding of a value is the following ABNF: 843 CountryString = p p 845 The production for p is given in section 2.1. 847 Example: US 849 3.5 Delivery Method 851 A value in this syntax is a set of the ASN.1 enumerated INTEGER 852 values that indicates, in preference order, the service(s) by which 853 the user, represented by the entry, is willing and/or capable of 854 receiving messages. 856 The following syntax description gives the OID assigned to this 857 syntax: 859 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 861 The native LDAP encoding of a value is the following ABNF: 863 delivery-value = pdm / ( whsp pdm space "$" space delivery-value ) 865 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 866 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 868 The production for space is given in section 2.1. 870 Example: telephone $ videotex 872 3.6 Directory String 874 A value in this syntax is a value of one of the TeletexString, 875 PrintableString or UniversalString data types from ASN.1 [ASN1]. The 876 minimum length of a Directory String value is one character, that 877 is, the string cannot be 'empty'. The following syntax description 878 gives the OID assigned to this syntax: 880 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 882 The native LDAP encoding of a value is the character string itself. 884 Note: The form of DirectoryString is not indicated in protocol, 885 unless the ;binary option is used (see [Prot]). Servers which 886 convert to DAP MUST choose an appropriate form. Servers MUST NOT 887 reject values merely because they contain legal Unicode characters 888 outside of the range of printable ASCII. 890 Servers and clients MUST be prepared to receive arbitrary Unicode 891 characters, including characters not presently assigned to any 892 character set. 894 Example: 895 This is a string of DirectoryString containing #!%#@. 897 For characters in the PrintableString form, the value in the native 898 LDAP encoding is the value itself. 900 If it is in the TeletexString form, then the characters are 901 transliterated to their equivalents in UniversalString, and encoded 902 in UTF-8 [UTF-8]. 904 If it is in the UniversalString or BMPString forms [UCS], UTF-8 is 905 the native LDAP encoding. 907 3.7 DIT Content Rule Description 909 A value in this syntax is a definition of a DIT content rule 910 according to the following ABNF: 912 DITContentRuleDescription = "(" whsp 913 numericoid 914 [ space "NAME" space qdescrs ] 915 [ space "DESC" space qdstring ] 916 [ space "OBSOLETE" ] 917 [ space "AUX" space oids ] 918 [ space "MUST" space oids ] 919 [ space "MAY" space oids ] 921 [ space "NOT" space oids ] 922 extensions 923 whsp ")" 925 The numericoid is the identifier of the Structural Object Class to 926 which the Content Rule being described applies. 928 The MUST oids identify Attribute Types, besides those in the 929 Structural Object Class, that must have values in every instance of 930 the Object Class. 932 ...The MAY oids identify Attribute Types, besides those in the 933 Structural and Auxiliary Object Classes, that are permitted to have 934 values in an instance of the Structural Object Class. 936 The NOT oids identify Attribute Types, which occur in the Structural 937 and Auxiliary Object Classes, that are prohibited from having values 938 in an instance of the Structural Object Class. 940 The AUX oids identify the Auxiliary Object Classes which can be 941 added to instances of the Structural Object Class. 943 The productions for whsp, numericoid, qdescrs, qdstring, space and 944 oids are given in section 2.1. Implementors, note that future 945 versions of this document could expand this ABNF to include 946 additional terms. Terms which begin with the characters "X-" are 947 reserved for private experiments, and MUST be followed by a 948 and a tokens. 950 This syntax is the form in which schema content rules are published 951 in the directory in a subentry. The following syntax description 952 gives the OID assigned to this syntax: 954 ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule 955 Description' ) 957 3.8 DIT Structure Rule Description 959 A value in the DIT Structure Rule Description syntax is a definition 960 of a schema Structure Rule according to the following ABNF: 962 DITStructureRuleDescription = "(" whsp 963 ruleidentifier 964 [ space "NAME" space qdescrs ] 965 [ space "DESC" space qdstring ] 966 [ space "OBSOLETE" ] 967 space "FORM" space oid 968 [ space "SUP" ruleidentifiers ] 969 extensions 970 whsp ")" 972 The ruleidentifier is an integer which distinguishes one Structure 973 Rule from the others used in the same LDAP server. 975 The FORM oid identifies the Name Form that specifies the naming 976 attribute(s) used at the point in the DIT to which the Structure 977 Rule applies. 979 The SUP ruleidentifiers indicate the Structure Rules that can be 980 applied immediately ahead of the subject Structure Rule in the DIT. 981 That is, the RDN forms which can be one level higher in the DIT. 983 ruleidentifier = numericstring 985 ruleidentifiers = ruleidentifier / "(" whsp ruleidentifierlist 986 whsp ")" 988 ruleidentifierlist = [ ruleidentifier *( space ruleidentifier ) ] 990 The productions for whsp, numericstring, qdescrs, qdstring, space, 991 and oid are given in paragraph 2.1. 993 The native LDAP encoding is the character codes in UTF-8 [UTF-8] 994 which correspond to the characters in the structure rule definition. 996 This syntax is the form in which schema structure rules are 997 published in the directory in a subentry. The following syntax 998 description gives the OID assigned to this syntax: 1000 ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule 1001 Description' ) 1003 3.9 DN 1005 A value in the Distinguished Name syntax is a structured set of the 1006 ASN.1 data types that are included in the DirectoryString syntax. 1007 The following syntax description gives the OID assigned to this 1008 syntax: 1010 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 1012 The native LDAP encoding of a value is defined in [DN String]. Note 1013 that the native LDAP encoding is not reversible to the original BER 1014 encoding used in X.500 for Distinguished Names, as the CHOICE of any 1015 DirectoryString element in an RDN is not evident in the native LDAP 1016 encoding.. See the note in section 3.10. 1018 Examples (from [DN String]): 1020 CN=Steve Kille,O=Isode Limited,C=GB 1022 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 1023 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 1025 CN=Before\0DAfter,O=Test,C=GB 1027 1.1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 1029 SN=Lu\C4\8Di\C4\87 1031 3.10 Enhanced Guide 1033 A value in the Enhanced Guide syntax is the matching criteria and 1034 scope of operation in an Enhanced Filter. 1036 The native LDAP encoding of a value is the following ABNF: 1038 EnhancedGuide = space oid whsp "#" whsp criteria whsp "#" 1039 whsp subset 1041 subset = "baseobject" / "oneLevel" / "wholeSubtree" 1043 criteria = or-term / "(" or-term ")" 1045 or-term = and-term *( "|" and-term ) 1047 and-term = not-term *( "&" not-term ) 1049 not-term = "!" not-term / 1050 attributetype "$" match-type / 1051 "(" or-term ")" / 1052 "?true" / ; 1053 "?false" 1055 The ?true term alternative represents an empty "and" in the Criteria 1056 ASN.1 type. The ?false alternative represents an empty "or" in the 1057 Criteria ASN.1 type. 1059 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 1061 The following syntax description gives the OID assigned to this syntax: 1063 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 1065 Example: 1067 person#(sn)#oneLevel 1069 3.11 Facsimile Telephone Number 1071 A value in the Facsimile Telephone Number syntax is a subscriber 1072 number on the (public) telephone network of a facsimile device. The 1073 native LDAP encoding of a value is the following ABNF: 1075 fax-number = printablestring [ "$" faxparameters ] 1076 ; telephone number, possibly followed by facsimile 1077 parameters 1079 faxparameters = faxparm / ( faxparm "$" faxparameters ) 1081 faxparm = "twoDimensional" / "fineResolution" / "unlimitedLength" 1082 / "b4Length" / "a3Width" / "b4Width" / "uncompressed" 1084 The production for printablestring is given in section 2.1. 1086 The telephone number is based on E.123 [Tel #]. 1088 A printablestring is the PrintableString data type from ASN.1 1089 [ASN1]. The following syntax description gives the OID assigned 1090 to this syntax: 1092 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') 1094 3.12 Fax 1096 A value in the Fax syntax is an image which is produced using the 1097 Group 3 facsimile process [Fax] to duplicate an object, such as 1098 a memo. 1100 The following syntax description gives the OID assigned to this 1101 syntax: 1103 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 1105 Values in this syntax are expressed as octet strings containing 1106 Group 3 Fax images as defined in [Fax]. 1108 3.13 Generalized Time 1110 A value in the Generalized Time syntax is a date and time. The year 1111 is given as a four-digit number. 1113 The native LDAP encoding is a value of the GeneralizedTime data type 1114 from ASN.1 [ASN1]. Time zone MUST be present and SHOULD be GMT (Z). 1116 The following syntax description gives the OID assigned to this 1117 syntax: 1119 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 1121 Example: 1122 199412161032Z means 10:32 a.m. Dec. 16, 1994 in the Greenwich 1123 Mean Time time zone. 1125 3.14 Guide 1127 A value in the Guide syntax is the matching criteria in a Filter. 1129 The following syntax description gives the OID assigned to this 1130 syntax: 1132 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 1134 The Guide syntax is not intended to be used for defining new 1135 attributes. It is important for backwards compatibility with LDAP 1136 systems that implement an earlier version of LDAP [LDAP '95]. 1138 The native LDAP encoding of a value is defined by the following ABNF: 1140 guide-value = [ object-class "#" ] criteria 1142 object-class = space oid 1144 The criteria production is defined in the Enhanced Guide syntax in 1145 section 3.14. The productions for oid and space are in section 2.1. 1147 3.15 IA5 String 1149 A value in the IA5 String syntax is a value of the IA5String data 1150 type from ASN.1 [ASN1]. International Alphabet 5 (IA5) [IA5] is the 1151 international version of the ASCII character set. 1153 The following syntax description gives the OID assigned to this 1154 syntax: 1156 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 1158 The native LDAP encoding of a value in this syntax is the character 1159 string value itself. 1161 3.16 Integer 1163 A value in the INTEGER syntax is a whole number as specified in the 1164 INTEGER data type from ASN.1 [ASN1]. 1166 The following syntax description gives the OID assigned to this 1167 syntax: 1169 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 1171 The native LDAP encoding of a value is the decimal representation of 1172 the value, with each decimal digit represented by the its character 1173 equivalent. So, the number 1321 is represented by the character 1174 string "1321". 1176 3.17 JPEG 1178 A value in the JPEG syntax is an image produced according to 1179 specific rules for light values. The native LDAP encoding of a 1180 value is strings containing JPEG images in the JPEG File Interchange 1181 Format (JFIF), as described in [JPEG]. 1183 The following syntax description gives the OID assigned to this 1184 syntax: 1186 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 1188 3.18 LDAP Syntax Description 1190 A value in the LDAP Syntax Description syntax is a definition of a 1191 LDAP syntax description according to the ABNF given in section 2.2.3. 1193 The native LDAP encoding is the character codes in UTF-8 [UTF-8] 1194 which correspond to the characters in the definition. 1196 This syntax is the form in which schema syntax descriptions are 1197 published in the directory in a subentry. The following syntax 1198 description gives the OID assigned to this syntax: 1200 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 1202 Note that, in X.520 [Attr], syntaxes are not labeled distinctly 1203 with respect to attributes. 1205 3.19 Matching Rule Description 1207 A value in the Matching Rule Description syntax is a definition of 1208 a matching rule according to the ABNF given in section 2.3.2. The 1209 native LDAP encoding is the character codes in UTF-8 [UTF-8] which 1210 correspond to the characters in the definition of a Matching Rule. 1211 This syntax is the form in which schema matching rules are published 1212 in the directory in a subentry. The following syntax definition 1213 gives the OID assigned to this syntax: 1215 ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Description' ) 1217 3.20 Matching Rule Use Description 1219 A value in the Matching Rule Use Description syntax is a definition 1220 of a matching Rule and the attribute types with which the rule could 1221 be used in an extensibleMatch search filter according to the 1222 following ABNF: 1224 MatchingRuleUseDescription = "(" whsp 1225 numericoid 1226 [ space "NAME" space qdescrs ] 1228 [ space "DESC" space qdstring ] 1229 [ space "OBSOLETE" ] 1230 space "APPLIES" space oids ; AttributeType identifiers 1231 extensions 1232 whsp ")" 1234 The numericoid identifies the Matching Rule for which the usage is 1235 specified. 1237 The APPLIES oids identify the Attribute Types for which the Matching 1238 Rule can be used. 1240 The productions for whsp, numericoid, qdescrs, qdstring, space, and 1241 oids are given in paragraph 2.1. Implementors, note that 1242 future versions of this document could expand this ABNF to include 1243 additional terms. Terms whose identifier begins with "X-" are 1244 reserved for private experiments, and MUST be followed by a 1245 and a tokens. 1247 The native LDAP encoding is the character codes in UTF-8 [UTF-8] 1248 which correspond to the characters in the definition. 1250 The following syntax description gives the OID assigned to this 1251 syntax: 1253 ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use 1254 Description' ) 1256 This syntax is the form in which schema matching rule usage 1257 permissions are published in the directory in a subentry. 1259 3.21 MHS OR Address 1261 A value in the MHS OR Address syntax is the addressing information of 1262 a user of an X.400 messaging service. The native LDAP encoding is 1263 defined in RFC 1327 [Map]. 1265 The following syntax description gives the OID assigned to this 1266 syntax: 1268 ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) 1270 3.22 Name and Optional UID 1272 A value of the Name and Optional UID (Unique IDentifier) syntax is a 1273 Distinguished Name as defined in section 3.13 plus a bit string 1274 that differentiates the value from otherwise identical names. 1276 The native LDAP encoding of a value is the following ABNF: 1278 NameAndOptionalUID = DistinguishedName [ "#" bitstring ] 1280 The bitstring production is defined in section 3.3. 1282 Although the '#' character could occur in a string representation of 1283 a distinguished name, no additional special quoting is done. 1285 Example: 1286 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 1288 The following syntax description gives the OID assigned to this 1289 syntax: 1291 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 1293 3.23 Name Form Description 1295 A value in the Name Form Description syntax is a definition of a 1296 Name Form according to the following ABNF: 1298 NameFormDescription = "(" whsp 1299 numericoid 1300 [ space "NAME" space qdescrs ] 1301 [ space "DESC" space qdstring ] 1302 [ space "OBSOLETE" ] 1303 space "OC" space oid 1304 space "MUST" space oids ; AttributeTypes 1305 [ space "MAY" space oids ] ; AttributeTypes 1306 extentions 1307 whsp ")" 1309 The numericoid identifies the Name Form being described. 1311 The OC oid identifies the Structural Object Class for instances of 1312 which the Name Form specifies the naming attributes (i.e., the RDN). 1314 The MUST oids identify the Attribute Types that are required to have 1315 a distinguished value in the RDN for a directory entry. 1317 The MAY oids identify Attribute Types that are optional in the RDN. 1319 The productions for whsp, numericoid, qdescrs, qdstring, oid, and 1320 oids are given in section 2.1. Implementors, note that future 1321 versions of this document could have expanded this ABNF to include 1322 additional terms. 1324 A value indicates the one or more attributes in an entry type (e.g., 1325 person, device) that are used as the Relative Distinguished Name of 1326 the entries. 1328 This syntax is the form in which schema name forms are published in 1329 the directory. The native LDAP encoding of a value is the character 1330 codes in UTF-8 [UTF-8] which correspond to the characters in the 1331 definition. 1333 The following syntax description gives the OID assigned to this 1334 syntax: 1336 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 1338 3.24 Numeric String 1340 A value in the Numeric String syntax is a series of numerals and 1341 spaces as specified in the NumericString data type from 1342 ASN.1 [ASN1]. The following string states the OID assigned to 1343 this syntax: 1345 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 1347 The representation of a string in this syntax is the string value 1348 itself. 1350 Example: 1997 1352 3.25 Object Class Description 1354 A value in this syntax is a character string which expresses the 1355 definition of an object class according to the ABNF given in 1356 section 2.5.2. This syntax is the form in which schema object 1357 classes are published in the directory in a subentry. The following 1358 string states the OID assigned to this syntax: 1360 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 1362 For example, the character string below specifies the country object 1363 class, which requires the c (country name) attribute and allows the 1364 searchGuide and description attributes. All of these schema 1365 elements are specified in [User]. 1367 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 1368 MAY ( searchGuide $ description ) ) 1370 3.26 Octet String 1372 A value in the Octet String syntax is a value of the OCTET STRING 1373 data type from ASN.1 [ASN1]. The following string states the OID 1374 assigned to this syntax: 1376 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 1378 Values in this syntax are written as a series of 8-bit values, 1379 according to the octet string value notation specified in [ASN1]. 1380 In the case of character strings, the characters themselves could be 1381 written. 1383 Example: 1384 secret 1386 3.27 OID 1388 A value in the Object Identifier syntax is a series of integers, 1389 ordered as specified in the OBJECT IDENTIFIER data type from ASN.1 1390 [ASN1]. The following string states the OID assigned to this 1391 syntax: 1393 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 1395 Values in this syntax are expressed according to the ABNF in 1396 section 2.1 for "oid". 1398 Examples: 1.2.3.4 1399 cn 1401 3.28 Other Mailbox 1403 A value in the Other Mailbox syntax gives a mail system name with 1404 the name of a mailbox in the system. The following string states 1405 the OID assigned to this syntax: 1407 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 1409 Values in this syntax are written according to the following ABNF: 1411 otherMailbox = mailbox-type "$" mailbox 1413 mailbox-type = printablestring 1415 mailbox = 1417 The printablestring production is defined in section 2.1. 1419 In the above, mailbox-type represents the type of mail system in 1420 which the mailbox resides, for example "MCIMail"; and mailbox is 1421 the actual mailbox in the mail system defined by mailbox-type. 1423 3.29 Postal Address 1425 A value in the Postal Address syntax is a series of strings which 1426 form an address in a physical mail system. The following string 1427 states the OID assigned to this syntax: 1429 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 1431 Values in this syntax are written according to the following ABNF: 1433 postal-address = dstring *( "$" dstring ) 1435 In the above, each dstring component of a postal address value is 1436 written as a value of type Directory String syntax. Backslashes and 1437 dollar characters, if they occur in the component, are quoted as 1438 described in section 2.1. Many servers limit the postal address to 1439 six lines of up to thirty characters. 1441 The production for dstring is defined in section 2.1. 1443 Example: 1445 1234 Main St.$Anytown, CA 12345$USA 1446 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 1448 3.30 Presentation Address 1450 A value in the Presentation Address syntax is an OSI Application 1451 Layer address of a remote application. Logically, a presentation 1452 address consists of: 1454 o A presentation selector 1456 o A session selector 1458 o A transport selector 1460 o A set of network addresses 1462 The following string states the OID assigned to this syntax: 1463 ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) 1465 Values in this syntax are written according to the following ABNF: 1467 presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ] 1468 network-address-list 1470 psel = selector 1471 ssel = selector 1472 tsel = selector 1474 network-address-list = network-address "_" network-address-list / 1475 network-address 1477 network-address = "NS" "+" dothexstring 1478 / afi "+" idi [ "+" dsp ] 1479 / idp "+" hexstring 1481 The first (NS) alternative is the Concrete Binary Representation. 1482 It is the compact encoding. 1484 The afi alternative is a user-oriented representation of a network 1485 address. 1487 The idp alternative is a form of network-address included for 1488 compatibility with ISO 8348 [NSAP]. 1490 selector = """ otherstring """ 1491 / "#" numericstring 1492 / "'" hexstring "'H" 1493 / "" 1495 The otherstring alternative for the selector is IA5 characters. 1497 The "" alternative for the selector expresses the case where the 1498 selector is present, but Empty. 1500 idp = numericstring 1502 dsp = "d" numericstring 1503 / "x" dothexstring 1504 / "l" otherstring 1505 / "RFC-1006" "+" prefix "+" ip [ "+" port [ "+" tset ]] 1506 / "X.25(80)" "+" prefix "+" dte [ "+" cudf-or-pid "+" 1507 hexstring ] 1508 / "ECMA-117-Binary" "+" hexstring "+" hexstring "+" hexstring 1509 / "ECMA-117-Decimal" "+" numericstring "+" 1510 numericstring "+" numericstring 1512 The d alternative is the Abstract Decimal form of the Domain 1513 Specific Part (dsp) in a network address. 1515 The x alternative is the Abstract Binary form of the dsp in a 1516 network address. 1518 The l alternative is IA5 characters and is only meaningful locally. 1520 idi = numericstring 1522 afi = "X121" / "DCC" / "TELEX" / "PSTN" / "ISDN" / "ICD" / "LOCAL" 1524 prefix = DIGIT DIGIT 1526 ip = numericstring 1527 ; dotted decimal form (e.g., 10.0.0.6) or 1528 domain (e.g., twg.com) 1530 port = numericstring 1532 tset = numericstring 1534 dte = numericstring 1536 cudf-or-pid = "CUDF" / "PID" 1538 other = k / "+" / DOT 1540 domainchar = k / DOT 1541 hexoctet = hex-digit hex-digit 1543 decimal-octet = 1*3DIGIT 1545 otherstring = other otherstring / other 1547 domainstring = domainchar otherstring / domainchar 1549 hexstring = hexoctet hexstring / hexoctet 1551 dotstring = decimaloctet DOT dotstring / 1552 decimaloctet DOT decimaloctet 1554 dothexstring = dotstring / hexstring 1556 3.31 Printable String 1558 A value in the Printable String syntax is a series of alphabetic, 1559 numeric, and (limited) punctuation characters as specified in the 1560 PrintableString data type from ASN.1 [ASN1] and in production p of 1561 section 2.1. Values in this syntax are expressed as the string 1562 itself. The following string states the OID assigned to this syntax: 1564 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 1566 Example: This is a PrintableString. 1568 3.32 Substring Assertion 1570 The Substring Assertion syntax is used in rules which can be used in 1571 substrings and extensible matching rules. When using a substrings 1572 assertion, substrings components are provided in a SubstringFilter 1573 sequence. The following string states the OID assigned to this 1574 syntax: 1576 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1578 When using a matching rule assertion, substring components are 1579 encoded according to the following ABNF and provided as the 1580 matchValue of the MatchingRuleAssertion: 1582 substring = [initial] any [final] 1584 initial = value 1586 any = "*" *(value "*") 1588 final = value 1590 The production is a UTF-8 [UTF-8] string. If a backslash or 1591 asterix character is present in a production of , it is 1592 quoted as described in section 2.1. 1594 3.33 Telephone Number 1596 A value in the telephone number syntax is the series of characters 1597 that express a number (address) assigned to a telephone system 1598 subscriber. The following string states the OID assigned to this 1599 syntax: 1601 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1603 Values in this syntax are written as if they were Printable String 1604 types. Telephone numbers are defined in X.520 [Attr] to comply 1605 with the internationally agreed format for expressing international 1606 telephone numbers in Recommendation E.123 [Tel #]. 1608 Example: +1 512 315 0280 1610 3.34 Teletex Terminal Identifier 1612 A value in this syntax is a string of characters that express the 1613 identifier value assigned to a teletex service subscriber. The 1614 following string states the OID assigned to this syntax: 1616 ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal 1617 Identifier' ) 1619 Values in this syntax are written according to the following ABNF: 1621 teletex-id = ttx-term 0*("$" ttx-param) 1623 ttx-term = printablestring 1625 ttx-param = ttx-key ":" ttx-value 1627 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1629 ttx-value = octetstring 1631 In the above, the first printablestring is the encoding of the first 1632 portion of the teletex terminal identifier to be encoded, and the 1633 subsequent 0 or more octetstrings are subsequent portions of the 1634 teletex terminal identifier. 1636 The productions for printablestring and octetstring are defined in 1637 section 2.1. 1639 3.35 Telex Number 1641 A value in the Telex Number syntax is the number assigned to a telex 1642 system subscriber with the country and answerback values indicated. 1644 The following string states the OID assigned to this syntax: 1646 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1648 Values in this syntax are written according to the following ABNF: 1650 telex-number = actual-number "$" country "$" answerback 1652 actual-number = printablestring 1654 country = printablestring 1656 answerback = printablestring 1658 In the above, actual-number is the syntactic representation of the 1659 number portion of the TELEX number being written, country is the 1660 TELEX country code, and answerback is the answerback code of a TELEX 1661 terminal. 1663 The production for printablestring is defined in section 2.1. 1665 3.36 UTC Time 1667 A value in the UTC Time syntax is a date and time indicating accuracy 1668 to minute or second. The year is given as a two-digit number. The 1669 following string states the OID assigned to this syntax: 1671 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1673 Values in this syntax are written as if they were printable strings, 1674 formulated as specified for the UTCTime data type in ASN.1 [ASN1]. 1675 It is strongly suggested that GMT time be used. 1677 Note: This syntax is deprecated in favor of the Generalized Time 1678 syntax. 1680 4. Matching Rules 1682 When performing the caseExactMatch, caseIgnoreMatch, 1683 caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and 1684 caseIgnoreIA5Match, multiple adjoining whitespace characters are 1685 treated the same as an individual space, and leading and trailing 1686 whitespace is ignored. 1688 4.1 bitStringMatch 1690 The following ABNF associates the bitStringMatch rule with the Bit 1691 String syntax: 1693 ( 2.5.13.16 NAME 'bitStringMatch' 1694 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) ; Bit String 1696 This matching rule is used to test equality. 1698 4.2 caseExactIA5Match 1700 The following ABNF associates the caseExactIA5Match rule with the IA5 1701 String syntax: 1703 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1704 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String 1706 This matching rule is used to test equality. 1708 4.3 caseIgnoreIA5Match 1710 The following ABNF associates the caseIgnoreIA5Match rule with the 1711 IA5 String syntax: 1713 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1714 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String 1716 This matching rule is used to test equality. 1718 4.4 caseIgnoreListMatch 1720 The ABNF below associates the caseIgnoreListMatch rule with the 1721 Postal Address syntax. The X.520 [Attr] syntax for this matching 1722 rule is a SEQUENCE Of DirectoryString. Since the Postal Address 1723 syntax is such a sequence, it is used in defining the matching rule 1724 for LDAP, although the matching rule can be used with any SEQUENCE 1725 OF DirectoryString syntax/assertion. 1727 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1728 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ; Postal Address 1730 This matching rule is used to test equality. 1732 4.5 caseIgnoreMatch 1734 The following ABNF associates the caseIgnoreMatch rule with the 1735 Directory String syntax: 1737 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1738 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String 1740 This matching rule is used to test equality. 1742 4.6 caseIgnoreOrderingMatch 1744 The following ABNF associates the caseIgnoreOrderingMatch rule with 1745 the Directory String syntax: 1747 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1748 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String 1750 This matching rule is used to test inequality, i.e., greaterOrEqual 1751 or lessOrEqual. 1753 The sort ordering for a caseIgnoreOrderingMatch is implementation- 1754 dependent. 1756 4.7 caseIgnoreSubstringsMatch 1758 The following ABNF associates the caseIgnoreSubstringsMatch rule with 1759 the Substring Assertion: 1761 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1762 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1764 This matching rule is used to test substrings equality. 1766 4.8 distinguishedNameMatch 1768 The following ABNF associates the distinguishedNameMatch rule with 1769 the DN syntax: 1771 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1772 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ; DN 1774 This matching rule is used to test equality. 1776 4.9 generalizedTimeMatch 1778 The following ABNF associates the generalizedTimeMatch rule with the 1779 Generalized Time syntax: 1781 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1782 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ; Generalized Time 1784 This matching rule is used to test equality. 1786 4.10 generalizedTimeOrderingMatch 1788 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1789 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ; Generalized Time 1791 This matching rule is used to test inequality, i.e., greaterOrEqual 1792 or lessOrEqual. 1794 4.11 integerFirstComponentMatch 1796 The following ABNF associates the integerFirstComponentMatch rule 1797 with the INTEGER syntax: 1799 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1800 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER 1802 Implementors, note that the assertion syntax of this matching 1803 rule, an INTEGER, is different from the value syntax of attributes 1804 for which this is the equality matching rule. 1806 This matching rule is used to test equality with the first component 1807 in a compound syntax. 1809 4.12 integerMatch 1811 The following ABNF associates the integerMatch rule with the INTEGER 1812 syntax: 1814 ( 2.5.13.14 NAME 'integerMatch' 1815 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER 1817 This matching rule is used to test equality. 1819 4.13 numericStringMatch 1821 The following ABNF associates the numericStringMatch rule with the 1822 Numeric String syntax: 1824 ( 2.5.13.8 NAME 'numericStringMatch' 1825 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) ; Numeric String 1827 This matching rule is used to test equality. 1829 4.14 numericStringSubstringsMatch 1831 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1832 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1834 This matching rule is used to test substrings equality. 1836 4.15 objectIdentifierFirstComponentMatch 1838 The following ABNF associates the 1839 objectIdentifierFirstComponentMatch rule with the OID syntax: 1841 ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' 1842 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID 1844 If the client supplies an extensible filter using an 1845 objectIdentifierFirstComponentMatch whose matchValue is in the 1846 "descr" form, and the OID is not recognized by the server, then the 1847 filter is Undefined. 1849 This matching rule is used to test equality with the first component 1850 in a compound syntax. 1852 4.16 objectIdentifierMatch 1854 The following ABNF associates the objectIdentifierMatch rule with the 1855 OID syntax: 1857 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1858 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID 1860 This matching rule is used to test equality. 1862 Implementors, note that the assertion syntax of this matching 1863 rule, an OID, is different from the value syntax of attributes for 1864 which this is the equality matching rule. 1866 If the client supplies a filter using an objectIdentifierMatch whose 1867 matchValue oid is in the "descr" form, and the oid is not recognized 1868 by the server, then the filter is Undefined. 1870 4.17 octetStringMatch 1872 Servers which implement the extensibleMatch filter SHOULD allow the 1873 matching rule listed in this section to be used in the 1874 extensibleMatch. In general these servers SHOULD allow matching 1875 rules to be used with all attribute types known to the server, when 1876 the assertion syntax of the matching rule is the same as the value 1877 syntax of the attribute. 1879 The Octet String Match rule compares for equality an asserted octet 1880 string with an attribute value of type OCTET STRING. 1882 The strings match if they are the same length and corresponding 1883 octets are identical. 1885 ( 2.5.13.17 NAME 'octetStringMatch' 1886 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1888 4.18 presentationAddressMatch 1890 The following ABNF associates the presentationAddressMatch rule with 1891 the Presentation Address syntax: 1893 ( 2.5.13.22 NAME 'presentationAddressMatch' 1894 SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) ; Presentation Address 1896 This matching rule is used to test equality. 1898 4.19 protocolInformationMatch 1900 The following ABNF associates the protocolInformationMatch rule with 1901 the Protocol Information syntax: 1903 ( 2.5.13.24 NAME 'protocolInformationMatch' 1904 SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) ; Protocol Information 1906 This matching rule is used to test equality. 1908 4.20 telephoneNumberMatch 1910 The following ABNF associates the telephoneNumberMatch rule with the 1911 Telephone Number syntax: 1913 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1914 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) ; Telephone Number 1916 This matching rule is used to test equality. 1918 4.21 telephoneNumberSubstringsMatch 1920 The following ABNF associates the telephoneNumberSubstringsMatch rule 1921 with the Substring Assertion syntax: 1923 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 1924 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1926 This matching rule is used to test substrings equality. 1928 4.22 uniqueMemberMatch 1930 The following ABNF associates the uniqueMemberMatch rule with the 1931 Name and Optional UID syntax: 1933 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1934 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) ; Name And Optional UID 1936 This matching rule is used to test equality. 1938 5. Attribute Types 1940 5.1 altServer 1942 The values of this attribute are URLs of other servers which could be 1943 contacted when this server becomes unavailable. If the server does 1944 not know of any other servers which could be used this attribute will 1945 be absent. Clients can cache this information in case their 1946 preferred LDAP server later becomes unavailable. 1948 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' 1949 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 1950 USAGE dSAOperation ) 1952 The SYNTAX oid indicates the IA5 String syntax. 1954 This attribute is only present in the root DSE (see [Prot] 1955 and [Models]). 1957 5.2 attributeTypes 1959 The attributeTypes attribute holds descriptions of the attributes in 1960 a schema. This attribute is typically located in the subschema 1961 entry. 1963 ( 2.5.21.5 NAME 'attributeTypes' 1964 EQUALITY objectIdentifierFirstComponentMatch 1965 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 1966 USAGE directoryOperation ) 1968 The SYNTAX oid indicates the Attribute Type Description syntax. 1970 5.3 createTimestamp 1972 ( 2.5.18.1 NAME 'createTimestamp' 1973 EQUALITY generalizedTimeMatch 1974 ORDERING generalizedTimeOrderingMatch 1975 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 1976 SINGLE-VALUE 1977 NO-USER-MODIFICATION 1978 USAGE directoryOperation ) 1980 The SYNTAX oid indicates the Generalized Time syntax. 1982 5.4 creatorsName 1984 ( 2.5.18.3 NAME 'creatorsName' 1985 EQUALITY distinguishedNameMatch 1986 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 1987 SINGLE-VALUE 1988 NO-USER-MODIFICATION 1989 USAGE directoryOperation ) 1991 The SYNTAX oid indicates the DN syntax. 1993 5.5 ditContentRules 1995 ( 2.5.21.2 NAME 'dITContentRules' 1996 EQUALITY objectIdentifierFirstComponentMatch 1997 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 1998 USAGE directoryOperation ) 2000 The SYNTAX oid indicates the DIT Content Rule Description syntax. 2002 This attribute is located in the subschema entry. 2004 5.6 dITStructureRules 2006 ( 2.5.21.1 NAME 'dITStructureRules' 2007 EQUALITY integerFirstComponentMatch 2008 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 2009 USAGE directoryOperation ) 2011 The SYNTAX oid indicates the DIT Structure Rule Description syntax. 2013 This attribute is located in the subschema entry. 2015 5.7 ldapSyntaxes 2017 This attribute is typically located in the subschema entry. 2019 This attribute identifies the syntaxes implemented, with each value 2020 corresponding to one syntax. 2022 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' 2023 EQUALITY objectIdentifierFirstComponentMatch 2024 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 2025 USAGE directoryOperation ) 2027 The SYNTAX oid indicates the LDAP Syntax Description syntax. 2029 5.8 matchingRules 2031 This attribute is typically located in the subschema entry. 2033 ( 2.5.21.4 NAME 'matchingRules' 2034 EQUALITY objectIdentifierFirstComponentMatch 2035 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 2036 USAGE directoryOperation ) 2038 The SYNTAX oid indicates the Matching Rule Description syntax. 2040 5.9 matchingRuleUse 2042 This attribute is typically located in the subschema entry. 2044 ( 2.5.21.8 NAME 'matchingRuleUse' 2045 EQUALITY objectIdentifierFirstComponentMatch 2046 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 2047 USAGE directoryOperation ) 2049 The SYNTAX oid indicates the Matching Rule Use Description syntax. 2051 5.10 modifiersName 2053 ( 2.5.18.4 NAME 'modifiersName' 2054 EQUALITY distinguishedNameMatch 2055 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2056 SINGLE-VALUE 2057 NO-USER-MODIFICATION 2058 USAGE directoryOperation ) 2060 The SYNTAX oid indicates the DN syntax. 2062 5.11 modifyTimestamp 2064 ( 2.5.18.2 NAME 'modifyTimestamp' 2065 EQUALITY generalizedTimeMatch 2066 ORDERING generalizedTimeOrderingMatch 2067 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 2068 SINGLE-VALUE 2069 NO-USER-MODIFICATION 2070 USAGE directoryOperation ) 2072 The SYNTAX oid indicates the Generalized Time syntax. 2074 5.12 nameForms 2076 ( 2.5.21.7 NAME 'nameForms' 2077 EQUALITY objectIdentifierFirstComponentMatch 2078 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 2079 USAGE directoryOperation ) 2081 The SYNTAX oid indicates the Name Form Description syntax. 2083 This attribute is located in the subschema entry. 2085 5.13 namingContexts 2087 The values of this attribute correspond to naming contexts which 2088 this server masters or shadows. If the server does not master any 2089 information (e.g. it is an LDAP gateway to a public X.500 directory) 2090 this attribute will be absent. If the server believes it contains 2091 the entire directory, the attribute will have a single value, and 2092 that value will be the empty string (indicating the null DN of the 2093 root). This attribute will allow a client to choose suitable base 2094 objects for searching when it has contacted a server. 2096 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' 2097 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2098 USAGE dSAOperation ) 2100 The SYNTAX oid indicates the DN syntax. 2102 This attribute is only present in the root DSE (see [Prot] 2103 and [Models]). 2105 5.14 objectClasses 2107 This attribute is typically located in the subschema entry. 2109 ( 2.5.21.6 NAME 'objectClasses' 2110 EQUALITY objectIdentifierFirstComponentMatch 2111 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 2112 USAGE directoryOperation ) 2114 The SYNTAX oid indicates the Object Class Description syntax. 2116 5.15 subschemaSubentry 2118 The value of this attribute is the name of a subschema entry (or 2119 subentry) where the server makes available attributes specifying the 2120 schema controlling the subject entry. 2122 ( 2.5.18.10 NAME 'subschemaSubentry' 2123 EQUALITY distinguishedNameMatch 2124 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 2125 SINGLE-VALUE 2126 NO-USER-MODIFICATION 2127 USAGE directoryOperation ) 2129 The SYNTAX oid indicates the DN syntax. 2131 5.16 supportedControl 2133 The values of this attribute are the OBJECT IDENTIFIERs identifying 2134 controls which the server supports. If the server does not support 2135 any controls, this attribute will be absent. 2137 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' 2138 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 2139 USAGE dSAOperation ) 2141 The SYNTAX oid indicates the OID syntax. 2143 This attribute is only present in the root DSE (see [Prot] 2144 and [Models]). 2146 5.17 supportedExtension 2148 The values of this attribute are OBJECT IDENTIFIERs identifying the 2149 supported extended operations which the server supports. 2151 If the server does not support any extensions this attribute will be 2152 absent. 2154 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' 2155 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 2156 USAGE dSAOperation ) 2158 The SYNTAX oid indicates the OID syntax. 2160 This attribute is only present in the root DSE (see [Prot] 2161 and [Models]). 2163 5.18 supportedLDAPVersion 2165 The values of this attribute are the versions of the LDAP protocol 2166 which the server implements. 2168 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' 2169 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 2170 USAGE dSAOperation ) 2172 The SYNTAX oid indicates the INTEGER syntax. 2174 This attribute is only present in the root DSE (see [Prot] 2175 and [Models]). 2177 5.19 supportedSASLMechanisms 2179 The values of this attribute are the names of supported SASL 2180 mechanisms which the server supports. If the server does not support 2181 any mechanisms this attribute will be absent. 2183 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' 2184 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 2185 USAGE dSAOperation ) 2187 The SYNTAX oid indicates the Directory String syntax. 2189 This attribute is only present in the root DSE (see [Prot] 2190 and [Models]). 2192 6. Object Classes 2194 6.1 Extensible Object Class 2196 The extensibleObject object class, if present in an entry, permits 2197 that entry to hold any attribute. The "MAY" attribute list 2198 of this class is implicitly the set of all attributes. 2200 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 2201 SUP top 2202 AUXILIARY ) 2203 ; MAY all attributes is implied 2205 The mandatory attributes of the other object classes of this entry 2206 are still required to be present. 2208 Note that not all servers will implement this object class, and those 2209 which do not will reject requests to add entries which contain this 2210 object class, or modify an entry to add this object class. 2212 Note that, if the server implements the extensibleObject class but an 2213 attribute is not recognized, this is the same case as for any other 2214 object class. 2216 6.2 subschema 2218 This object class contains a description of the schema that is 2219 applied in the server and is used in the subschema entry. 2221 ( 2.5.20.1 NAME 'subschema' 2222 AUXILIARY 2223 MAY ( dITStructureRules $ 2224 nameForms $ 2225 ditContentRules $ 2226 objectClasses $ 2227 attributeTypes $ 2228 matchingRules $ 2229 matchingRuleUse ) ) 2231 The ldapSyntaxes operational attribute can also be present in 2232 subschema entries. 2234 7. Security Considerations 2236 7.1 Disclosure 2238 Attributes of directory entries are used to provide descriptive 2239 information about the real-world objects they represent, which can 2240 be people, organizations or devices. Most countries have privacy 2241 laws regarding the publication of information about people. 2243 7.2 Security Information Syntaxes 2245 Several X.500 attributes, such as, the userCertificate attribute, 2246 are used to include key-based security information in directory 2247 entries. The attribute syntaxes for these attributes are: 2249 Certificate 2250 CertificateList 2251 CertificatePair 2252 SupportedAlgorithm 2254 These syntaxes are specified for LDAP by the PKIX Working Group, and 2255 so, are not included in this document. 2257 The ABNF specifications of "User Certificate", "Authority Revocation 2258 List", and "Certificate Pair" in RFC 1778 [Syn String] are 2259 not to be used. 2261 7.3 Use of Attribute Values in Security Applications 2263 The transformations of an AttributeValue value from its X.501 form 2264 to an LDAP string representation are not always reversible back to 2265 the same BER or DER form. 2267 For example, a distinguished name consisting of one RDN with one AVA, 2268 in which the type is commonName and the value is of the 2269 TeletexString choice with the letters 'Sam' would be represented in 2270 LDAP as the string cn=Sam. Another distinguished name in which the 2271 value is still 'Sam' but of the PrintableString choice would have the 2272 same representation cn=Sam. 2274 Applications which require the reconstruction of the DER form of a 2275 value SHOULD NOT use the string LDAP native encoding when converting 2276 a value to LDAP format. Instead the ;binary transfer option [Prot] 2277 SHOULD be used. 2279 7.4 Securing the Directory 2281 In order to protect the directory and its contents, strong 2282 authentication MUST have been used to identify the Client when an 2283 update operation is requested. 2285 8. Acknowledgements 2287 This document is an update of RFC 2252 by M. Wahl, A. Coulbeck, 2288 T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID 2289 Working Group. 2291 This document is based upon input of the IETF LDAPBIS working group. 2292 The authors wish to thank J. Sermersheim and K. Zeilenga for their 2293 significant contribution to this update. 2295 9. Authors' Addresses 2297 Kathy Dally 2298 The MITRE Corp. 2299 7515 Colshire Dr., ms-W650 2300 McLean VA 22102 2301 USA 2303 Phone: +1 703 883 6058 2304 Fax: +1 703 883 7142 2305 Email: kdally@mitre.org 2307 Steven Legg 2308 Adacel Technologies Ltd. 2309 405-409 Ferntree Gully Road 2310 Mount Waverley, Victoria 3149 2311 AUSTRALIA 2313 Phone: +61 3 9451 2107 2314 Fax: +61 3 9541 2121 2315 EMail: steven.legg@adacel.com.au 2317 10 References 2319 10.1 Normative 2321 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 2322 Specifications: ABNF", RFC 2234, November 1997 2324 [ASN1] Information Technology - Abstract Syntax Notation One 2325 (ASN.1): Specification of Basic Notation, ITU-T Recommendation 2326 X.680, 1994 2328 [Attr] The Directory: Selected Attribute Types. ITU-T Recommendation 2329 X.520, 1993. 2331 [Codes] ISO 3166, "Codes for the representation of names of countries". 2333 [DN String] draft-ietf-ldapbis-dn-xx, replacement for Wahl, M., Kille, S., 2334 and T. Howes, "Lightweight Directory Access Protocol (v3): 2335 UTF-8 String Representation of Distinguished Names", RFC 2253, 2336 December 1997. 2338 [Fax] Standardization of Group 3 facsimile apparatus for document 2339 transmission - Terminal Equipment and Protocols for Telematic 2340 Services, ITU-T Recommendation T.4, 1993 2342 [IA5] International Reference Alphabet (IRA) (Formerly International 2343 Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded 2344 Character Set for Information Interchange, ITU-T Recommendation 2345 T.50, 1992 2347 [JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton, 2348 C-Cube Microsystems, Milpitas, CA, September 1, 1992. 2350 [Keywds] Bradner, S., "Key words for use in RFCs to Indicate 2351 Requirement Levels", RFC 2119, March 1997. 2353 [Map] Hardcastle-Kille, S., "Mapping between X.400(1988)/ISO 10021 2354 and RFC 822", RFC 1327, May 1992. 2356 [Models] The Directory: Models, ITU-T Recommendation X.501, 1993. 2358 [Prot] draft-ietf-ldapbis-protocol-xx, replacement for Wahl, M., 2359 Howes, T., and S. Kille, "Lightweight Directory Access Protocol 2360 (v3)", RFC 2251, December 1997. 2362 [Tel #] Notation for national and international telephone numbers, 2363 ITU-T Recommendation E.123, 1988. 2365 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - 2366 Architecture and Basic Multilingual Plane, 2367 ISO/IEC 10646-1: 1993 (with amendments). 2369 [User] draft-ietf-ldapbis-user-schema-xx, replacement for Wahl, M., 2370 "A Summary of the X.500(96) User Schema for use with LDAPv3", 2371 RFC 2256, December 1997. 2373 [UTF-8] Yergeau, F., "UTF-8, a transformation format of Unicode and 2374 ISO 10646", RFC 2044, October 1996. 2376 10.2 Informative References 2378 [LDAP '95] Yeong, W., Howes, T., Kille, S., "Lightweight Directory 2379 Access Protocol", RFC 1777, March 1995 2381 [NSAP] Information technology -- Open Systems Interconnection -- 2382 Network Service Definition, ISO/IEC 8348:1996 2384 [Syn String] Howes, T., Kille, S., Yeong, W., Robbins, C., "The 2385 String Representation of Standard Attribute Syntaxes", RFC 1778, 2386 March 1995. 2388 11. Full Copyright Statement 2390 Copyright (C) The Internet Society (2002). All Rights Reserved. 2392 This document and translations of it may be copied and furnished to 2393 others, and derivative works that comment on or otherwise explain it 2394 or assist in its implementation may be prepared, copied, published 2395 and distributed, in whole or in part, without restriction of any 2396 kind, provided that the above copyright notice and this paragraph 2397 are included on all such copies and derivative works. However, this 2398 document itself may not be modified in any way, such as by removing 2399 the copyright notice or references to the Internet Society or other 2400 Internet organizations, except as needed for the purpose of 2401 developing Internet standards in which case the procedures for 2402 copyrights defined in the Internet Standards process must be 2403 followed, or as required to translate it into languages other 2404 than English. 2406 The limited permissions granted above are perpetual and will not be 2407 revoked by the Internet Society or its successors or assigns. 2409 This document and the information contained herein is provided on an 2410 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2411 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2412 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2413 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2414 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2416 Annex A Object Identifiers of Syntaxes 2418 This list contains the object identifiers for the syntaxes used in 2419 this specification and in the user schema specification [User]. 2421 Syntax of Value Represented OBJECT IDENTIFIER 2422 ===================================================================== 2423 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 2424 Bit String 1.3.6.1.4.1.1466.115.121.1.6 2425 Boolean 1.3.6.1.4.1.1466.115.121.1.7 2427 Country String 1.3.6.1.4.1.1466.115.121.1.11 2429 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 2430 Directory String 1.3.6.1.4.1.1466.115.121.1.15 2431 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 2432 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 2433 DN 1.3.6.1.4.1.1466.115.121.1.12 2434 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 2435 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 2436 Fax 1.3.6.1.4.1.1466.115.121.1.23 2438 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 2439 Guide 1.3.6.1.4.1.1466.115.121.1.25 2440 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 2441 INTEGER 1.3.6.1.4.1.1466.115.121.1.27 2442 JPEG 1.3.6.1.4.1.1466.115.121.1.28 2444 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 2445 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.31 2446 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 2447 MHS OR Address 1.3.6.1.4.1.1466.115.121.1.33 2448 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 2449 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 2450 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 2451 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 2452 Octet String 1.3.6.1.4.1.1466.115.121.1.40 2453 OID 1.3.6.1.4.1.1466.115.121.1.38 2454 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 2455 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 2456 Presentation Address 1.3.6.1.4.1.1466.115.121.1.43 2457 Printable String 1.3.6.1.4.1.1466.115.121.1.44 2458 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 2459 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 2460 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 2461 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 2462 UTC Time 1.3.6.1.4.1.1466.115.121.1.53 2463 Annex B Topics Yet To Be Addressed In This Document 2465 This appendix is provided for informational purposes only, it is not 2466 a normative part of this specification. 2468 APPEARED: -00 2469 Paragraph 2.2.3 - Should any syntaxes listed in the table be removed? 2470 Should any new syntaxes be added? 2471 RESOLUTION: Cannot add syntaxes. Moving the table to an annex keeps 2472 a record of the OIDS that have been assigned. Deleted unspecified 2473 syntaxes from the list. APPLIED: -02 2475 APPEARED: -00 2476 Paragraph 2.2.4 - Should attribute syntaxes be allowed to be referenced 2477 by a common name, and if so, where should the name come from? 2478 RESOLUTION: Rejected because of adding functionality. APPLIED: -01 2480 APPEARED: -00 2481 How does the data model draft affect 2482 this draft? 2483 RESOLUTION: It does not. The draft was preliminary to the revised 2484 Schema and Protocol I-Ds. APPLIED: -01 2486 APPEARED: -00 2487 Section 3 - Should all listed syntaxes from paragraph 2.2.3 be 2488 detailed in this section? Nearly half the listed syntaxes are not 2489 referenced in this section. 2490 RESOLUTION: No, because many are not being used, currently. 2491 APPLIED: -01 2493 APPEARED: -01 2494 Section 4 - Should all of the X.520(1993) matching rules be included? 2495 In particular, how about caseExactMatch? Also, should 2496 octetStringMatch be moved from updated RFC 2256? 2497 RESOLUTION: caseExactMatch not included. octetStringMatch moved to 2498 this document. APPLIED: -01 2500 APPEARED: -00 2501 Section 6 - Recognized list of Object classes needs to be reconciled 2502 with updated RFC 2256 and the data model draft. 2503 RESOLUTION: Not necessary. APPLIED: -01 2505 APPEARED: -00 2506 Section 7 - Proper security statement needs to be formulated. 2507 RESOLUTION: Text has been expanded since RFC 2252, but needs 2508 more work. APPLIED: 2510 Annex C Change Log 2512 This annex lists the changes that have been made from RFC 2252 to 2513 this specification. 2515 This annex is provided for informational purposes only. It is not 2516 a normative part of this specification. Items 32 - end are new in 2517 the -02 version of this document. 2519 1. Removed the IESG Note. 2521 2. Changed "types" to "syntaxes" in the last sentence of the 2522 Abstract. Also, added to the last sentence in order to 2523 indicate that syntaxes are not the only schema elements 2524 defined in this document. 2526 3. Reorganized the sections so that: 2528 * the schema element categories are specified in the 2529 order in which they build on one another: syntaxes, 2530 matching rules, attributes, object classes 2532 * within each category the elements are specified in 2533 alphbetical order 2535 4. Added an "Implementation Status" paragraph for each element, 2536 gathering the conformance statements. 2538 5. Clarified schema description in the Overview. 2540 6. Changed the "Common Encoding Aspects" section title to 2541 "Notation" and made corresponding changes throughout the 2542 document. The purpose being to relegate all encoding issues 2543 to the Protocol specification [Prot]. 2545 7. Added a MUST statement regarding the syntaxes required of 2546 servers. 2548 8. Expanded the discussion of each of the syntaxes in section 3. 2550 9. Added examples to some of the syntax descriptions. 2552 10. Added NAME option to the syntax description ABNF 2553 in 2.2.4. 2555 RESCINDED IN -01!! 2557 11. Added a note deprecating the UTCTime attribute syntax 2558 description in 3.41 2560 12. In the ABNF of the MatchingRuleDescription in paragraph 2.3.2, 2561 replaced "numericoid" with "oid". 2563 13. In paragraph 2.4.1, replaced the conformance statement about 2564 attributes in 2256 with a reference. 2566 14. Added caseIgnoreIA5Match as the EQUALITY matching rule for 2567 the altServer attribute type ABNF in paragraph 5.1. Note that 2568 this could be caseExactIA5Match instead. SHOULD IT BE?? 2570 RESCINDED IN -01 2572 15. In paragraphs 5.10 and 5.11, changed "the MODIFY operation" 2573 to "LDAP update operations" 2575 16. Added distinguishedNameMatch as the EQUALITY matching rule 2576 for the namingContexts attribute type ABNF in paragraph 5.13. 2578 RESCINDED IN -01 2580 17. Reworded paragraph 5.15. 2582 18. Added distinguishedNameMatch as the EQUALITY matching rule 2583 for the namingContexts attribute type ABNF in paragraph 5.13. 2585 RESCINDED IN -01 2587 19. Added integerMatch as the EQUALITY and integerOrderingMatch 2588 as the Ordering matching rules for the supportedLDAPVersion 2589 attribute type ABNF in paragraph 5.18. 2591 RESCINDED IN -01 2593 20. Added caseIgnoreMatch as the EQUALITY matching rule for the 2594 supportedSASLMechanisms attribute type ABNF in paragraph 5.19. 2595 Note that this could be caseExactMatch instead. SHOULD 2596 IT BE?? 2598 RESCINDED IN -01 2600 21. Made corrections to the ABNF in paragraph 3.12. 2602 22. Added the seven syntax definitions from RFC 2256 and ordered 2603 the definitions alphabetically. 2605 23. Changed the "Bibliography" section title to "References". 2607 24. Replaced the X.208 reference with one to X.680(1994), since 2608 X.680 is the ASN.1 referred to in the X.500(1993)-series. 2610 25. Moved the table listing the syntaxes and their oids from 2611 paragraph 2.2.3 to a new Annex A. 2613 REMOVED SYNTAXES NOT DEFINED IN THIS I-D FROM THE LIST - 02 2615 26. Moved the specification of the octetStringMatch matching rule 2616 from RFC 2256 to section 4 of this document. 2618 27. Throughout this I-D, cleaned up whitespace in the ABNF definitions. 2620 28. In Section 2.1: 2621 * Corrected the characters defined in the p rule to match 2622 the PrintableString syntax. 2623 * Deleted the letterstring rule. 2624 * Modified the utf8 and dstring rules according to a 2625 suggestion from K. Zeilenga. 2626 * Deleted ";" from the k rule, which affects the anhstring, 2627 keystring, and descr rules. 2628 * Removed the length option from the numericoid rule 2630 29. In section 2.2, deleted the sentence about needing a new OID 2631 when a syntax is modified. 2633 30. In section 2.2, replaced the editor's proposal and subject 2634 text with explanation of the native LDAP encoding of 2635 attribute values. 2637 31. Removed section 2.2.2 (and renumbered the remainder of 2638 section 2.2), leaving the description of binary encoding to 2639 the protocol I-D. 2641 ------- 2643 32. Revised specifications to use ABNF [ABNF] instead of BNF 2644 throughout the docment. 2646 33. Removed embedded comments from the ABNF productions 2647 throughout the document. 2649 34. Removed the Binary syntax because it was not adequately 2650 specified, implementations with different interpretations 2651 exist, and it was confused with the ;binary transfer encoding. 2653 35. Removed the syntaxes, which are not defined in this document, 2654 from the list in Annex A. Consult RFC 2252 for the 2655 assignments made previously for syntaxes that have not been 2656 defined to date. 2658 36. Inserted the specification of the octetstring production, from 2659 RFC 2234 [ABNF].j 2661 37. Cleaned up the references; adopted word instead of number 2662 tags; split Section 10 into normative and non-normative 2663 subsections. 2665 38. Inserted ABNF from RFC 1278 in place of a reference. 2667 38. Deleted the certificate-related syntaxes and noted in the 2668 Security Considerations (Section 7) that they are covered 2669 in PKIX WG documents.