idnits 2.17.1 draft-ietf-ldapbis-syntaxes-00.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 48) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 50 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 37 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. 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 (19 June 2001) is 8340 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) -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 822 (ref. '4') (Obsoleted by RFC 2822) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1778 (ref. '7') (Obsoleted by RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2044 (ref. '11') (Obsoleted by RFC 2279) -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' ** Obsolete normative reference: RFC 1327 (ref. '17') (Obsoleted by RFC 2156) -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. '18' ** Downref: Normative reference to an Informational RFC: RFC 1278 (ref. '19') Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 18 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 19 December 2001 19 June 2001 4 Obsoletes: RFC 2252 6 Lightweight Directory Access Protocol (v3): 7 Attribute Syntax Definitions 8 10 [Editor's note: 11 This Internet-Draft (I-D) is a modified version of the text of 12 RFC 2252, in order to bring it up to date. This action is part of 13 the maintenance activity that is needed in order to progress LDAPv3 14 to Draft Standard. The changes are described in Annex B of this 15 document. Open items are listed in Annex A. 16 End of Editor's note] 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC 2026. 23 This document is intended to be, after appropriate review and 24 revision, submitted to the RFC Editor as a Standard Track document. 25 Distribution of this memo is unlimited. Technical discussion of 26 this document will take place on the IETF LDAP Revision Working 27 Group (LDAPbis) mailing list . Please 28 send editorial comments directly to the author . 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as 33 Internet-Drafts. Internet-Drafts are draft documents valid for a 34 maximum of six months and may be updated, replaced, or obsoleted by 35 other documents at any time. It is inappropriate to use 36 Internet-Drafts as reference material or to cite them other than as 37 "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. The list of 41 Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Copyright 2000, The Internet Society. All Rights Reserved. 46 Please see the Copyright section near the end of this document for 47 more information. 49 Abstract 51 The Lightweight Directory Access Protocol (LDAP) [1] requires that 52 the contents of AttributeValue fields in protocol elements be octet 53 strings. This document defines a set of syntaxes for LDAPv3, and 54 the rules by which attribute values of these syntaxes are represented 55 in the LDAP protocol. The syntaxes defined in this document are 56 referenced by this and other documents that define attribute types. 57 In addition to defining the set of attribute syntaxes which LDAP 58 servers should support, this document defines other schema elements 59 (mandatory and optional) that are common to all LDAP servers. 61 Table of Contents 63 Status of Memo.........................................................1 65 Abstract...............................................................2 67 1. Overview...........................................................5 69 2. General Issues.....................................................6 70 2.1 Notation..........................................................6 71 2.2 Syntaxes..........................................................8 72 2.2.1 Syntaxes Implementation Status..................................9 73 2.2.2 Binary Transfer of Values.......................................9 74 2.2.3 Syntax Object Identifiers.......................................9 75 2.2.4 Syntax Description.............................................11 76 2.2.5 Example........................................................12 77 2.3 Matching Rules...................................................12 78 2.3.1 Matching Rules Implementation Status...........................12 79 2.3.2 Matching Rule Description......................................12 80 2.3.3 Matching Rule Usage Description................................13 81 2.3.4 Example........................................................13 82 2.4 Attribute Types..................................................14 83 2.4.1 Attributes Implementation Status...............................14 84 2.4.2 Attribute Description..........................................15 85 2.4.3 Example........................................................16 86 2.5 Object Classes...................................................16 87 2.5.1 Object Classes Implementation Status...........................16 88 2.5.2 Object Class Description.......................................16 89 2.5.3 Example........................................................17 91 3. Syntaxes..........................................................18 92 3.1 Attribute Type Description.......................................18 93 3.2 Binary...........................................................18 94 3.3 Bit String.......................................................18 95 3.4 Boolean..........................................................18 96 3.5 Certificate......................................................19 97 3.6 Certificate List.................................................19 98 3.7 Certificate Pair.................................................19 99 3.8 Country String...................................................20 100 3.9 Delivery Method..................................................20 101 3.10 Directory String.................................................20 102 3.11 DIT Content Rule.................................................21 103 3.12 DIT Structure Rule Description...................................22 104 3.13 DN...............................................................22 105 3.14 Enhanced Guide...................................................23 106 3.15 Facsimile Telephone Number.......................................23 107 3.16 Fax..............................................................24 108 3.17 Generalized Time.................................................24 109 3.18 Guide............................................................24 110 3.19 IA5 String.......................................................25 111 3.20 Integer..........................................................25 112 3.21 JPEG.............................................................25 113 3.22 LDAP Syntax Description..........................................25 114 3.23 Matching Rule Description........................................26 115 3.24 Matching Rule Use Description....................................26 116 3.25 MHS OR Address...................................................26 117 3.26 Name and Optional UID............................................26 118 3.27 Name Form Description............................................27 119 3.28 Numeric String...................................................27 120 3.29 Object Class Description.........................................28 121 3.30 Octet String.....................................................28 122 3.31 OID..............................................................28 123 3.32 Other Mailbox....................................................28 124 3.33 Postal Address...................................................29 125 3.34 Presentation Address.............................................29 126 3.35 Printable String.................................................30 127 3.36 Substring Assertion Syntax.......................................30 128 3.37 Supported Algorithm..............................................30 129 3.38 Telephone Number.................................................31 130 3.39 Teletex Terminal Identifier......................................31 131 3.40 Telex Number.....................................................31 132 3.41 UTC Time.........................................................32 134 4. Matching Rules....................................................33 135 4.1 bitStringMatch...................................................33 136 4.2 caseExactIA5Match................................................33 137 4.3 caseIgnoreIA5Match...............................................33 138 4.4 caseIgnoreListMatch..............................................33 139 4.5 caseIgnoreMatch..................................................34 140 4.6 caseIgnoreOrderingMatch..........................................34 141 4.7 caseIgnoreSubstringsMatch........................................34 142 4.8 distinguishedNameMatch...........................................34 143 4.9 generalizedTimeMatch.............................................34 144 4.10 generalizedTimeOrderingMatch.....................................35 145 4.11 integerFirstComponentMatch.......................................35 146 4.12 integerMatch.....................................................35 147 4.13 numericStringMatch...............................................35 148 4.14 numericStringSubstringsMatch.....................................35 149 4.15 objectIdentifierFirstComponentMatch..............................36 150 4.16 objectIdentifierMatch............................................36 151 4.17 presentationAddressMatch.........................................36 152 4.18 protocolInformationMatch.........................................36 153 4.19 telephoneNumberMatch.............................................37 154 4.20 telephoneNumberSubstringsMatch...................................37 155 4.21 uniqueMemberMatch................................................37 157 5. Attribute Types...................................................38 158 5.1 altServer........................................................38 159 5.2 attributeTypes...................................................38 160 5.3 createTimestamp..................................................38 161 5.4 creatorsName.....................................................38 162 5.5 dITContentRules..................................................38 163 5.6 dITStructureRules................................................39 164 5.7 ldapSyntaxes.....................................................39 165 5.8 matchingRules....................................................39 166 5.9 matchingRuleUse..................................................39 167 5.10 modifiersName....................................................40 168 5.11 modifyTimestamp..................................................40 169 5.12 nameForms........................................................40 170 5.13 namingContexts...................................................40 171 5.14 objectClasses....................................................40 172 5.15 subschemaSubentry................................................41 173 5.16 supportedControl.................................................41 174 5.17 supportedExtension...............................................41 175 5.18 supportedLDAPVersion.............................................41 176 5.19 supportedSASLMechanisms..........................................42 178 6. Object Classes....................................................43 179 6.1 Extensible Object Class..........................................43 180 6.2 subschema........................................................43 182 7. Security Considerations...........................................44 183 7.1 Disclosure.......................................................44 184 7.2 Use of Attribute Values in Security Applications.................44 185 7.3 Securing the Directory...........................................44 187 8. Acknowledgements..................................................44 189 9. Author's Address..................................................45 191 10. References........................................................45 193 11. Full Copyright Statement..........................................47 195 Annex A Topics to be Addressed in This Document......................48 197 Annex B Change Log...................................................49 198 1. Overview 200 This document defines the framework for developing schemas for 201 directories accessible via the Lightweight Directory Access Protocol. 203 Schema is the collection of attribute type definitions, object class 204 definitions and other information which specify the entries and their 205 contents that a server holds. A server uses schema to determine how 206 to match a filter or attribute value assertion (in a compare 207 operation) against the attributes of an entry, and whether to permit 208 add and modify operations. 210 Section 2 states the general requirements and notations for 211 definition of attribute types, object classes, syntaxes and 212 matching rules. 214 Section 3 lists syntaxes, section 4 matching rules, section 5 215 attribute types, and section 6 object classes. 217 Additional documents define schemas for representing real-world 218 objects as directory entries. 220 2. General Issues 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in RFC 2119 [2]. 226 This document describes the syntaxes of data conveyed in an 227 Internet protocol. 229 Attribute Type and Object Class definitions are written in a string 230 representation of the AttributeTypeDescription and 231 ObjectClassDescription data types defined in X.501(93) [3]. 232 Implementors are strongly advised to first read the description of 233 how schema is represented in X.500 before reading the rest of this 234 document. 236 2.1 Notation 238 For the purposes of defining the rules for describing attribute 239 syntaxes and other schema elements, the following Backus-Naur Form 240 (BNF) definitions will be used. They are based on the BNF styles 241 of RFC 822 [4]. 243 a = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / 244 "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / 245 "u" / "v" / "w" / "x" / "y" / "z" / "A" / "B" / "C" / "D" / 246 "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / 247 "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / 248 "Y" / "Z" 250 d = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" 252 hex-digit = d / "a" / "b" / "c" / "d" / "e" / "f" / 253 "A" / "B" / "C" / "D" / "E" / "F" 255 k = a / d / "-" / ";" 257 p = a / d / """ / "(" / ")" / "+" / "," / "-" / "." / 258 "/" / ":" / "?" / " " 260 letterstring = 1*a 262 numericstring = 1*d 264 anhstring = 1*k 266 keystring = a [ anhstring ] 268 printablestring = 1*p 270 space = 1*" " 271 whsp = [ space ] 273 utf8 = 276 dstring = 1*utf8 278 qdstring = whsp "'" dstring "'" whsp 280 qdstringlist = [ qdstring *( qdstring ) ] 282 qdstrings = qdstring / ( whsp "(" qdstringlist ")" whsp ) 284 In the following BNF for the string representation of OBJECT 285 IDENTIFIERs, descr is the syntactic representation of an object 286 descriptor, which consists of letters and digits, starting with a 287 letter. An OBJECT IDENTIFIER in the numericoid format should not 288 have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should 289 not be generated). 291 When 'oid' elements occur in a value, the descr notation option 292 SHOULD be used in preference to the numericoid. An object descriptor 293 is more readable than a numeric OBJECT IDENTIFIER, and a descriptor 294 (where assigned and known by the implementation) SHOULD be used in 295 preference to numeric oids to the greatest extent possible. Examples 296 of object descriptors in LDAP are attribute type, object class and 297 matching rule names. 299 oid = descr / numericoid 301 descr = keystring 303 numericoid = numericstring *( "." numericstring ) [ "{" len "}" ] 305 len = numericstring 307 woid = whsp oid whsp 309 oids = woid / ( "(" oidlist ")" ) ; set of oids of either form 311 oidlist = woid *( "$" woid ) 313 qdescrs = qdescr / ( whsp "(" qdescrlist ")" whsp ) ; object 314 ; descriptors used as schema element names 316 qdescrlist = [ qdescr *( qdescr ) ] 318 qdescr = whsp "'" descr "'" whsp 320 Note that while lines have been folded for readability in the 321 definitions of schema elements (e.g., objectClassDescription 322 attribute), the values transferred in protocol would not contain 323 newlines. 325 In cases where an arbitrary string, not a Distinguished Name or part 326 of one, is used in a value of an attribute, a backslash quoting 327 mechanism is used to escape the following separator symbol character 328 (such as "'", "$" or "#") if it should occur in that string. The 329 backslash is followed by a pair of hexadecimal digits representing 330 the next character. A backslash itself in the string which forms 331 part of a larger syntax is always represented as '\5C' or '\5c'. An 332 example is given in section ?? postalAddress attribute. 334 Servers are not required to provide the same or any text in the 335 description part of the subschema values they maintain. 337 2.2 Syntaxes 339 This section defines general requirements for LDAPv3 attribute value 340 syntaxes. All documents defining attribute syntaxes for use with 341 LDAP are expected to conform to these requirements. 343 Syntaxes are also defined for matching rules whose assertion value 344 syntax is different from the attribute value syntax. 346 The syntaxes specified in this document are defined in section 3. 348 In an LDAP schema, an Object Identifier (OID) is assigned to a 349 syntax definition when the syntax is named. The syntaxes defined 350 for LDAP, are listed in paragraph 2.2.3. A syntax definition should 351 not be changed without having a new OID assigned to it. 353 In X.501 [3] and X.520 [9], the definition of the syntax is part of 354 the attribute specification and a distinct OID for the syntax is not 355 assigned. As a result, X.501 does not define an attribute for 356 publishing syntaxes explicitly in a subschema entry. 358 [Editor's proposal: 359 The following paragraph should be moved to the draft-ietf-ldapbis- 360 protocol-xx I-D, because it specifies encoding principles. 361 End of Editor's proposal] 362 The encoding rules defined for a given attribute syntax must produce 363 octet strings. To the greatest extent possible, encoded octet 364 strings should be usable in their native encoded form for display 365 purposes. In particular, encoding rules for attribute syntaxes 366 defining non-binary values should produce strings that can be 367 displayed with little or no translation by clients implementing LDAP. 368 There are a few cases (e.g. audio) however, when it is not sensible 369 to produce a printable representation. 371 2.2.1 Syntaxes Implementation Status 373 The syntaxes that have been identified for LDAP are listed in 374 section 2.2.3. The specifications of the syntaxes that are further 375 defined this document are given in section 3. 377 Clients and servers need not implement all the syntaxes listed, and 378 MAY implement other syntaxes. 380 [Editor's Note: The following statement is a new MUST statement 381 that seems to be logical. End of Editor's Note] Servers MUST 382 implement the syntaxes specified for the attribute types that are 383 implemented. 385 Clients MUST NOT assume that an unrecognized syntax is a string 386 representation. 388 2.2.2 Binary Transfer of Values 390 The binary encoding format specified in draft-ietf-ldapbis- 391 protocol-xx [1] is used,for returning an attribute value, if binary 392 format is requested by the client or if the attribute syntax is 393 "binary", i.e., "1.3.6.1.4.1.1466.115.121.1.5". [EDITOR'S NOTE: 394 The remainder of this paragraph plus the next paragraph should be 395 moved to the draft-ietf-ldapbis-protocol-xx I-D. END.] The contents 396 of the LDAP AttributeValue or AssertionValue field is a BER-encoded 397 instance of the attribute value or a matching rule assertion value 398 ASN.1 data type as defined for use with X.500. (The first byte 399 inside the OCTET STRING wrapper is a tag octet. However, the OCTET 400 STRING is still encoded in primitive form.) 402 All servers MUST implement this form for both generating attribute 403 values in search responses, and parsing attribute values in add, 404 compare, and modify requests, if the attribute type is recognized 405 and the attribute syntax name is that of Binary. Clients which 406 request that all attributes be returned from entries MUST be prepared 407 to receive values in binary (e.g. userCertificate;binary), and SHOULD 408 NOT simply display binary or unrecognized values to users. 410 2.2.3 Syntax Object Identifiers 412 Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which 413 are dotted-decimal strings. These are not intended to be displayed 414 to users. 416 The following table lists the syntaxes that have been defined for 417 LDAP, thus far. The H-R column suggests whether a value of that 418 syntax is likely to be a human readable string. 420 Other documents may define additional syntaxes. However, the 421 definition of additional arbitrary syntaxes is strongly deprecated 422 since it will hinder interoperability. Today's client and server 423 implementations generally do not have the ability to dynamically 424 recognize new syntaxes. In most cases, attributes will be defined 425 with the syntax for directory strings. 427 Value being represented H-R OBJECT IDENTIFIER 428 ===================================================================== 429 ACI Item N 1.3.6.1.4.1.1466.115.121.1.1 430 Access Point Y 1.3.6.1.4.1.1466.115.121.1.2 431 Attribute Type Description Y 1.3.6.1.4.1.1466.115.121.1.3 432 Audio N 1.3.6.1.4.1.1466.115.121.1.4 433 Binary N 1.3.6.1.4.1.1466.115.121.1.5 434 Bit String Y 1.3.6.1.4.1.1466.115.121.1.6 435 Boolean Y 1.3.6.1.4.1.1466.115.121.1.7 436 Certificate N 1.3.6.1.4.1.1466.115.121.1.8 437 Certificate List N 1.3.6.1.4.1.1466.115.121.1.9 438 Certificate Pair N 1.3.6.1.4.1.1466.115.121.1.10 439 Country String Y 1.3.6.1.4.1.1466.115.121.1.11 440 DN Y 1.3.6.1.4.1.1466.115.121.1.12 441 Data Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.13 442 Delivery Method Y 1.3.6.1.4.1.1466.115.121.1.14 443 Directory String Y 1.3.6.1.4.1.1466.115.121.1.15 444 DIT Content Rule Description Y 1.3.6.1.4.1.1466.115.121.1.16 445 DIT Structure Rule Description Y 1.3.6.1.4.1.1466.115.121.1.17 446 DL Submit Permission Y 1.3.6.1.4.1.1466.115.121.1.18 447 DSA Quality Syntax Y 1.3.6.1.4.1.1466.115.121.1.19 448 DSE Type Y 1.3.6.1.4.1.1466.115.121.1.20 449 Enhanced Guide Y 1.3.6.1.4.1.1466.115.121.1.21 450 Facsimile Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.22 451 Fax N 1.3.6.1.4.1.1466.115.121.1.23 452 Generalized Time Y 1.3.6.1.4.1.1466.115.121.1.24 453 Guide Y 1.3.6.1.4.1.1466.115.121.1.25 454 IA5 String Y 1.3.6.1.4.1.1466.115.121.1.26 455 INTEGER Y 1.3.6.1.4.1.1466.115.121.1.27 456 JPEG N 1.3.6.1.4.1.1466.115.121.1.28 457 LDAP Syntax Description Y 1.3.6.1.4.1.1466.115.121.1.54 458 LDAP Schema Definition Y 1.3.6.1.4.1.1466.115.121.1.56 459 LDAP Schema Description Y 1.3.6.1.4.1.1466.115.121.1.57 460 Master And Shadow Access Points Y 1.3.6.1.4.1.1466.115.121.1.29 461 Matching Rule Description Y 1.3.6.1.4.1.1466.115.121.1.30 462 Matching Rule Use Description Y 1.3.6.1.4.1.1466.115.121.1.31 463 Mail Preference Y 1.3.6.1.4.1.1466.115.121.1.32 464 MHS OR Address Y 1.3.6.1.4.1.1466.115.121.1.33 465 Modify Rights Y 1.3.6.1.4.1.1466.115.121.1.55 466 Name And Optional UID Y 1.3.6.1.4.1.1466.115.121.1.34 467 Name Form Description Y 1.3.6.1.4.1.1466.115.121.1.35 468 Numeric String Y 1.3.6.1.4.1.1466.115.121.1.36 469 Object Class Description Y 1.3.6.1.4.1.1466.115.121.1.37 470 Octet String Y 1.3.6.1.4.1.1466.115.121.1.40 471 OID Y 1.3.6.1.4.1.1466.115.121.1.38 472 Other Mailbox Y 1.3.6.1.4.1.1466.115.121.1.39 473 Postal Address Y 1.3.6.1.4.1.1466.115.121.1.41 474 Value being represented H-R OBJECT IDENTIFIER 475 ===================================================================== 476 Protocol Information Y 1.3.6.1.4.1.1466.115.121.1.42 477 Presentation Address Y 1.3.6.1.4.1.1466.115.121.1.43 478 Printable String Y 1.3.6.1.4.1.1466.115.121.1.44 479 Substring Assertion Y 1.3.6.1.4.1.1466.115.121.1.58 480 Subtree Specification Y 1.3.6.1.4.1.1466.115.121.1.45 481 Supplier Information Y 1.3.6.1.4.1.1466.115.121.1.46 482 Supplier Or Consumer Y 1.3.6.1.4.1.1466.115.121.1.47 483 Supplier And Consumer Y 1.3.6.1.4.1.1466.115.121.1.48 484 Supported Algorithm N 1.3.6.1.4.1.1466.115.121.1.49 485 Telephone Number Y 1.3.6.1.4.1.1466.115.121.1.50 486 Teletex Terminal Identifier Y 1.3.6.1.4.1.1466.115.121.1.51 487 Telex Number Y 1.3.6.1.4.1.1466.115.121.1.52 488 UTC Time Y 1.3.6.1.4.1.1466.115.121.1.53 490 A suggested minimum upper bound on the number of characters in a 491 value with a string-based syntax, or the number of bytes in a value 492 for all other syntaxes, may be indicated by appending this bound 493 count inside of curly braces following the syntax name's OBJECT 494 IDENTIFIER in an attribute type definition. See the "numericoid" 495 production in paragraph 2.1. Such a bound is not part of the syntax 496 name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests that 497 server implementations should allow a string to be 64 characters 498 long, although they may allow longer strings. Note that a single 499 character of the Directory String syntax may be encoded in more than 500 one byte since UTF-8 is a variable-length encoding. 502 2.2.4 Syntax Description 504 The following BNF is used in this document to associate a short 505 description (e.g., a name) with a syntax OBJECT IDENTIFIER. The 506 productions for whsp, numericoid, qdescrs and qdstring are given in 507 paragraph 2.1. Implementors should note that future versions of this 508 document may expand this definition to include additional terms. 509 Terms whose identifier begins with "X-" are reserved for private 510 experiments, and MUST be followed by a token. 512 SyntaxDescription = "(" whsp 513 numericoid whsp 514 ["NAME" qdescrs ] 515 [ "DESC" qdstring ] 516 whsp ")" 518 Note that the SyntaxDescription BNF is also the BNF that defines the 519 LDAP Syntax Description syntax. 521 2.2.5 Example 523 For example, the INTEGER syntax for whole number values could be 524 written as: 526 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 528 2.3 Matching Rules 530 The matching rules specified in this document are defined in 531 section 4. 533 Matching rules are used by servers to compare attribute values 534 against assertion values when performing Search and Compare 535 operations. They are also used to identify the value to be added or 536 deleted when modifying entries, and are used when comparing a 537 purported distinguished name with the name of an entry. 539 Most of the attributes given in this document have an equality 540 matching rule defined. 542 ...An OID is assigned to a matching rule when it is defined. A 543 matching rule definition should not be changed without having a new 544 OID assigned to it. 546 2.3.1 Matching Rules Implementation Status 548 Servers which support matching rules and the extensibleMatch SHOULD 549 implement all the matching rules in section 4. 551 Servers MAY implement additional matching rules not listed in this 552 document, and if they do so, MUST publish the definitions of the 553 matching rules in the matchingRules attribute of their subschema 554 entries. If the server supports the extensibleMatch, then the 555 server MUST publish the relationship between the matching rules and 556 attributes using the matchingRuleUse attribute. 558 Clients MUST NOT assume that servers are capable of transliteration 559 of Unicode values. 561 2.3.2 Matching Rule Description 563 Matching rule descriptions are written according to the following 564 BNF. The productions for numericoid, qdescrs, qdstring, oid, and 565 whsp are given in paragraph 2.1. Implementors should note that 566 future versions of this document may expand this BNF to include 567 additional terms. Terms whose identifier begins with "X-" are 568 reserved for private experiments, and MUST be followed by a 569 token. 571 MatchingRuleDescription = "(" whsp 572 numericoid whsp ; MatchingRule identifier 573 [ "NAME" qdescrs ] 574 [ "DESC" qdstring ] 575 [ "OBSOLETE" whsp ] 576 "SYNTAX" oid 577 whsp ")" 579 Note that the MatchingRuleDescription BNF is also the BNF that 580 defines the Matching Rule Description syntax. 582 2.3.3 Matching Rule Use Description 584 Matching Rule Use Descriptions list the attributes which are 585 suitable for use in an extensibleMatch that employs the associated 586 matching rule. See paragraph xxx of [1]. The following BNF is used 587 when writing Matching Rule Use Descriptions: 589 MatchingRuleUseDescription = "(" whsp 590 numericoid whsp ; MatchingRule identifier 591 [ "NAME" qdescrs ] 592 [ "DESC" qdstring ] 593 [ "OBSOLETE" ] 594 "APPLIES" oids ; AttributeType identifiers 595 whsp ")" 597 The productions for whsp, numericoid, qdescrs, qdstring, and oids 598 are given in paragraph 2.1. Implementors should note that future 599 versions of this document may expand this BNF to include additional 600 terms. Terms whose identifier begins with "X-" are reserved for 601 private experiments, and MUST be followed by a token. 603 Note that the MatchingRuleUseDescription BNF is also the BNF that 604 defines the Matching Rule Use Description syntax. 606 2.3.4 Example 608 For example, in specifying a server which implements a privately- 609 defined matching rule for performing sound-alike matches on 610 Directory String-valued attributes, the matching rule could be 611 written as (1.2.3.4.5 is an example, the OID of an actual matching 612 rule would be different): 614 matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch' 615 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 617 This description could be the one included in the subschema entry in 618 the server. If this matching rule could be used with the attributes 619 2.5.4.41 and 2.5.4.15, the following could be the use description 620 present in the subschema entry: 622 matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) ) 624 A client could then make use of this matching rule by sending a 625 search operation in which the filter is of the extensibleMatch 626 choice, the matchingRule field is "soundAlikeMatch", and the type 627 field is "2.5.4.41" or "2.5.4.15". 629 2.4 Attribute Types 631 Attributes represent the characteristics of the real-world object 632 which an entry represents. The attributes defined in this document 633 are given in section 5. 635 An OID is assigned to an attribute when the attribute is defined. 636 An attribute definition should not be changed without having a new 637 OID assigned to it. 639 2.4.1 Attributes Implementation Status 641 Servers MUST implement all the attribute types referenced in 642 section 5. 644 Servers MAY recognize additional attribute types not listed in this 645 document, and if they do so, MUST publish the definitions of the 646 types in the attributeTypes attribute of their subschema entries. 648 Schema developers MUST NOT create attribute definitions whose names 649 conflict with attributes defined for use with LDAP in existing 650 standards-track RFCs. 652 All LDAP server implementations MUST recognize the attribute types 653 defined in section 5. 655 Servers MUST maintain values of these attributes in accordance with 656 the definitions in X.501(93): createTimestamp, modifyTimestamp, 657 creatorsName, modifiersName, subschemaSubentry, attributeTypes, 658 objectClasses, matchingRules, and matchingRuleUse. 660 The createTimestamp and creatorsName attributes SHOULD appear 661 in entries which were created using the Add operation. 663 The modifyTimestamp and modifiersName attributes SHOULD appear in 664 entries which have been modified using LDAP update operations. 666 The subschemaSubentry attribute SHOULD appear in all entries. 668 Servers MUST recognize these attribute names, but it is not required 669 that a server provide values for these attributes, when the attribute 670 corresponds to a feature which the server does not implement: 671 namingContexts, altServer, supportedExtension, supportedControl, 672 supportedSASLMechanisms, supportedLDAPVersion, 674 Servers MAY use the ldapSyntaxes attribute to list the syntaxes 675 which are implemented. 677 All servers SHOULD recognize these attribute names, although 678 typically only X.500 servers will implement their functionality: 679 dITStructureRules, nameForms, and ditContentRules. 681 For the status of user schema attribute types see section 5 of [12]. 683 2.4.2 Attribute Description 685 Attribute types are expressed according to the following BNF. 686 The productions for whsp, numericoid, qdescrs, qdstring, woid, and 687 noidlen are given in paragraph 2.1. Implementors should note that 688 future versions of this document may expand this BNF to include 689 additional terms. Terms which begin with the characters "X-" are 690 reserved for private experiments, and MUST be followed by a 691 token. 693 AttributeTypeDescription = "(" whsp 694 numericoid whsp ; AttributeType identifier 695 [ "NAME" qdescrs ] ; name used in AttributeType 696 [ "DESC" qdstring ] ; description 697 [ "OBSOLETE" whsp ] 698 [ "SUP" woid ] ; derived from this other 699 ; AttributeType 700 [ "EQUALITY" woid ] ; Matching Rule name 701 [ "ORDERING" woid ] ; Matching Rule name 702 [ "SUBSTR" woid ] ; Matching Rule name 703 [ "SYNTAX" whsp noidlen whsp ] ; see section 2.3 704 [ "SINGLE-VALUE" whsp ] ; default multi-valued 705 [ "COLLECTIVE" whsp ] ; default not collective 706 [ "NO-USER-MODIFICATION" whsp ] ; default user modifiable 707 [ "USAGE" whsp AttributeUsage ] ; default userApplications 708 whsp ")" 710 Servers SHOULD provide at least one of the "SUP" and "SYNTAX" fields 711 for each AttributeTypeDescription. 713 An AttributeDescription (i.e., the means of referring to an attribute 714 in the protocol [1]) can be used as the value in a NAME part of 715 an AttributeTypeDescription. Note that these are case insensitive. 716 [Editor's Note: The preceding paragraph seems to be circular in 717 nature, especially when looking at the AttributeType explanation in 718 [1]. What is the fix? End of Editor's Note] 720 Note that the AttributeTypeDescription does not list the matching 721 rules which can be used with that attribute type in an 722 extensibleMatch search filter. This is done using the 723 matchingRuleUseDescription described in paragraph 2.3.3. 725 This document refines the schema description of X.501 [3] by 726 requiring that the syntax field in an AttributeTypeDescription be a 727 string representation of an OBJECT IDENTIFIER for the LDAP string 728 syntax definition, and an optional indication of the maximum length 729 of a value of this attribute (defined in section 2.2.3). 731 Note that the AttributeTypeDescription BNF is also the BNF that 732 defines the Attribute Type Description syntax. 734 2.4.3 Example 736 For example, it would be useful for the directory to know when an 737 entry was put into the directory. The following definition is an 738 Attribute Type Description that could be used to specify such 739 an attribute. 741 ( 2.5.18.1 NAME 'createTimestamp' 742 EQUALITY generalizedTimeMatch 743 ORDERING generalizedTimeOrderingMatch 744 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ; Generalized Time 745 SINGLE-VALUE 746 NO-USER-MODIFICATION 747 USAGE directoryOperation ) 749 2.5 Object Classes 751 Object classes are the components of an entry. In general, every 752 entry is defined in terms of an abstract class ("top"), at least one 753 structural object class, and zero or more auxiliary object classes. 754 Whether an object class is abstract, structural, or auxiliary is 755 defined when the object class OID is assigned. An object class 756 definition should not be changed without having a new identifier 757 assigned to it. 759 2.5.1 Object Classes Implementation Status 761 Servers SHOULD implement the subschema object class. 763 Implementing the extensibleObject object class is optional. 765 Servers MAY implement additional object classes not listed in this 766 document, and if they do so, MUST publish the definitions of the 767 classes in the objectClasses attribute of their subschema entries. 769 Schema developers MUST NOT create object class definitions whose 770 names conflict with object classes defined for use with LDAP in 771 existing standards-track RFCs. 773 2.5.2 Object Class Description 775 Object class descriptions are written according to the following BNF. 776 The productions for whsp, numericoid, qdescrs, qdstring, and oids 777 are given in paragraph 2.1. Implementors should note that future 778 versions of this document may expand this definition to include 779 additional terms. Terms whose identifier begins with "X-" are 780 reserved for private experiments, and MUST be followed by a 781 token. 783 ObjectClassDescription = "(" whsp 784 numericoid whsp ; ObjectClass identifier 785 [ "NAME" qdescrs ] 786 [ "DESC" qdstring ] 787 [ "OBSOLETE" whsp ] 788 [ "SUP" oids ] ; Superior ObjectClasses 789 [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] 790 ; default structural 791 [ "MUST" oids ] ; AttributeTypes 792 [ "MAY" oids ] ; AttributeTypes 793 whsp ")" 795 2.5.3 Example 797 For example, information about an employee with respect to their 798 job is useful in an application which queries the directory. The 799 same pieces of information are needed in several kinds of entries, 800 such as manager, part-time, and exempt employees. An auxiliary 801 object class could be developed to be included in the structural 802 object classes that represent the different kinds of employees. The 803 pieces of information could be: name of the last training course 804 attended, how many courses has the employee taken, category of 805 training program. The types of information could be named the 806 lastCourse, coursesCount, program attributes, respectively. The 807 following could be the description of an auxiliary object class that 808 provides for inclusion of the training information in different 809 kinds of entries. (The OID is artificial.) 811 ( 1.3.170.2.65 NAME 'trainingInfo' 812 AUXILIARY 813 MUST program 814 MAY ( lastCourse $ coursesCount ) ) 816 3. Syntaxes 818 3.1 Attribute Type Description 820 A value in this syntax is a character string which expresses the 821 definition of an attribute type according to the BNF given in 822 paragraph 2.4.2. This syntax is the form in which schema attribute 823 types are published in the directory. The following string states 824 the OID assigned to this syntax: 826 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 828 For example, this character string specifies the objectClass 829 attribute, whose values are OIDs: 831 ( 2.5.4.0 NAME 'objectClass' 832 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 834 3.2 Binary 836 A value in this syntax is a series of 0's and 1's. The length of 837 the series is octet-aligned (i.e., evenly divisible by eight). The 838 series is expressed as described in paragraph 2.2.2. The following 839 string states the OID assigned to this syntax: 841 ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' ) 843 The interpretation of a value is part of the definition of the 844 attribute which contains the value. 846 3.3 Bit String 848 A value in this syntax is a value of the BIT STRING data type from 849 ASN.1 [5]. The following string states the OID assigned to 850 this syntax: 852 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 854 Values in this syntax are expressed according to the following BNF: 856 bitstring = "'" *binary-digit "'B" 858 binary-digit = "0" / "1" 860 Example: '0101111101'B 862 3.4 Boolean 864 A value in this syntax is a value of the BOOLEAN data type from 865 ASN.1 [5]. That is, there are exactly two values: one value 866 representing logically true, and the other representing logically 867 false. The following string states the OID assigned to this syntax: 869 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 871 Values in this syntax are expressed according to the following BNF: 873 boolean = "TRUE" / "FALSE" 875 3.5 Certificate 877 A value in this syntax is the binary string that results from 878 BER/DER-encoding an X.509 [6] public key certificate. The following 879 string states the OID assigned to this syntax: 881 ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' ) 883 Due to the changes from X.509(1988) to X.509(1993) and subsequent 884 changes to the ASN.1 definition to support certificate extensions, 885 no string representation is defined, and values in this syntax MUST 886 only be transferred using the binary encoding, by requesting or 887 returning the attributes with descriptions "userCertificate;binary" 888 or "caCertificate;binary". The BNF notation in RFC 1778 [7] for 889 "User Certificate" is not recommended to be used. 891 3.6 Certificate List 893 A value in this syntax is the binary string that results from 894 BER/DER-encoding an X.509 certificate revocation list. The 895 following string states the OID assigned to this syntax: 897 ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' ) 899 Due to the incompatibility of the X.509(1988) and X.509(1993) [6] 900 definitions of revocation lists, values in this syntax MUST only be 901 transferred using a binary encoding, by requesting or returning the 902 attributes with descriptions "certificateRevocationList;binary" or 903 "authorityRevocationList;binary". The BNF notation in RFC 1778 [7] 904 for "Authority Revocation List" is not recommended to be used. 906 3.7 Certificate Pair 908 A value in this syntax is the binary string that results from 909 BER/DER-encoding an X.509 [6] public key certificate pair. The 910 following string states the OID assigned to this syntax: 912 ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' ) 914 Due to the Certificate Pair being carried in binary, values in 915 this syntax MUST only be transferred using a binary encoding, by 916 requesting or returning the attribute description 917 "crossCertificatePair;binary". The BNF notation in RFC 1778 [7] for 918 "Certificate Pair" is not recommended to be used. 920 3.8 Country String 922 A value in this syntax is two printable string characters 923 representing a country. The permitted values are as listed in 924 ISO 3166 [8]. The following string states the OID assigned to this 925 syntax: 927 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 929 A value in this syntax is expressed according to the following BNF: 931 CountryString = p p 933 The production for p is given in paragraph 2.1. 935 Example: US 937 3.9 Delivery Method 939 A value in the Delivery Method syntax is a character string that 940 indicates, in preference order, the service(s) by which the user, 941 represented by the entry, is willing and/or capable of receiving 942 messages. The following string states the OID assigned to this 943 syntax: 945 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 947 A value in this syntax is expressed according to the following BNF: 949 delivery-value = pdm / ( pdm whsp "$" whsp delivery-value ) 951 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 952 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 954 The production for whsp is given in paragraph 2.1. 956 Example: telephone 958 3.10 Directory String 960 A value in Directory String syntax is a string of Unicode 961 characters. See [ ??? ]. The following string states the OID 962 assigned to this syntax: 964 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 966 In X.520 [9], a directory string is defined to be in one of 967 these forms: PrintableString, TeletexString, UniversalString, or 968 BMPString. (All of the forms are data types from ASN.1 [5].) 970 [Editor's note: What should the BNF be for this syntax? End of 971 Editor's note]. 973 Note: The form of DirectoryString is not indicated in protocol 974 unless the attribute value is carried in binary. Servers 975 which convert to DAP MUST choose an appropriate form. Servers 976 MUST NOT reject values merely because they contain legal 977 Unicode characters outside of the range of printable ASCII. 979 Servers and clients MUST be prepared to receive arbitrary Unicode 980 characters, including characters not presently assigned to 981 any character set. 983 Example: This is a string of DirectoryString containing #!%#@. 985 [Editor's note: the following three paragraphs should be moved 986 to [1] (paragraph ???). End of Editor's note] 988 For characters in the PrintableString form, the value is encoded as 989 the string value itself. 991 If it is of the TeletexString form, then the characters are 992 transliterated to their equivalents in UniversalString, and encoded 993 in UTF-8 [11]. 995 If it is of the UniversalString or BMPString forms [10], UTF-8 is 996 used to encode them. 998 3.11 DIT Content Rule Description 1000 A value in the DIT Content Rule Description syntax is a string that 1001 expresses the definition of a schema Content Rule. This syntax is 1002 the form in which schema content rules are published in the 1003 directory. The following string states the OID assigned to this 1004 syntax: 1006 ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule 1007 Description' ) 1009 Values in this syntax are written according to the following BNF. 1010 The productions for whsp, numericoid, qdescrs, qdstring, and oids 1011 are given in paragraph 2.1. Implementors should note that future 1012 versions of this document may expand this BNF to include additional 1013 terms. 1015 DITContentRuleDescription = "(" 1016 numericoid ; Structural ObjectClass identifier 1017 [ "NAME" qdescrs ] 1018 [ "DESC" qdstring ] 1019 [ "OBSOLETE" ] 1020 [ "AUX" oids ] ; Auxiliary ObjectClasses 1021 [ "MUST" oids ] ; AttributeType identifiers 1022 [ "MAY" oids ] ; AttributeType identifiers 1023 [ "NOT" oids ] ; AttributeType identifiers 1024 ")" 1026 3.12 DIT Structure Rule Description 1028 A value in the DIT Structure Rule Description syntax is a string that 1029 expresses the definition of a schema Structure Rule. This syntax is 1030 the form in which schema structure rules are published in the 1031 directory. The following string states the OID assigned to this 1032 syntax: 1034 ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule 1035 Description' ) 1037 Values with this syntax are written according to the following BNF: 1039 DITStructureRuleDescription = "(" whsp 1040 ruleidentifier whsp ; DITStructureRule identifier 1041 [ "NAME" qdescrs ] 1042 [ "DESC" qdstring ] 1043 [ "OBSOLETE" whsp ] 1044 "FORM" woid whsp ; NameForm 1045 [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules 1046 ")" 1048 ruleidentifier = numericstring 1050 ruleidentifiers = ruleidentifier | "(" whsp ruleidentifierlist 1051 whsp ")" 1053 ruleidentifierlist = [ ruleidentifier *( whsp "$" whsp 1054 ruleidentifier ) ] 1056 The productions for whsp, numericstring, qdescrs, qdstring, and woid 1057 are given in paragraph 2.1. 1059 3.13 DN 1061 A value in the Distinguished Name syntax is the sequence of 1062 name values that traverse the DIT to the named entry. The following 1063 string states the OID assigned to this syntax: 1065 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 1067 Values in the Distinguished Name syntax are expressed by the 1068 representation defined in [12]. Note that this representation is not 1069 reversible to an ASN.1 encoding used in X.500 for Distinguished 1070 Names, as the CHOICE of any DirectoryString element in an RDN is no 1071 longer known. 1073 Examples (from [12]): 1075 CN=Steve Kille,O=Isode Limited,C=GB 1077 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 1078 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 1080 CN=Before\0DAfter,O=Test,C=GB 1082 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 1084 SN=Lu\C4\8Di\C4\87 1086 3.14 Enhanced Guide 1088 A value in the Enhanced Guide syntax gives the matching criteria and 1089 scope of operation in an Enhanced Filter. The following string 1090 states the OID assigned to this syntax: 1092 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 1094 Values in this syntax are expressed according to the following BNF: 1096 EnhancedGuide = woid whsp "#" whsp criteria whsp "#" whsp subset 1098 subset = "baseobject" / "oneLevel" / "wholeSubtree" 1100 criteria = criteria-item / criteria-set / ( "!" criteria ) 1102 criteria-set = ( [ "(" ] criteria "&" criteria-set [ ")" ] ) / 1103 ( [ "(" ] criteria "|" criteria-set [ ")" ] ) 1105 criteria-item = [ "(" ] attributetype "$" match-type [ ")" ] 1107 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 1109 This syntax has been added subsequent to RFC 1778 [7]. 1111 Example: 1113 person#(sn)#oneLevel 1115 3.15 Facsimile Telephone Number 1117 A value in the Facsimile Telephone Number syntax is a subscriber 1118 number on the (public) telephone network of a facsimile device. The 1119 following string states the OID assigned to this syntax: 1121 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) 1123 Values in this syntax are expressed according to the following BNF: 1125 fax-number = printablestring [ "$" faxparameters ] 1127 faxparameters = faxparm / ( faxparm "$" faxparameters ) 1128 faxparm = "twoDimensional" / "fineResolution" / "unlimitedLength" 1129 / "b4Length" / "a3Width" / "b4Width" / "uncompressed" 1131 The production for printablestring is given in paragraph 2.1. In 1132 the above, the first printablestring is the telephone number, based 1133 on E.123 [13], and the faxparm tokens represent fax parameters. 1135 A printablestring is the PrintableString data type from ASN.1 [5]. 1137 3.16 Fax 1139 A value in the Fax syntax is an image which is produced using the 1140 Group 3 facsimile process [14] to duplicate an object, such as a 1141 memo. The following string states the OID assigned to this syntax: 1143 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 1145 Values in this syntax are expressed as octet strings containing 1146 Group 3 Fax images as defined in [14]. 1148 3.17 Generalized Time 1150 A value in the Generalized Time syntax is a date and time indicating 1151 accuracy to second or tenth of a second. The year is given as a 1152 four-digit number. The following string states the OID assigned to 1153 this syntax: 1155 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 1157 Values in this syntax are written as if they were printable strings, 1158 formulated as specified for the GeneralizeTime data type in ASN.1 1159 [5]. Note that the time zone must be specified. It is strongly 1160 recommended that GMT time be used. 1162 For example: 199412161032Z means 10:32 a.m. Dec. 16, 1994 in the 1163 Greenwich Mean Time time zone. 1165 3.18 Guide 1167 A value in the Guide syntax gives the matching criteria in a Filter. 1168 The following string states the OID assigned to this syntax: 1170 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 1172 The Guide syntax should not be used for defining new attributes. It 1173 is important for backwards compatibility with LDAPv2 systems. 1175 Values in this syntax are encoded according to the following BNF: 1177 guide-value = [ object-class "#" ] criteria 1179 object-class = woid 1181 The criteria production is defined in the Enhanced Guide syntax in 1182 paragraph 3.14. The production for woid is in paragraph 2.1. 1184 3.19 IA5 String 1186 A value in the IA5 String syntax is a string of characters from the 1187 International Alphabet 5 [15] (international version of ASCII) 1188 character set. The following string states the OID assigned to this 1189 syntax: 1191 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 1193 The written representation of a value in this syntax is the string 1194 value itself. Also, IA5String is an ASN.1 data type from X.680 [5]. 1196 3.20 INTEGER 1198 A value in the INTEGER syntax is a whole number as specified in the 1199 INTEGER data type from ASN.1 [5]. The following string states the 1200 OID assigned to this syntax: 1202 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 1204 Values in this syntax are expressed as the decimal representation of 1205 their values, with each decimal digit represented by the its 1206 character equivalent. So, the number 1321 is represented by the 1207 character string "1321". 1209 3.21 JPEG 1211 A value in the JPEG syntax is an image produced according to 1212 specific rules for light values. The following string states the 1213 OID assigned to this syntax: 1215 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 1217 Values in this syntax are expressed as strings containing JPEG images 1218 in the JPEG File Interchange Format (JFIF), as described in [16]. 1220 3.22 LDAP Syntax Description 1222 A value in the LDAP Syntax Description syntax is a string that 1223 expresses the definition of a schema Syntax Description in LDAP. 1224 This syntax is the form in which schema syntax descriptions are 1225 published in the directory. The following string states the OID 1226 assigned to this syntax: 1228 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 1230 Note that, in X.520 [9], syntaxes are not labeled distinctly with 1231 respect to attributes. 1233 Values in this syntax are written according to the BNF in 1234 section 2.2.4. 1236 3.23 Matching Rule Description 1238 A value in the Matching Rule Description syntax is a string that 1239 expresses the definition of a schema Matching Rule. This syntax is 1240 the form in which schema matching rules are published in the 1241 directory. The following string states the OID assigned to this 1242 syntax: 1244 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 1246 Values of type matchingRules are written as strings according to the 1247 BNF given in section 2.3.2. 1249 3.24 Matching Rule Use Description 1251 A value in the Matching Rule Use Description syntax is a string that 1252 expresses, for one of the Matching Rules implemented by the server, 1253 the attribute types with which the rule may be used in an 1254 extensibleMatch search filter. The following string states the OID 1255 assigned to this syntax: 1257 ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use 1258 Description' ) 1260 Values of type matchingRuleUse are written as strings according to 1261 the BNF given in section 2.3.3. 1263 3.25 MHS OR Address 1265 A value in the MHS OR Address syntax is the addressing information of 1266 a user of an X.400 messaging service. The following string states 1267 the OID assigned to this syntax: 1269 ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) 1271 Values in this syntax are expressed as strings, according to the 1272 format defined in RFC 1327 [17]. 1274 3.26 Name and Optional UID 1276 A value of the Name and Optional UID (Unique IDentifier) syntax is a 1277 Distinguished Name as defined in paragraph 3.13 plus a bit string 1278 that differentiates the value from otherwise identical names. The 1279 following string states the OID assigned to this syntax: 1281 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 1283 Values in this syntax are expressed according to the following BNF: 1285 NameAndOptionalUID = DistinguishedName [ "#" bitstring ] 1287 The bitstring production is defined in [Editor's note: Where is 1288 bitstring?? End of Editor note]. 1290 Although the '#' character may occur in a string representation of a 1291 distinguished name, no additional special quoting is done. This 1292 syntax has been added subsequent to RFC 1778 [7]. 1294 Example: 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 1296 3.27 Name Form Description 1298 A value in the Name Form Description syntax is a string that 1299 indicates the one or more attributes in an entry type (e.g., person, 1300 device) that are used as the Relative Distinguished Name of the 1301 entries. This syntax is the form in which schema name forms are 1302 published in the directory. The following string states the OID 1303 assigned to this syntax: 1305 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 1307 Values in this syntax are expressed according to the following BNF. 1308 The productions for whsp, numericoid, qdescrs, qdstring, woid, and 1309 oids are given in paragraph 2.1. Implementors should note that 1310 future versions of this document may have expanded this BNF to 1311 include additional terms. 1313 NameFormDescription = "(" whsp 1314 numericoid whsp ; NameForm identifier 1315 [ "NAME" qdescrs ] 1316 [ "DESC" qdstring ] 1317 [ "OBSOLETE" whsp ] 1318 "OC" woid ; Structural ObjectClass 1319 "MUST" oids ; AttributeTypes 1320 [ "MAY" oids ] ; AttributeTypes 1321 whsp ")" 1323 3.28 Numeric String 1325 A value in the Numeric String syntax is a series of numerals and 1326 spaces as specified in the NumericString data type from ASN.1 [5]. 1327 The following string states the OID assigned to this syntax: 1329 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 1331 The representation of a string in this syntax is the string value 1332 itself. 1334 Example: 1997 1336 3.29 Object Class Description 1338 A value in this syntax is a character string which expresses the 1339 definition of an object class according to the BNF given in 1340 paragraph 2.5.2. This syntax is the form in which schema object 1341 classes are published in the directory. The following string states 1342 the OID assigned to this syntax: 1344 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 1346 For example, the character string below specifies the country object 1347 class, which requires the c (country name) attribute and allows the 1348 searchGuide and description attributes. All of these schema 1349 elements are specified in RFC ____ [18]. 1351 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 1352 MAY ( searchGuide $ description ) ) 1354 3.30 Octet String 1356 A value in the Octet String syntax is a value of the OCTET STRING 1357 data type from ASN.1 [5]. The following string states the OID 1358 assigned to this syntax: 1360 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 1362 Values in this syntax are written as a series of 8-bit values, 1363 according to the octet string value notation specified in [5]. In 1364 the case of character strings, the characters themselves may be 1365 written. 1367 Example: 1369 secret 1371 3.31 OID 1373 A value in the Object Identifier syntax is a series of integers, 1374 ordered as specified in the OBJECT IDENTIFIER data type from ASN.1 1375 [5]. The following string states the OID assigned to this syntax: 1377 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 1379 Values in this syntax are expressed according to the BNF in 1380 paragraph 2.1 for "oid". 1382 Examples: 1.2.3.4 1383 cn 1385 3.32 Other Mailbox 1387 A value in the Other Mailbox syntax gives a mail system name with 1388 the name of a mailbox in the system. The following string states 1389 the OID assigned to this syntax: 1391 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 1393 Values in this syntax are written according to the following BNF: 1395 otherMailbox = mailbox-type "$" mailbox 1397 mailbox-type = printablestring 1399 mailbox = 1401 The printablestring production is defined in paragraph 2.1. 1403 In the above, mailbox-type represents the type of mail system in 1404 which the mailbox resides, for example "MCIMail"; and mailbox is 1405 the actual mailbox in the mail system defined by mailbox-type. 1407 3.33 Postal Address 1409 A value in the Postal Address syntax is a series of strings which 1410 form an address in a physical mail system. The following string 1411 states the OID assigned to this syntax: 1413 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 1415 Values in this syntax are written according to the following BNF: 1417 postal-address = dstring *( "$" dstring ) 1419 In the above, each dstring component of a postal address value is 1420 written as a value of type Directory String syntax. Backslashes and 1421 dollar characters, if they occur in the component, are quoted as 1422 described in paragraph 2.1. Many servers limit the postal address to 1423 six lines of up to thirty characters. 1425 The production for dstring is defined in paragraph 2.1. 1427 Example: 1429 1234 Main St.$Anytown, CA 12345$USA 1430 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 1432 3.34 Presentation Address 1434 A value in the Presentation Address syntax is an OSI Application 1435 Layer address of a remote application. Values in this syntax are 1436 written as described in RFC 1278 [19]. 1437 [Editor's note: Is this reference allowed, because RFC 1278 is 1438 Informational as opposed to Standard? End of Editor's note] 1439 The following string states the OID assigned to this syntax: 1441 ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) 1443 3.35 Printable String 1445 A value in the Printable String syntax is a series of alphabetic, 1446 numeric, and (limited) punctuation characters as specified in the 1447 PrintableString data type from ASN.1 [5] and in production p of 1448 paragraph 2.1. Values in this syntax are expressed as the string 1449 itself. The following string states the OID assigned to this syntax: 1451 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 1453 Example: This is a PrintableString. 1455 3.36 Substring Assertion Syntax 1457 The Substring Assertion syntax is used only as the syntax of 1458 assertion values in the extensible match. It is not used as the 1459 syntax of attributes, or in the substring filter. 1461 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1463 The Substring Assertion is expressed according to the following BNF: 1465 substring = [initial] any [final] 1467 initial = value 1469 any = "*" *(value "*") 1471 final = value 1473 The production is UTF-8 string. Should the backslash or 1474 asterix characters be present in a production of , they are 1475 quoted as described in section 2.1. 1477 3.37 Supported Algorithm 1479 A value in the Supported Algorithm syntax is the identifier of a 1480 cryptologic method with its intended usage and policies under which 1481 the algorithm is permitted. The following string states the OID 1482 assigned to this syntax: 1484 ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' ) 1486 No printable representation of values of the supportedAlgorithms 1487 attribute (see [18]) is defined in this document. Clients which wish 1488 to store and retrieve this attribute MUST use 1489 "supportedAlgorithms;binary", in which the value is transferred as a 1490 binary encoding. 1492 3.38 Telephone Number 1494 A value in the telephone number syntax is the series of characters 1495 that express a number (address) assigned to a telephone system 1496 subscriber. The following string states the OID assigned to this 1497 syntax: 1499 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1501 Values in this syntax are written as if they were Printable String 1502 types. Telephone numbers are defined in X.520 [9] to comply with the 1503 internationally agreed format for expressing international telephone 1504 numbers, Recommendation E.123 [15]. 1506 Example: +1 512 305 0280 1508 3.39 Teletex Terminal Identifier 1510 A value in this syntax is a string of characters that express the 1511 identifier value assigned to a teletex service subscriber. The 1512 following string states the OID assigned to this syntax: 1514 ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal 1515 Identifier' ) 1517 Values in this syntax are written according to the following BNF: 1519 teletex-id = ttx-term 0*("$" ttx-param) 1521 ttx-term = printablestring 1523 ttx-param = ttx-key ":" ttx-value 1525 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1527 ttx-value = octetstring 1529 In the above, the first printablestring is the encoding of the first 1530 portion of the teletex terminal identifier to be encoded, and the 1531 subsequent 0 or more octetstrings are subsequent portions of the 1532 teletex terminal identifier. 1534 The production for printablestring is defined in paragraph 2.1. 1536 [Editor's note: There is no production for octetstring in 1537 paragraph 2.1. How should it be defined? End of Editor's note] 1539 3.40 Telex Number 1541 A value in the Telex Number syntax is the number assigned to a telex 1542 system subscriber with the country and answerback values indicated. 1544 The following string states the OID assigned to this syntax: 1546 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1548 Values in this syntax are written according to the following BNF: 1550 telex-number = actual-number "$" country "$" answerback 1552 actual-number = printablestring 1554 country = printablestring 1556 answerback = printablestring 1558 In the above, actual-number is the syntactic representation of the 1559 number portion of the TELEX number being written, country is the 1560 TELEX country code, and answerback is the answerback code of a TELEX 1561 terminal. 1563 The production for printablestring is defined in paragraph 2.1. 1565 3.41 UTC Time 1567 A value in the UTC Time syntax is a date and time indicating accuracy 1568 to minute or second. The year is given as a two-digit number. The 1569 following string states the OID assigned to this syntax: 1571 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1573 Values in this syntax are written as if they were printable strings, 1574 formulated as specified for the UTCTime data type in ASN.1 [5]. 1575 Note that the time zone must be specified. It is strongly 1576 recommended that GMT time be used. 1578 Note: This syntax is deprecated in favor of the Generalized Time 1579 syntax. 1581 [Editor�s note: The convention for interpretation of 2-digit year 1582 values should be here (at least by reference), but where is the LDAP 1583 convention specified? Is LDAP referring to X.500 for this? If so, 1584 where? End of Editor's note] 1586 4. Matching Rules 1588 When performing the caseExactMatch, caseIgnoreMatch, 1589 caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and 1590 caseIgnoreIA5Match, multiple adjoining whitespace characters are 1591 treated the same as an individual space, and leading and trailing 1592 whitespace is ignored. 1594 4.1 bitStringMatch 1596 The following BNF associates the bitStringMatch rule with the Bit 1597 String syntax: 1599 ( 2.5.13.16 NAME 'bitStringMatch' 1600 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) ; Bit String 1602 This matching rule is used to test equality. 1604 4.2 caseExactIA5Match 1606 The following BNF associates the caseExactIA5Match rule with the IA5 1607 String syntax: 1609 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1610 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String 1612 This matching rule is used to test equality. 1614 4.3 caseIgnoreIA5Match 1616 The following BNF associates the caseIgnoreIA5Match rule with the 1617 IA5 String syntax: 1619 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1620 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String 1622 This matching rule is used to test equality. 1624 4.4 caseIgnoreListMatch 1626 The BNF below associates the caseIgnoreListMatch rule with the 1627 Postal Address syntax. The X.520 [] syntax for this matching rule 1628 is a SEQUENCE Of DirectoryString. Since the Postal Address syntax 1629 is such a sequence, it is used in defining the matching rule for 1630 LDAPv3, although the matching rule can be used with any SEQUENCE OF 1631 DirectoryString syntax/assertion. 1633 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1634 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ; Postal Address 1636 This matching rule is used to test equality. 1638 4.5 caseIgnoreMatch 1640 The following BNF associates the caseIgnoreMatch rule with the 1641 Directory String syntax: 1643 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1644 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String 1646 This matching rule is used to test equality. 1648 4.6 caseIgnoreOrderingMatch 1650 The following BNF associates the caseIgnoreOrderingMatch rule with 1651 the Directory String syntax: 1653 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1654 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String 1656 This matching rule is used to test inequality, i.e., greaterOrEqual 1657 or lessOrEqual. 1659 The sort ordering for a caseIgnoreOrderingMatch is implementation- 1660 dependent. 1662 4.7 caseIgnoreSubstringsMatch 1664 The following BNF associates the caseIgnoreSubstringsMatch rule with 1665 the Substring Assertion: 1667 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1668 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1670 This matching rule is used to test substrings equality. 1672 4.8 distinguishedNameMatch 1674 The following BNF associates the distinguishedNameMatch rule with 1675 the DN syntax: 1677 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1678 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ; DN 1680 This matching rule is used to test equality. 1682 4.9 generalizedTimeMatch 1684 The following BNF associates the generalizedTimeMatch rule with the 1685 Generalized Time syntax: 1687 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1688 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ; Generalized Time 1690 This matching rule is used to test equality. 1692 4.10 generalizedTimeOrderingMatch 1694 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1695 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ; Generalized Time 1697 This matching rule is used to test inequality, i.e., greaterOrEqual 1698 or lessOrEqual. 1700 4.11 integerFirstComponentMatch 1702 Implementors should note that the assertion syntax of this matching 1703 rule, an INTEGER, is different from the value syntax of attributes 1704 for which this is the equality matching rule. 1706 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1707 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER 1709 This matching rule is used to test equality with the first component 1710 in a compound syntax. 1712 Implementors should note that the assertion syntax of this matching 1713 rule, an INTEGER, is different from the value syntax of attributes 1714 for which this is the equality matching rule. 1716 4.12 integerMatch 1718 The following BNF associates the integerMatch rule with the INTEGER 1719 syntax: 1721 ( 2.5.13.14 NAME 'integerMatch' 1722 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER 1724 This matching rule is used to test equality. 1726 4.13 numericStringMatch 1728 The following BNF associates the numericStringMatch rule with the 1729 Numeric String syntax: 1731 ( 2.5.13.8 NAME 'numericStringMatch' 1732 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) ; Numeric String 1734 This matching rule is used to test equality. 1736 4.14 numericStringSubstringsMatch 1738 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1739 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1741 This matching rule is used to test substrings equality. 1743 4.15 objectIdentifierFirstComponentMatch 1745 Implementors should note that the assertion syntax of this matching 1746 rule, an OID, is different from the value syntax of attributes for 1747 which this is the equality matching rule. 1749 ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' 1750 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID 1752 This matching rule is used to test equality with the first component 1753 in a compound syntax. 1755 If the client supplies an extensible filter using an 1756 objectIdentifierFirstComponentMatch whose matchValue is in the 1757 "descr" form, and the OID is not recognized by the server, then the 1758 filter is Undefined. 1760 4.16 objectIdentifierMatch 1762 The following BNF associates the objectIdentifierMatch rule with the 1763 OID syntax: 1765 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1766 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID 1768 This matching rule is used to test equality. 1770 Implementors should note that the assertion syntax of this matching 1771 rule, an OID, is different from the value syntax of attributes for 1772 which this is the equality matching rule. 1774 If the client supplies a filter using an objectIdentifierMatch whose 1775 matchValue oid is in the "descr" form, and the oid is not recognized 1776 by the server, then the filter is Undefined. 1778 4.17 presentationAddressMatch 1780 The following BNF associates the presentationAddressMatch rule with 1781 the Presentation Address syntax: 1783 ( 2.5.13.22 NAME 'presentationAddressMatch' 1784 SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) ; Presentation Address 1786 This matching rule is used to test equality. 1788 4.18 protocolInformationMatch 1790 The following BNF associates the protocolInformationMatch rule with 1791 the Protocol Information syntax: 1793 ( 2.5.13.24 NAME 'protocolInformationMatch' 1794 SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) ; Protocol Information 1796 This matching rule is used to test equality. 1798 4.19 telephoneNumberMatch 1800 The following BNF associates the telephoneNumberMatch rule with the 1801 Telephone Number syntax: 1803 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1804 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) ; Telephone Number 1806 This matching rule is used to test equality. 1808 4.20 telephoneNumberSubstringsMatch 1810 The following BNF associates the telephoneNumberSubstringsMatch rule 1811 with the Substring Assertion syntax: 1813 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 1814 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1816 This matching rule is used to test substrings equality. 1818 4.21 uniqueMemberMatch 1820 The following BNF associates the uniqueMemberMatch rule with the 1821 Name and Optional UID syntax: 1823 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1824 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) ; Name And Optional UID 1826 This matching rule is used to test equality. 1828 5. Attribute Types 1830 5.1 altServer 1832 The values of this attribute are URLs of other servers which may be 1833 contacted when this server becomes unavailable. If the server does 1834 not know of any other servers which could be used this attribute will 1835 be absent. Clients may cache this information in case their 1836 preferred LDAP server later becomes unavailable. 1838 ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' 1839 EQUALITY caseIgnoreIA5Match 1840 ; OR SHOULD THIS BE caseExactIA5Match?? 1841 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ; IA5 String 1842 USAGE dSAOperation ) 1844 This attribute is only present in the root DSE (see [1] and [3]). 1846 5.2 attributeTypes 1848 This attribute is typically located in the subschema entry. 1850 ( 2.5.21.5 NAME 'attributeTypes' 1851 EQUALITY objectIdentifierFirstComponentMatch 1852 SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 ; Attribute Type 1853 ; Description 1854 USAGE directoryOperation ) 1856 5.3 createTimestamp 1858 ( 2.5.18.1 NAME 'createTimestamp' 1859 EQUALITY generalizedTimeMatch 1860 ORDERING generalizedTimeOrderingMatch 1861 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ; Generalized Time 1862 SINGLE-VALUE 1863 NO-USER-MODIFICATION 1864 USAGE directoryOperation ) 1866 5.4 creatorsName 1868 ( 2.5.18.3 NAME 'creatorsName' 1869 EQUALITY distinguishedNameMatch 1870 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ; DN 1871 SINGLE-VALUE 1872 NO-USER-MODIFICATION 1873 USAGE directoryOperation ) 1875 5.5 ditContentRules 1877 ( 2.5.21.2 NAME 'dITContentRules' 1878 EQUALITY objectIdentifierFirstComponentMatch 1879 SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 ; DIT Content Rule 1880 ; Description 1881 USAGE directoryOperation ) 1883 This attribute is located in the subschema entry. 1885 5.6 dITStructureRules 1887 ( 2.5.21.1 NAME 'dITStructureRules' 1888 EQUALITY integerFirstComponentMatch 1889 SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 ; DIT Structure Rule 1890 ; Description 1891 USAGE directoryOperation ) 1893 This attribute is located in the subschema entry. 1895 5.7 ldapSyntaxes 1897 This attribute is typically located in the subschema entry. 1899 This attribute identifies the syntaxes implemented, with each value 1900 corresponding to one syntax. 1902 ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' 1903 EQUALITY objectIdentifierFirstComponentMatch 1904 SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 ; LDAP Syntax 1905 ; Description 1906 USAGE directoryOperation ) 1908 5.8 matchingRules 1910 This attribute is typically located in the subschema entry. 1912 ( 2.5.21.4 NAME 'matchingRules' 1913 EQUALITY objectIdentifierFirstComponentMatch 1914 SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 ; Matching Rule 1915 ; DESCRIPTION 1916 USAGE directoryOperation ) 1918 5.9 matchingRuleUse 1920 This attribute is typically located in the subschema entry. 1922 ( 2.5.21.8 NAME 'matchingRuleUse' 1923 EQUALITY objectIdentifierFirstComponentMatch 1924 SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 ; Matching Rule Use 1925 ; Description 1926 USAGE directoryOperation ) 1928 5.10 modifiersName 1930 ( 2.5.18.4 NAME 'modifiersName' 1931 EQUALITY distinguishedNameMatch 1932 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ; DN 1933 SINGLE-VALUE 1934 NO-USER-MODIFICATION 1935 USAGE directoryOperation ) 1937 5.11 modifyTimestamp 1939 ( 2.5.18.2 NAME 'modifyTimestamp' 1940 EQUALITY generalizedTimeMatch 1941 ORDERING generalizedTimeOrderingMatch 1942 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ; Generalized Time 1943 SINGLE-VALUE 1944 NO-USER-MODIFICATION 1945 USAGE directoryOperation ) 1947 5.12 nameForms 1949 ( 2.5.21.7 NAME 'nameForms' 1950 EQUALITY objectIdentifierFirstComponentMatch 1951 SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 ; Name Form Description 1952 USAGE directoryOperation ) 1954 This attribute is located in the subschema entry. 1956 5.13 namingContexts 1958 The values of this attribute correspond to naming contexts which 1959 this server masters or shadows. If the server does not master any 1960 information (e.g. it is an LDAP gateway to a public X.500 directory) 1961 this attribute will be absent. If the server believes it contains 1962 the entire directory, the attribute will have a single value, and 1963 that value will be the empty string (indicating the null DN of the 1964 root). This attribute will allow a client to choose suitable base 1965 objects for searching when it has contacted a server. 1967 ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' 1968 EQUALITY distinguishedNameMatch 1969 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ; DN 1970 USAGE dSAOperation ) 1972 This attribute is only present in the root DSE (see [1] and [3]). 1974 5.14 objectClasses 1976 This attribute is typically located in the subschema entry. 1978 ( 2.5.21.6 NAME 'objectClasses' 1979 EQUALITY objectIdentifierFirstComponentMatch 1980 SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 ; Object Class 1981 ; Description 1982 USAGE directoryOperation ) 1984 5.15 subschemaSubentry 1986 The value of this attribute is the name of a subschema entry (or 1987 subentry) where the server makes available attributes specifying the 1988 schema controlling the subject entry. 1990 ( 2.5.18.10 NAME 'subschemaSubentry' 1991 EQUALITY distinguishedNameMatch 1992 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ; DN 1993 NO-USER-MODIFICATION 1994 SINGLE-VALUE 1995 USAGE directoryOperation ) 1997 5.16 supportedControl 1999 The values of this attribute are the OBJECT IDENTIFIERs identifying 2000 controls which the server supports. If the server does not support 2001 any controls, this attribute will be absent. 2003 ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' 2004 EQUALITY objectIdentifierMatch 2005 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ; OID 2006 USAGE dSAOperation ) 2008 This attribute is only present in the root DSE (see [1] and [3]). 2010 5.17 supportedExtension 2012 The values of this attribute are OBJECT IDENTIFIERs identifying the 2013 supported extended operations which the server supports. 2015 If the server does not support any extensions this attribute will be 2016 absent. 2018 ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' 2019 EQUALITY objectIdentifierMatch 2020 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ; OID 2021 USAGE dSAOperation ) 2023 This attribute is only present in the root DSE (see [1] and [3]). 2025 5.18 supportedLDAPVersion 2027 The values of this attribute are the versions of the LDAP protocol 2028 which the server implements. 2030 ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' 2031 EQUALITY integerMatch 2032 ORDERING integerOrderingMatch 2033 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ; INTEGER 2034 USAGE dSAOperation ) 2036 This attribute is only present in the root DSE (see [1] and [3]). 2038 5.19 supportedSASLMechanisms 2040 The values of this attribute are the names of supported SASL 2041 mechanisms which the server supports. If the server does not support 2042 any mechanisms this attribute will be absent. 2044 ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' 2045 EQUALITY caseIgnoreMatch ; OR SHOULD THIS BE caseExactMatch?? 2046 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ; Directory String 2047 USAGE dSAOperation ) 2049 This attribute is only present in the root DSE (see [1] and [3]). 2051 6. Object Classes 2053 6.1 Extensible Object Class 2055 The extensibleObject object class, if present in an entry, permits 2056 that entry to optionally hold any attribute. The MAY attribute list 2057 of this class is implicitly the set of all attributes. 2059 ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' 2060 SUP top 2061 AUXILIARY 2062 ; MAY all attributes is implied 2063 ) 2065 The mandatory attributes of the other object classes of this entry 2066 are still required to be present. 2068 Note that not all servers will implement this object class, and those 2069 which do not will reject requests to add entries which contain this 2070 object class, or modify an entry to add this object class. 2072 Note that, if the server implements the extensibleObject class but an 2073 attribute is not recognized, this is the same case as for any other 2074 object class. 2076 6.2 subschema 2078 This object class contains a description of the schema that is 2079 applied in the server and is used in the subschema entry. 2081 ( 2.5.20.1 NAME 'subschema' 2082 AUXILIARY 2083 MAY ( dITStructureRules $ 2084 nameForms $ 2085 ditContentRules $ 2086 objectClasses $ 2087 attributeTypes $ 2088 matchingRules $ 2089 matchingRuleUse ) ) 2091 The ldapSyntaxes operational attribute may also be present in 2092 subschema entries. [Editor's Proposal: add "A Content Rule could be 2093 used to enable this." End of Editor's Proposal] 2095 7. Security Considerations 2097 7.1 Disclosure 2099 Attributes of directory entries are used to provide descriptive 2100 information about the real-world objects they represent, which can 2101 be people, organizations or devices. Most countries have privacy 2102 laws regarding the publication of information about people. 2104 7.2 Use of Attribute Values in Security Applications 2106 The transformations of an AttributeValue value from its X.501 form 2107 to an LDAP string representation are not always reversible back to 2108 the same BER or DER form. An example of a situation which requires 2109 the DER form of a distinguished name is the verification of an X.509 2110 certificate. 2112 For example, a distinguished name consisting of one RDN with one AVA, 2113 in which the type is commonName and the value is of the 2114 TeletexString choice with the letters 'Sam' would be represented in 2115 LDAP as the string CN=Sam. Another distinguished name in which the 2116 value is still 'Sam' but of the PrintableString choice would have the 2117 same representation CN=Sam. 2119 Applications which require the reconstruction of the DER form of the 2120 value SHOULD NOT use the string representation of attribute syntaxes 2121 when converting a value to LDAP format. Instead it SHOULD use the 2122 Binary syntax. 2124 7.3 Securing the Directory 2126 In order to protect the directory and its contents, strong 2127 authentication MUST have been used to identify the Client when an 2128 update operation is requested. 2129 [Editor's Note: This paragraph has been provided at Kurt Zeilenga's 2130 suggestion. There is probably more to be said. Input please! End 2131 of Editor's Note] 2133 8. Acknowledgements 2135 This document is an update of RFC 2252 by M. Wahl, A. Coulbeck, 2136 T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID 2137 Working Group. 2139 This document is based upon input of the IETF LDAPBIS working group. 2140 The authors wish to thank ___ for their significant contribution to 2141 this update. 2143 9. Author's Address 2145 Kathy Dally 2146 The MITRE Corp. 2147 7515 Colshire Dr., ms-W650 2148 McLean VA 22102 2149 USA 2151 Phone: +1 703 883 6058 2152 Email: kdally@mitre.org 2154 10. References 2156 [1] draft-ietf-ldapbis-protocol-xx, replacement for Wahl, M., 2157 Howes, T., and S. Kille, "Lightweight Directory Access 2158 Protocol (v3)", RFC 2251, December 1997. 2160 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2161 Levels", RFC 2119, March 1997. 2163 [3] The Directory: Models. ITU-T Recommendation X.501, 1993. 2165 [4] Crocker, D., "Standard of the Format of ARPA-Internet Text 2166 Messages", STD 11, RFC 822, August 1982. 2168 [5] Information Technology - Abstract Syntax Notation One (ASN.1): 2169 Specification of Basic Notation, ITU-T Recommendation 2170 X.680, 1994 2172 ...[6] The Directory: Authentication Framework. ITU-T Recommendation 2173 X.509 1993. 2175 [7] Howes, T., Kille, S., Yeong, W., Robbins, C., "The String 2176 Representation of Standard Attribute Syntaxes", RFC 1778, 2177 March 1995. 2179 [8] ISO 3166, "Codes for the representation of names of countries". 2181 [9] The Directory: Selected Attribute Types. ITU-T Recommendation 2182 X.520, 1993. 2184 [10] Universal Multiple-Octet Coded Character Set (UCS) - 2185 Architecture and Basic Multilingual Plane, 2186 ISO/IEC 10646-1: 1993 (with amendments). 2188 [11] Yergeau, F., "UTF-8, a transformation format of Unicode and 2189 ISO 10646", RFC 2044, October 1996. 2191 [12] draft-ietf-ldapbis-dn-xx, replacement for Wahl, M., Kille, S., 2192 and T. Howes, "Lightweight Directory Access Protocol (v3): 2193 UTF-8 String Representation of Distinguished Names", RFC 2253, 2194 December 1997. 2196 [13] Notation for national and international 2197 telephone numbers. ITU-T Recommendation E.123, 1988. 2199 [14] Standardization of Group 3 facsimile apparatus for document 2200 transmission - Terminal Equipment and Protocols for Telematic 2201 Services. ITU-T Recommendation T.4, 1993 2203 [15] International Reference Alphabet (IRA) (Formerly International 2204 Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded 2205 Character Set for Information Interchange, ITU-T Recommendation 2206 T.50, 1992 2208 [16] JPEG File Interchange Format (Version 1.02). Eric Hamilton, 2209 C-Cube Microsystems, Milpitas, CA, September 1, 1992. 2211 [17] Hardcastle-Kille, S., "Mapping between X.400(1988)/ISO 10021 2212 and RFC 822", RFC 1327, May 1992. 2214 [18] draft-ietf-ldapbis-user-schema-xx, replacement for Wahl, M., 2215 "A Summary of the X.500(96) User Schema for use with LDAPv3", 2216 RFC 2256, December 1997. 2218 [19] Kille, S., "A String Representation for Presentation Addresses", 2219 RFC 1278, November 1991. 2221 11. Full Copyright Statement 2223 Copyright (C) The Internet Society (2001). All Rights Reserved. 2225 This document and translations of it may be copied and furnished to 2226 others, and derivative works that comment on or otherwise explain it 2227 or assist in its implementation may be prepared, copied, published 2228 and distributed, in whole or in part, without restriction of any 2229 kind, provided that the above copyright notice and this paragraph 2230 are included on all such copies and derivative works. However, this 2231 document itself may not be modified in any way, such as by removing 2232 the copyright notice or references to the Internet Society or other 2233 Internet organizations, except as needed for the purpose of 2234 developing Internet standards in which case the procedures for 2235 copyrights defined in the Internet Standards process must be 2236 followed, or as required to translate it into languages other 2237 than English. 2239 The limited permissions granted above are perpetual and will not be 2240 revoked by the Internet Society or its successors or assigns. 2242 This document and the information contained herein is provided on an 2243 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2244 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2245 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2246 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2247 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2249 Annex A Topics Yet To Be Addressed In This Document 2251 This appendix is provided for informational purposes only, it is not 2252 a normative part of this specification. 2254 Paragraph 2.2.3 - Should attribute syntaxes be allowed to be referenced 2255 by a common name, and if so, where should the name come from? An 2256 optional NAME has been added to the BNF for SyntaxDescription in 2257 paragraph 2.2.4. 2259 Paragraph 2.2.3 - Should any syntaxes listed in the table be removed? 2260 Should any new syntaxes be added? 2262 How does the data model draft affect 2263 this draft? 2265 Section 3 - Should all listed syntaxes from paragraph 2.2.3 be 2266 detailed in this section? Nearly half the listed syntaxes are not 2267 referenced in this section. 2269 Section 6 - Recognized list of Object classes needs to be reconciled 2270 with updated RFC 2256 and the data model draft. 2272 Section 7 - Proper security statement needs to be formulated. 2274 Annex B Change Log 2276 This annex lists the changes that have been made from RFC 2252 to 2277 this I-D. 2279 This annex is provided for informational purposes only. It is not 2280 a normative part of this specification. 2282 1. Removed the IESG Note. 2284 2. Changed "types" to "syntaxes" in the last sentence of the 2285 Abstract. Also, added to the last sentence in order to 2286 indicate that syntaxes are not the only schema elements 2287 defined in this document. 2289 3. Reorganized the sections so that: 2291 * the schema element categories are specified in the 2292 order in which they build on one another: syntaxes, 2293 matching rules, attributes, object classes 2295 * within each category the elements are specified in 2296 alphbetical order 2298 4. Added an "Implementation Status" paragraph for each element, 2299 gathering the conformance statements. 2301 5. Clarified schema description in the Overview. 2303 6. Changed the "Common Encoding Aspects" section title to 2304 "Notation" and made corresponding changes throughout the 2305 document. The purpose being to relegate all encoding issues 2306 to the Protocol specification [1]. 2308 7. Added a MUST statement regarding the syntaxes required of 2309 servers. 2311 8. Expanded the discussion of each of the syntaxes in section 3. 2313 9. Added examples to some of the syntax descriptions. 2315 10. Added NAME option to the syntax description BNF 2316 in 2.2.4. 2318 11. Added a note deprecating the UTCTime attribute syntax 2319 description in 3.41 2321 12. In the BNF of the MatchingRuleDescription in paragraph 2.3.2, 2322 replaced "numericoid" with "oid". 2324 13. In paragraph 2.4.1, replaced the conformance statement about 2325 attributes in 2256 with a reference. 2327 14. Added caseIgnoreIA5Match as the EQUALITY matching rule for 2328 the altServer attribute type BNF in paragraph 5.1. Note that 2329 this could be caseExactIA5Match instead. SHOULD IT BE?? 2331 15. In paragraphs 5.10 and 5.11, changed "the MODIFY operation" 2332 to "LDAP update operations" 2334 16. Added distinguishedNameMatch as the EQUALITY matching rule 2335 for the namingContexts attribute type BNF in paragraph 5.13. 2337 17. Reworded paragraph 5.15. 2339 18. Added objectIdentifierMatch as the EQUALITY matching rule for 2340 the supportedControl and supportedExtension attribute types 2341 BNF in paragraphs 5.16 and 5.17. 2343 19. Added integerMatch as the EQUALITY and integerOrderingMatch 2344 as the Ordering matching rules for the supportedLDAPVersion 2345 attribute type BNF in paragraph 5.18. 2347 20. Added caseIgnoreMatch as the EQUALITY matching rule for the 2348 supportedSASLMechanisms attribute type BNF in paragraph 5.19. 2349 Note that this could be caseExactMatch instead. SHOULD 2350 IT BE?? 2352 21. Made corrections to the BNF in paragraph 3.12. 2354 22. Added the seven syntax definitions from RFC 2256 and ordered 2355 the definitions alphabetically. 2357 23. Changed the "Bibliography" section title to "References". 2359 24. Replaced the X.208 reference with on to X.680(1994), since 2360 X.680 is the ASN.1 referred to in the X.500(1993)-series.