idnits 2.17.1 draft-ietf-ldapbis-syntaxes-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2227. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2195), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 11. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 45 longer pages, the longest (page 8) being 76 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 48 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 47 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2252, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC2256, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack 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 (21 May 2004) is 7279 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) -- Looks like a reference, but probably isn't: '3' on line 584 == Missing Reference: 'ISO8601' is mentioned on line 593, but not defined == Missing Reference: 'RFC3383' is mentioned on line 888, but not defined ** Obsolete undefined reference: RFC 3383 (Obsoleted by RFC 4520) ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3383 (ref. 'BCP64') (Obsoleted by RFC 4520) -- 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. 'PROT' -- Possible downref: Non-RFC (?) normative reference: ref. 'FAX' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166' -- Possible downref: Non-RFC (?) normative reference: ref. 'UCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'JPEG' -- No information found for draft-ietf-ldapbis-roadmap-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ROADMAP' -- No information found for draft-ietf-ldapbis-models-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MODELS' -- No information found for draft-ietf-ldapbis-strprep-xx - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PREP' -- Obsolete informational reference (is this intentional?): RFC 2252 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4523) -- Obsolete informational reference (is this intentional?): RFC 2256 (Obsoleted by RFC 4510, RFC 4512, RFC 4517, RFC 4519, RFC 4523) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) -- No information found for draft-ietf-ldapbis-user-schema-xx - is the name correct? -- No information found for draft-ietf-pkix-ldap-pki-schema-xx - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Legg, Editor 3 draft-ietf-ldapbis-syntaxes-08.txt Adacel Technologies 4 Intended Category: Standards Track K. Dally 5 Obsoletes: RFC 2252, RFC 2256 The MITRE Corp. 6 21 May 2004 8 Lightweight Directory Access Protocol (LDAP): 9 Syntaxes and Matching Rules 11 Copyright (C) The Internet Society (2004). All Rights Reserved. 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress". 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This document is intended to be, after appropriate review and 35 revision, submitted to the RFC Editor as a Standard Track document. 36 Distribution of this document is unlimited. Technical discussion of 37 this document should take place on the IETF LDAP Revision Working 38 Group (LDAPbis) mailing list . Please 39 send editorial comments directly to the editor 40 . 42 This Internet-Draft expires on 21 November 2004. 44 Abstract 46 Each attribute stored in a Lightweight Directory Access Protocol 47 (LDAP) directory, and whose values may be transfered in the LDAP 48 protocol, has a defined syntax which constrains the structure and 49 format of its values. The comparison semantics for values of a 50 syntax are not part of the syntax definition but are instead provided 51 through separately defined matching rules. Matching rules specify an 52 argument, an assertion value, which also has a defined syntax. This 53 document defines a base set of syntaxes and matching rules for use in 54 defining attributes for LDAP directories. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. General Considerations . . . . . . . . . . . . . . . . . 6 62 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 6 63 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7 64 3.3.1. Attribute Type Description . . . . . . . . . . . 7 65 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 7 66 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8 67 3.3.4. Country String . . . . . . . . . . . . . . . . . 8 68 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9 69 3.3.6. Directory String . . . . . . . . . . . . . . . . 9 70 3.3.7. DIT Content Rule Description . . . . . . . . . . 10 71 3.3.8. DIT Structure Rule Description . . . . . . . . . 11 72 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11 73 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12 74 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13 75 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13 76 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14 77 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15 78 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15 79 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 15 80 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16 81 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16 82 3.3.19. Matching Rule Description. . . . . . . . . . . . 17 83 3.3.20. Matching Rule Use Description. . . . . . . . . . 17 84 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 17 85 3.3.22. Name Form Description. . . . . . . . . . . . . . 18 86 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 18 87 3.3.24. Object Class Description . . . . . . . . . . . . 19 88 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 19 89 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20 90 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20 91 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21 92 3.3.29. Printable String . . . . . . . . . . . . . . . . 22 93 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22 94 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23 95 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 23 96 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24 97 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25 98 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 25 99 4.1. General Considerations . . . . . . . . . . . . . . . . . 26 100 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27 101 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 27 102 4.2.2. caseExactIA5Match. . . . . . . . . . . . . . . . 28 103 4.2.3. caseIgnoreIA5Match . . . . . . . . . . . . . . . 28 104 4.2.4. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 29 105 4.2.5. caseIgnoreListMatch. . . . . . . . . . . . . . . 29 106 4.2.6. caseIgnoreListSubstringsMatch. . . . . . . . . . 30 107 4.2.7. caseIgnoreMatch. . . . . . . . . . . . . . . . . 30 108 4.2.8. caseIgnoreOrderingMatch. . . . . . . . . . . . . 31 109 4.2.9. caseIgnoreSubstringsMatch. . . . . . . . . . . . 31 110 4.2.10. distinguishedNameMatch . . . . . . . . . . . . . 32 111 4.2.11. generalizedTimeMatch . . . . . . . . . . . . . . 33 112 4.2.12. generalizedTimeOrderingMatch . . . . . . . . . . 33 113 4.2.13. integerFirstComponentMatch . . . . . . . . . . . 33 114 4.2.14. integerMatch . . . . . . . . . . . . . . . . . . 34 115 4.2.15. numericStringMatch . . . . . . . . . . . . . . . 34 116 4.2.16. numericStringSubstringsMatch . . . . . . . . . . 35 117 4.2.17. objectIdentifierFirstComponentMatch. . . . . . . 35 118 4.2.18. objectIdentifierMatch. . . . . . . . . . . . . . 36 119 4.2.19. octetStringMatch . . . . . . . . . . . . . . . . 37 120 4.2.20. telephoneNumberMatch . . . . . . . . . . . . . . 37 121 4.2.21. telephoneNumberSubstringsMatch . . . . . . . . . 37 122 4.2.22. uniqueMemberMatch. . . . . . . . . . . . . . . . 38 123 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 38 124 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 125 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39 126 Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 41 127 Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 42 128 Normative References . . . . . . . . . . . . . . . . . . . . . . . 44 129 Informative References . . . . . . . . . . . . . . . . . . . . . . 46 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 131 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47 133 1. Introduction 135 Each attribute stored in a Lightweight Directory Access Protocol 136 (LDAP) directory [ROADMAP], and whose values may be transfered in the 137 LDAP protocol [PROT], has a defined syntax (i.e., data type) which 138 constrains the structure and format of its values. The comparison 139 semantics for values of a syntax are not part of the syntax 140 definition but are instead provided through separately defined 141 matching rules. Matching rules specify an argument, an assertion 142 value, which also has a defined syntax. This document defines a base 143 set of syntaxes and matching rules for use in defining attributes for 144 LDAP directories. 146 Readers are advised to familiarize themselves with the Directory 147 Information Models [MODELS] before reading the rest of this document. 148 Section 3 provides definitions for the base set of LDAP syntaxes. 149 Section 4 provides definitions for the base set of matching rules for 150 LDAP. 152 This document is a integral part of the LDAP technical specification 153 [ROADMAP] which obsoletes the previously defined LDAP technical 154 specification [RFC3377] in its entirety. 156 Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS]. 157 The remainder of RFC 2252 is obsoleted by this document. Sections 6 158 and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The 159 remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS]. 161 A number of schema elements which were included in the previous 162 revision of the LDAP technical specification are not included in this 163 revision of LDAP. Public Key Infrastructure schema elements are now 164 specified in [LDAP-PKI]. Unless reintroduced in future technical 165 specifications, the remainder are to be considered Historic. 167 The changes from RFC 2252 and RFC 2256 are described in Appendix B of 168 this document. 170 2. Conventions 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in BCP 14, RFC 2119 175 [KEYWORD]. 177 Syntax definitions are written according to the 178 ABNF [ABNF] rule specified in [MODELS], and matching rule definitions 179 are written according to the ABNF rule 180 specified in [MODELS], except that the syntax and matching rule 181 definitions provided in this document are line-wrapped for 182 readability. When such definitions are transfered as attribute 183 values in the LDAP protocol (e.g., as values of the ldapSyntaxes and 184 matchingRules attributes [MODELS] respectively) then those values 185 would not contain line breaks. 187 3. Syntaxes 189 Syntax definitions constrain the structure of attribute values stored 190 in an LDAP directory, and determine the representation of attribute 191 and assertion values transfered in the LDAP protocol. 193 Syntaxes that are required for directory operation, or that are in 194 common use, are specified in this section. Servers SHOULD recognize 195 all the syntaxes listed in this document, but are not required to 196 otherwise support them, and MAY recognise or support other syntaxes. 197 However, the definition of additional arbitrary syntaxes is 198 discouraged since it will hinder interoperability. Client and server 199 implementations typically do not have the ability to dynamically 200 recognize new syntaxes. 202 3.1. General Considerations 204 The description of each syntax specifies how attribute or assertion 205 values conforming to the syntax are to be represented when transfered 206 in the LDAP protocol [PROT]. This representation is referred to as 207 the LDAP-specific encoding to distinguish it from other methods of 208 encoding attribute values (e.g., the Basic Encoding Rules (BER) 209 encoding [BER] used by X.500 [X.500] directories). 211 The LDAP-specific encoding of a given attribute syntax always 212 produces octet-aligned values. To the greatest extent possible, 213 encoding rules for LDAP syntaxes should produce character strings 214 that can be displayed with little or no translation by clients 215 implementing LDAP. However, clients MUST NOT assume that the 216 LDAP-specific encoding of a value of an unrecognized syntax is a 217 human-readable character string. There are a few cases (e.g., the 218 JPEG syntax) when it is not reasonable to produce a human-readable 219 representation. 221 Each LDAP syntax is uniquely identified with an object identifier 222 [ASN.1] represented in the dotted-decimal format (short descriptive 223 names are not defined for syntaxes). These object identifiers are 224 not intended to be displayed to users. The object identifiers for 225 the syntaxes defined in this document are summarized in Appendix A. 227 A suggested minimum upper bound on the number of characters in an 228 attribute value with a string-based syntax, or the number of octets 229 in a value for all other syntaxes, MAY be indicated by appending the 230 bound inside of curly braces following the syntax's OBJECT IDENTIFIER 231 in an attribute type definition (see the rule in [MODELS]). 232 Such a bound is not considered part of the syntax identifier. 234 For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute 235 definition suggests that the directory server will allow a value of 236 the attribute to be up to 64 characters long, although it may allow 237 longer character strings. Note that a single character of the 238 Directory String syntax can be encoded in more than one octet since 239 UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character 240 string may be more than 64 octets in length. 242 3.2. Common Definitions 244 The following ABNF rules are used in a number of the syntax 245 definitions in Section 3.3. 247 PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / 248 PLUS / COMMA / HYPHEN / DOT / EQUALS / 249 SLASH / COLON / QUESTION / SPACE 250 PrintableString = 1*PrintableCharacter 251 IA5String = *(%x00-7F) 252 HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" 253 ; N.B. allows upper and lower case 254 SLASH = %x2F ; forward slash ("/") 255 COLON = %x3A ; colon (":") 256 QUESTION = %x3F ; question mark ("?") 258 The , , , , , , , 259 , , , and rules are defined in 260 [MODELS]. 262 3.3. Syntax Definitions 264 3.3.1. Attribute Type Description 266 A value of the Attribute Type Description syntax is the definition of 267 an attribute type. The LDAP-specific encoding of a value of this 268 syntax is defined by the rule in [MODELS]. 269 For example, the following definition of the createTimestamp 270 attribute type from [MODELS] is also a value of the Attribute Type 271 Description syntax (note: line breaks have been added for readability 272 - they are not part of the value when transfered in protocol). 274 ( 2.5.18.1 NAME 'createTimestamp' 275 EQUALITY generalizedTimeMatch 276 ORDERING generalizedTimeOrderingMatch 277 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 278 SINGLE-VALUE NO-USER-MODIFICATION 279 USAGE directoryOperation ) 281 The LDAP definition for the Attribute Type Description syntax is: 283 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) 285 This syntax corresponds to the AttributeTypeDescription ASN.1 type 286 from [X.501]. 288 3.3.2. Bit String 290 A value of the Bit String syntax is a sequence of binary digits. The 291 LDAP-specific encoding of a value of this syntax is defined by the 292 following ABNF: 294 BitString = SQUOTE *binary-digit SQUOTE "B" 295 binary-digit = "0" / "1" 297 The rule is defined in [MODELS]. 299 Example: 300 '0101111101'B 302 The LDAP definition for the Bit String syntax is: 304 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) 306 This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1]. 308 3.3.3. Boolean 310 A value of the Boolean syntax is one of the Boolean values, true or 311 false. The LDAP-specific encoding of a value of this syntax is 312 defined by the following ABNF: 314 Boolean = "TRUE" / "FALSE" 316 The LDAP definition for the Boolean syntax is: 318 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) 320 This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1]. 322 3.3.4. Country String 324 A value of the Country String syntax is one of the two-character 325 codes from ISO 3166 [ISO3166] for representing a country. The 326 LDAP-specific encoding of a value of this syntax is defined by the 327 following ABNF: 329 CountryString = 2(PrintableCharacter) 331 The rule is defined in Section 3.2. 333 Examples: 334 US 335 AU 337 The LDAP definition for the Country String syntax is: 339 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) 341 This syntax corresponds to the following ASN.1 type from [X.520]: 343 PrintableString (SIZE (2)) -- ISO 3166 codes only 345 3.3.5. Delivery Method 347 A value of the Delivery Method syntax is a sequence of items that 348 indicate, in preference order, the service(s) by which an entity is 349 willing and/or capable of receiving messages. The LDAP-specific 350 encoding of a value of this syntax is defined by the following ABNF: 352 DeliveryMethod = pdm *( WSP DOLLAR WSP pdm ) 354 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / 355 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone" 357 The and rules are defined in [MODELS]. 359 Example: 360 telephone $ videotex 362 The LDAP definition for the Delivery Method syntax is: 364 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) 366 This syntax corresponds to the following ASN.1 type from [X.520]: 368 SEQUENCE OF INTEGER { 369 any-delivery-method (0), 370 mhs-delivery (1), 371 physical-delivery (2), 372 telex-delivery (3), 373 teletex-delivery (4), 374 g3-facsimile-delivery (5), 375 g4-facsimile-delivery (6), 376 ia5-terminal-delivery (7), 377 videotex-delivery (8), 378 telephone-delivery (9) } 380 3.3.6. Directory String 382 A value of the Directory String syntax is a string of one or more 383 arbitrary characters from the Universal Character Set (UCS) [UCS]. A 384 zero length character string is not permitted. The LDAP-specific 385 encoding of a value of this syntax is the UTF-8 encoding [UTF8] of 386 the character string. Such encodings conform to the following ABNF: 388 DirectoryString = 1*UTF8 390 The rule is defined in [MODELS]. 392 Example: 394 This is a value of Directory String containing #!%#@. 396 Servers and clients MUST be prepared to receive arbitrary UCS code 397 points, including code points outside the range of printable ASCII 398 and code points not presently assigned to any character. 400 Attribute type definitions using the Directory String syntax should 401 not restrict the format of Directory String values, e.g., by 402 requiring that the character string conforms to specific patterns 403 described by ABNF. A new syntax should be defined in such cases. 405 The LDAP definition for the Directory String syntax is: 407 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) 409 This syntax corresponds to the DirectoryString parameterized ASN.1 410 type from [X.520]. 412 The DirectoryString ASN.1 type allows a choice between the 413 TeletexString, PrintableString or UniversalString ASN.1 types from 414 [ASN.1]. However, note that the chosen alternative is not indicated 415 in the LDAP-specific encoding of a Directory String value. 417 Implementations which convert Directory String values from the 418 LDAP-specific encoding to the BER encoding used by X.500 must choose 419 an alternative that permits the particular characters in the string, 420 and must convert the characters from the UTF-8 encoding into the 421 character encoding of the chosen alternative. 423 When converting Directory String values from the BER encoding to the 424 LDAP-specific encoding the characters must be converted from the 425 character encoding of the chosen alternative into the UTF-8 encoding. 427 3.3.7. DIT Content Rule Description 429 A value of the DIT Content Rule Description syntax is the definition 430 of a DIT (Directory Information Tree) content rule. The 431 LDAP-specific encoding of a value of this syntax is defined by the 432 rule in [MODELS]. 434 Example: 435 ( 2.5.6.4 DESC 'content rule for organization' 436 NOT ( x121Address $ telexNumber ) ) 438 Note: a line break has been added for readability - it is not part of 439 the value. 441 The LDAP definition for the DIT Content Rule Description syntax is: 443 ( 1.3.6.1.4.1.1466.115.121.1.16 444 DESC 'DIT Content Rule Description' ) 446 This syntax corresponds to the DITContentRuleDescription ASN.1 type 447 from [X.501]. 449 3.3.8. DIT Structure Rule Description 451 A value of the DIT Structure Rule Description syntax is the 452 definition of a DIT structure rule. The LDAP-specific encoding of a 453 value of this syntax is defined by the 454 rule in [MODELS]. 456 Example: 457 ( 2 DESC 'organization structure rule' FORM 2.5.15.3 ) 459 The LDAP definition for the DIT Structure Rule Description syntax is: 461 ( 1.3.6.1.4.1.1466.115.121.1.17 462 DESC 'DIT Structure Rule Description' ) 464 This syntax corresponds to the DITStructureRuleDescription ASN.1 type 465 from [X.501]. 467 3.3.9. DN 469 A value of the DN syntax is the (purported) distinguished name (DN) 470 of an entry [MODELS]. The LDAP-specific encoding of a value of this 471 syntax is defined by the rule in [LDAPDN]. 473 Examples (from [LDAPDN]): 474 UID=jsmith,DC=example,DC=net 475 OU=Sales+CN=J. Smith,DC=example,DC=net 476 CN=John Smith\, III,DC=example,DC=net 477 CN=Before\0dAfter,DC=example,DC=net 478 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com 479 CN=Lu\C4\8Di\C4\87 481 The LDAP definition for the DN syntax is: 483 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' ) 485 The DN syntax corresponds to the DistinguishedName ASN.1 type from 486 [X.501]. Note that a BER encoded distinguished name (as used by 487 X.500) re-encoded into the LDAP-specific encoding is not necessarily 488 reversible to the original BER encoding since the chosen string type 489 in any DirectoryString components of the distinguished name is not 490 indicated in the LDAP-specific encoding of the distinguished name 491 (see Section 3.3.6). 493 3.3.10. Enhanced Guide 495 A value of the Enhanced Guide syntax suggests criteria, which consist 496 of combinations of attribute types and filter operators, to be used 497 in constructing filters to search for entries of particular object 498 classes. The Enhanced Guide syntax improves upon the Guide syntax by 499 allowing the recommended depth of the search to be specified. 501 The LDAP-specific encoding of a value of this syntax is defined by 502 the following ABNF: 504 EnhancedGuide = object-class SHARP WSP criteria WSP 505 SHARP WSP subset 506 object-class = WSP oid WSP 507 subset = "baseobject" / "oneLevel" / "wholeSubtree" 509 criteria = and-term *( BAR and-term ) 510 and-term = term *( AMPERSAND term ) 511 term = EXCLAIM term / 512 attributetype DOLLAR match-type / 513 LPAREN criteria RPAREN / 514 true / 515 false 516 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" 517 true = "?true" 518 false = "?false" 519 BAR = %x7C ; vertical bar ("|") 520 AMPERSAND = %x26 ; ampersand ("&") 521 EXCLAIM = %x21 ; exclamation mark ("!") 523 The , , , , , and 524 rules are defined in [MODELS]. 526 The LDAP definition for the Enhanced Guide syntax is: 528 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) 530 Example: 531 person#(sn$EQ)#oneLevel 533 The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type 534 from [X.520]. The EnhancedGuide type references the Criteria ASN.1 535 type, also from [X.520]. The rule above represents an empty 536 "and" expression in a value of the Criteria type. The rule 537 above represents an empty "or" expression in a value of the Criteria 538 type. 540 3.3.11. Facsimile Telephone Number 542 A value of the Facsimile Telephone Number syntax is a subscriber 543 number of a facsimile device on the public switched telephone 544 network. The LDAP-specific encoding of a value of this syntax is 545 defined by the following ABNF: 547 fax-number = telephone-number *( DOLLAR fax-parameter ) 548 telephone-number = PrintableString 549 fax-parameter = "twoDimensional" / 550 "fineResolution" / 551 "unlimitedLength" / 552 "b4Length" / 553 "a3Width" / 554 "b4Width" / 555 "uncompressed" 557 The is a string of printable characters that 558 complies with the internationally agreed format for representing 559 international telephone numbers [E.123]. The rule 560 is defined in Section 3.2. The rule is defined in [MODELS]. 562 The LDAP definition for the Facsimile Telephone Number syntax is: 564 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number') 566 The Facsimile Telephone Number syntax corresponds to the 567 FacsimileTelephoneNumber ASN.1 type from [X.520]. 569 3.3.12. Fax 571 A value of the Fax syntax is an image which is produced using the 572 Group 3 facsimile process [FAX] to duplicate an object, such as a 573 memo. The LDAP-specific encoding of a value of this syntax is the 574 string of octets for a Group 3 Fax image as defined in [FAX]. 576 The LDAP definition for the Fax syntax is: 578 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' ) 580 The ASN.1 type corresponding to the Fax syntax is defined as follows, 581 assuming EXPLICIT TAGS: 583 Fax ::= CHOICE { 584 g3-facsimile [3] G3FacsimileBodyPart 585 } 587 The G3FacsimileBodyPart ASN.1 type is defined in [X.420]. 589 3.3.13. Generalized Time 591 A value of the Generalized Time syntax is a character string 592 representing a date and time. The LDAP-specific encoding of a value 593 of this syntax is a restriction of the format defined in [ISO8601], 594 and is described by the following ABNF: 596 century = 2(%x30-39) ; "00" to "99" 597 year = 2(%x30-39) ; "00" to "99" 598 month = ( %x30 %x31-39 ) ; "01" (January) to "09" 599 / ( %x31 %x30-32 ) ; "10" to "12" 600 day = ( %x30 %x31-39 ) ; "01" to "09" 601 / ( %x31-32 %x30-39 ) ; "10" to "29" 602 / ( %x33 %x30-31 ) ; "30" to "31" 603 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" 604 minute = %x30-35 %x30-39 ; "00" to "59" 605 second = ( %x30-35 %x30-39 ) ; "00" to "59" 606 / ( %x36 %x30 ) ; "60" (a leap second) 608 GeneralizedTime = century year month day hour 609 [ minute [ second ] ] [ fraction ] 610 g-time-zone 611 fraction = ( DOT / COMMA ) 1*(%x30-39) 612 g-time-zone = %x5A ; "Z" 613 / g-differential 614 g-differential = ( MINUS / PLUS ) hour [ minute ] 615 MINUS = %x2D ; minus sign ("-") 617 The , and rules are defined in [MODELS]. 619 The time value represents coordinated universal time (equivalent to 620 Greenwich Mean Time) if the "Z" form of is used, 621 otherwise the value represents a local time in the time zone 622 indicated by . In the latter case, coordinated 623 universal time can be calculated by subtracting the differential from 624 the local time. The "Z" form of SHOULD be used in 625 preference to . 627 Examples: 628 199412161032Z 629 199412160532-0500 631 Both example values represent the same coordinated universal time: 632 10:32 AM, December 16, 1994. 634 The LDAP definition for the Generalized Time syntax is: 636 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) 638 This syntax corresponds to the GeneralizedTime ASN.1 type from 639 [ASN.1], with the constraint that local time without a differential 640 SHALL NOT be used. 642 3.3.14. Guide 644 A value of the Guide syntax suggests criteria, which consist of 645 combinations of attribute types and filter operators, to be used in 646 constructing filters to search for entries of particular object 647 classes. The Guide syntax is obsolete and should not be used for 648 defining new attribute types. 650 The LDAP-specific encoding of a value of this syntax is defined by 651 the following ABNF: 653 Guide = [ object-class SHARP ] criteria 655 The and rules are defined in Section 656 3.3.10. The rule is defined in [MODELS]. 658 The LDAP definition for the Guide syntax is: 660 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) 662 The Guide syntax corresponds to the Guide ASN.1 type from [X.520]. 664 3.3.15. IA5 String 666 A value of the IA5 String syntax is a string of zero, one or more 667 characters from International Alphabet 5 (IA5) [T.50], the 668 international version of the ASCII character set. The LDAP-specific 669 encoding of a value of this syntax is the unconverted string of 670 characters, which conforms to the rule in Section 3.2. 672 The LDAP definition for the IA5 String syntax is: 674 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) 676 This syntax corresponds to the IA5String ASN.1 type from [ASN.1]. 678 3.3.16. Integer 680 A value of the Integer syntax is a whole number of unlimited 681 magnitude. The LDAP-specific encoding of a value of this syntax is 682 the optionally signed decimal digit character string representation 683 of the number (so, for example, the number 1321 is represented by the 684 character string "1321"). The encoding is defined by the following 685 ABNF: 687 Integer = ( HYPHEN LDIGIT *DIGIT ) / number 689 The , , and rules are defined in 690 [MODELS]. 692 The LDAP definition for the Integer syntax is: 694 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' ) 696 This syntax corresponds to the INTEGER ASN.1 type from [ASN.1]. 698 3.3.17. JPEG 700 A value of the JPEG syntax is an image in the JPEG File Interchange 701 Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of 702 a value of this syntax is the sequence of octets of the JFIF encoding 703 of the image. 705 The LDAP definition for the JPEG syntax is: 707 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' ) 709 The JPEG syntax corresponds to the following ASN.1 type: 711 JPEG ::= OCTET STRING (CONSTRAINED BY 712 { -- contents octets are an image in the -- 713 -- JPEG File Interchange Format -- }) 715 3.3.18. LDAP Syntax Description 717 A value of the LDAP Syntax Description syntax is the description of 718 an LDAP syntax. The LDAP-specific encoding of a value of this syntax 719 is defined by the rule in [MODELS]. 721 The LDAP definition for the LDAP Syntax Description syntax is: 723 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) 725 The above LDAP definition for the LDAP Syntax Description syntax is 726 itself a legal value of the LDAP Syntax Description syntax. 728 The ASN.1 type corresponding to the LDAP Syntax Description syntax is 729 defined as follows, assuming EXPLICIT TAGS: 731 LDAPSyntaxDescription ::= SEQUENCE { 732 identifier OBJECT IDENTIFIER, 733 description DirectoryString { ub-schema } OPTIONAL } 735 The DirectoryString parameterized ASN.1 type is defined in [X.520]. 737 The value of ub-schema (an integer) is implementation defined. A 738 non-normative definition appears in [X.520]. 740 3.3.19. Matching Rule Description 742 A value of the Matching Rule Description syntax is the definition of 743 a matching rule. The LDAP-specific encoding of a value of this 744 syntax is defined by the rule in [MODELS]. 746 Example: 747 ( 2.5.13.2 NAME 'caseIgnoreMatch' 748 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 750 Note: a line break has been added for readability - it is not part of 751 the syntax. 753 The LDAP definition for the Matching Rule Description syntax is: 755 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) 757 This syntax corresponds to the MatchingRuleDescription ASN.1 type 758 from [X.501]. 760 3.3.20. Matching Rule Use Description 762 A value of the Matching Rule Use Description syntax indicates the 763 attribute types to which a matching rule may be applied in an 764 extensibleMatch search filter [PROT]. The LDAP-specific encoding of 765 a value of this syntax is defined by the 766 rule in [MODELS]. 768 Example: 769 ( 2.5.13.16 APPLIES ( givenName $ surname ) ) 771 The LDAP definition for the Matching Rule Use Description syntax is: 773 ( 1.3.6.1.4.1.1466.115.121.1.31 774 DESC 'Matching Rule Use Description' ) 776 This syntax corresponds to the MatchingRuleUseDescription ASN.1 type 777 from [X.501]. 779 3.3.21. Name and Optional UID 780 A value of the Name and Optional UID syntax is the distinguished name 781 [MODELS] of an entity optionally accompanied by a unique identifier 782 that serves to differentiate the entity from others with an identical 783 distinguished name. 785 The LDAP-specific encoding of a value of this syntax is defined by 786 the following ABNF: 788 NameAndOptionalUID = distinguishedName [ SHARP BitString ] 790 The rule is defined in Section 3.3.2. The 791 rule is defined in [LDAPDN]. The rule is 792 defined in [MODELS]. 794 Note that although the '#' character may occur in the string 795 representation of a distinguished name, no additional escaping of 796 this character is performed when a is encoded in 797 a . 799 Example: 800 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B 802 The LDAP definition for the Name and Optional UID syntax is: 804 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) 806 This syntax corresponds to the NameAndOptionalUID ASN.1 type from 807 [X.520]. 809 3.3.22. Name Form Description 811 A value of the Name Form Description syntax is the definition of a 812 name form, which regulates how entries may be named. The 813 LDAP-specific encoding of a value of this syntax is defined by the 814 rule in [MODELS]. 816 Example: 817 ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o ) 819 The LDAP definition for the Name Form Description syntax is: 821 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) 823 This syntax corresponds to the NameFormDescription ASN.1 type from 824 [X.501]. 826 3.3.23. Numeric String 827 A value of the Numeric String syntax is a sequence of one or more 828 numerals and spaces. The LDAP-specific encoding of a value of this 829 syntax is the unconverted string of characters, which conforms to the 830 following ABNF: 832 NumericString = 1*(DIGIT / SPACE) 834 The and rules are defined in [MODELS]. 836 Example: 837 15 079 672 281 839 The LDAP definition for the Numeric String syntax is: 841 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) 843 This syntax corresponds to the NumericString ASN.1 type from [ASN.1]. 845 3.3.24. Object Class Description 847 A value of the Object Class Description syntax is the definition of 848 an object class. The LDAP-specific encoding of a value of this 849 syntax is defined by the rule in [MODELS]. 851 Example: 852 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c 853 MAY ( searchGuide $ description ) ) 855 Note: a line break has been added for readability - it is not part of 856 the syntax. 858 The LDAP definition for the Object Class Description syntax is: 860 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) 862 This syntax corresponds to the ObjectClassDescription ASN.1 type from 863 [X.501]. 865 3.3.25. Octet String 867 A value of the Octet String syntax is a sequence of zero, one or more 868 arbitrary octets. The LDAP-specific encoding of a value of this 869 syntax is the unconverted sequence of octets, which conforms to the 870 following ABNF: 872 OctetString = *OCTET 874 The rule is defined in [MODELS]. Values of this syntax are 875 not generally human-readable. 877 The LDAP definition for the Octet String syntax is: 879 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) 881 This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1]. 883 3.3.26. OID 885 A value of the OID syntax is an object identifier; a sequence of two 886 or more non-negative integers that uniquely identify some object or 887 item of specification. Many of the object identifiers used in LDAP 888 also have IANA registered names [RFC3383]. 890 The LDAP-specific encoding of a value of this syntax is defined by 891 the rule in [MODELS]. 893 Examples: 894 1.2.3.4 895 cn 897 The LDAP definition for the OID syntax is: 899 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) 901 This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from 902 [ASN.1]. 904 3.3.27. Other Mailbox 906 A value of the Other Mailbox syntax identifies an electronic mailbox, 907 in a particular named mail system. The LDAP-specific encoding of a 908 value of this syntax is defined by the following ABNF: 910 OtherMailbox = mailbox-type DOLLAR mailbox 911 mailbox-type = PrintableString 912 mailbox = IA5String 914 The rule represents the type of mail system in which 915 the mailbox resides, for example "MCIMail", and is the 916 actual mailbox in the mail system described by . The 917 and rules are defined in Section 3.2. 918 The rule is defined in [MODELS]. 920 The LDAP definition for the Other Mailbox syntax is: 922 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) 924 The ASN.1 type corresponding to the Other Mailbox syntax is defined 925 as follows, assuming EXPLICIT TAGS: 927 OtherMailbox ::= SEQUENCE { 928 mailboxType PrintableString, 929 mailbox IA5String 930 } 932 3.3.28. Postal Address 934 A value of the Postal Address syntax is a sequence of strings of one 935 or more arbitrary UCS characters, which form an address in a physical 936 mail system. 938 The LDAP-specific encoding of a value of this syntax is defined by 939 the following ABNF: 941 PostalAddress = line *( DOLLAR line ) 942 line = 1*line-char 943 line-char = %x00-23 944 / (%x5C "24") ; escaped "$" 945 / %x25-5B 946 / (%x5C "5C") ; escaped "\" 947 / %x5D-7F 948 / UTFMB 950 Each character string (i.e., ) of a postal address value is 951 encoded as a UTF-8 [UTF8] string except that "\" and "$" characters, 952 if they occur in the string, are escaped by a "\" character followed 953 by the two hexadecimal digit code for the character. The 954 rule is defined in Section 3.2. The and rules are 955 defined in [MODELS]. 957 Many servers limit the postal address to no more than six lines of no 958 more than thirty characters each. 960 Example: 961 1234 Main St.$Anytown, CA 12345$USA 962 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA 964 The LDAP definition for the Postal Address syntax is: 966 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) 968 This syntax corresponds to the PostalAddress ASN.1 type from [X.520], 969 i.e., 971 PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF 972 DirectoryString { ub-postal-string } 974 The values of ub-postal-line and ub-postal-string (both integers) are 975 implementation defined. Non-normative definitions appear in [X.520]. 977 3.3.29. Printable String 979 A value of the Printable String syntax is a string of one or more 980 latin alphabetic, numeric, and selected punctuation characters as 981 specified by the rule in Section 3.2. 983 The LDAP-specific encoding of a value of this syntax is the 984 unconverted string of characters, which conforms to the 985 rule in Section 3.2. 987 Example: 988 This is a PrintableString. 990 The LDAP definition for the PrintableString syntax is: 992 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) 994 This syntax corresponds to the PrintableString ASN.1 type from 995 [ASN.1]. 997 3.3.30. Substring Assertion 999 A value of the Substring Assertion syntax is a sequence of zero, one 1000 or more character substrings used as an argument for substring 1001 extensible matching of character string attribute values, i.e., as 1002 the matchValue of a MatchingRuleAssertion [PROT]. Each substring is 1003 a string of one or more arbitrary characters from the Universal 1004 Character Set (UCS) [UCS]. A zero length substring is not permitted. 1006 The LDAP-specific encoding of a value of this syntax is defined by 1007 the following ABNF: 1009 SubstringAssertion = [ initial ] any [ final ] 1011 initial = substring 1012 any = ASTERISK *(substring ASTERISK) 1013 final = substring 1014 ASTERISK = %x2A ; asterisk ("*") 1016 substring = 1*substring-character 1017 substring-character = %x00-29 1018 / (%x5C "2A") ; escaped "*" 1019 / %x2B-5B 1020 / (%x5C "5C") ; escaped "\" 1021 / %x5D-7F 1022 / UTFMB 1024 Each of a Substring Assertion value is encoded as a UTF-8 1025 [UTF8] string, except that "\" and "*" characters, if they occur in 1026 the substring, are escaped by a "\" character followed by the two 1027 hexadecimal digit code for the character. 1029 The Substring Assertion syntax is used only as the syntax of 1030 assertion values in the extensible match. It is not used as an 1031 attribute syntax, or in the SubstringFilter [PROT]. 1033 The LDAP definition for the Substring Assertion syntax is: 1035 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) 1037 This syntax corresponds to the SubstringAssertion ASN.1 type from 1038 [X.520]. 1040 3.3.31. Telephone Number 1042 A value of the Telephone Number syntax is a string of printable 1043 characters that complies with the internationally agreed format for 1044 representing international telephone numbers [E.123]. 1046 The LDAP-specific encoding of a value of this syntax is the 1047 unconverted string of characters, which conforms to the 1048 rule in Section 3.2. 1050 Example: +1 512 315 0280 1052 The LDAP definition for the Telephone Number syntax is: 1054 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) 1056 The Telephone Number syntax corresponds to the following ASN.1 type 1057 from [X.520]: 1059 PrintableString (SIZE(1..ub-telephone-number)) 1061 The value of ub-telephone-number (an integer) is implementation 1062 defined. A non-normative definition appears in [X.520]. 1064 3.3.32. Teletex Terminal Identifier 1066 A value of this syntax specifies the identifier and (optionally) 1067 parameters of a teletex terminal. 1069 The LDAP-specific encoding of a value of this syntax is defined by 1070 the following ABNF: 1072 teletex-id = ttx-term *(DOLLAR ttx-param) 1073 ttx-term = PrintableString ; terminal identifier 1074 ttx-param = ttx-key COLON ttx-value ; parameter 1075 ttx-key = "graphic" / "control" / "misc" / "page" / "private" 1076 ttx-value = *ttx-value-char 1078 ttx-value-char = %x00-23 1079 / (%x5C "24") ; escaped "$" 1080 / %x25-5B 1081 / (%x5C "5C") ; escaped "\" 1082 / %x5D-FF 1084 The and rules are defined in Section 3.2. 1085 The rule is defined in [MODELS]. 1087 The LDAP definition for the Teletex Terminal Identifier syntax is: 1089 ( 1.3.6.1.4.1.1466.115.121.1.51 1090 DESC 'Teletex Terminal Identifier' ) 1092 This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type 1093 from [X.520]. 1095 3.3.33. Telex Number 1097 A value of the Telex Number syntax specifies the telex number, 1098 country code and answerback code of a telex terminal. 1100 The LDAP-specific encoding of a value of this syntax is defined by 1101 the following ABNF: 1103 telex-number = actual-number DOLLAR country-code 1104 DOLLAR answerback 1105 actual-number = PrintableString 1106 country-code = PrintableString 1107 answerback = PrintableString 1109 The rule is defined in Section 3.2. The 1110 rule is defined in [MODELS]. 1112 The LDAP definition for the Telex Number syntax is: 1114 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) 1116 This syntax corresponds to the TelexNumber ASN.1 type from [X.520]. 1118 3.3.34. UTC Time 1120 A value of the UTC Time syntax is a character string representing a 1121 date and time to a precision of one minute or one second. The year 1122 is given as a two-digit number. The LDAP-specific encoding of a 1123 value of this syntax follows the format defined in [ASN.1] for the 1124 UTCTime type and is described by the following ABNF: 1126 UTCTime = year month day hour minute [ second ] 1127 [ u-time-zone ] 1128 u-time-zone = %x5A ; "Z" 1129 / u-differential 1130 u-differential = ( MINUS / PLUS ) hour minute 1132 The , , , , , and 1133 rules are defined in Section 3.3.13. The rule is defined in 1134 [MODELS]. 1136 The time value represents coordinated universal time if the "Z" form 1137 of is used, otherwise the value represents a local 1138 time. In the latter case, if is provided then 1139 coordinated universal time can be calculated by subtracting the 1140 differential from the local time. The SHOULD be 1141 present in time values and the "Z" form of SHOULD be 1142 used in preference to . 1144 The LDAP definition for the UTC Time syntax is: 1146 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' ) 1148 Note: This syntax is deprecated in favor of the Generalized Time 1149 syntax. 1151 The UTC Time syntax corresponds to the UTCTime ASN.1 type from 1152 [ASN.1]. 1154 4. Matching Rules 1156 Matching rules are used by directory implementations to compare 1157 attribute values against assertion values when performing Search and 1158 Compare operations [PROT]. They are also used when comparing a 1159 purported distinguished name [MODELS] with the name of an entry. 1160 When modifying entries, matching rules are used to identify values to 1161 be deleted and to prevent an attribute from containing two equal 1162 values. 1164 Matching rules that are required for directory operation, or that are 1165 in common use, are specified in this section. 1167 4.1. General Considerations 1169 A matching rule is applied to attribute values through an 1170 AttributeValueAssertion or MatchingRuleAssertion [PROT]. The 1171 conditions under which an AttributeValueAssertion or 1172 MatchingRuleAssertion evaluates to Undefined are specified in [PROT]. 1173 If an assertion is not Undefined then the result of the assertion is 1174 the result of applying the selected matching rule. A matching rule 1175 evaluates to TRUE, and in some cases Undefined, as specified in the 1176 description of the matching rule, otherwise it evaluates to FALSE. 1178 Each assertion contains an assertion value. The definition of each 1179 matching rule specifies the syntax for the assertion value. The 1180 syntax of the assertion value is typically, but not necessarily, the 1181 same as the syntax of the attribute values to which the matching rule 1182 may be applied. Note that the AssertionValue in a SubstringFilter 1183 [PROT] MUST conform to the assertion syntax of the equality matching 1184 rule for the attribute type rather than the assertion syntax of the 1185 substrings matching rule for the attribute type. The entire 1186 SubstringFilter is converted into an assertion value of the 1187 substrings matching rule prior to applying the rule. 1189 The definition of each matching rule indicates the attribute syntaxes 1190 to which the rule may be applied, by specifying conditions the 1191 corresponding ASN.1 type of a candidate attribute syntax must 1192 satisfy. These conditions are also satisfied if the corresponding 1193 ASN.1 type is a tagged or constrained derivative of the ASN.1 type 1194 explicitly mentioned in the rule description (i.e., ASN.1 tags and 1195 constraints are ignored in checking applicability), or an alternative 1196 reference notation for the explicitly mentioned type. Each rule 1197 description lists as examples of applicable attribute syntaxes, the 1198 complete list of the syntaxes defined in this document to which the 1199 matching rule applies. A matching rule may be applicable to 1200 additional syntaxes defined in other documents if those syntaxes 1201 satisfy the conditions on the corresponding ASN.1 type. 1203 The description of each matching rule indicates whether the rule is 1204 suitable for use as the equality matching rule (EQUALITY), ordering 1205 matching rule (ORDERING) or substrings matching rule (SUBSTR) in an 1206 attribute type definition [MODELS]. 1208 Each matching rule is uniquely identified with an object identifier. 1209 The definition of a matching rule should not be subsequently changed. 1210 If a change is desirable then a new matching rule with a different 1211 object identifier should be defined instead. 1213 Servers SHOULD implement all the matching rules in Section 4.2. 1214 Servers MAY implement additional matching rules. 1216 Servers which implement the extensibleMatch filter SHOULD allow the 1217 matching rules listed in Section 4.2 to be used in the 1218 extensibleMatch filter and SHOULD allow matching rules to be used 1219 with all attribute types known to the server, where the assertion 1220 syntax of the matching rule is the same as the value syntax of the 1221 attribute. 1223 Servers MUST publish in the matchingRules attribute, the definitions 1224 of matching rules referenced by values of the attributeTypes and 1225 matchingRuleUse attributes in the same subschema entry. Other 1226 unreferenced matching rules MAY be published in the matchingRules 1227 attribute. 1229 If the server supports the extensibleMatch filter, then the server 1230 MAY use the matchingRuleUse attribute to indicate the applicability 1231 (in an extensibleMatch filter) of selected matching rules to 1232 nominated attribute types. 1234 4.2. Matching Rule Definitions 1236 When evaluating the numericStringMatch, numericStringSubstringsMatch, 1237 caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, 1238 caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch, 1239 caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, 1240 telephoneNumberMatch and telephoneNumberSubstringsMatch matching 1241 rules the assertion value and attribute value are prepared according 1242 to the string preparation algorithms [PREP] for LDAP before being 1243 compared. The Transcode, Normalize, Prohibit and Check bidi steps 1244 are the same for each of the matching rules. However, the Map and 1245 Insignificant Character Removal steps depends on the specific rule, 1246 as detailed in the description of these matching rules in the 1247 sections that follow. 1249 4.2.1. bitStringMatch 1251 The bitStringMatch rule compares an assertion value of the Bit String 1252 syntax to an attribute value of a syntax (e.g., the Bit String 1253 syntax) whose corresponding ASN.1 type is BIT STRING. 1255 If the corresponding ASN.1 type of the attribute syntax does not have 1256 a named bit list (which is the case for the Bit String syntax) then 1257 the rule evaluates to TRUE if and only if the attribute value has the 1258 same number of bits as the assertion value and the bits match on a 1259 bitwise basis. 1261 If the corresponding ASN.1 type does have a named bit list then 1262 bitStringMatch operates as above except that trailing zero bits in 1263 the attribute and assertion values are treated as absent. 1265 The LDAP definition for the bitStringMatch rule is: 1267 ( 2.5.13.16 NAME 'bitStringMatch' 1268 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) 1270 The bitStringMatch rule is an equality matching rule. 1272 4.2.2. caseExactIA5Match 1274 The caseExactIA5Match rule compares an assertion value of the IA5 1275 String syntax to an attribute value of a syntax (e.g the IA5 String 1276 syntax) whose corresponding ASN.1 type is IA5String. 1278 The rule evaluates to TRUE if and only if the prepared attribute 1279 value character string and the prepared assertion value character 1280 string have the same number of characters and corresponding 1281 characters have the same code point. 1283 In preparing the attribute value and assertion value for comparison, 1284 characters are not case folded in the Map preparation step, and only 1285 Insignificant Space Removal is applied in the Insignificant Character 1286 Removal step. 1288 The LDAP definition for the caseExactIA5Match rule is: 1290 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' 1291 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1293 The caseExactIA5Match rule is an equality matching rule. 1295 4.2.3. caseIgnoreIA5Match 1297 The caseIgnoreIA5Match rule compares an assertion value of the IA5 1298 String syntax to an attribute value of a syntax (e.g the IA5 String 1299 syntax) whose corresponding ASN.1 type is IA5String. 1301 The rule evaluates to TRUE if and only if the prepared attribute 1302 value character string and the prepared assertion value character 1303 string have the same number of characters and corresponding 1304 characters have the same code point. 1306 In preparing the attribute value and assertion value for comparison, 1307 characters are case folded in the Map preparation step, and only 1308 Insignificant Space Removal is applied in the Insignificant Character 1309 Removal step. 1311 The LDAP definition for the caseIgnoreIA5Match rule is: 1313 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' 1314 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 1316 The caseIgnoreIA5Match rule is an equality matching rule. 1318 4.2.4. caseIgnoreIA5SubstringsMatch 1320 The caseIgnoreIA5SubstringsMatch rule compares an assertion value of 1321 the Substring Assertion syntax to an attribute value of a syntax (e.g 1322 the IA5 String syntax) whose corresponding ASN.1 type is IA5String. 1324 The rule evaluates to TRUE if and only if the prepared substrings of 1325 the assertion value match disjoint portions of the prepared attribute 1326 value character string in the order of the substrings in the 1327 assertion value, and an substring, if present, matches the 1328 beginning of the prepared attribute value character string, and a 1329 substring, if present, matches the end of the prepared 1330 attribute value character string. A prepared substring matches a 1331 portion of the prepared attribute value character string if 1332 corresponding characters have the same code point. 1334 In preparing the attribute value and assertion value substrings for 1335 comparison, characters are case folded in the Map preparation step, 1336 and only Insignificant Space Removal is applied in the Insignificant 1337 Character Removal step. 1339 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' 1340 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1342 The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule. 1344 4.2.5. caseIgnoreListMatch 1346 The caseIgnoreListMatch rule compares an assertion value that is a 1347 sequence of strings to an attribute value of a syntax (e.g., the 1348 Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE 1349 OF the DirectoryString ASN.1 type. 1351 The rule evaluates to TRUE if and only if the attribute value and the 1352 assertion value have the same number of strings and corresponding 1353 strings (by position) match according to the caseIgnoreMatch matching 1354 rule. 1356 In [X.520] the assertion syntax for this matching rule is defined to 1357 be: 1359 SEQUENCE OF DirectoryString {ub-match} 1361 i.e., different from the corresponding type for the Postal Address 1362 syntax. The choice of the Postal Address syntax for the assertion 1363 syntax of the caseIgnoreListMatch in LDAP should not be seen as 1364 limiting the matching rule to only apply to attributes with the 1365 Postal Address syntax. 1367 The LDAP definition for the caseIgnoreListMatch rule is: 1369 ( 2.5.13.11 NAME 'caseIgnoreListMatch' 1370 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) 1372 The caseIgnoreListMatch rule is an equality matching rule. 1374 4.2.6. caseIgnoreListSubstringsMatch 1376 The caseIgnoreListSubstringsMatch rule compares an assertion value of 1377 the Substring Assertion syntax to an attribute value of a syntax 1378 (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a 1379 SEQUENCE OF the DirectoryString ASN.1 type. 1381 The rule evaluates to TRUE if and only if the assertion value 1382 matches, per the caseIgnoreSubstringsMatch rule, the character string 1383 formed by concatenating the strings of the attribute value, except 1384 that none of the , , or substrings of the 1385 assertion value are considered to match a substring of the 1386 concatenated string which spans more than one of the original strings 1387 of the attribute value. 1389 Note that, in terms of the LDAP-specific encoding of the Postal 1390 Address syntax, the concatenated string omits the line 1391 separator and the escaping of "\" and "$" characters. 1393 The LDAP definition for the caseIgnoreListSubstringsMatch rule is: 1395 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' 1396 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1398 The caseIgnoreListSubstringsMatch rule is a substrings matching rule. 1400 4.2.7. caseIgnoreMatch 1402 The caseIgnoreMatch rule compares an assertion value of the Directory 1403 String syntax to an attribute value of a syntax (e.g., the Directory 1404 String, Printable String, Country String or Telephone Number syntax) 1405 whose corresponding ASN.1 type is DirectoryString or one of the 1406 alternative string types of DirectoryString, e.g., PrintableString 1407 (the other alternatives do not correspond to any syntax defined in 1408 this document). 1410 The rule evaluates to TRUE if and only if the prepared attribute 1411 value character string and the prepared assertion value character 1412 string have the same number of characters and corresponding 1413 characters have the same code point. 1415 In preparing the attribute value and assertion value for comparison, 1416 characters are case folded in the Map preparation step, and only 1417 Insignificant Space Removal is applied in the Insignificant Character 1418 Removal step. 1420 The LDAP definition for the caseIgnoreMatch rule is: 1422 ( 2.5.13.2 NAME 'caseIgnoreMatch' 1423 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1425 The caseIgnoreMatch rule is an equality matching rule. 1427 4.2.8. caseIgnoreOrderingMatch 1429 The caseIgnoreOrderingMatch rule compares an assertion value of the 1430 Directory String syntax to an attribute value of a syntax (e.g., the 1431 Directory String, Printable String, Country String or Telephone 1432 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1433 one of its alternative string types. 1435 The rule evaluates to TRUE if, and only if, in the code point 1436 collation order, the prepared attribute value character string 1437 appears earlier than the prepared assertion value character string, 1438 i.e., the attribute value is "less than" the assertion value. 1440 In preparing the attribute value and assertion value for comparison, 1441 characters are case folded in the Map preparation step, and only 1442 Insignificant Space Removal is applied in the Insignificant Character 1443 Removal step. 1445 The LDAP definition for the caseIgnoreOrderingMatch rule is: 1447 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' 1448 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 1450 The caseIgnoreOrderingMatch rule is an ordering matching rule. 1452 4.2.9. caseIgnoreSubstringsMatch 1454 The caseIgnoreSubstringsMatch rule compares an assertion value of the 1455 Substring Assertion syntax to an attribute value of a syntax (e.g., 1456 the Directory String, Printable String, Country String or Telephone 1457 Number syntax) whose corresponding ASN.1 type is DirectoryString or 1458 one of its alternative string types. 1460 The rule evaluates to TRUE if and only if the prepared substrings of 1461 the assertion value match disjoint portions of the prepared attribute 1462 value character string in the order of the substrings in the 1463 assertion value, and an substring, if present, matches the 1464 beginning of the prepared attribute value character string, and a 1465 substring, if present, matches the end of the prepared 1466 attribute value character string. A prepared substring matches a 1467 portion of the prepared attribute value character string if 1468 corresponding characters have the same code point. 1470 In preparing the attribute value and assertion value substrings for 1471 comparison, characters are case folded in the Map preparation step, 1472 and only Insignificant Space Removal is applied in the Insignificant 1473 Character Removal step. 1475 The LDAP definition for the caseIgnoreSubstringsMatch rule is: 1477 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' 1478 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1480 The caseIgnoreSubstringsMatch rule is a substrings matching rule. 1482 4.2.10. distinguishedNameMatch 1484 The distinguishedNameMatch rule compares an assertion value of the DN 1485 syntax to an attribute value of a syntax (e.g., the DN syntax) whose 1486 corresponding ASN.1 type is DistinguishedName. 1488 The rule evaluates to TRUE if and only if the attribute value and the 1489 assertion value have the same number of relative distinguished names 1490 and corresponding relative distinguished names (by position) are the 1491 same. A relative distinguished name (RDN) of the assertion value is 1492 the same as an RDN of the attribute value if and only if they have 1493 the same number of attribute value assertions and each attribute 1494 value assertion (AVA) of the first RDN is the same as the AVA of the 1495 second RDN with the same attribute type. The order of the AVAs is 1496 not significant. Also note that a particular attribute type may 1497 appear in at most one AVA in an RDN. Two AVAs with the same 1498 attribute type are the same if their values are equal according to 1499 the equality matching rule of the attribute type. If one or more of 1500 the AVA comparisons evaluate to Undefined and the remaining AVA 1501 comparisons return TRUE then the distinguishedNameMatch rule 1502 evaluates to Undefined. 1504 The LDAP definition for the distinguishedNameMatch rule is: 1506 ( 2.5.13.1 NAME 'distinguishedNameMatch' 1507 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) 1509 The distinguishedNameMatch rule is an equality matching rule. 1511 4.2.11. generalizedTimeMatch 1513 The generalizedTimeMatch rule compares an assertion value of the 1514 Generalized Time syntax to an attribute value of a syntax (e.g the 1515 Generalized Time syntax) whose corresponding ASN.1 type is 1516 GeneralizedTime. 1518 The rule evaluates to TRUE if and only if the attribute value 1519 represents the same universal coordinated time as the assertion 1520 value. If a time is specified with the minutes or seconds absent 1521 then the number of minutes or seconds (respectively) is assumed to be 1522 zero. 1524 The LDAP definition for the generalizedTimeMatch rule is: 1526 ( 2.5.13.27 NAME 'generalizedTimeMatch' 1527 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1529 The generalizedTimeMatch rule is an equality matching rule. 1531 4.2.12. generalizedTimeOrderingMatch 1533 The generalizedTimeOrderingMatch rule compares the time ordering of 1534 an assertion value of the Generalized Time syntax to an attribute 1535 value of a syntax (e.g the Generalized Time syntax) whose 1536 corresponding ASN.1 type is GeneralizedTime. 1538 The rule evaluates to TRUE if and only if the attribute value 1539 represents a universal coordinated time which is earlier than the 1540 universal coordinated time represented by the assertion value. 1542 The LDAP definition for the generalizedTimeOrderingMatch rule is: 1544 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' 1545 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) 1547 The generalizedTimeOrderingMatch rule is an ordering matching rule. 1549 4.2.13. integerFirstComponentMatch 1551 The integerFirstComponentMatch rule compares an assertion value of 1552 the Integer syntax to an attribute value of a syntax (e.g the DIT 1553 Structure Rule Description syntax) whose corresponding ASN.1 type is 1554 a SEQUENCE with a mandatory first component of the INTEGER ASN.1 1555 type. 1557 Note that the assertion syntax of this matching rule differs from the 1558 attribute syntax of attributes for which this is the equality 1559 matching rule. 1561 The rule evaluates to TRUE if and only if the assertion value and the 1562 first component of the attribute value are the same integer value. 1564 The LDAP definition for the integerFirstComponentMatch matching rule 1565 is: 1567 ( 2.5.13.29 NAME 'integerFirstComponentMatch' 1568 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1570 The integerFirstComponentMatch rule is an equality matching rule. 1571 When using integerFirstComponentMatch to compare two attribute values 1572 (of an applicable syntax), an assertion value must first be derived 1573 from one of the attribute values. An assertion value can be derived 1574 from an attribute value by taking the first component of that 1575 attribute value. 1577 4.2.14. integerMatch 1579 The integerMatch rule compares an assertion value of the Integer 1580 syntax to an attribute value of a syntax (e.g the Integer syntax) 1581 whose corresponding ASN.1 type is INTEGER. 1583 The rule evaluates to TRUE if and only if the attribute value and the 1584 assertion value are the same integer value. 1586 The LDAP definition for the integerMatch matching rule is: 1588 ( 2.5.13.14 NAME 'integerMatch' 1589 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) 1591 The integerMatch rule is an equality matching rule. 1593 4.2.15. numericStringMatch 1595 The numericStringMatch rule compares an assertion value of the 1596 Numeric String syntax to an attribute value of a syntax (e.g the 1597 Numeric String syntax) whose corresponding ASN.1 type is 1598 NumericString. 1600 The rule evaluates to TRUE if and only if the prepared attribute 1601 value character string and the prepared assertion value character 1602 string have the same number of characters and corresponding 1603 characters have the same code point. 1605 In preparing the attribute value and assertion value for comparison, 1606 characters are not case folded in the Map preparation step, and only 1607 numericString Insignificant Character Removal is applied in the 1608 Insignificant Character Removal step. 1610 The LDAP definition for the numericStringMatch matching rule is: 1612 ( 2.5.13.8 NAME 'numericStringMatch' 1613 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) 1615 The numericStringMatch rule is an equality matching rule. 1617 4.2.16. numericStringSubstringsMatch 1619 The numericStringSubstringsMatch rule compares an assertion value of 1620 the Substring Assertion syntax to an attribute value of a syntax (e.g 1621 the Numeric String syntax) whose corresponding ASN.1 type is 1622 NumericString. 1624 The rule evaluates to TRUE if and only if the prepared substrings of 1625 the assertion value match disjoint portions of the prepared attribute 1626 value character string in the order of the substrings in the 1627 assertion value, and an substring, if present, matches the 1628 beginning of the prepared attribute value character string, and a 1629 substring, if present, matches the end of the prepared 1630 attribute value character string. A prepared substring matches a 1631 portion of the prepared attribute value character string if 1632 corresponding characters have the same code point. 1634 In preparing the attribute value and assertion value for comparison, 1635 characters are not case folded in the Map preparation step, and only 1636 numericString Insignificant Character Removal is applied in the 1637 Insignificant Character Removal step. 1639 The LDAP definition for the numericStringSubstringsMatch matching 1640 rule is: 1642 ( 2.5.13.10 NAME 'numericStringSubstringsMatch' 1643 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1645 The numericStringSubstringsMatch rule is a substrings matching rule. 1647 4.2.17. objectIdentifierFirstComponentMatch 1649 The objectIdentifierFirstComponentMatch rule compares an assertion 1650 value of the OID syntax to an attribute value of a syntax (e.g the 1651 Attribute Type Description, DIT Content Rule Description, LDAP Syntax 1652 Description, Matching Rule Description, Matching Rule Use 1653 Description, Name Form Description or Object Class Description 1654 syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory 1655 first component of the OBJECT IDENTIFIER ASN.1 type. 1657 Note that the assertion syntax of this matching rule differs from the 1658 attribute syntax of attributes for which this is the equality 1659 matching rule. 1661 The rule evaluates to TRUE if and only if the assertion value matches 1662 the first component of the attribute value using the rules of 1663 objectIdentifierMatch. 1665 The LDAP definition for the objectIdentifierFirstComponentMatch 1666 matching rule is: 1668 ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch' 1669 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1671 The objectIdentifierFirstComponentMatch rule is an equality matching 1672 rule. When using objectIdentifierFirstComponentMatch to compare two 1673 attribute values (of an applicable syntax), an assertion value must 1674 first be derived from one of the attribute values. An assertion 1675 value can be derived from an attribute value by taking the first 1676 component of that attribute value. 1678 4.2.18. objectIdentifierMatch 1680 The objectIdentifierMatch rule compares an assertion value of the OID 1681 syntax to an attribute value of a syntax (e.g the OID syntax) whose 1682 corresponding ASN.1 type is OBJECT IDENTIFIER. 1684 The rule evaluates to TRUE if and only if the assertion value and the 1685 attribute value represent the same object identifier, that is, the 1686 same sequence of integers, whether represented explicitly in the 1687 form of or implicitly in the form (see 1688 [MODELS]). 1690 If an LDAP client supplies an assertion value in the form, 1691 and the chosen descriptor is not recognized by the server, then the 1692 objectIdentifierMatch rule evaluates to Undefined. 1694 The LDAP definition for the objectIdentifierMatch matching rule is: 1696 ( 2.5.13.0 NAME 'objectIdentifierMatch' 1697 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) 1699 The objectIdentifierMatch rule is an equality matching rule. 1701 4.2.19. octetStringMatch 1703 The octetStringMatch rule compares an assertion value of the Octet 1704 String syntax to an attribute value of a syntax (e.g the Octet String 1705 or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING 1706 ASN.1 type. 1708 The rule evaluates to TRUE if and only if the attribute value and the 1709 assertion value are the same length and corresponding octets (by 1710 position) are the same. 1712 The LDAP definition for the octetStringMatch matching rule is: 1714 ( 2.5.13.17 NAME 'octetStringMatch' 1715 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 1717 The octetStringMatch rule is an equality matching rule. 1719 4.2.20. telephoneNumberMatch 1721 The telephoneNumberMatch rule compares an assertion value of the 1722 Telephone Number syntax to an attribute value of a syntax (e.g the 1723 Telephone Number syntax) whose corresponding ASN.1 type is a 1724 PrintableString representing a telephone number. 1726 The rule evaluates to TRUE if and only if the prepared attribute 1727 value character string and the prepared assertion value character 1728 string have the same number of characters and corresponding 1729 characters have the same code point. 1731 In preparing the attribute value and assertion value for comparison, 1732 characters are case folded in the Map preparation step, and only 1733 telephoneNumber Insignificant Character Removal is applied in the 1734 Insignificant Character Removal step. 1736 The LDAP definition for the telephoneNumberMatch matching rule is: 1738 ( 2.5.13.20 NAME 'telephoneNumberMatch' 1739 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) 1741 The telephoneNumberMatch rule is an equality matching rule. 1743 4.2.21. telephoneNumberSubstringsMatch 1745 The telephoneNumberSubstringsMatch rule compares an assertion value 1746 of the Substring Assertion syntax to an attribute value of a syntax 1747 (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a 1748 PrintableString representing a telephone number. 1750 The rule evaluates to TRUE if and only if the prepared substrings of 1751 the assertion value match disjoint portions of the prepared attribute 1752 value character string in the order of the substrings in the 1753 assertion value, and an substring, if present, matches the 1754 beginning of the prepared attribute value character string, and a 1755 substring, if present, matches the end of the prepared 1756 attribute value character string. A prepared substring matches a 1757 portion of the prepared attribute value character string if 1758 corresponding characters have the same code point. 1760 In preparing the attribute value and assertion value substrings for 1761 comparison, characters are case folded in the Map preparation step, 1762 and only telephoneNumber Insignificant Character Removal is applied 1763 in the Insignificant Character Removal step. 1765 The LDAP definition for the telephoneNumberSubstringsMatch matching 1766 rule is: 1768 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' 1769 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) 1771 The telephoneNumberSubstringsMatch rule is a substrings matching 1772 rule. 1774 4.2.22. uniqueMemberMatch 1776 The uniqueMemberMatch rule compares an assertion value of the Name 1777 And Optional UID syntax to an attribute value of a syntax (e.g the 1778 Name And Optional UID syntax) whose corresponding ASN.1 type is 1779 NameAndOptionalUID. 1781 The rule evaluates to TRUE if and only if the 1782 components of the assertion value and attribute value match according 1783 to the distinguishedNameMatch rule and the component is 1784 absent from the attribute value or matches the component 1785 of the assertion value according to the bitStringMatch rule. 1787 The LDAP definition for the uniqueMemberMatch matching rule is: 1789 ( 2.5.13.23 NAME 'uniqueMemberMatch' 1790 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) 1792 The uniqueMemberMatch rule is an equality matching rule. 1794 5. Security Considerations 1795 In general, the LDAP-specific encodings for syntaxes defined in this 1796 document do not define canonical encodings. That is, a 1797 transformation from an LDAP-specific encoding into some other 1798 encoding (e.g., BER) and back into the LDAP-specific encoding will 1799 not necessarily reproduce exactly the original octets of the 1800 LDAP-specific encoding. Therefore an LDAP-specific encoding should 1801 not be used where a canonical encoding is required. 1803 Furthermore, the LDAP-specific encodings do not necessarily enable an 1804 alternative encoding of values of the Directory String and DN 1805 syntaxes to be reconstructed, e.g., a transformation from a 1806 Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific 1807 encoding and back to a DER encoding may not reproduce the original 1808 DER encoding. Therefore LDAP-specific encodings should not be used 1809 where reversibility to DER is needed, e.g., for the verification of 1810 digital signatures. Instead, DER or a DER-reversible encoding should 1811 be used. 1813 When interpreting security-sensitive fields, and in particular fields 1814 used to grant or deny access, implementations MUST ensure that any 1815 matching rule comparisons are done on the underlying abstract value, 1816 regardless of the particular encoding used. 1818 6. Acknowledgements 1820 This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T. 1821 Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working 1822 Group. 1824 This document is based upon input of the IETF LDAPBIS working group. 1825 The authors wish to thank J. Sermersheim and K. Zeilenga for their 1826 significant contribution to this revision. 1828 7. IANA Considerations 1830 The Internet Assigned Numbers Authority (IANA) is requested to update 1831 the LDAP descriptors registry [BCP64] as indicated by the following 1832 templates: 1834 Subject: Request for LDAP Descriptor Registration Update 1835 Descriptor (short name): see comment 1836 Object Identifier: see comment 1837 Person & email address to contact for further information: 1838 Steven Legg 1839 Usage: see comment 1840 Specification: RFC XXXX 1841 Author/Change Controller: IESG 1842 Comments: 1844 The following descriptors (short names) should be updated to refer 1845 to RFC XXXX. 1847 NAME Type OID 1848 ------------------------------------------------------------------ 1849 bitStringMatch M 2.5.13.16 1850 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1 1851 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2 1852 caseIgnoreListMatch M 2.5.13.11 1853 caseIgnoreMatch M 2.5.13.2 1854 caseIgnoreOrderingMatch M 2.5.13.3 1855 caseIgnoreSubstringsMatch M 2.5.13.4 1856 distinguishedNameMatch M 2.5.13.1 1857 generalizedTimeMatch M 2.5.13.27 1858 generalizedTimeOrderingMatch M 2.5.13.28 1859 integerFirstComponentMatch M 2.5.13.29 1860 integerMatch M 2.5.13.14 1861 numericStringMatch M 2.5.13.8 1862 numericStringSubstringsMatch M 2.5.13.10 1863 objectIdentifierFirstComponentMatch M 2.5.13.31 1864 octetStringMatch M 2.5.13.17 1865 telephoneNumberMatch M 2.5.13.20 1866 telephoneNumberSubstringsMatch M 2.5.13.21 1867 uniqueMemberMatch M 2.5.13.23 1869 The descriptor for the object identifier 2.5.13.0 was incorrectly 1870 registered as objectIdentifiersMatch (extraneous `s') in BCP 64. 1871 It should be changed to the following with a reference to RFC 1872 XXXX. 1874 NAME Type OID 1875 ------------------------------------------------------------------ 1876 objectIdentifierMatch M 2.5.13.0 1878 Subject: Request for LDAP Descriptor Registration 1879 Descriptor (short name): caseIgnoreIA5SubstringsMatch 1880 Object Identifier: 1.3.6.1.4.1.1466.109.114.3 1881 Person & email address to contact for further information: 1882 Steven Legg 1883 Usage: other (M) 1884 Specification: RFC XXXX 1885 Author/Change Controller: IESG 1887 Subject: Request for LDAP Descriptor Registration 1888 Descriptor (short name): caseIgnoreListSubstringsMatch 1889 Object Identifier: 2.5.13.12 1890 Person & email address to contact for further information: 1891 Steven Legg 1892 Usage: other (M) 1893 Specification: RFC XXXX 1894 Author/Change Controller: IESG 1896 Appendix A. Summary of Syntax Object Identifiers 1898 The following list summarizes the object identifiers assigned to the 1899 syntaxes defined in this document. 1901 Syntax OBJECT IDENTIFIER 1902 ============================================================== 1903 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3 1904 Bit String 1.3.6.1.4.1.1466.115.121.1.6 1905 Boolean 1.3.6.1.4.1.1466.115.121.1.7 1906 Country String 1.3.6.1.4.1.1466.115.121.1.11 1907 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14 1908 Directory String 1.3.6.1.4.1.1466.115.121.1.15 1909 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16 1910 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17 1911 DN 1.3.6.1.4.1.1466.115.121.1.12 1912 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21 1913 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22 1914 Fax 1.3.6.1.4.1.1466.115.121.1.23 1915 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24 1916 Guide 1.3.6.1.4.1.1466.115.121.1.25 1917 IA5 String 1.3.6.1.4.1.1466.115.121.1.26 1918 Integer 1.3.6.1.4.1.1466.115.121.1.27 1919 JPEG 1.3.6.1.4.1.1466.115.121.1.28 1920 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54 1921 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30 1922 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31 1923 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34 1924 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35 1925 Numeric String 1.3.6.1.4.1.1466.115.121.1.36 1926 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37 1927 Octet String 1.3.6.1.4.1.1466.115.121.1.40 1928 OID 1.3.6.1.4.1.1466.115.121.1.38 1929 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39 1930 Postal Address 1.3.6.1.4.1.1466.115.121.1.41 1931 Printable String 1.3.6.1.4.1.1466.115.121.1.44 1932 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58 1933 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50 1934 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51 1935 Telex Number 1.3.6.1.4.1.1466.115.121.1.52 1936 UTC Time 1.3.6.1.4.1.1466.115.121.1.53 1938 Appendix B. Changes from RFC 2252 & RFC 2256 1940 This annex lists the significant differences between this 1941 specification and RFC 2252 and Sections 6 and 8 of RFC 2256. 1943 This annex is provided for informational purposes only. It is not a 1944 normative part of this specification. 1946 1. The IESG Note has been removed. 1948 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS] 1949 and revised. Changes to the parts of these sections moved to 1950 [MODELS] are detailed in [MODELS]. 1952 3. BNF descriptions of syntax formats have been replaced by ABNF 1953 [ABNF] specifications. 1955 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the 1956 use of a backslash quoting mechanism to escape separator symbols 1957 has been removed. The escaping mechanism is now explicitly 1958 represented in the ABNF for the syntaxes where this provision 1959 applies. 1961 5. The description of each of the LDAP syntaxes has been expanded so 1962 that they are less dependent on knowledge of X.500 for 1963 interpretation. 1965 6. The relationship of LDAP syntaxes to corresponding ASN.1 type 1966 definitions has been made explicit. 1968 7. The set of characters allowed in a (formerly 1969 ) has been corrected to align with the 1970 PrintableString ASN.1 type in [ASN.1]. Specifically, the double 1971 quote character has been removed and the single quote character 1972 and equals sign have been added. 1974 8. Values of the Directory String, Printable String and Telephone 1975 Number syntaxes are now required to have at least one character. 1977 9. The , and 1978 rules have been moved to [MODELS]. 1980 10. The corresponding ASN.1 type for the Other Mailbox syntax has 1981 been incorporated from RFC 1274. 1983 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax 1984 has been invented. 1986 12. The Binary syntax has been removed because it was not adequately 1987 specified, implementations with different incompatible 1988 interpretations exist, and it was confused with the ;binary 1989 transfer encoding. 1991 13. All discussion of transfer options, including the ";binary" 1992 option, has been removed. All imperatives regarding binary 1993 transfer of values have been removed. 1995 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex 1996 Terminal Identifier and Telex Number syntaxes from RFC 2256 have 1997 been incorporated. 1999 15. The rule for the Enhanced Guide and Guide syntaxes has 2000 been extended to accommodate empty "and" and "or" expressions. 2002 16. An encoding for the rule in the Teletex Terminal 2003 Identifier syntax has been defined. 2005 17. The PKI-related syntaxes (Certificate, Certificate List and 2006 Certificate Pair from RFC 2252, and Supported Algorithm syntax 2007 from RFC 2256) have been removed. They are to be reintroduced in 2008 PKIX documents. 2010 18. The MHS OR Address syntax has been removed since its 2011 specification (in RFC 2156) is not at draft standard maturity. 2013 19. The DL Submit Permission syntax has been removed as it depends on 2014 the MHS OR Address syntax. 2016 20. The Presentation Address syntax has been removed since its 2017 specification (in RFC 1278) is not at draft standard maturity. 2019 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE 2020 Type, LDAP Schema Description, Master And Shadow Access Points, 2021 Modify Rights, Protocol Information, Subtree Specification, 2022 Supplier Information, Supplier Or Consumer and Supplier And 2023 Consumer syntaxes have been removed. These syntaxes are 2024 referenced in RFC 2252, but not defined. 2026 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the 2027 Mail Preference syntax have been removed on the grounds that they 2028 are out of scope for a core specification. 2030 23. The description of each of the matching rules has been expanded 2031 so that they are less dependent on knowledge of X.500 for 2032 interpretation. 2034 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has 2035 been added. 2037 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and 2038 caseIgnoreSubstringsMatch matching rules have been added to the 2039 list of matching rules for which the provisions for handling 2040 leading, trailing and multiple adjoining whitespace characters 2041 apply (now through string preparation). This is consistent with 2042 the definitions of these matching rules in X.500. The 2043 caseIgnoreIA5SubstringsMatch rule has also been added to the 2044 list. 2046 26. The specification of the octetStringMatch matching rule from RFC 2047 2256 has been added to this document. 2049 27. The presentationAddressMatch matching rule has been removed as it 2050 depends on an assertion syntax (Presentation Address) that is not 2051 at draft standard maturity. 2053 28. The protocolInformationMatch matching rule has been removed as it 2054 depends on an undefined assertion syntax (Protocol Information). 2056 29. The definitive reference for ASN.1 has been changed from X.208 to 2057 X.680 since X.680 is the version of ASN.1 referred to by X.500. 2059 30. The specification of the caseIgnoreListSubstringsMatch matching 2060 rule from RFC 2798 & X.520 has been added to this document. 2062 31. String preparation algorithms have been applied to the character 2063 string matching rules. 2065 Normative References 2067 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate 2068 Requirement Levels", BCP 14, RFC 2119, March 1997. 2070 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2071 Specifications: ABNF", RFC 2234, November 1997. 2073 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 2074 10646", RFC 3629, November 2003. 2076 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) 2077 Considerations for the Lightweight Directory Access 2078 Protocol (LDAP)", BCP 64, RFC 3383, September 2002. 2080 [LDAPDN] Zeilenga, K., "LDAP: String Representation of 2081 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work 2082 in progress, February 2004. 2084 [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis- 2085 protocol-xx.txt, a work in progress, May 2004. 2087 [E.123] Notation for national and international telephone numbers, 2088 ITU-T Recommendation E.123, 1988. 2090 [FAX] Standardization of Group 3 facsimile apparatus for 2091 document transmission - Terminal Equipment and Protocols 2092 for Telematic Services, ITU-T Recommendation T.4, 1993 2094 [T.50] International Reference Alphabet (IRA) (Formerly 2095 International Alphabet No. 5 or IA5) Information 2096 Technology - 7-Bit Coded Character Set for Information 2097 Interchange, ITU-T Recommendation T.50, 1992 2099 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, 2100 Information Technology - Message Handling Systems (MHS): 2101 Interpersonal messaging system 2103 [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, 2104 Information Technology - Open Systems Interconnection - 2105 The Directory: Models 2107 [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, 2108 Information Technology - Open Systems Interconnection - 2109 The Directory: Selected attribute types 2111 [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, 2112 Information technology - Abstract Syntax Notation One 2113 (ASN.1): Specification of basic notation 2115 [ISO3166] ISO 3166, "Codes for the representation of names of 2116 countries". 2118 [UCS] Universal Multiple-Octet Coded Character Set (UCS) - 2119 Architecture and Basic Multilingual Plane, ISO/IEC 2120 10646-1: 1993 (with amendments). 2122 [JPEG] JPEG File Interchange Format (Version 1.02). Eric 2123 Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 2124 1992. 2126 [ROADMAP] Zeilenga, K., "Lightweight Directory Access Protocol 2127 (LDAP): Technical Specification Road Map", draft-ietf- 2128 ldapbis-roadmap-xx.txt, a work in progress, February 2004. 2130 [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft- 2131 ietf-ldapbis-models-xx.txt, a work in progress, February 2132 2004. 2134 [PREP] Zeilenga, K., "LDAP: Internationalized String 2135 Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in 2136 progress, February 2004. 2138 Informative References 2140 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, 2141 "Lightweight Directory Access Protocol (v3): Attribute 2142 Syntax Definitions", RFC 2252, December 1997. 2144 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use 2145 with LDAPv3", RFC 2256, December 1997. 2147 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access 2148 Protocol (v3): Technical Specification", RFC 3377, 2149 September 2002. 2151 [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft- 2152 ietf-ldapbis-user-schema-xx.txt, a work in progress, June 2153 2003. 2155 [LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for 2156 PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in 2157 progress, July 2002. 2159 [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, 2160 Information Technology - Open Systems Interconnection - 2161 The Directory: Overview of concepts, models and services 2163 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, 2164 Information technology - ASN.1 encoding rules: 2165 Specification of Basic Encoding Rules (BER), Canonical 2166 Encoding Rules (CER) and Distinguished Encoding Rules 2167 (DER) 2169 Authors' Addresses 2171 Steven Legg 2172 Adacel Technologies Ltd. 2173 250 Bay Street 2174 Brighton, Victoria 3186 2175 AUSTRALIA 2177 Phone: +61 3 8530 7710 2178 Fax: +61 3 8530 7888 2179 Email: steven.legg@adacel.com.au 2181 Kathy Dally 2182 The MITRE Corp. 2183 7515 Colshire Dr., ms-W650 2184 McLean VA 22102 2185 USA 2187 Phone: +1 703 883 6058 2188 Fax: +1 703 883 7142 2189 Email: kdally@mitre.org 2191 Full Copyright Statement 2193 Copyright (C) The Internet Society (2004). This document is subject 2194 to the rights, licenses and restrictions contained in BCP 78, and 2195 except as set forth therein, the authors retain all their rights. 2197 This document and the information contained herein are provided on an 2198 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2199 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2200 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2201 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2202 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2203 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2205 Intellectual Property 2207 The IETF takes no position regarding the validity or scope of any 2208 Intellectual Property Rights or other rights that might be claimed to 2209 pertain to the implementation or use of the technology described in 2210 this document or the extent to which any license under such rights 2211 might or might not be available; nor does it represent that it has 2212 made any independent effort to identify any such rights. Information 2213 on the procedures with respect to rights in RFC documents can be 2214 found in BCP 78 and BCP 79. 2216 Copies of IPR disclosures made to the IETF Secretariat and any 2217 assurances of licenses to be made available, or the result of an 2218 attempt made to obtain a general license or permission for the use of 2219 such proprietary rights by implementers or users of this 2220 specification can be obtained from the IETF on-line IPR repository at 2221 http://www.ietf.org/ipr. 2223 The IETF invites any interested party to bring to its attention any 2224 copyrights, patents or patent applications, or other proprietary 2225 rights that may cover technology that may be required to implement 2226 this standard. Please address the information to the IETF at 2227 ietf-ipr@ietf.org.