idnits 2.17.1 draft-ietf-ldapbis-syntaxes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 32) being 64 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of too long lines in the document, the longest one being 60 characters in excess of 72. ** The abstract seems to contain references ([Protocol]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 23 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2252, but the abstract doesn't seem to directly say this. It does mention RFC2252 though, so this could be OK. -- The draft header indicates that this document obsoletes RFC2256, but the abstract doesn't seem to directly say this. It does mention RFC2256 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (4 November 2002) is 7843 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Models' is mentioned on line 488, but not defined == Missing Reference: 'Schema' is mentioned on line 803, but not defined == Missing Reference: 'User' is mentioned on line 1556, but not defined == Missing Reference: 'Prot' is mentioned on line 454, but not defined == Missing Reference: 'UTF-8' is mentioned on line 490, but not defined == Missing Reference: 'Fax' is mentioned on line 599, but not defined == Missing Reference: 'MODELS' is mentioned on line 1820, but not defined == Missing Reference: 'Attr' is mentioned on line 690, but not defined == Unused Reference: 'JPEG' is defined on line 1473, but no explicit reference was found in the text == Unused Reference: 'RFC 2256' is defined on line 1492, but no explicit reference was found in the text == Unused Reference: 'RFC1777' is defined on line 1514, but no explicit reference was found in the text == Unused Reference: 'RFC2253' is defined on line 1521, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'IA5' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10646' -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG' -- No information found for draft-ietf-ldapbis-dn-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'LDAPDN' -- No information found for draft-ietf-ldapbis-protocol-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Protocol' ** Obsolete normative reference: RFC 1327 (Obsoleted by RFC 2156) ** Obsolete normative reference: RFC 2044 (Obsoleted by RFC 2279) -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC 2256' -- Obsolete informational reference (is this intentional?): RFC 1777 (Obsoleted by RFC 3494) -- Obsolete informational reference (is this intentional?): RFC 1778 (Obsoleted by RFC 3494) -- Obsolete informational reference (is this intentional?): RFC 2253 (Obsoleted by RFC 4510, RFC 4514) Summary: 7 errors (**), 0 flaws (~~), 19 warnings (==), 17 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: 4 May 2003 S. Legg 4 Obsoletes: RFC 2252, RFC 2256 ADACEL 5 4 November 2002 7 LDAP: Syntaxes 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 15 This document is intended to be, after appropriate review and 16 revision, submitted to the RFC Editor as a Standard Track document. 17 Distribution of this memo is unlimited. Technical discussion of 18 this document will take place on the IETF LDAP Revision Working 19 Group (LDAPbis) mailing list . Please 20 send editorial comments directly to the editor . 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. The list of 32 Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright 2002, The Internet Society. All Rights Reserved. 37 Please see the Copyright section near the end of this document for 38 more information. 40 Abstract 42 The Lightweight Directory Access Protocol (LDAP) [Protocol] provides 43 for exchanging AttributeValue fields in protocol. This document 44 defines a set of syntaxes for LDAP, rules by which attribute values 45 of these syntaxes are represented in the LDAP protocol, and the 46 matching rules which specify how values are compared. Also, this 47 document indicates the syntax support requirements on LDAP servers. 48 The syntaxes and matching rules defined in this document are used in 49 schema definition documents to specify attribute types. 51 [Editor's note: This document is a modified version of parts of 52 RFC 2252 and RFC 2256, in order to bring then up to date. This 53 action is part of the maintenance activity that is needed in order 54 to progress LDAP (v3) to Draft Standard. The changes are described 55 in Annex C of this document. Open items are listed in Annex B. 56 End of Editor's note] 57 Table of Contents 59 Status of this Memo....................................................1 61 Abstract...............................................................2 63 1. Overview...........................................................5 65 2. General Issues.....................................................5 66 2.1 Notation..........................................................5 67 2.2 Syntaxes..........................................................5 68 2.2.1 LDAP-Specific Encodings.........................................6 69 2.2.2 Syntaxes Implementation Status..................................6 70 2.2.3 Syntax Object Identifiers.......................................6 71 2.2.4 Syntax Description..............................................6 72 2.3 Matching Rules....................................................7 73 2.3.1 Matching Rules Implementation Status............................7 74 2.3.2 Matching Rule Description.......................................7 76 3. Syntaxes...........................................................8 77 3.1 Attribute Type Description........................................8 78 3.2 Bit String........................................................8 79 3.3 Boolean...........................................................8 80 3.4 Country String....................................................9 81 3.5 Delivery Method...................................................9 82 3.6 Directory String..................................................9 83 3.7 DIT Content Rule Description.....................................10 84 3.8 DIT Structure Rule Description...................................11 85 3.9 DN...............................................................11 86 3.10 Enhanced Guide...................................................12 87 3.11 Facsimile Telephone Number.......................................12 88 3.12 Fax..............................................................13 89 3.13 Generalized Time.................................................13 90 3.14 Guide............................................................13 91 3.15 IA5 String.......................................................14 92 3.16 Integer..........................................................14 93 3.17 JPEG.............................................................14 94 3.18 LDAP Syntax Description..........................................15 95 3.19 Matching Rule Description........................................15 96 3.20 Matching Rule Use Description....................................15 97 3.21 MHS OR Address...................................................15 98 3.22 Name and Optional UID............................................16 99 3.23 Name Form Description............................................16 100 3.24 Numeric String...................................................16 101 3.25 Object Class Description.........................................17 102 3.26 Octet String.....................................................17 103 3.27 OID..............................................................17 104 3.28 Other Mailbox....................................................18 105 3.29 Postal Address...................................................18 106 3.30 Presentation Address.............................................19 107 3.31 Printable String.................................................21 108 3.32 Substring Assertion .......................................21 109 3.33 Telephone Number.................................................21 110 3.34 Teletex Terminal Identifier......................................22 111 3.35 Telex Number.....................................................22 112 3.36 UTC Time.........................................................23 114 4. Matching Rules....................................................23 115 4.1 bitStringMatch...................................................23 116 4.2 caseExactIA5Match................................................23 117 4.3 caseIgnoreIA5Match...............................................24 118 4.4 caseIgnoreListMatch..............................................24 119 4.5 caseIgnoreMatch..................................................24 120 4.6 caseIgnoreOrderingMatch..........................................24 121 4.7 caseIgnoreSubstringsMatch........................................25 122 4.8 distinguishedNameMatch...........................................25 123 4.9 generalizedTimeMatch.............................................25 124 4.10 generalizedTimeOrderingMatch.....................................25 125 4.11 integerFirstComponentMatch.......................................25 126 4.12 integerMatch.....................................................26 127 4.13 numericStringMatch...............................................26 128 4.14 numericStringSubstringsMatch.....................................26 129 4.15 objectIdentifierFirstComponentMatch..............................26 130 4.16 objectIdentifierMatch............................................26 131 4.17 octetStringMatch.................................................27 132 4.18 presentationAddressMatch.........................................27 133 4.19 protocolInformationMatch.........................................27 134 4.20 telephoneNumberMatch.............................................28 135 4.21 telephoneNumberSubstringsMatch...................................28 136 4.22 uniqueMemberMatch................................................28 138 5. Security Considerations...........................................28 139 5.1 Disclosure.......................................................28 140 5.2 Security Information Syntaxes....................................28 141 5.3 Securing the Directory...........................................29 143 6. Acknowledgements..................................................29 145 7. Authors' Addresses................................................29 147 8. References........................................................30 148 8.1 Normative........................................................30 149 8.2 Informative......................................................31 151 9. Full Copyright Statement..................... .....................31 153 Annex A Object Identifiers for Syntaxes..............................32 154 Annex B Topics to be Addressed in This Document......................33 155 Annex C Change Log...................................................34 156 1. Overview 158 This document defines part of the framework for developing schemas 159 for directories accessible via the Lightweight Directory Access 160 Protocol (LDAP) [Protocol]. 162 Schema is the collection of attribute type definitions, object class 163 definitions and other information which specify the entries and their 164 contents that a server holds. A server uses schema to determine how 165 to match a filter or attribute value assertion (in a compare 166 operation) against the attributes of an entry, and whether to permit 167 add and modify operations. This document specifies syntaxes, which 168 are used in defining attribute types, and matching rules. 170 Therefore, Section 2 states the general requirements and notation 171 for definition of syntaxes and matching rules. 173 Section 3 lists syntaxes and section 4 contains matching rules. 175 Additional documents define schemas for representing real-world 176 objects as directory entries. See [Models], sections 2.4.1 and 2.6 177 and [Schema] for the definitions of user objects and attributes from 178 [X.501], [X.520], and [X.521]. 180 2. General Issues 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in BCP 14 [RFC2119]. 186 This document describes the syntaxes of data conveyed in an 187 Internet protocol. 189 Implementors are strongly advised to first read the description of 190 how schema is represented in X.501 [X.501] before reading the rest 191 of this document. 193 2.1 Notation 195 For the purposes of defining attribute syntaxes and matching rules, 196 Augmented Backus-Naur Form (ABNF) is used. The ABNF productions 197 used in this document are used by other documents in the LDAP set 198 and are listed in [Models]. 200 The schema definitions provided in this document are line-wrapped 201 for readability. 203 In addition, the following ABNF productions are used in this 204 document: 206 2.2 Syntaxes 208 This section defines general requirements for LDAP attribute 209 syntaxes. All documents defining attribute syntaxes for use with 210 LDAP are expected to conform to these requirements. Syntaxes are 211 also defined for matching rules whose assertion value syntax is 212 different from the attribute value syntax. 214 2.2.1 LDAP-Specific Encodings 216 In [Protocol], the encoding of the LDAP protocol is specified. The 217 protcol encapsulates values of attributes in many places. In this 218 specification, the encoding of the values is specified, as part of 219 each syntax definition. These value encoding rules are termed 220 "LDAP-specific encodings". The LDAP-specific encoding of a value is 221 what is transmitted in the protocol. 223 The LDAP-specific encoding of a given attribute syntax always 224 produces octet-aligned values. To the greatest extent possible, the 225 LDAP-specific encoding of a value is supposed to be usable for 226 display purposes. In particular, encoding rules for attribute 227 syntaxes defining non-binary values are supposed to produce strings 228 that can be displayed with little or no translation by clients 229 implementing LDAP. There are a few cases (e.g., audio) however, 230 when it is not sensible to produce a human-readable representation. 232 2.2.2 Syntaxes Implementation Status 234 Clients and servers need not implement all the syntaxes listed in 235 section 3, and MAY implement other syntaxes. 237 Clients MUST NOT assume that the LDAP-specific encoding of a value 238 of an unrecognized syntax is a human-readable character string. 240 Other documents define additional attribute syntaxes. However, the 241 definition of additional arbitrary syntaxes is strongly deprecated 242 since it will hinder interoperability. Today's client and server 243 implementations generally do not have the ability to dynamically 244 recognize new syntaxes. 246 2.2.3 Syntax Object Identifiers 248 In an LDAP schema, a syntax is named by the Object Identifier (OID) 249 assigned to it. 251 Syntaxes that are currently in use in the user schema specification 252 [Schema] and the models specification [Models] are specified in this 253 document in section 3. The object identifiers assigned to these 254 syntaxes are listed in Annex A. 256 2.2.4 Syntax Description 258 The SyntaxDescription ABNF specified in [Models] is the method used 259 in this document to define the values for each syntax. 261 For example, the syntax description of the INTEGER syntax for whole 262 number values is: 264 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 266 2.3 Matching Rules 268 The matching rules specified in this document are defined in 269 Section 4. 271 Matching rules are used by servers to compare attribute values 272 against assertion values when performing Search and Compare 273 operations. They are also used to identify the value to be added 274 or deleted when modifying entries, and are used when comparing a 275 purported distinguished name with the name of an entry. 277 Most of the attributes given in the user schema [Schema] have an 278 equality matching rule defined. 280 ...An OID is assigned to a matching rule when it is defined. A 281 matching rule definition ought not be changed without having a new 282 OID assigned to it. 284 2.3.1 Matching Rules Implementation Status 286 Servers which support matching rules and the extensibleMatch SHOULD 287 implement all the matching rules in section 4. 289 Servers MUST publish in the matchingRules attribute, the definitions 290 of matching rules referenced by values of the attributeTypes and 291 matchingRuleUse attributes in the same subschema entry. Other 292 unreferenced matching rules MAY be published in the matchingRules 293 attribute. 295 If the server supports the extensibleMatch, then the server MAY use 296 the matchingRuleUse attribute to indicate the applicability of 297 selected matching rules to designated attribute types in an 298 extensibleMatch. 300 2.3.2 Matching Rule Description 302 The SyntaxDescription ABNF specified in [Models] is the method used 303 The Matching Rule descriptions are specified according to the 304 MatchingRule ABNF specified in [Models]. 306 3. Syntaxes 308 3.1 Attribute Type Description 310 A value in this syntax is a definition of an attribute type 311 according to the ABNF given [Models]. The LDAP-specific encoding is 312 the character codes in UTF-8 which correspond to the characters in 313 the definition. 315 This syntax is the form in which schema attribute types are 316 published in the directory in a subentry. The following syntax 317 description gives the OID assigned to this syntax: 319 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 321 For example, this is the definition from [User] of the 322 businessCategory attribute type: 324 ( 2.5.4.15 NAME 'businessCategory' 325 EQUALITY caseIgnoreMatch 326 SUBSTR caseIgnoreSubstringsMatch 327 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} ) 329 The syntax type for the businessCategory Attribute Type is Directory 330 String. 332 This example definition is a value of the Attribute Type Description 333 syntax. The LDAP-specific encoding of this value is the definition 334 itself. 336 3.2 Bit String 338 A value in this syntax is a value of the BIT STRING data type from 339 ASN.1 [X.680]. The following syntax description gives the OID 340 assigned to this syntax: 342 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 344 The LDAP-specific encoding of a value is the following ABNF: 346 bitstring = SQUOTE *binary-digit SQUOTE "B" 348 binary-digit = "0" / "1" 350 Example: '0101111101'B 352 3.3 Boolean 354 A value in this syntax is a value of the BOOLEAN data type from 355 ASN.1 [X.680]. That is, there are exactly two values: one value 356 representing logically true, and the other representing logically 357 false. The following syntax description gives the OID assigned to 358 this syntax: 360 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 362 The LDAP-specific encoding of a value is the following ABNF: 364 boolean = "TRUE" / "FALSE" 366 3.4 Country String 368 A value in this syntax is two ASN.1 [X.680] printable string characters 369 representing a country. The permitted values are as listed in 370 ISO 3166 [ISO3166]. The following syntax description gives the OID 371 assigned to this syntax: 373 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 375 The LDAP-specific encoding of a value is the following ABNF: 377 CountryString = ALPHA ALPHA 379 Example: US 381 3.5 Delivery Method 383 A value in this syntax is a set of the ASN.1 [X.680] enumerated 384 INTEGER values that indicates, in preference order, the service(s) 385 by which the user, represented by the entry, is willing and/or 386 capable of receiving messages. 388 The following syntax description gives the OID assigned to this 389 syntax: 391 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 393 The LDAP-specific encoding of a value is the following ABNF: 395 delivery-value = pdm / ( WSP pdm SP DOLLAR SP delivery-value ) 397 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 398 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 400 Example: telephone $ videotex 402 3.6 Directory String 404 A value in this syntax is a value of one of the TeletexString, 405 PrintableString or UniversalString data types from ASN.1 [X.680]. 406 The minimum length of a Directory String value is one character, that 407 is, the string cannot be 'empty'. The following syntax description 408 gives the OID assigned to this syntax: 410 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 412 The LDAP-specific encoding of a value is the character string itself. 414 Note: The form of DirectoryString is not indicated in protocol. 415 Servers which convert to DAP MUST choose an appropriate form. 416 Servers MUST NOT reject values merely because they contain legal 417 Unicode characters outside of the range of printable ASCII. 419 Servers and clients MUST be prepared to receive arbitrary Unicode 420 characters, including characters not presently assigned to any 421 character set. 423 Example: 424 This is a string of DirectoryString containing #!%#@. 426 For characters in the PrintableString form, the value in the native 427 LDAP encoding is the value itself. 429 If the string is in the TeletexString form, then the characters are 430 transliterated to their equivalents in UniversalString, and encoded 431 in UTF-8 [RFC2044]. 433 If the string is in the UniversalString or BMPString forms [ISO10646], 434 UTF-8 is the LDAP-specific encoding. 436 3.7 DIT Content Rule Description 438 The following syntax description gives the OID assigned to this 439 syntax: 441 ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule 442 Description' ) 444 This syntax is the form in which schema content rules are published 445 in the directory in a subentry. 447 A value in this syntax is a definition of a DIT content rule 448 according to the ABNF in [Models]. 450 The native LDAP encoding of a value is the character string 451 (DirectoryString) itself. 453 Note: The form of DirectoryString is not indicated in protocol, 454 unless the ;binary option is used (see [Prot]). Servers which 455 convert to DAP MUST choose an appropriate form. Servers MUST NOT 456 reject values merely because they contain legal Unicode characters 457 outside of the range of printable ASCII. 459 Servers and clients MUST be prepared to receive arbitrary Unicode 460 characters, including characters not presently assigned to any 461 character set. 463 Example: 464 This is a string of DirectoryString containing #!%#@. 466 For characters in the PrintableString form, the value in the native 467 LDAP encoding is the value itself. 469 If it is in the TeletexString form, then the characters are 470 transliterated to their equivalents in UniversalString, and encoded 471 in UTF-8 [UTF-8]. 473 If it is in the UniversalString or BMPString forms [ISO10646], UTF-8 474 is the native LDAP encoding. 476 3.8 DIT Structure Rule Description 478 The following syntax description gives the OID assigned to this 479 syntax: 481 ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule 482 Description' ) 484 This syntax is the form in which schema structure rules are published 485 in the directory in a subentry. 487 A value in the DIT Structure Rule Description syntax is a definition 488 of a schema Structure Rule according to the ABNF in [Models]. 490 The LDAP-specific encoding is the character codes in UTF-8 [UTF-8] 491 which correspond to the characters in the structure rule definition. 493 3.9 DN 495 A value in the Distinguished Name syntax is a structured set of the 496 ASN.1 [X.680] data types that are included in the DirectoryString 497 syntax. The following syntax description gives the OID assigned to 498 this syntax: 500 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 502 The LDAP-specific encoding of a value is defined in [LDAPDN]. Note 503 that the LDAP-specific encoding is not reversible to the original BER 504 encoding used in X.500 for Distinguished Names, as the CHOICE of any 505 DirectoryString element in an RDN is not evident in the LDAP-specific 506 encoding.. See the note in section 3.7. 508 Examples (from [LDAPDN]): 510 CN=Steve Kille,O=Isode Limited,C=GB 512 OU=Sales+CN=J. Smith,O=Widget Inc.,C=US 514 CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB 516 CN=Before\0DAfter,O=Test,C=GB 517 1.1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB 519 SN=Lu\C4\8Di\C4\87 521 3.10 Enhanced Guide 523 A value in the Enhanced Guide syntax is the matching criteria and 524 scope of operation in an Enhanced Filter. 526 The following syntax description gives the OID assigned to this syntax: 528 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 530 The LDAP-specific encoding of a value is defined by the 531 following ABNF: 533 EnhancedGuide = SP oid WSP SHARP WSP criteria WSP SHARP 534 WSP subset 536 subset = "baseobject" / "oneLevel" / "wholeSubtree" 538 criteria = or-term / LPAREN or-term RPAREN 540 or-term = and-term *( "|" and-term ) 542 and-term = not-term *( "&" not-term ) 544 not-term = "!" not-term / 545 attributetype DOLLAR match-type / 546 LPAREN or-term RPAREN / 547 "?true" / ; 548 "?false" 550 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 552 The ?true term alternative represents an empty "and" in the Criteria. 553 The ?false alternative represents an empty "or" in the Criteria. 555 Example: 557 person#(sn)#oneLevel 559 3.11 Facsimile Telephone Number 561 A value in the Facsimile Telephone Number syntax is a subscriber 562 number on the (public) telephone network of a facsimile device. The 563 telephone number is a character string based on E.123 [E.123]. The 564 character string type is the PrintableString data type from 565 ASN.1 [X.680]. The following syntax description gives the OID 566 assigned to this syntax: 568 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') 570 The LDAP-specific encoding of a value is defined by the 571 following ABNF: 573 fax-number = printablestring [ "$" faxparameters ] 574 ; telephone number, possibly followed by facsimile 575 ; parameters 577 printablestring = 1*p 579 p = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PLUS / COMMA / 580 HYPHEN / DOT / EQUALS / SLASH / COLON / QUESTION / SPACE 582 faxparameters = faxparm / ( faxparm "$" faxparameters ) 584 faxparm = "twoDimensional" / "fineResolution" / "unlimitedLength" 585 / "b4Length" / "a3Width" / "b4Width" / "uncompressed" 587 3.12 Fax 589 A value in the Fax syntax is an image which is produced using the 590 Group 3 facsimile process [Fax] to duplicate an object, such as 591 a memo. 593 The following syntax description gives the OID assigned to this 594 syntax: 596 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 598 Values in this syntax are expressed as octet strings containing 599 Group 3 Fax images as defined in [Fax]. 601 3.13 Generalized Time 603 A value in the Generalized Time syntax is a date and time. The year 604 is given as a four-digit number. The following syntax description 605 gives the OID assigned to this syntax: 607 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 609 The LDAP-specific encoding is a value of the GeneralizedTime data type 610 from ASN.1 [X.680]. Time zone MUST be present and SHOULD be GMT (Z). 612 Example: 613 199412161032Z means 10:32 a.m. Dec. 16, 1994 in the Greenwich 614 Mean Time time zone. 616 3.14 Guide 618 A value in the Guide syntax is the matching criteria in a Filter. 620 The following syntax description gives the OID assigned to this 621 syntax: 623 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 625 The Guide syntax is not intended to be used for defining new 626 attributes. It is important for backwards compatibility with LDAP 627 systems that implement an earlier version of LDAP [RFC1778]. 629 The LDAP-specific encoding of a value is defined by the 630 following ABNF: 632 guide-value = [ object-class "#" ] criteria 634 object-class = SP oid 636 The criteria production is defined in the Enhanced Guide syntax in 637 section 3.11. 639 3.15 IA5 String 641 A value in the IA5 String syntax is a value of the IA5String data 642 type from ASN.1 [X.680]. International Alphabet 5 (IA5) [IA5] is the 643 international version of the ASCII character set. 645 The following syntax description gives the OID assigned to this 646 syntax: 648 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'IA5 String' ) 650 The LDAP-specific encoding of a value in this syntax is the character 651 string value itself. 653 3.16 Integer 655 A value in the INTEGER syntax is a whole number as specified in the 656 INTEGER data type from ASN.1 [X.680]. 658 The following syntax description gives the OID assigned to this 659 syntax: 661 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 663 The LDAP-specific encoding of a value is the decimal representation of 664 the value, with each decimal digit represented by the its character 665 equivalent. So, the number 1321 is represented by the character 666 string "1321". 668 3.17 JPEG 670 A value in the JPEG syntax is an image produced according to 671 specific rules for light values. The following syntax description 672 gives the OID assigned to this syntax: 674 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 676 The LDAP-specific encoding of a value is an octet string of the 677 light values representing the image. 679 3.18 LDAP Syntax Description 681 A value in the LDAP Syntax Description syntax is a definition of a 682 LDAP syntax description according to the ABNF given in [MODELS]. 684 This syntax is the form in which schema syntax descriptions are 685 published in the directory in a subentry. The following syntax 686 description gives the OID assigned to this syntax: 688 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 690 Note that, in X.520 [Attr], syntaxes are not labeled distinctly 691 with respect to attributes. 693 The LDAP-specific encoding is the character codes in UTF-8 [ISO10646] 694 which correspond to the characters in the definition. 696 3.19 Matching Rule Description 698 A value in the Matching Rule Description syntax is a definition of 699 a matching rule according to the ABNF given in [MODELS]. This syntax 700 is the form in which schema matching rules are published in the 701 directory in a subentry. The following syntax definition gives the 702 OID assigned to this syntax: 704 ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Description' ) 706 The LDAP-specific encoding is the character codes in UTF-8 [ISO10646] 707 which correspond to the characters in the definition of a Matching 708 Rule. 710 3.20 Matching Rule Use Description 712 A value in the Matching Rule Use Description syntax is a definition 713 of a matching Rule and the attribute types with which the rule could 714 be used in an extensibleMatch search filter. The values are 715 specified according to the ABNF given in [MODELS]. The following 716 syntax description gives the OID assigned to this syntax: 718 ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use 719 Description' ) 721 This syntax is the form in which schema matching rule usage 722 permissions are published in the directory in a subentry. 724 The LDAP-specific encoding is the character codes in UTF-8 [ISO10646] 725 which correspond to the characters in the definition. 727 3.21 MHS OR Address 729 A value in the MHS OR Address syntax is the addressing information of 730 a user of an X.400 messaging service. The LDAP-specific encoding is 731 defined in RFC 1327 [RFC1327]. 733 The following syntax description gives the OID assigned to this 734 syntax: 736 ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) 738 3.22 Name and Optional UID 740 A value of the Name and Optional UID (Unique IDentifier) syntax is a 741 Distinguished Name as defined in section 3.9 plus a bit string 742 that differentiates the value from otherwise identical names. The following syntax description gives the OID assigned to this 743 syntax: 745 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 747 The LDAP-specific encoding of a value is the following ABNF: 749 NameAndOptionalUID = DistinguishedName [ "#" bitstring ] 751 Although the '#' character could occur in a string representation of 752 a distinguished name, no additional special quoting is done. 754 Example: 755 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 757 3.23 Name Form Description 759 A value in the Name Form Description syntax is a definition of a 760 Name Form according to the ABNF given in [MODELS]. 762 A value indicates the one or more attributes in an entry type (e.g., 763 person, device) that are used as the Relative Distinguished Name of 764 the entrY. 766 This syntax is the form in which schema name forms are published in 767 the directory. The LDAP-specific encoding of a value is the 768 character codes in UTF-8 [ISO10646] which correspond to the 769 characters in the definition. 771 The following syntax description gives the OID assigned to this 772 syntax: 774 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 776 3.24 Numeric String 778 A value in the Numeric String syntax is a series of numerals and 779 spaces as specified in the NumericString data type from 780 ASN.1 [X.680]. The following string states the OID assigned to 781 this syntax: 783 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 785 The representation of a string in this syntax is the string value 786 itself. 788 Example: 1997 790 3.25 Object Class Description 792 A value in this syntax is a character string which expresses the 793 definition of an object class according to the ABNF given in 794 [MODELS]. This syntax is the form in which schema object classes 795 are published in the directory in a subentry. The following string 796 states the OID assigned to this syntax: 798 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 800 For example, the character string below specifies the country object 801 class, which requires the c (country name) attribute and allows the 802 searchGuide and description attributes. All of these schema 803 elements are specified in [Schema]. 805 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 806 MAY ( searchGuide $ description ) ) 808 3.26 Octet String 810 A value in the Octet String syntax is a value of the OCTET STRING 811 data type from ASN.1 [X.680]. The following string states the OID 812 assigned to this syntax: 814 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 816 Values in this syntax are written as a series of 8-bit values, 817 according to the octet string value notation specified in [X.680]. 818 In the case of character strings, the characters themselves could be 819 written. 821 Example: 822 secret 824 3.27 OID 826 A value in the Object Identifier syntax is a series of integers, 827 ordered as specified in the OBJECT IDENTIFIER data type from ASN.1 828 [X.680]. The following string states the OID assigned to this 829 syntax: 831 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 833 Values in this syntax are expressed according to the ABNF in 834 [MODELS], section 1.3 for "oid". 836 Examples: 1.2.3.4 837 cn 839 3.28 Other Mailbox 841 A value in the Other Mailbox syntax gives a mail system name with 842 the name of a mailbox in the system. The following string states 843 the OID assigned to this syntax: 845 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 847 Values in this syntax are written according to the following ABNF: 849 otherMailbox = mailbox-type DOLLAR mailbox 851 mailbox-type = printableString 853 mailbox = 855 The printableString production is defined in section 3.11. 857 In the above, mailbox-type represents the type of mail system in 858 which the mailbox resides, for example "MCIMail"; and mailbox is 859 the actual mailbox in the mail system defined by mailbox-type. 861 The representation of a string in this syntax is the string value 862 itself. 864 3.29 Postal Address 866 A value in the Postal Address syntax is a series of strings which 867 form an address in a physical mail system. The following string 868 states the OID assigned to this syntax: 870 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 872 Values in this syntax are written according to the following ABNF: 874 postal-address = dstring *( DOLLAR dstring ) 876 In the above, each dstring component of a postal address value is 877 written as a value of type Directory String syntax. Backslashes and 878 dollar characters, if they occur in the component, are quoted as 879 described in [MODELS]. Many servers limit the postal address to 880 six lines of up to thirty characters. 882 Example: 884 1234 Main St.$Anytown, CA 12345$USA 885 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 887 3.30 Presentation Address 889 A value in the Presentation Address syntax is an OSI Application 890 Layer address of a remote application. Logically, a presentation 891 address consists of: 893 o A presentation selector 895 o A session selector 897 o A transport selector 899 o A set of network addresses 901 The following string states the OID assigned to this syntax: 903 ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) 905 Values in this syntax are written according to the following ABNF: 907 presentation-address = [[[ psel "/" ] ssel "/" ] tsel "/" ] 908 network-address-list 910 psel = selector 911 ssel = selector 912 tsel = selector 914 network-address-list = network-address USCORE 915 network-address-list / network-address 917 network-address = "NS" PLUS dothexstring 918 / afi PLUS idi [ PLUS dsp ] 919 / idp PLUS hexstring 921 The first (NS) alternative is the Concrete Binary Representation. 922 It is the compact encoding. 924 The afi alternative is a user-oriented representation of a network 925 address. 927 The idp alternative is a form of network-address included for 928 compatibility with ISO 8348 [ISO8348]. 930 selector = DQUOTE otherstring DQUOTE 931 / SHARP numericstring 932 / SQUOTE hexstring "'H" 933 / "" 935 The otherstring alternative for the selector is IA5 characters. 937 The "" alternative for the selector expresses the case where the 938 selector is present, but Empty. 940 idp = numericstring 941 dsp = "d" numericstring 942 / "x" dothexstring 943 / "l" otherstring 944 / "RFC-1006" PLUS prefix PLUS ip [ PLUS port [ PLUS tset ]] 945 / "X.25(80)" PLUS prefix PLUS dte [ PLUS cudf-or-pid PLUS 946 hexstring ] 947 / "ECMA-117-Binary" PLUS hexstring PLUS hexstring PLUS 948 hexstring / "ECMA-117-Decimal" PLUS numericstring PLUS 949 numericstring PLUS numericstring 951 The d alternative is the Abstract Decimal form of the Domain 952 Specific Part (dsp) in a network address. 954 The x alternative is the Abstract Binary form of the dsp in a 955 network address. 957 The l alternative is IA5 characters and is only meaningful locally. 959 idi = numericstring 961 afi = "X121" / "DCC" / "TELEX" / "PSTN" / "ISDN" / "ICD" / "LOCAL" 963 prefix = DIGIT DIGIT 965 ip = numericstring 966 ; dotted decimal form (e.g., 10.0.0.6) or 967 domain (e.g., twg.com) 969 port = numericstring 971 tset = numericstring 973 dte = numericstring 975 cudf-or-pid = "CUDF" / "PID" 977 other = keychar / PLUS / DOT 979 domainchar = keychar / DOT 981 hexoctet = HEX HEX 983 decimal-octet = 1*3DIGIT 985 otherstring = other otherstring / other 987 domainstring = domainchar otherstring / domainchar 989 hexstring = hexoctet hexstring / hexoctet 991 dotstring = decimaloctet DOT dotstring / 992 decimaloctet DOT decimaloctet 994 dothexstring = dotstring / hexstring 996 3.31 Printable String 998 A value in the Printable String syntax is a series of alphabetic, 999 numeric, and (limited) punctuation characters as specified in the 1000 PrintableString data type from ASN.1 [X.680] and in production p of 1001 section 3.11. Values in this syntax are expressed as the string 1002 itself. The following string states the OID assigned to this syntax: 1004 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 1006 Example: This is a PrintableString. 1008 3.32 Substring Assertion 1010 The Substring Assertion syntax is used in rules which can be used in 1011 substrings and extensible matching rules. When using a substrings 1012 assertion, substrings components are provided in a SubstringFilter 1013 sequence. The following string states the OID assigned to this 1014 syntax: 1016 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1018 When using a matching rule assertion, substring components are 1019 encoded according to the following ABNF and provided as the 1020 matchValue of the MatchingRuleAssertion: 1022 substring = [initial] any [final] 1024 initial = value 1026 any = "*" *(value "*") 1028 final = value 1030 The production is a UTF-8 [ISO10646] string. If a backslash or 1031 asterix character is present in a production of , it is 1032 quoted as described in [MODELS]. 1034 3.33 Telephone Number 1036 A value in the telephone number syntax is the series of characters 1037 that express a number (address) assigned to a telephone system 1038 subscriber. The following string states the OID assigned to this 1039 syntax: 1041 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1043 Values in this syntax are written as if they were ASN.1 [X.680] 1044 Printable String types. Telephone numbers are defined in X.520 1045 [X.520] to comply with the internationally agreed format for 1046 expressing international telephone numbers in Recommendation 1047 E.123 [E.123]. 1049 The representation of a string in this syntax is the string value 1050 itself. 1052 Example: +1 512 315 0280 1054 3.34 Teletex Terminal Identifier 1056 A value in this syntax is a string of characters that express the 1057 identifier value assigned to a teletex service subscriber. The 1058 following string states the OID assigned to this syntax: 1060 ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal 1061 Identifier' ) 1063 Values in this syntax are written according to the following ABNF: 1065 teletex-id = ttx-term 0*("$" ttx-param) 1067 ttx-term = printablestring 1069 ttx-param = ttx-key ":" ttx-value 1071 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1073 ttx-value = octetstring 1075 In the above, the first printablestring is the encoding of the first 1076 portion of the teletex terminal identifier to be encoded, and the 1077 subsequent 0 or more octetstrings are subsequent portions of the 1078 teletex terminal identifier. 1080 The representation of a string in this syntax is the string value 1081 itself. 1083 3.35 Telex Number 1085 A value in the Telex Number syntax is the number assigned to a telex 1086 system subscriber with the country and answerback values indicated. 1088 The following string states the OID assigned to this syntax: 1090 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1092 Values in this syntax are written according to the following ABNF: 1094 telex-number = actual-number "$" country "$" answerback 1096 actual-number = printablestring 1098 country = printablestring 1100 answerback = printablestring 1102 In the above, actual-number is the syntactic representation of the 1103 number portion of the TELEX number being written, country is the 1104 TELEX country code, and answerback is the answerback code of a TELEX 1105 terminal. 1107 The representation of a string in this syntax is the string value 1108 itself. 1110 3.36 UTC Time 1112 A value in the UTC Time syntax is a date and time indicating accuracy 1113 to minute or second. The year is given as a two-digit number. The 1114 following string states the OID assigned to this syntax: 1116 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1118 Values in this syntax are written as if they were printable strings, 1119 formulated as specified for the UTCTime data type in ASN.1 [X.680]. 1120 It is strongly suggested that GMT time be used. 1122 Note: This syntax is deprecated in favor of the Generalized Time 1123 syntax. 1125 4. Matching Rules 1127 When performing the caseExactMatch, caseIgnoreMatch, 1128 caseIgnoreListMatch, telephoneNumberMatch, caseExactIA5Match and 1129 caseIgnoreIA5Match, multiple adjoining whitespace characters are 1130 treated the same as an individual space, and leading and trailing 1131 whitespace is ignored. 1133 4.1 bitStringMatch 1135 The following ABNF associates the bitStringMatch rule with the Bit 1136 String syntax: 1138 ( 2.5.13.16 NAME 'bitStringMatch' 1139 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) ; Bit String 1141 This matching rule is used to test equality. 1143 4.2 caseExactIA5Match 1145 The following ABNF associates the caseExactIA5Match rule with the IA5 1146 String syntax: 1148 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1149 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String 1151 This matching rule is used to test equality. 1153 4.3 caseIgnoreIA5Match 1155 The following ABNF associates the caseIgnoreIA5Match rule with the 1156 IA5 String syntax: 1158 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1159 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ; IA5 String 1161 This matching rule is used to test equality. 1163 4.4 caseIgnoreListMatch 1165 The ABNF below associates the caseIgnoreListMatch rule with the 1166 Postal Address syntax. The X.520 [X.520] syntax for this matching 1167 rule is a SEQUENCE Of DirectoryString. Since the Postal Address 1168 syntax is such a sequence, it is used in defining the matching rule 1169 for LDAP, although the matching rule can be used with any SEQUENCE 1170 OF DirectoryString syntax/assertion. 1172 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1173 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ; Postal Address 1175 This matching rule is used to test equality. 1177 4.5 caseIgnoreMatch 1179 The following ABNF associates the caseIgnoreMatch rule with the 1180 Directory String syntax: 1182 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1183 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String 1185 This matching rule is used to test equality. 1187 4.6 caseIgnoreOrderingMatch 1189 The following ABNF associates the caseIgnoreOrderingMatch rule with 1190 the Directory String syntax: 1192 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1193 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ; Directory String 1195 This matching rule is used to test inequality, i.e., greaterOrEqual 1196 or lessOrEqual. 1198 The sort ordering for a caseIgnoreOrderingMatch is implementation- 1199 dependent. 1201 4.7 caseIgnoreSubstringsMatch 1203 The following ABNF associates the caseIgnoreSubstringsMatch rule with 1204 the Substring Assertion: 1206 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1207 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1209 This matching rule is used to test substrings equality. 1211 4.8 distinguishedNameMatch 1213 The following ABNF associates the distinguishedNameMatch rule with 1214 the DN syntax: 1216 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1217 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ; DN 1219 This matching rule is used to test equality. 1221 4.9 generalizedTimeMatch 1223 The following ABNF associates the generalizedTimeMatch rule with the 1224 Generalized Time syntax: 1226 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1227 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ; Generalized Time 1229 This matching rule is used to test equality. 1231 4.10 generalizedTimeOrderingMatch 1233 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1234 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ; Generalized Time 1236 This matching rule is used to test inequality, i.e., greaterOrEqual 1237 or lessOrEqual. 1239 4.11 integerFirstComponentMatch 1241 The following ABNF associates the integerFirstComponentMatch rule 1242 with the INTEGER syntax: 1244 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1245 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER 1247 Implementors, note that the assertion syntax of this matching 1248 rule, an INTEGER, is different from the value syntax of attributes 1249 for which this is the equality matching rule. 1251 This matching rule is used to test equality with the first component 1252 in a compound syntax. 1254 4.12 integerMatch 1256 The following ABNF associates the integerMatch rule with the INTEGER 1257 syntax: 1259 ( 2.5.13.14 NAME 'integerMatch' 1260 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ; INTEGER 1262 This matching rule is used to test equality. 1264 4.13 numericStringMatch 1266 The following ABNF associates the numericStringMatch rule with the 1267 Numeric String syntax: 1269 ( 2.5.13.8 NAME 'numericStringMatch' 1270 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) ; Numeric String 1272 This matching rule is used to test equality. 1274 4.14 numericStringSubstringsMatch 1276 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1277 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1279 This matching rule is used to test substrings equality. 1281 4.15 objectIdentifierFirstComponentMatch 1283 The following ABNF associates the 1284 objectIdentifierFirstComponentMatch rule with the OID syntax: 1286 ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' 1287 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID 1289 If the client supplies an extensible filter using an 1290 objectIdentifierFirstComponentMatch whose matchValue is in the 1291 "descr" form, and the OID is not recognized by the server, then the 1292 filter is Undefined. 1294 This matching rule is used to test equality with the first component 1295 in a compound syntax. 1297 4.16 objectIdentifierMatch 1299 The following ABNF associates the objectIdentifierMatch rule with the 1300 OID syntax: 1302 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1303 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ; OID 1305 This matching rule is used to test equality. 1307 Implementors, note that the assertion syntax of this matching 1308 rule, an OID, is different from the value syntax of attributes for 1309 which this is the equality matching rule. 1311 If the client supplies a filter using an objectIdentifierMatch whose 1312 matchValue oid is in the "descr" form, and the oid is not recognized 1313 by the server, then the filter is Undefined. 1315 4.17 octetStringMatch 1317 Servers which implement the extensibleMatch filter SHOULD allow the 1318 matching rule listed in this section to be used in the 1319 extensibleMatch. In general these servers SHOULD allow matching 1320 rules to be used with all attribute types known to the server, when 1321 the assertion syntax of the matching rule is the same as the value 1322 syntax of the attribute. 1324 The Octet String Match rule compares for equality an asserted octet 1325 string with an attribute value of type OCTET STRING. 1327 The strings match if they are the same length and corresponding 1328 octets are identical. 1330 The following ABNF associates the octetStringMatch rule with 1331 the OCTET STRING syntax: 1333 ( 2.5.13.17 NAME 'octetStringMatch' 1334 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1336 4.18 presentationAddressMatch 1338 The following ABNF associates the presentationAddressMatch rule with 1339 the Presentation Address syntax: 1341 ( 2.5.13.22 NAME 'presentationAddressMatch' 1342 SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) ; Presentation Address 1344 This matching rule is used to test equality. 1346 4.19 protocolInformationMatch 1348 The following ABNF associates the protocolInformationMatch rule with 1349 the Protocol Information syntax: 1351 ( 2.5.13.24 NAME 'protocolInformationMatch' 1352 SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) ; Protocol Information 1354 This matching rule is used to test equality. 1356 4.20 telephoneNumberMatch 1358 The following ABNF associates the telephoneNumberMatch rule with the 1359 Telephone Number syntax: 1361 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1362 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) ; Telephone Number 1364 This matching rule is used to test equality. 1366 4.21 telephoneNumberSubstringsMatch 1368 The following ABNF associates the telephoneNumberSubstringsMatch rule 1369 with the Substring Assertion syntax: 1371 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 1372 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ; Substring Assertion 1374 This matching rule is used to test substrings equality. 1376 4.22 uniqueMemberMatch 1378 The following ABNF associates the uniqueMemberMatch rule with the 1379 Name and Optional UID syntax: 1381 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1382 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) ; Name And Optional UID 1384 This matching rule is used to test equality. 1386 5. Security Considerations 1388 5.1 Disclosure 1390 Attributes of directory entries are used to provide descriptive 1391 information about the real-world objects they represent, which can 1392 be people, organizations or devices. Most countries have privacy 1393 laws regarding the publication of information about people. 1395 5.2 Security Information Syntaxes 1397 Several X.500 attributes, such as, the userCertificate attribute, 1398 are used to include key-based security information in directory 1399 entries. The attribute syntaxes for these attributes are: 1401 Certificate 1402 CertificateList 1403 CertificatePair 1404 SupportedAlgorithm 1406 These syntaxes are specified for LDAP by the PKIX Working Group, and 1407 so, are not included in this document. 1409 The ABNF specifications of "User Certificate", "Authority Revocation 1410 List", and "Certificate Pair" in RFC 1778 [RFC1778] are not to 1411 be used. 1413 5.3 Securing the Directory 1415 In order to protect the directory and its contents, strong 1416 authentication MUST have been used to identify the Client when an 1417 update operation is requested. 1419 6. Acknowledgements 1421 This document is an update of RFC 2252 by M. Wahl, A. Coulbeck, 1422 T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID 1423 Working Group. 1425 This document is based upon input of the IETF LDAPBIS working group. 1426 The authors wish to thank J. Sermersheim and K. Zeilenga for their 1427 significant contribution to this update. 1429 7. Authors' Addresses 1431 Kathy Dally 1432 The MITRE Corp. 1433 7515 Colshire Dr., ms-W650 1434 McLean VA 22102 1435 USA 1437 Phone: +1 703 883 6058 1438 Fax: +1 703 883 7142 1439 Email: kdally@mitre.org 1441 Steven Legg 1442 Adacel Technologies Ltd. 1443 405-409 Ferntree Gully Road 1444 Mount Waverley, Victoria 3149 1445 AUSTRALIA 1447 Phone: +61 3 9451 2107 1448 Fax: +61 3 9541 2121 1449 EMail: steven.legg@adacel.com.au 1451 8. References 1453 8.1 Normative 1455 [ABNF] Crocker, D., Overell, P., "Augmented BNF for Syntax 1456 Specifications: ABNF", RFC 2234, November 1997 1458 [E.123] Notation for national and international telephone numbers, 1459 ITU-T Recommendation E.123, 1988. 1461 [IA5] International Reference Alphabet (IRA) (Formerly International 1462 Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded 1463 Character Set for Information Interchange, ITU-T Recommendation 1464 T.50, 1992 1466 [ISO3166] ISO 3166, "Codes for the representation of names 1467 of countries". 1469 [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) - 1470 Architecture and Basic Multilingual Plane, 1471 ISO/IEC 10646-1: 1993 (with amendments). 1473 [JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton, 1474 C-Cube Microsystems, Milpitas, CA, September 1, 1992. 1476 [LDAPDN] K. Zeilenga (editor), "LDAP: String Representation of 1477 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, (a 1478 work in progress). 1480 [Protocol] J. Sermersheim (editor), "LDAP: The Protocol", 1481 draft-ietf-ldapbis-protocol-xx.txt, a work in progress. 1483 [RFC1327] Hardcastle-Kille, S., "Mapping between X.400(1988)/ 1484 ISO 10021 and RFC 822", RFC 1327, May 1992. 1486 [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode 1487 and ISO 10646", RFC 2044, October 1996. 1489 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1490 Requirement Levels", RFC 2119, March 1997. 1492 [RFC 2256] draft-ietf-ldapbis-user-schema-xx, replacement for Wahl, M., 1493 "A Summary of the X.500(96) User Schema for use with LDAPv3", 1494 RFC 2256, December 1997. 1496 [T.4] Standardization of Group 3 facsimile apparatus for document 1497 transmission - Terminal Equipment and Protocols for Telematic 1498 Services, ITU-T Recommendation T.4, 1993 1500 [X.501] The Directory: Models, ITU-T Recommendation X.501, 1993. 1502 [X.520] The Directory: Selected Attribute Types. ITU-T 1503 Recommendation X.520, 1993. 1505 [X.680] Information Technology - Abstract Syntax Notation One 1506 (ASN.1): Specification of Basic Notation, ITU-T Recommendation 1507 X.680, 1994 1509 8.2 Informative References 1511 [ISO8348] Information technology -- Open Systems Interconnection -- 1512 Network Service Definition, ISO/IEC 8348:1996 1514 [RFC1777] Yeong, W., Howes, T., Kille, S., "Lightweight Directory 1515 Access Protocol", RFC 1777, March 1995 1517 [RFC1778] Howes, T., Kille, S., Yeong, W., Robbins, C., "The 1518 String Representation of Standard Attribute Syntaxes", RFC 1778, 1519 March 1995. 1521 [RFC2253] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory 1522 Access Protocol (v3): UTF-8 String Representation of 1523 Distinguished Names", RFC 2253, December 1997. 1525 9. Full Copyright Statement 1527 Copyright (C) The Internet Society (2002). All Rights Reserved. 1529 This document and translations of it may be copied and furnished to 1530 others, and derivative works that comment on or otherwise explain it 1531 or assist in its implementation may be prepared, copied, published 1532 and distributed, in whole or in part, without restriction of any 1533 kind, provided that the above copyright notice and this paragraph 1534 are included on all such copies and derivative works. However, this 1535 document itself may not be modified in any way, such as by removing 1536 the copyright notice or references to the Internet Society or other 1537 Internet organizations, except as needed for the purpose of 1538 developing Internet standards in which case the procedures for 1539 copyrights defined in the Internet Standards process must be 1540 followed, or as required to translate it into languages other 1541 than English. 1543 The limited permissions granted above are perpetual and will not be 1544 revoked by the Internet Society or its successors or assigns. 1546 This document and the information contained herein is provided on an 1547 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1548 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1549 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1550 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1551 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1553 Annex A Object Identifiers of Syntaxes 1555 This list contains the object identifiers for the syntaxes used in 1556 this specification and in the user schema specification [User]. 1558 Syntax of Value Represented OBJECT IDENTIFIER 1559 ===================================================================== 1560 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 1561 Bit String 1.3.6.1.4.1.1466.115.121.1.6 1562 Boolean 1.3.6.1.4.1.1466.115.121.1.7 1564 Country String 1.3.6.1.4.1.1466.115.121.1.11 1566 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 1567 Directory String 1.3.6.1.4.1.1466.115.121.1.15 1568 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 1569 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 1570 DN 1.3.6.1.4.1.1466.115.121.1.12 1571 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 1572 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 1573 Fax 1.3.6.1.4.1.1466.115.121.1.23 1575 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 1576 Guide 1.3.6.1.4.1.1466.115.121.1.25 1577 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 1578 INTEGER 1.3.6.1.4.1.1466.115.121.1.27 1579 JPEG 1.3.6.1.4.1.1466.115.121.1.28 1581 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 1582 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.31 1583 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 1584 MHS OR Address 1.3.6.1.4.1.1466.115.121.1.33 1585 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 1586 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 1587 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 1588 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 1589 Octet String 1.3.6.1.4.1.1466.115.121.1.40 1590 OID 1.3.6.1.4.1.1466.115.121.1.38 1591 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 1592 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 1593 Presentation Address 1.3.6.1.4.1.1466.115.121.1.43 1594 Printable String 1.3.6.1.4.1.1466.115.121.1.44 1595 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 1596 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 1597 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 1598 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 1599 UTC Time 1.3.6.1.4.1.1466.115.121.1.53 1600 Annex B Topics Yet To Be Addressed In This Document 1602 This appendix is provided for informational purposes only, it is not 1603 a normative part of this specification. 1605 APPEARED: -00 1606 Paragraph 2.2.3 - Should any syntaxes listed in the table be removed? 1607 Should any new syntaxes be added? 1608 RESOLUTION: Cannot add syntaxes. Moving the table to an annex keeps 1609 a record of the OIDS that have been assigned. Deleted unspecified 1610 syntaxes from the list. APPLIED: -02 1612 APPEARED: -00 1613 Paragraph 2.2.4 - Should attribute syntaxes be allowed to be referenced 1614 by a common name, and if so, where should the name come from? 1615 RESOLUTION: Rejected because of adding functionality. APPLIED: -01 1617 APPEARED: -00 1618 How does the data model draft affect 1619 this draft? 1620 RESOLUTION: It does not. The draft was preliminary to the revised 1621 Schema and Protocol I-Ds. APPLIED: -01 1623 APPEARED: -00 1624 Section 3 - Should all listed syntaxes from paragraph 2.2.3 be 1625 detailed in this section? Nearly half the listed syntaxes are not 1626 referenced in this section. 1627 RESOLUTION: No, because many are not being used, currently. 1628 APPLIED: -01 1630 APPEARED: -01 1631 Section 4 - Should all of the X.520(1993) matching rules be included? 1632 In particular, how about caseExactMatch? Also, should 1633 octetStringMatch be moved from updated RFC 2256? 1634 RESOLUTION: caseExactMatch not included. octetStringMatch moved to 1635 this document. APPLIED: -01 1637 APPEARED: -00 1638 Section 6 - Recognized list of Object classes needs to be reconciled 1639 with updated RFC 2256 and the data model draft. 1640 RESOLUTION: Not necessary. APPLIED: -01 1642 APPEARED: -00 1643 Section 7 - Proper security statement needs to be formulated. 1644 RESOLUTION: Text has been expanded since RFC 2252, but needs 1645 more work. APPLIED: 1647 Annex C Change Log 1649 This annex lists the changes that have been made from RFC 2252 to 1650 this specification. 1652 This annex is provided for informational purposes only. It is not 1653 a normative part of this specification. Items 32 - end are new in 1654 the -02 version of this document. 1656 ------- 1657 -00 changes 1659 1. Removed the IESG Note. 1661 2. Changed "types" to "syntaxes" in the last sentence of the 1662 Abstract. Also, added to the last sentence in order to 1663 indicate that syntaxes are not the only schema elements 1664 defined in this document. 1666 3. Reorganized the sections so that: 1668 * the schema element categories are specified in the 1669 order in which they build on one another: syntaxes, 1670 matching rules, attributes, object classes 1672 * within each category the elements are specified in 1673 alphbetical order 1675 4. Added an "Implementation Status" paragraph for each element, 1676 gathering the conformance statements. 1678 5. Clarified schema description in the Overview. 1680 6. Changed the "Common Encoding Aspects" section title to 1681 "Notation" and made corresponding changes throughout the 1682 document. The purpose being to relegate all encoding issues 1683 to the Protocol specification [Protocol]. 1685 7. Added a MUST statement regarding the syntaxes required of 1686 servers. 1688 8. Expanded the discussion of each of the syntaxes in section 3. 1690 9. Added examples to some of the syntax descriptions. 1692 10. Added NAME option to the syntax description ABNF 1693 in 2.2.4. 1695 RESCINDED IN -01!! 1697 11. Added a note deprecating the UTCTime attribute syntax 1698 description in 3.41 1700 12. In the ABNF of the MatchingRuleDescription in paragraph 2.3.2, 1701 replaced "numericoid" with "oid". 1703 13. In paragraph 2.4.1, replaced the conformance statement about 1704 attributes in 2256 with a reference. 1706 14. Added caseIgnoreIA5Match as the EQUALITY matching rule for 1707 the altServer attribute type ABNF in paragraph 5.1. Note that 1708 this could be caseExactIA5Match instead. SHOULD IT BE?? 1710 RESCINDED IN -01 1712 15. In paragraphs 5.10 and 5.11, changed "the MODIFY operation" 1713 to "LDAP update operations" 1715 16. Added distinguishedNameMatch as the EQUALITY matching rule 1716 for the namingContexts attribute type ABNF in paragraph 5.13. 1718 RESCINDED IN -01 1720 17. Reworded paragraph 5.15. 1722 18. Added distinguishedNameMatch as the EQUALITY matching rule 1723 for the namingContexts attribute type ABNF in paragraph 5.13. 1725 RESCINDED IN -01 1727 19. Added integerMatch as the EQUALITY and integerOrderingMatch 1728 as the Ordering matching rules for the supportedLDAPVersion 1729 attribute type ABNF in paragraph 5.18. 1731 RESCINDED IN -01 1733 20. Added caseIgnoreMatch as the EQUALITY matching rule for the 1734 supportedSASLMechanisms attribute type ABNF in paragraph 5.19. 1735 Note that this could be caseExactMatch instead. SHOULD 1736 IT BE?? 1738 RESCINDED IN -01 1740 21. Made corrections to the ABNF in paragraph 3.12. 1742 22. Added the seven syntax definitions from RFC 2256 and ordered 1743 the definitions alphabetically. 1745 23. Changed the "Bibliography" section title to "References". 1747 24. Replaced the X.208 reference with one to X.680(1994), since 1748 X.680 is the ASN.1 referred to in the X.500(1993)-series. 1750 ------- 1751 -01 changes 1753 25. Moved the table listing the syntaxes and their oids from 1754 paragraph 2.2.3 to a new Annex A. 1756 REMOVED SYNTAXES NOT DEFINED IN THIS I-D FROM THE LIST - 02 1758 26. Moved the specification of the octetStringMatch matching rule 1759 from RFC 2256 to section 4 of this document. 1761 27. Throughout this I-D, cleaned up whitespace in the ABNF definitions. 1763 28. In Section 2.1: 1764 * Corrected the characters defined in the p rule to match 1765 the PrintableString syntax. 1766 * Deleted the letterstring rule. 1767 * Modified the utf8 and dstring rules according to a 1768 suggestion from K. Zeilenga. 1769 * Deleted ";" from the keychar rule, which affects the 1770 anhstring, keystring, and descr rules. 1771 * Removed the length option from the numericoid rule 1773 29. In section 2.2, deleted the sentence about needing a new OID 1774 when a syntax is modified. 1776 30. In section 2.2, replaced the editor's proposal and subject 1777 text with explanation of the LDAP-specific encoding of 1778 attribute values. 1780 31. Removed section 2.2.2 (and renumbered the remainder of 1781 section 2.2), leaving the description of binary encoding to 1782 the protocol I-D. 1784 ------- 1785 -02 changes 1787 32. Revised specifications to use ABNF [ABNF] instead of BNF 1788 throughout the document. 1790 33. Removed embedded comments from the ABNF productions 1791 throughout the document. 1793 34. Removed the Binary syntax because it was not adequately 1794 specified, implementations with different interpretations 1795 exist, and it was confused with the ;binary transfer encoding. 1797 35. Removed the syntaxes, which are not defined in this document, 1798 from the list in Annex A. Consult RFC 2252 for the 1799 assignments made previously for syntaxes that have not been 1800 defined to date. 1802 36. Inserted the specification of the octetstring production, from 1803 RFC 2234 [ABNF].j 1805 37. Cleaned up the references; adopted word instead of number 1806 tags; split Section 10 into normative and informative 1807 subsections. 1809 38. Inserted ABNF from RFC 1278 in place of a reference. 1811 39. Deleted the certificate-related syntaxes and noted in the 1812 Security Considerations (Section 7) that they are covered 1813 in PKIX WG documents. 1815 ------- 1816 -03 changes 1818 40. Removed all discussion of transfer options and the binary option. 1820 41. Aligned the text to the [MODELS] document.