7 INTERNET-DRAFT S. Legg, Editor
8 draft-ietf-ldapbis-syntaxes-07.txt Adacel Technologies
9 Intended Category: Standards Track K. Dally
10 Obsoletes: RFC 2252, RFC 2256 The MITRE Corp.
14 LDAP: Syntaxes and Matching Rules
16 Copyright (C) The Internet Society (2003). All Rights Reserved.
21 This document is an Internet-Draft and is in full conformance with
22 all provisions of Section 10 of RFC2026.
24 Internet-Drafts are working documents of the Internet Engineering
25 Task Force (IETF), its areas, and its working groups. Note that
26 other groups may also distribute working documents as
29 Internet-Drafts are draft documents valid for a maximum of six months
30 and may be updated, replaced, or obsoleted by other documents at any
31 time. It is inappropriate to use Internet-Drafts as reference
32 material or to cite them other than as "work in progress".
34 The list of current Internet-Drafts can be accessed at
35 http://www.ietf.org/ietf/1id-abstracts.txt
37 The list of Internet-Draft Shadow Directories can be accessed at
38 http://www.ietf.org/shadow.html.
40 This document is intended to be, after appropriate review and
41 revision, submitted to the RFC Editor as a Standard Track document.
42 Distribution of this document is unlimited. Technical discussion of
43 this document should take place on the IETF LDAP Revision Working
44 Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>. Please
45 send editorial comments directly to the editor
46 <steven.legg@adacel.com.au>.
48 This Internet-Draft expires on 27 April 2004.
53 Each attribute stored in a Lightweight Directory Access Protocol
54 (LDAP) directory, and whose values may be transfered in the LDAP
58 Legg & Dally Expires 27 April 2004 [Page 1]
60 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
63 protocol, has a defined syntax which constrains the structure and
64 format of its values. The comparison semantics for values of a
65 syntax are not part of the syntax definition but are instead provided
66 through separately defined matching rules. Matching rules specify an
67 argument, an assertion value, which also has a defined syntax. This
68 document defines a base set of syntaxes and matching rules for use in
69 defining attributes for LDAP directories.
114 Legg & Dally Expires 27 April 2004 [Page 2]
116 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
121 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
122 2. Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . 5
123 3. Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
124 3.1. General Considerations . . . . . . . . . . . . . . . . . 6
125 3.2. Common Definitions . . . . . . . . . . . . . . . . . . . 6
126 3.3. Syntax Definitions . . . . . . . . . . . . . . . . . . . 7
127 3.3.1. Attribute Type Description . . . . . . . . . . . 7
128 3.3.2. Bit String . . . . . . . . . . . . . . . . . . . 7
129 3.3.3. Boolean. . . . . . . . . . . . . . . . . . . . . 8
130 3.3.4. Country String . . . . . . . . . . . . . . . . . 8
131 3.3.5. Delivery Method. . . . . . . . . . . . . . . . . 9
132 3.3.6. Directory String . . . . . . . . . . . . . . . . 9
133 3.3.7. DIT Content Rule Description . . . . . . . . . . 10
134 3.3.8. DIT Structure Rule Description . . . . . . . . . 11
135 3.3.9. DN . . . . . . . . . . . . . . . . . . . . . . . 11
136 3.3.10. Enhanced Guide . . . . . . . . . . . . . . . . . 12
137 3.3.11. Facsimile Telephone Number . . . . . . . . . . . 13
138 3.3.12. Fax. . . . . . . . . . . . . . . . . . . . . . . 13
139 3.3.13. Generalized Time . . . . . . . . . . . . . . . . 14
140 3.3.14. Guide. . . . . . . . . . . . . . . . . . . . . . 15
141 3.3.15. IA5 String . . . . . . . . . . . . . . . . . . . 15
142 3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 15
143 3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
144 3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 16
145 3.3.19. Matching Rule Description. . . . . . . . . . . . 17
146 3.3.20. Matching Rule Use Description. . . . . . . . . . 17
147 3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
148 3.3.22. Name Form Description. . . . . . . . . . . . . . 18
149 3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
150 3.3.24. Object Class Description . . . . . . . . . . . . 19
151 3.3.25. Octet String . . . . . . . . . . . . . . . . . . 19
152 3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
153 3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 20
154 3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
155 3.3.29. Printable String . . . . . . . . . . . . . . . . 22
156 3.3.30. Substring Assertion. . . . . . . . . . . . . . . 22
157 3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
158 3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
159 3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 24
160 3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
161 4. Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 25
162 4.1. General Considerations . . . . . . . . . . . . . . . . . 26
163 4.2. Matching Rule Definitions. . . . . . . . . . . . . . . . 27
164 4.2.1. bitStringMatch . . . . . . . . . . . . . . . . . 27
165 4.2.2. caseExactIA5Match. . . . . . . . . . . . . . . . 28
166 4.2.3. caseIgnoreIA5Match . . . . . . . . . . . . . . . 28
170 Legg & Dally Expires 27 April 2004 [Page 3]
172 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
175 4.2.4. caseIgnoreIA5SubstringsMatch . . . . . . . . . . 29
176 4.2.5. caseIgnoreListMatch. . . . . . . . . . . . . . . 29
177 4.2.6. caseIgnoreListSubstringsMatch. . . . . . . . . . 30
178 4.2.7. caseIgnoreMatch. . . . . . . . . . . . . . . . . 31
179 4.2.8. caseIgnoreOrderingMatch. . . . . . . . . . . . . 31
180 4.2.9. caseIgnoreSubstringsMatch. . . . . . . . . . . . 32
181 4.2.10. distinguishedNameMatch . . . . . . . . . . . . . 32
182 4.2.11. generalizedTimeMatch . . . . . . . . . . . . . . 33
183 4.2.12. generalizedTimeOrderingMatch . . . . . . . . . . 33
184 4.2.13. integerFirstComponentMatch . . . . . . . . . . . 34
185 4.2.14. integerMatch . . . . . . . . . . . . . . . . . . 34
186 4.2.15. numericStringMatch . . . . . . . . . . . . . . . 35
187 4.2.16. numericStringSubstringsMatch . . . . . . . . . . 35
188 4.2.17. objectIdentifierFirstComponentMatch. . . . . . . 36
189 4.2.18. objectIdentifierMatch. . . . . . . . . . . . . . 36
190 4.2.19. octetStringMatch . . . . . . . . . . . . . . . . 37
191 4.2.20. telephoneNumberMatch . . . . . . . . . . . . . . 37
192 4.2.21. telephoneNumberSubstringsMatch . . . . . . . . . 38
193 4.2.22. uniqueMemberMatch. . . . . . . . . . . . . . . . 38
194 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 39
195 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
196 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 39
197 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
198 8.1. Normative References . . . . . . . . . . . . . . . . . . 41
199 8.2. Informative References . . . . . . . . . . . . . . . . . 42
200 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 43
201 10. Intellectual Property Notice . . . . . . . . . . . . . . . . . 44
202 Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 44
203 Appendix B. Changes from RFC 2252 & RFC 2256 . . . . . . . . . . . 45
204 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 47
208 Each attribute stored in a Lightweight Directory Access Protocol
209 (LDAP) directory [ROADMAP], and whose values may be transfered in the
210 LDAP protocol [PROT], has a defined syntax (i.e., data type) which
211 constrains the structure and format of its values. The comparison
212 semantics for values of a syntax are not part of the syntax
213 definition but are instead provided through separately defined
214 matching rules. Matching rules specify an argument, an assertion
215 value, which also has a defined syntax. This document defines a base
216 set of syntaxes and matching rules for use in defining attributes for
219 Readers are advised to familiarize themselves with the Directory
220 Information Models [MODELS] before reading the rest of this document.
221 Section 3 provides definitions for the base set of LDAP syntaxes.
222 Section 4 provides definitions for the base set of matching rules for
226 Legg & Dally Expires 27 April 2004 [Page 4]
228 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
233 This document is a integral part of the LDAP technical specification
234 [ROADMAP] which obsoletes the previously defined LDAP technical
235 specification [RFC3377] in its entirety.
237 Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
238 The remainder of RFC 2252 is obsoleted by this document. Sections 6
239 and 8 of RFC 2256 [RFC2256] are obsoleted by this document. The
240 remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS].
242 A number of schema elements which were included in the previous
243 revision of the LDAP technical specification are not included in this
244 revision of LDAP. Public Key Infrastructure schema elements are now
245 specified in [LDAP-PKI]. Unless reintroduced in future technical
246 specifications, the remainder are to be considered Historic.
248 The changes from RFC 2252 and RFC 2256 are described in Appendix B of
253 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
254 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
255 document are to be interpreted as described in BCP 14, RFC 2119
258 Syntax definitions are written according to the <SyntaxDescription>
259 ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
260 are written according to the <MatchingRuleDescription> ABNF rule
261 specified in [MODELS], except that the syntax and matching rule
262 definitions provided in this document are line-wrapped for
263 readability. When such definitions are transfered as attribute
264 values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
265 matchingRules attributes [MODELS] respectively) then those values
266 would not contain line breaks.
270 Syntax definitions constrain the structure of attribute values stored
271 in an LDAP directory, and determine the representation of attribute
272 and assertion values transfered in the LDAP protocol.
274 Syntaxes that are required for directory operation, or that are in
275 common use, are specified in this section. Servers SHOULD recognize
276 all the syntaxes listed in this document, but are not required to
277 otherwise support them, and MAY recognise or support other syntaxes.
278 However, the definition of additional arbitrary syntaxes is
282 Legg & Dally Expires 27 April 2004 [Page 5]
284 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
287 discouraged since it will hinder interoperability. Client and server
288 implementations typically do not have the ability to dynamically
289 recognize new syntaxes.
291 3.1. General Considerations
293 The description of each syntax specifies how attribute or assertion
294 values conforming to the syntax are to be represented when transfered
295 in the LDAP protocol [PROT]. This representation is referred to as
296 the LDAP-specific encoding to distinguish it from other methods of
297 encoding attribute values (e.g., the Basic Encoding Rules (BER)
298 encoding [BER] used by X.500 [X.500] directories).
300 The LDAP-specific encoding of a given attribute syntax always
301 produces octet-aligned values. To the greatest extent possible,
302 encoding rules for LDAP syntaxes should produce character strings
303 that can be displayed with little or no translation by clients
304 implementing LDAP. However, clients MUST NOT assume that the
305 LDAP-specific encoding of a value of an unrecognized syntax is a
306 human-readable character string. There are a few cases (e.g., the
307 JPEG syntax) when it is not reasonable to produce a human-readable
310 Each LDAP syntax is uniquely identified with an object identifier
311 [ASN.1] represented in the dotted-decimal format (short descriptive
312 names are not defined for syntaxes). These object identifiers are
313 not intended to be displayed to users. The object identifiers for
314 the syntaxes defined in this document are summarized in Appendix A.
316 A suggested minimum upper bound on the number of characters in an
317 attribute value with a string-based syntax, or the number of octets
318 in a value for all other syntaxes, MAY be indicated by appending the
319 bound inside of curly braces following the syntax's OBJECT IDENTIFIER
320 in an attribute type definition (see the <noidlen> rule in [MODELS]).
321 Such a bound is not considered part of the syntax identifier.
323 For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
324 definition suggests that the directory server will allow a value of
325 the attribute to be up to 64 characters long, although it may allow
326 longer character strings. Note that a single character of the
327 Directory String syntax can be encoded in more than one octet since
328 UTF-8 [UTF8] is a variable-length encoding. Therefore a 64 character
329 string may be more than 64 octets in length.
331 3.2. Common Definitions
333 The following ABNF rules are used in a number of the syntax
334 definitions in Section 3.3.
338 Legg & Dally Expires 27 April 2004 [Page 6]
340 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
343 PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
344 PLUS / COMMA / HYPHEN / DOT / EQUALS /
345 SLASH / COLON / QUESTION / SPACE
346 PrintableString = 1*PrintableCharacter
347 IA5String = *(%x00-7F)
348 HEX-DIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
349 ; N.B. allows upper and lower case
350 SLASH = %x2F ; forward slash ("/")
351 COLON = %x3A ; colon (":")
352 QUESTION = %x3F ; question mark ("?")
354 The <OCTET>, <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>,
355 <COMMA>, <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in
358 3.3. Syntax Definitions
360 3.3.1. Attribute Type Description
362 A value of the Attribute Type Description syntax is the definition of
363 an attribute type. The LDAP-specific encoding of a value of this
364 syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
365 For example, the following definition of the createTimestamp
366 attribute type from [MODELS] is also a value of the Attribute Type
367 Description syntax (note: line breaks have been added for readability
368 - they are not part of the value when transfered in protocol).
370 ( 2.5.18.1 NAME 'createTimestamp'
371 EQUALITY generalizedTimeMatch
372 ORDERING generalizedTimeOrderingMatch
373 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
374 SINGLE-VALUE NO-USER-MODIFICATION
375 USAGE directoryOperation )
377 The LDAP definition for the Attribute Type Description syntax is:
379 ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
381 This syntax corresponds to the AttributeTypeDescription ASN.1 type
386 A value of the Bit String syntax is a sequence of binary digits. The
387 LDAP-specific encoding of a value of this syntax is defined by the
390 BitString = SQUOTE *binary-digit SQUOTE "B"
394 Legg & Dally Expires 27 April 2004 [Page 7]
396 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
399 binary-digit = "0" / "1"
401 The <SQUOTE> rule is defined in [MODELS].
406 The LDAP definition for the Bit String syntax is:
408 ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
410 This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
414 A value of the Boolean syntax is one of the Boolean values, true or
415 false. The LDAP-specific encoding of a value of this syntax is
416 defined by the following ABNF:
418 Boolean = "TRUE" / "FALSE"
420 The LDAP definition for the Boolean syntax is:
422 ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
424 This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
426 3.3.4. Country String
428 A value of the Country String syntax is one of the two-character
429 codes from ISO 3166 [ISO3166] for representing a country. The
430 LDAP-specific encoding of a value of this syntax is defined by the
433 CountryString = 2(PrintableCharacter)
435 The <PrintableCharacter> rule is defined in Section 3.2.
441 The LDAP definition for the Country String syntax is:
443 ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
445 This syntax corresponds to the following ASN.1 type from [X.520]:
450 Legg & Dally Expires 27 April 2004 [Page 8]
452 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
455 PrintableString (SIZE (2)) -- ISO 3166 codes only
457 3.3.5. Delivery Method
459 A value of the Delivery Method syntax is a sequence of items that
460 indicate, in preference order, the service(s) by which an entity is
461 willing and/or capable of receiving messages. The LDAP-specific
462 encoding of a value of this syntax is defined by the following ABNF:
464 DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
466 pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
467 "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
469 The <WSP> and <DOLLAR> rules are defined in [MODELS].
474 The LDAP definition for the Delivery Method syntax is:
476 ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
478 This syntax corresponds to the following ASN.1 type from [X.520]:
480 SEQUENCE OF INTEGER {
481 any-delivery-method (0),
483 physical-delivery (2),
485 teletex-delivery (4),
486 g3-facsimile-delivery (5),
487 g4-facsimile-delivery (6),
488 ia5-terminal-delivery (7),
489 videotex-delivery (8),
490 telephone-delivery (9) }
492 3.3.6. Directory String
494 A value of the Directory String syntax is a string of one or more
495 arbitrary characters from the Universal Character Set (UCS) [UCS]. A
496 zero length character string is not permitted. The LDAP-specific
497 encoding of a value of this syntax is the UTF-8 encoding [UTF8] of
498 the character string. Such encodings conform to the following ABNF:
500 DirectoryString = 1*UTF8
502 The <UTF8> rule is defined in [MODELS].
506 Legg & Dally Expires 27 April 2004 [Page 9]
508 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
512 This is a value of Directory String containing #!%#@.
514 Servers and clients MUST be prepared to receive arbitrary UCS code
515 points, including code points outside the range of printable ASCII
516 and code points not presently assigned to any character.
518 Attribute type definitions using the Directory String syntax should
519 not restrict the format of Directory String values, e.g., by
520 requiring that the character string conforms to specific patterns
521 described by ABNF. A new syntax should be defined in such cases.
523 The LDAP definition for the Directory String syntax is:
525 ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
527 This syntax corresponds to the DirectoryString parameterized ASN.1
530 The DirectoryString ASN.1 type allows a choice between the
531 TeletexString, PrintableString or UniversalString ASN.1 types from
532 [ASN.1]. However, note that the chosen alternative is not indicated
533 in the LDAP-specific encoding of a Directory String value.
535 Implementations which convert Directory String values from the
536 LDAP-specific encoding to the BER encoding used by X.500 must choose
537 an alternative that permits the particular characters in the string,
538 and must convert the characters from the UTF-8 encoding into the
539 character encoding of the chosen alternative.
541 When converting Directory String values from the BER encoding to the
542 LDAP-specific encoding the characters must be converted from the
543 character encoding of the chosen alternative into the UTF-8 encoding.
545 3.3.7. DIT Content Rule Description
547 A value of the DIT Content Rule Description syntax is the definition
548 of a DIT (Directory Information Tree) content rule. The
549 LDAP-specific encoding of a value of this syntax is defined by the
550 <DITContentRuleDescription> rule in [MODELS].
553 ( 2.5.6.4 DESC 'content rule for organization'
554 NOT ( x121Address $ telexNumber ) )
556 Note: a line break has been added for readability - it is not part of
562 Legg & Dally Expires 27 April 2004 [Page 10]
564 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
567 The LDAP definition for the DIT Content Rule Description syntax is:
569 ( 1.3.6.1.4.1.1466.115.121.1.16
570 DESC 'DIT Content Rule Description' )
572 This syntax corresponds to the DITContentRuleDescription ASN.1 type
575 3.3.8. DIT Structure Rule Description
577 A value of the DIT Structure Rule Description syntax is the
578 definition of a DIT structure rule. The LDAP-specific encoding of a
579 value of this syntax is defined by the <DITStructureRuleDescription>
583 ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
585 The LDAP definition for the DIT Structure Rule Description syntax is:
587 ( 1.3.6.1.4.1.1466.115.121.1.17
588 DESC 'DIT Structure Rule Description' )
590 This syntax corresponds to the DITStructureRuleDescription ASN.1 type
595 A value of the DN syntax is the (purported) distinguished name (DN)
596 of an entry [MODELS]. The LDAP-specific encoding of a value of this
597 syntax is defined by the <distinguishedName> rule in [LDAPDN].
599 Examples (from [LDAPDN]):
600 UID=jsmith,DC=example,DC=net
601 OU=Sales+CN=J. Smith,DC=example,DC=net
602 CN=John Smith\, III,DC=example,DC=net
603 CN=Before\0dAfter,DC=example,DC=net
604 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
607 The LDAP definition for the DN syntax is:
609 ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
611 The DN syntax corresponds to the DistinguishedName ASN.1 type from
612 [X.501]. Note that a BER encoded distinguished name (as used by
613 X.500) re-encoded into the LDAP-specific encoding is not necessarily
614 reversible to the original BER encoding since the chosen string type
618 Legg & Dally Expires 27 April 2004 [Page 11]
620 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
623 in any DirectoryString components of the distinguished name is not
624 indicated in the LDAP-specific encoding of the distinguished name
627 3.3.10. Enhanced Guide
629 A value of the Enhanced Guide syntax suggests criteria, which consist
630 of combinations of attribute types and filter operators, to be used
631 in constructing filters to search for entries of particular object
632 classes. The Enhanced Guide syntax improves upon the Guide syntax by
633 allowing the recommended depth of the search to be specified.
635 The LDAP-specific encoding of a value of this syntax is defined by
638 EnhancedGuide = object-class SHARP WSP criteria WSP
640 object-class = WSP oid WSP
641 subset = "baseobject" / "oneLevel" / "wholeSubtree"
643 criteria = and-term *( BAR and-term )
644 and-term = term *( AMPERSAND term )
645 term = EXCLAIM term /
646 attributetype DOLLAR match-type /
647 LPAREN criteria RPAREN /
650 match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
653 BAR = %x7C ; vertical bar ("|")
654 AMPERSAND = %x26 ; ampersand ("&")
655 EXCLAIM = %x21 ; exclamation mark ("!")
657 The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
658 <DOLLAR> rules are defined in [MODELS].
660 The LDAP definition for the Enhanced Guide syntax is:
662 ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
666 person#(sn$EQ)#oneLevel
668 The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
669 from [X.520]. The EnhancedGuide type references the Criteria ASN.1
670 type, also from [X.520]. The <true> rule above represents an empty
674 Legg & Dally Expires 27 April 2004 [Page 12]
676 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
679 "and" expression in a value of the Criteria type. The <false> rule
680 above represents an empty "or" expression in a value of the Criteria
683 3.3.11. Facsimile Telephone Number
685 A value of the Facsimile Telephone Number syntax is a subscriber
686 number of a facsimile device on the public switched telephone
687 network. The LDAP-specific encoding of a value of this syntax is
688 defined by the following ABNF:
690 fax-number = telephone-number *( DOLLAR fax-parameter )
691 telephone-number = PrintableString
692 fax-parameter = "twoDimensional" /
700 The <telephone-number> is a string of printable characters that
701 complies with the internationally agreed format for representing
702 international telephone numbers [E.123]. The <PrintableString> rule
703 is defined in Section 3.2. The <DOLLAR> rule is defined in [MODELS].
705 The LDAP definition for the Facsimile Telephone Number syntax is:
707 ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
709 The Facsimile Telephone Number syntax corresponds to the
710 FacsimileTelephoneNumber ASN.1 type from [X.520].
714 A value of the Fax syntax is an image which is produced using the
715 Group 3 facsimile process [FAX] to duplicate an object, such as a
716 memo. The LDAP-specific encoding of a value of this syntax is the
717 string of octets for a Group 3 Fax image as defined in [FAX].
719 The LDAP definition for the Fax syntax is:
721 ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
723 The ASN.1 type corresponding to the Fax syntax is defined as follows,
724 assuming EXPLICIT TAGS:
730 Legg & Dally Expires 27 April 2004 [Page 13]
732 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
735 g3-facsimile [3] G3FacsimileBodyPart
738 The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
740 3.3.13. Generalized Time
742 A value of the Generalized Time syntax is a character string
743 representing a date and time. The LDAP-specific encoding of a value
744 of this syntax is a restriction of the format defined in [ISO8601],
745 and is described by the following ABNF:
747 century = 2(%x30-39) ; "00" to "99"
748 year = 2(%x30-39) ; "00" to "99"
749 month = ( %x30 %x31-39 ) ; "01" (January) to "09"
750 / ( %x31 %x30-32 ) ; "10" to "12"
751 day = ( %x30 %x31-39 ) ; "01" to "09"
752 / ( %x31-32 %x30-39 ) ; "10" to "29"
753 / ( %x33 %x30-31 ) ; "30" to "31"
754 hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
755 minute = %x30-35 %x30-39 ; "00" to "59"
756 second = ( %x30-35 %x30-39 ) ; "00" to "59"
757 / ( %x36 %x30 ) ; "60" (a leap second)
759 GeneralizedTime = century year month day hour
760 [ minute [ second ] ] [ fraction ]
762 fraction = ( DOT / COMMA ) 1*(%x30-39)
763 g-time-zone = %x5A ; "Z"
765 g-differential = ( MINUS / PLUS ) hour [ minute ]
766 MINUS = %x2D ; minus sign ("-")
768 The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
770 The time value represents coordinated universal time (equivalent to
771 Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
772 otherwise the value represents a local time in the time zone
773 indicated by <g-differential>. In the latter case, coordinated
774 universal time can be calculated by subtracting the differential from
775 the local time. The "Z" form of <g-time-zone> SHOULD be used in
776 preference to <g-differential>.
782 Both example values represent the same coordinated universal time:
786 Legg & Dally Expires 27 April 2004 [Page 14]
788 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
791 10:32 AM, December 16, 1994.
793 The LDAP definition for the Generalized Time syntax is:
795 ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
797 This syntax corresponds to the GeneralizedTime ASN.1 type from
798 [ASN.1], with the constraint that local time without a differential
803 A value of the Guide syntax suggests criteria, which consist of
804 combinations of attribute types and filter operators, to be used in
805 constructing filters to search for entries of particular object
806 classes. The Guide syntax is obsolete and should not be used for
807 defining new attribute types.
809 The LDAP-specific encoding of a value of this syntax is defined by
812 Guide = [ object-class SHARP ] criteria
814 The <object-class> and <criteria> rules are defined in Section
815 3.3.10. The <SHARP> rule is defined in [MODELS].
817 The LDAP definition for the Guide syntax is:
819 ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
821 The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
825 A value of the IA5 String syntax is a string of zero, one or more
826 characters from International Alphabet 5 (IA5) [T.50], the
827 international version of the ASCII character set. The LDAP-specific
828 encoding of a value of this syntax is the unconverted string of
829 characters, which conforms to the <IA5String> rule in Section 3.2.
831 The LDAP definition for the IA5 String syntax is:
833 ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
835 This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
842 Legg & Dally Expires 27 April 2004 [Page 15]
844 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
847 A value of the Integer syntax is a whole number of unlimited
848 magnitude. The LDAP-specific encoding of a value of this syntax is
849 the optionally signed decimal digit character string representation
850 of the number (so, for example, the number 1321 is represented by the
851 character string "1321"). The encoding is defined by the following
854 Integer = ( HYPHEN LDIGIT *DIGIT ) / number
856 The <HYPHEN>, <LDIGIT>, <DIGIT> and <number> rules are defined in
859 The LDAP definition for the Integer syntax is:
861 ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
863 This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
867 A value of the JPEG syntax is an image in the JPEG File Interchange
868 Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of
869 a value of this syntax is the sequence of octets of the JFIF encoding
872 The LDAP definition for the JPEG syntax is:
874 ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
876 The JPEG syntax corresponds to the following ASN.1 type:
878 JPEG ::= OCTET STRING (CONSTRAINED BY
879 { -- contents octets are an image in the --
880 -- JPEG File Interchange Format -- })
882 3.3.18. LDAP Syntax Description
884 A value of the LDAP Syntax Description syntax is the description of
885 an LDAP syntax. The LDAP-specific encoding of a value of this syntax
886 is defined by the <SyntaxDescription> rule in [MODELS].
888 The LDAP definition for the LDAP Syntax Description syntax is:
890 ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
892 The above LDAP definition for the LDAP Syntax Description syntax is
893 itself a legal value of the LDAP Syntax Description syntax.
898 Legg & Dally Expires 27 April 2004 [Page 16]
900 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
903 The ASN.1 type corresponding to the LDAP Syntax Description syntax is
904 defined as follows, assuming EXPLICIT TAGS:
906 LDAPSyntaxDescription ::= SEQUENCE {
907 identifier OBJECT IDENTIFIER,
908 description DirectoryString { ub-schema } OPTIONAL }
910 The DirectoryString parameterized ASN.1 type is defined in [X.520].
912 The value of ub-schema (an integer) is implementation defined. A
913 non-normative definition appears in [X.520].
915 3.3.19. Matching Rule Description
917 A value of the Matching Rule Description syntax is the definition of
918 a matching rule. The LDAP-specific encoding of a value of this
919 syntax is defined by the <MatchingRuleDescription> rule in [MODELS].
922 ( 2.5.13.2 NAME 'caseIgnoreMatch'
923 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
925 Note: a line break has been added for readability - it is not part of
928 The LDAP definition for the Matching Rule Description syntax is:
930 ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
932 This syntax corresponds to the MatchingRuleDescription ASN.1 type
935 3.3.20. Matching Rule Use Description
937 A value of the Matching Rule Use Description syntax indicates the
938 attribute types to which a matching rule may be applied in an
939 extensibleMatch search filter [PROT]. The LDAP-specific encoding of
940 a value of this syntax is defined by the <MatchingRuleUseDescription>
944 ( 2.5.13.16 APPLIES ( givenName $ surname ) )
946 The LDAP definition for the Matching Rule Use Description syntax is:
948 ( 1.3.6.1.4.1.1466.115.121.1.31
949 DESC 'Matching Rule Use Description' )
954 Legg & Dally Expires 27 April 2004 [Page 17]
956 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
959 This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
962 3.3.21. Name and Optional UID
964 A value of the Name and Optional UID syntax is the distinguished name
965 [MODELS] of an entity optionally accompanied by a unique identifier
966 that serves to differentiate the entity from others with an identical
969 The LDAP-specific encoding of a value of this syntax is defined by
972 NameAndOptionalUID = distinguishedName [ SHARP BitString ]
974 The <BitString> rule is defined in Section 3.3.2. The
975 <distinguishedName> rule is defined in [LDAPDN]. The <SHARP> rule is
978 Note that although the '#' character may occur in the string
979 representation of a distinguished name, no additional escaping of
980 this character is performed when a <distinguishedName> is encoded in
981 a <NameAndOptionalUID>.
984 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
986 The LDAP definition for the Name and Optional UID syntax is:
988 ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
990 This syntax corresponds to the NameAndOptionalUID ASN.1 type from
993 3.3.22. Name Form Description
995 A value of the Name Form Description syntax is the definition of a
996 name form, which regulates how entries may be named. The
997 LDAP-specific encoding of a value of this syntax is defined by the
998 <NameFormDescription> rule in [MODELS].
1001 ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
1003 The LDAP definition for the Name Form Description syntax is:
1005 ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
1010 Legg & Dally Expires 27 April 2004 [Page 18]
1012 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1015 This syntax corresponds to the NameFormDescription ASN.1 type from
1018 3.3.23. Numeric String
1020 A value of the Numeric String syntax is a sequence of one or more
1021 numerals and spaces. The LDAP-specific encoding of a value of this
1022 syntax is the unconverted string of characters, which conforms to the
1025 NumericString = 1*(DIGIT / SPACE)
1027 The <DIGIT> and <SPACE> rules are defined in [MODELS].
1032 The LDAP definition for the Numeric String syntax is:
1034 ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
1036 This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
1038 3.3.24. Object Class Description
1040 A value of the Object Class Description syntax is the definition of
1041 an object class. The LDAP-specific encoding of a value of this
1042 syntax is defined by the <ObjectClassDescription> rule in [MODELS].
1045 ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
1046 MAY ( searchGuide $ description ) )
1048 Note: a line break has been added for readability - it is not part of
1051 The LDAP definition for the Object Class Description syntax is:
1053 ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
1055 This syntax corresponds to the ObjectClassDescription ASN.1 type from
1058 3.3.25. Octet String
1060 A value of the Octet String syntax is a sequence of zero, one or more
1061 arbitrary octets. The LDAP-specific encoding of a value of this
1062 syntax is the unconverted sequence of octets, which conforms to the
1066 Legg & Dally Expires 27 April 2004 [Page 19]
1068 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1073 OctetString = *OCTET
1075 The <OCTET> rule is defined in [MODELS]. Values of this syntax are
1076 not generally human-readable.
1078 The LDAP definition for the Octet String syntax is:
1080 ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
1082 This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
1086 A value of the OID syntax is an object identifier; a sequence of two
1087 or more non-negative integers that uniquely identify some object or
1088 item of specification. Many of the object identifiers used in LDAP
1089 also have IANA registered names [RFC3383].
1091 The LDAP-specific encoding of a value of this syntax is defined by
1092 the <oid> rule in [MODELS].
1098 The LDAP definition for the OID syntax is:
1100 ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
1102 This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
1105 3.3.27. Other Mailbox
1107 A value of the Other Mailbox syntax identifies an electronic mailbox,
1108 in a particular named mail system. The LDAP-specific encoding of a
1109 value of this syntax is defined by the following ABNF:
1111 OtherMailbox = mailbox-type DOLLAR mailbox
1112 mailbox-type = PrintableString
1115 The <mailbox-type> rule represents the type of mail system in which
1116 the mailbox resides, for example "MCIMail", and <mailbox> is the
1117 actual mailbox in the mail system described by <mailbox-type>. The
1118 <PrintableString> and <IA5String> rules are defined in Section 3.2.
1122 Legg & Dally Expires 27 April 2004 [Page 20]
1124 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1127 The <DOLLAR> rule is defined in [MODELS].
1129 The LDAP definition for the Other Mailbox syntax is:
1131 ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
1133 The ASN.1 type corresponding to the Other Mailbox syntax is defined
1134 as follows, assuming EXPLICIT TAGS:
1136 OtherMailbox ::= SEQUENCE {
1137 mailboxType PrintableString,
1141 3.3.28. Postal Address
1143 A value of the Postal Address syntax is a sequence of strings of one
1144 or more arbitrary UCS characters, which form an address in a physical
1147 The LDAP-specific encoding of a value of this syntax is defined by
1150 PostalAddress = line *( DOLLAR line )
1153 / (%x5C "24") ; escaped "$"
1155 / (%x5C "5C") ; escaped "\"
1159 Each character string (i.e., <line>) of a postal address value is
1160 encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
1161 if they occur in the string, are escaped by a "\" character followed
1162 by the two hexadecimal digit code for the character. The <HEX-DIGIT>
1163 rule is defined in Section 3.2. The <DOLLAR> and <UTFMB> rules are
1164 defined in [MODELS].
1166 Many servers limit the postal address to no more than six lines of no
1167 more than thirty characters each.
1170 1234 Main St.$Anytown, CA 12345$USA
1171 \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
1173 The LDAP definition for the Postal Address syntax is:
1178 Legg & Dally Expires 27 April 2004 [Page 21]
1180 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1183 ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
1185 This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
1188 PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
1189 DirectoryString { ub-postal-string }
1191 The values of ub-postal-line and ub-postal-string (both integers) are
1192 implementation defined. Non-normative definitions appear in [X.520].
1194 3.3.29. Printable String
1196 A value of the Printable String syntax is a string of one or more
1197 latin alphabetic, numeric, and selected punctuation characters as
1198 specified by the <PrintableCharacter> rule in Section 3.2.
1200 The LDAP-specific encoding of a value of this syntax is the
1201 unconverted string of characters, which conforms to the
1202 <PrintableString> rule in Section 3.2.
1205 This is a PrintableString.
1207 The LDAP definition for the PrintableString syntax is:
1209 ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
1211 This syntax corresponds to the PrintableString ASN.1 type from
1214 3.3.30. Substring Assertion
1216 A value of the Substring Assertion syntax is a sequence of zero, one
1217 or more character substrings used as an argument for substring
1218 extensible matching of character string attribute values, i.e., as
1219 the matchValue of a MatchingRuleAssertion [PROT]. Each substring is
1220 a string of one or more arbitrary characters from the Universal
1221 Character Set (UCS) [UCS]. A zero length substring is not permitted.
1223 The LDAP-specific encoding of a value of this syntax is defined by
1226 SubstringAssertion = [ initial ] any [ final ]
1229 any = ASTERISK *(substring ASTERISK)
1234 Legg & Dally Expires 27 April 2004 [Page 22]
1236 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1239 ASTERISK = %x2A ; asterisk ("*")
1241 substring = 1*substring-character
1242 substring-character = %x00-29
1243 / (%x5C "2A") ; escaped "*"
1245 / (%x5C "5C") ; escaped "\"
1249 Each <substring> of a Substring Assertion value is encoded as a UTF-8
1250 [UTF8] string, except that "\" and "*" characters, if they occur in
1251 the substring, are escaped by a "\" character followed by the two
1252 hexadecimal digit code for the character.
1254 The Substring Assertion syntax is used only as the syntax of
1255 assertion values in the extensible match. It is not used as an
1256 attribute syntax, or in the SubstringFilter [PROT].
1258 The LDAP definition for the Substring Assertion syntax is:
1260 ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
1262 This syntax corresponds to the SubstringAssertion ASN.1 type from
1265 3.3.31. Telephone Number
1267 A value of the Telephone Number syntax is a string of printable
1268 characters that complies with the internationally agreed format for
1269 representing international telephone numbers [E.123].
1271 The LDAP-specific encoding of a value of this syntax is the
1272 unconverted string of characters, which conforms to the
1273 <PrintableString> rule in Section 3.2.
1275 Example: +1 512 315 0280
1277 The LDAP definition for the Telephone Number syntax is:
1279 ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
1281 The Telephone Number syntax corresponds to the following ASN.1 type
1284 PrintableString (SIZE(1..ub-telephone-number))
1286 The value of ub-telephone-number (an integer) is implementation
1290 Legg & Dally Expires 27 April 2004 [Page 23]
1292 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1295 defined. A non-normative definition appears in [X.520].
1297 3.3.32. Teletex Terminal Identifier
1299 A value of this syntax specifies the identifier and (optionally)
1300 parameters of a teletex terminal.
1302 The LDAP-specific encoding of a value of this syntax is defined by
1305 teletex-id = ttx-term *(DOLLAR ttx-param)
1306 ttx-term = PrintableString ; terminal identifier
1307 ttx-param = ttx-key COLON ttx-value ; parameter
1308 ttx-key = "graphic" / "control" / "misc" / "page" / "private"
1309 ttx-value = *ttx-value-char
1311 ttx-value-char = %x00-23
1312 / (%x5C "24") ; escaped "$"
1314 / (%x5C "5C") ; escaped "\"
1317 The <PrintableString> and <COLON> rules are defined in Section 3.2.
1318 The <DOLLAR> rule is defined in [MODELS].
1320 The LDAP definition for the Teletex Terminal Identifier syntax is:
1322 ( 1.3.6.1.4.1.1466.115.121.1.51
1323 DESC 'Teletex Terminal Identifier' )
1325 This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
1328 3.3.33. Telex Number
1330 A value of the Telex Number syntax specifies the telex number,
1331 country code and answerback code of a telex terminal.
1333 The LDAP-specific encoding of a value of this syntax is defined by
1336 telex-number = actual-number DOLLAR country-code
1338 actual-number = PrintableString
1339 country-code = PrintableString
1340 answerback = PrintableString
1342 The <PrintableString> rule is defined in Section 3.2. The <DOLLAR>
1346 Legg & Dally Expires 27 April 2004 [Page 24]
1348 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1351 rule is defined in [MODELS].
1353 The LDAP definition for the Telex Number syntax is:
1355 ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
1357 This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
1361 A value of the UTC Time syntax is a character string representing a
1362 date and time to a precision of one minute or one second. The year
1363 is given as a two-digit number. The LDAP-specific encoding of a
1364 value of this syntax follows the format defined in [ASN.1] for the
1365 UTCTime type and is described by the following ABNF:
1367 UTCTime = year month day hour minute [ second ]
1369 u-time-zone = %x5A ; "Z"
1371 u-differential = ( MINUS / PLUS ) hour minute
1373 The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
1374 rules are defined in Section 3.3.13. The <PLUS> rule is defined in
1377 The time value represents coordinated universal time if the "Z" form
1378 of <u-time-zone> is used, otherwise the value represents a local
1379 time. In the latter case, if <u-differential> is provided then
1380 coordinated universal time can be calculated by subtracting the
1381 differential from the local time. The <u-time-zone> SHOULD be
1382 present in time values and the "Z" form of <u-time-zone> SHOULD be
1383 used in preference to <u-differential>.
1385 The LDAP definition for the UTC Time syntax is:
1387 ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
1389 Note: This syntax is deprecated in favor of the Generalized Time
1392 The UTC Time syntax corresponds to the UTCTime ASN.1 type from
1397 Matching rules are used by directory implementations to compare
1398 attribute values against assertion values when performing Search and
1402 Legg & Dally Expires 27 April 2004 [Page 25]
1404 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1407 Compare operations [PROT]. They are also used when comparing a
1408 purported distinguished name [MODELS] with the name of an entry.
1409 When modifying entries, matching rules are used to identify values to
1410 be deleted and to prevent an attribute from containing two equal
1413 Matching rules that are required for directory operation, or that are
1414 in common use, are specified in this section.
1416 4.1. General Considerations
1418 A matching rule is applied to attribute values through an
1419 AttributeValueAssertion or MatchingRuleAssertion [PROT]. The
1420 conditions under which an AttributeValueAssertion or
1421 MatchingRuleAssertion evaluates to Undefined are specified in [PROT].
1422 If an assertion is not Undefined then the result of the assertion is
1423 the result of applying the selected matching rule. A matching rule
1424 evaluates to TRUE, and in some cases Undefined, as specified in the
1425 description of the matching rule, otherwise it evaluates to FALSE.
1427 Each assertion contains an assertion value. The definition of each
1428 matching rule specifies the syntax for the assertion value. The
1429 syntax of the assertion value is typically, but not necessarily, the
1430 same as the syntax of the attribute values to which the matching rule
1431 may be applied. Note that the AssertionValue in a SubstringFilter
1432 [PROT] MUST conform to the assertion syntax of the equality matching
1433 rule for the attribute type rather than the assertion syntax of the
1434 substrings matching rule for the attribute type. The entire
1435 SubstringFilter is converted into an assertion value of the
1436 substrings matching rule prior to applying the rule.
1438 The definition of each matching rule indicates the attribute syntaxes
1439 to which the rule may be applied, by specifying conditions the
1440 corresponding ASN.1 type of a candidate attribute syntax must
1441 satisfy. These conditions are also satisfied if the corresponding
1442 ASN.1 type is a tagged or constrained derivative of the ASN.1 type
1443 explicitly mentioned in the rule description (i.e., ASN.1 tags and
1444 constraints are ignored in checking applicability), or an alternative
1445 reference notation for the explicitly mentioned type. Each rule
1446 description lists as examples of applicable attribute syntaxes, the
1447 complete list of the syntaxes defined in this document to which the
1448 matching rule applies. A matching rule may be applicable to
1449 additional syntaxes defined in other documents if those syntaxes
1450 satisfy the conditions on the corresponding ASN.1 type.
1452 The description of each matching rule indicates whether the rule is
1453 suitable for use as the equality matching rule (EQUALITY), ordering
1454 matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
1458 Legg & Dally Expires 27 April 2004 [Page 26]
1460 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1463 attribute type definition [MODELS].
1465 Each matching rule is uniquely identified with an object identifier.
1466 The definition of a matching rule should not be subsequently changed.
1467 If a change is desirable then a new matching rule with a different
1468 object identifier should be defined instead.
1470 Servers SHOULD implement all the matching rules in Section 4.2.
1471 Servers MAY implement additional matching rules.
1473 Servers which implement the extensibleMatch filter SHOULD allow the
1474 matching rules listed in Section 4.2 to be used in the
1475 extensibleMatch filter and SHOULD allow matching rules to be used
1476 with all attribute types known to the server, where the assertion
1477 syntax of the matching rule is the same as the value syntax of the
1480 Servers MUST publish in the matchingRules attribute, the definitions
1481 of matching rules referenced by values of the attributeTypes and
1482 matchingRuleUse attributes in the same subschema entry. Other
1483 unreferenced matching rules MAY be published in the matchingRules
1486 If the server supports the extensibleMatch filter, then the server
1487 MAY use the matchingRuleUse attribute to indicate the applicability
1488 (in an extensibleMatch filter) of selected matching rules to
1489 nominated attribute types.
1491 4.2. Matching Rule Definitions
1493 When evaluating the numericStringMatch, numericStringSubstringsMatch,
1494 caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch,
1495 caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch,
1496 caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch,
1497 telephoneNumberMatch and telephoneNumberSubstringsMatch matching
1498 rules the assertion value and attribute value are prepared according
1499 to the string preparation algorithms [PREP] for LDAP before being
1500 compared. The Transcode, Normalize, Prohibit and Check bidi steps
1501 are the same for each of the matching rules. However, the Map and
1502 Insignificant Character Removal steps depends on the specific rule,
1503 as detailed in the description of these matching rules in the
1504 sections that follow.
1506 4.2.1. bitStringMatch
1508 The bitStringMatch rule compares an assertion value of the Bit String
1509 syntax to an attribute value of a syntax (e.g., the Bit String
1510 syntax) whose corresponding ASN.1 type is BIT STRING.
1514 Legg & Dally Expires 27 April 2004 [Page 27]
1516 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1519 If the corresponding ASN.1 type of the attribute syntax does not have
1520 a named bit list (which is the case for the Bit String syntax) then
1521 the rule evaluates to TRUE if and only if the attribute value has the
1522 same number of bits as the assertion value and the bits match on a
1525 If the corresponding ASN.1 type does have a named bit list then
1526 bitStringMatch operates as above except that trailing zero bits in
1527 the attribute and assertion values are treated as absent.
1529 The LDAP definition for the bitStringMatch rule is:
1531 ( 2.5.13.16 NAME 'bitStringMatch'
1532 SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
1534 The bitStringMatch rule is an equality matching rule.
1536 4.2.2. caseExactIA5Match
1538 The caseExactIA5Match rule compares an assertion value of the IA5
1539 String syntax to an attribute value of a syntax (e.g the IA5 String
1540 syntax) whose corresponding ASN.1 type is IA5String.
1542 The rule evaluates to TRUE if and only if the prepared attribute
1543 value character string and the prepared assertion value character
1544 string have the same number of characters and corresponding
1545 characters have the same code point.
1547 In preparing the attribute value and assertion value for comparison,
1548 characters are not case folded in the Map preparation step, and only
1549 Insignificant Space Removal is applied in the Insignificant Character
1552 The LDAP definition for the caseExactIA5Match rule is:
1554 ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
1555 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1557 The caseExactIA5Match rule is an equality matching rule.
1559 4.2.3. caseIgnoreIA5Match
1561 The caseIgnoreIA5Match rule compares an assertion value of the IA5
1562 String syntax to an attribute value of a syntax (e.g the IA5 String
1563 syntax) whose corresponding ASN.1 type is IA5String.
1565 The rule evaluates to TRUE if and only if the prepared attribute
1566 value character string and the prepared assertion value character
1570 Legg & Dally Expires 27 April 2004 [Page 28]
1572 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1575 string have the same number of characters and corresponding
1576 characters have the same code point.
1578 In preparing the attribute value and assertion value for comparison,
1579 characters are case folded in the Map preparation step, and only
1580 Insignificant Space Removal is applied in the Insignificant Character
1583 The LDAP definition for the caseIgnoreIA5Match rule is:
1585 ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
1586 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1588 The caseIgnoreIA5Match rule is an equality matching rule.
1590 4.2.4. caseIgnoreIA5SubstringsMatch
1592 The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
1593 the Substring Assertion syntax to an attribute value of a syntax (e.g
1594 the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
1596 The rule evaluates to TRUE if and only if the prepared substrings of
1597 the assertion value match disjoint portions of the prepared attribute
1598 value character string in the order of the substrings in the
1599 assertion value, and an <initial> substring, if present, matches the
1600 beginning of the prepared attribute value character string, and a
1601 <final> substring, if present, matches the end of the prepared
1602 attribute value character string. A prepared substring matches a
1603 portion of the prepared attribute value character string if
1604 corresponding characters have the same code point.
1606 In preparing the attribute value and assertion value substrings for
1607 comparison, characters are case folded in the Map preparation step,
1608 and only Insignificant Space Removal is applied in the Insignificant
1609 Character Removal step.
1611 ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
1612 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1614 The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
1616 4.2.5. caseIgnoreListMatch
1618 The caseIgnoreListMatch rule compares an assertion value that is a
1619 sequence of strings to an attribute value of a syntax (e.g., the
1620 Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
1621 OF the DirectoryString ASN.1 type.
1626 Legg & Dally Expires 27 April 2004 [Page 29]
1628 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1631 The rule evaluates to TRUE if and only if the attribute value and the
1632 assertion value have the same number of strings and corresponding
1633 strings (by position) match according to the caseIgnoreMatch matching
1636 In [X.520] the assertion syntax for this matching rule is defined to
1639 SEQUENCE OF DirectoryString {ub-match}
1641 i.e., different from the corresponding type for the Postal Address
1642 syntax. The choice of the Postal Address syntax for the assertion
1643 syntax of the caseIgnoreListMatch in LDAP should not be seen as
1644 limiting the matching rule to only apply to attributes with the
1645 Postal Address syntax.
1647 The LDAP definition for the caseIgnoreListMatch rule is:
1649 ( 2.5.13.11 NAME 'caseIgnoreListMatch'
1650 SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
1652 The caseIgnoreListMatch rule is an equality matching rule.
1654 4.2.6. caseIgnoreListSubstringsMatch
1656 The caseIgnoreListSubstringsMatch rule compares an assertion value of
1657 the Substring Assertion syntax to an attribute value of a syntax
1658 (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
1659 SEQUENCE OF the DirectoryString ASN.1 type.
1661 The rule evaluates to TRUE if and only if the assertion value
1662 matches, per the caseIgnoreSubstringsMatch rule, the character string
1663 formed by concatenating the strings of the attribute value, except
1664 that none of the <initial>, <any>, or <final> substrings of the
1665 assertion value are considered to match a substring of the
1666 concatenated string which spans more than one of the original strings
1667 of the attribute value.
1669 Note that, in terms of the LDAP-specific encoding of the Postal
1670 Address syntax, the concatenated string omits the <DOLLAR> line
1671 separator and the escaping of "\" and "$" characters.
1673 The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
1675 ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
1676 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1678 The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
1682 Legg & Dally Expires 27 April 2004 [Page 30]
1684 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1687 4.2.7. caseIgnoreMatch
1689 The caseIgnoreMatch rule compares an assertion value of the Directory
1690 String syntax to an attribute value of a syntax (e.g., the Directory
1691 String, Printable String, Country String or Telephone Number syntax)
1692 whose corresponding ASN.1 type is DirectoryString or one of the
1693 alternative string types of DirectoryString, e.g., PrintableString
1694 (the other alternatives do not correspond to any syntax defined in
1697 The rule evaluates to TRUE if and only if the prepared attribute
1698 value character string and the prepared assertion value character
1699 string have the same number of characters and corresponding
1700 characters have the same code point.
1702 In preparing the attribute value and assertion value for comparison,
1703 characters are case folded in the Map preparation step, and only
1704 Insignificant Space Removal is applied in the Insignificant Character
1707 The LDAP definition for the caseIgnoreMatch rule is:
1709 ( 2.5.13.2 NAME 'caseIgnoreMatch'
1710 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1712 The caseIgnoreMatch rule is an equality matching rule.
1714 4.2.8. caseIgnoreOrderingMatch
1716 The caseIgnoreOrderingMatch rule compares an assertion value of the
1717 Directory String syntax to an attribute value of a syntax (e.g., the
1718 Directory String, Printable String, Country String or Telephone
1719 Number syntax) whose corresponding ASN.1 type is DirectoryString or
1720 one of its alternative string types.
1722 The rule evaluates to TRUE if, and only if, in the code point
1723 collation order, the prepared attribute value character string
1724 appears earlier than the prepared assertion value character string,
1725 i.e., the attribute value is "less than" the assertion value.
1727 In preparing the attribute value and assertion value for comparison,
1728 characters are case folded in the Map preparation step, and only
1729 Insignificant Space Removal is applied in the Insignificant Character
1732 The LDAP definition for the caseIgnoreOrderingMatch rule is:
1734 ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
1738 Legg & Dally Expires 27 April 2004 [Page 31]
1740 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1743 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1745 The caseIgnoreOrderingMatch rule is an ordering matching rule.
1747 4.2.9. caseIgnoreSubstringsMatch
1749 The caseIgnoreSubstringsMatch rule compares an assertion value of the
1750 Substring Assertion syntax to an attribute value of a syntax (e.g.,
1751 the Directory String, Printable String, Country String or Telephone
1752 Number syntax) whose corresponding ASN.1 type is DirectoryString or
1753 one of its alternative string types.
1755 The rule evaluates to TRUE if and only if the prepared substrings of
1756 the assertion value match disjoint portions of the prepared attribute
1757 value character string in the order of the substrings in the
1758 assertion value, and an <initial> substring, if present, matches the
1759 beginning of the prepared attribute value character string, and a
1760 <final> substring, if present, matches the end of the prepared
1761 attribute value character string. A prepared substring matches a
1762 portion of the prepared attribute value character string if
1763 corresponding characters have the same code point.
1765 In preparing the attribute value and assertion value substrings for
1766 comparison, characters are case folded in the Map preparation step,
1767 and only Insignificant Space Removal is applied in the Insignificant
1768 Character Removal step.
1770 The LDAP definition for the caseIgnoreSubstringsMatch rule is:
1772 ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
1773 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1775 The caseIgnoreSubstringsMatch rule is a substrings matching rule.
1777 4.2.10. distinguishedNameMatch
1779 The distinguishedNameMatch rule compares an assertion value of the DN
1780 syntax to an attribute value of a syntax (e.g., the DN syntax) whose
1781 corresponding ASN.1 type is DistinguishedName.
1783 The rule evaluates to TRUE if and only if the attribute value and the
1784 assertion value have the same number of relative distinguished names
1785 and corresponding relative distinguished names (by position) are the
1786 same. A relative distinguished name (RDN) of the assertion value is
1787 the same as an RDN of the attribute value if and only if they have
1788 the same number of attribute value assertions and each attribute
1789 value assertion (AVA) of the first RDN is the same as the AVA of the
1790 second RDN with the same attribute type. The order of the AVAs is
1794 Legg & Dally Expires 27 April 2004 [Page 32]
1796 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1799 not significant. Also note that a particular attribute type may
1800 appear in at most one AVA in an RDN. Two AVAs with the same
1801 attribute type are the same if their values are equal according to
1802 the equality matching rule of the attribute type. If one or more of
1803 the AVA comparisons evaluate to Undefined and the remaining AVA
1804 comparisons return TRUE then the distinguishedNameMatch rule
1805 evaluates to Undefined.
1807 The LDAP definition for the distinguishedNameMatch rule is:
1809 ( 2.5.13.1 NAME 'distinguishedNameMatch'
1810 SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
1812 The distinguishedNameMatch rule is an equality matching rule.
1814 4.2.11. generalizedTimeMatch
1816 The generalizedTimeMatch rule compares an assertion value of the
1817 Generalized Time syntax to an attribute value of a syntax (e.g the
1818 Generalized Time syntax) whose corresponding ASN.1 type is
1821 The rule evaluates to TRUE if and only if the attribute value
1822 represents the same universal coordinated time as the assertion
1823 value. If a time is specified with the minutes or seconds absent
1824 then the number of minutes or seconds (respectively) is assumed to be
1827 The LDAP definition for the generalizedTimeMatch rule is:
1829 ( 2.5.13.27 NAME 'generalizedTimeMatch'
1830 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1832 The generalizedTimeMatch rule is an equality matching rule.
1834 4.2.12. generalizedTimeOrderingMatch
1836 The generalizedTimeOrderingMatch rule compares the time ordering of
1837 an assertion value of the Generalized Time syntax to an attribute
1838 value of a syntax (e.g the Generalized Time syntax) whose
1839 corresponding ASN.1 type is GeneralizedTime.
1841 The rule evaluates to TRUE if and only if the attribute value
1842 represents a universal coordinated time which is earlier than the
1843 universal coordinated time represented by the assertion value.
1845 The LDAP definition for the generalizedTimeOrderingMatch rule is:
1850 Legg & Dally Expires 27 April 2004 [Page 33]
1852 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1855 ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
1856 SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1858 The generalizedTimeOrderingMatch rule is an ordering matching rule.
1860 4.2.13. integerFirstComponentMatch
1862 The integerFirstComponentMatch rule compares an assertion value of
1863 the Integer syntax to an attribute value of a syntax (e.g the DIT
1864 Structure Rule Description syntax) whose corresponding ASN.1 type is
1865 a SEQUENCE with a mandatory first component of the INTEGER ASN.1
1868 Note that the assertion syntax of this matching rule differs from the
1869 attribute syntax of attributes for which this is the equality
1872 The rule evaluates to TRUE if and only if the assertion value and the
1873 first component of the attribute value are the same integer value.
1875 The LDAP definition for the integerFirstComponentMatch matching rule
1878 ( 2.5.13.29 NAME 'integerFirstComponentMatch'
1879 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
1881 The integerFirstComponentMatch rule is an equality matching rule.
1882 When using integerFirstComponentMatch to compare two attribute values
1883 (of an applicable syntax), an assertion value must first be derived
1884 from one of the attribute values. An assertion value can be derived
1885 from an attribute value by taking the first component of that
1888 4.2.14. integerMatch
1890 The integerMatch rule compares an assertion value of the Integer
1891 syntax to an attribute value of a syntax (e.g the Integer syntax)
1892 whose corresponding ASN.1 type is INTEGER.
1894 The rule evaluates to TRUE if and only if the attribute value and the
1895 assertion value are the same integer value.
1897 The LDAP definition for the integerMatch matching rule is:
1899 ( 2.5.13.14 NAME 'integerMatch'
1900 SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
1902 The integerMatch rule is an equality matching rule.
1906 Legg & Dally Expires 27 April 2004 [Page 34]
1908 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1911 4.2.15. numericStringMatch
1913 The numericStringMatch rule compares an assertion value of the
1914 Numeric String syntax to an attribute value of a syntax (e.g the
1915 Numeric String syntax) whose corresponding ASN.1 type is
1918 The rule evaluates to TRUE if and only if the prepared attribute
1919 value character string and the prepared assertion value character
1920 string have the same number of characters and corresponding
1921 characters have the same code point.
1923 In preparing the attribute value and assertion value for comparison,
1924 characters are not case folded in the Map preparation step, and only
1925 numericString Insignificant Character Removal is applied in the
1926 Insignificant Character Removal step.
1928 The LDAP definition for the numericStringMatch matching rule is:
1930 ( 2.5.13.8 NAME 'numericStringMatch'
1931 SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
1933 The numericStringMatch rule is an equality matching rule.
1935 4.2.16. numericStringSubstringsMatch
1937 The numericStringSubstringsMatch rule compares an assertion value of
1938 the Substring Assertion syntax to an attribute value of a syntax (e.g
1939 the Numeric String syntax) whose corresponding ASN.1 type is
1942 The rule evaluates to TRUE if and only if the prepared substrings of
1943 the assertion value match disjoint portions of the prepared attribute
1944 value character string in the order of the substrings in the
1945 assertion value, and an <initial> substring, if present, matches the
1946 beginning of the prepared attribute value character string, and a
1947 <final> substring, if present, matches the end of the prepared
1948 attribute value character string. A prepared substring matches a
1949 portion of the prepared attribute value character string if
1950 corresponding characters have the same code point.
1952 In preparing the attribute value and assertion value for comparison,
1953 characters are not case folded in the Map preparation step, and only
1954 numericString Insignificant Character Removal is applied in the
1955 Insignificant Character Removal step.
1957 The LDAP definition for the numericStringSubstringsMatch matching
1962 Legg & Dally Expires 27 April 2004 [Page 35]
1964 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
1967 ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
1968 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1970 The numericStringSubstringsMatch rule is a substrings matching rule.
1972 4.2.17. objectIdentifierFirstComponentMatch
1974 The objectIdentifierFirstComponentMatch rule compares an assertion
1975 value of the OID syntax to an attribute value of a syntax (e.g the
1976 Attribute Type Description, DIT Content Rule Description, LDAP Syntax
1977 Description, Matching Rule Description, Matching Rule Use
1978 Description, Name Form Description or Object Class Description
1979 syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
1980 first component of the OBJECT IDENTIFIER ASN.1 type.
1982 Note that the assertion syntax of this matching rule differs from the
1983 attribute syntax of attributes for which this is the equality
1986 The rule evaluates to TRUE if and only if the assertion value matches
1987 the first component of the attribute value using the rules of
1988 objectIdentifierMatch.
1990 The LDAP definition for the objectIdentifierFirstComponentMatch
1993 ( 2.5.13.31 NAME 'objectIdentifierFirstComponentMatch'
1994 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
1996 The objectIdentifierFirstComponentMatch rule is an equality matching
1997 rule. When using objectIdentifierFirstComponentMatch to compare two
1998 attribute values (of an applicable syntax), an assertion value must
1999 first be derived from one of the attribute values. An assertion
2000 value can be derived from an attribute value by taking the first
2001 component of that attribute value.
2003 4.2.18. objectIdentifierMatch
2005 The objectIdentifierMatch rule compares an assertion value of the OID
2006 syntax to an attribute value of a syntax (e.g the OID syntax) whose
2007 corresponding ASN.1 type is OBJECT IDENTIFIER.
2009 The rule evaluates to TRUE if and only if the assertion value and the
2010 attribute value represent the same object identifier, that is, the
2011 same sequence of integers, whether represented explicitly in the
2012 <numericoid> form of <oid> or implicitly in the <descr> form (see
2018 Legg & Dally Expires 27 April 2004 [Page 36]
2020 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2023 If an LDAP client supplies an assertion value in the <descr> form,
2024 and the chosen descriptor is not recognized by the server, then the
2025 objectIdentifierMatch rule evaluates to Undefined.
2027 The LDAP definition for the objectIdentifierMatch matching rule is:
2029 ( 2.5.13.0 NAME 'objectIdentifierMatch'
2030 SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
2032 The objectIdentifierMatch rule is an equality matching rule.
2034 4.2.19. octetStringMatch
2036 The octetStringMatch rule compares an assertion value of the Octet
2037 String syntax to an attribute value of a syntax (e.g the Octet String
2038 or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
2041 The rule evaluates to TRUE if and only if the attribute value and the
2042 assertion value are the same length and corresponding octets (by
2043 position) are the same.
2045 The LDAP definition for the octetStringMatch matching rule is:
2047 ( 2.5.13.17 NAME 'octetStringMatch'
2048 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2050 The octetStringMatch rule is an equality matching rule.
2052 4.2.20. telephoneNumberMatch
2054 The telephoneNumberMatch rule compares an assertion value of the
2055 Telephone Number syntax to an attribute value of a syntax (e.g the
2056 Telephone Number syntax) whose corresponding ASN.1 type is a
2057 PrintableString representing a telephone number.
2059 The rule evaluates to TRUE if and only if the prepared attribute
2060 value character string and the prepared assertion value character
2061 string have the same number of characters and corresponding
2062 characters have the same code point.
2064 In preparing the attribute value and assertion value for comparison,
2065 characters are case folded in the Map preparation step, and only
2066 telephoneNumber Insignificant Character Removal is applied in the
2067 Insignificant Character Removal step.
2069 The LDAP definition for the telephoneNumberMatch matching rule is:
2074 Legg & Dally Expires 27 April 2004 [Page 37]
2076 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2079 ( 2.5.13.20 NAME 'telephoneNumberMatch'
2080 SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
2082 The telephoneNumberMatch rule is an equality matching rule.
2084 4.2.21. telephoneNumberSubstringsMatch
2086 The telephoneNumberSubstringsMatch rule compares an assertion value
2087 of the Substring Assertion syntax to an attribute value of a syntax
2088 (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
2089 PrintableString representing a telephone number.
2091 The rule evaluates to TRUE if and only if the prepared substrings of
2092 the assertion value match disjoint portions of the prepared attribute
2093 value character string in the order of the substrings in the
2094 assertion value, and an <initial> substring, if present, matches the
2095 beginning of the prepared attribute value character string, and a
2096 <final> substring, if present, matches the end of the prepared
2097 attribute value character string. A prepared substring matches a
2098 portion of the prepared attribute value character string if
2099 corresponding characters have the same code point.
2101 In preparing the attribute value and assertion value substrings for
2102 comparison, characters are case folded in the Map preparation step,
2103 and only telephoneNumber Insignificant Character Removal is applied
2104 in the Insignificant Character Removal step.
2106 The LDAP definition for the telephoneNumberSubstringsMatch matching
2109 ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
2110 SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2112 The telephoneNumberSubstringsMatch rule is a substrings matching
2115 4.2.22. uniqueMemberMatch
2117 The uniqueMemberMatch rule compares an assertion value of the Name
2118 And Optional UID syntax to an attribute value of a syntax (e.g the
2119 Name And Optional UID syntax) whose corresponding ASN.1 type is
2122 The rule evaluates to TRUE if and only if the <distinguishedName>
2123 components of the assertion value and attribute value match according
2124 to the distinguishedNameMatch rule and the <BitString> component is
2125 absent from the attribute value or matches the <BitString> component
2126 of the assertion value according to the bitStringMatch rule.
2130 Legg & Dally Expires 27 April 2004 [Page 38]
2132 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2135 The LDAP definition for the uniqueMemberMatch matching rule is:
2137 ( 2.5.13.23 NAME 'uniqueMemberMatch'
2138 SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
2140 The uniqueMemberMatch rule is an equality matching rule.
2142 5. Security Considerations
2144 In general, the LDAP-specific encodings for syntaxes defined in this
2145 document do not define canonical encodings. That is, a
2146 transformation from an LDAP-specific encoding into some other
2147 encoding (e.g., BER) and back into the LDAP-specific encoding will
2148 not necessarily reproduce exactly the original octets of the
2149 LDAP-specific encoding. Therefore an LDAP-specific encoding should
2150 not be used where a canonical encoding is required.
2152 Furthermore, the LDAP-specific encodings do not necessarily enable an
2153 alternative encoding of values of the Directory String and DN
2154 syntaxes to be reconstructed, e.g., a transformation from a
2155 Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
2156 encoding and back to a DER encoding may not reproduce the original
2157 DER encoding. Therefore LDAP-specific encodings should not be used
2158 where reversibility to DER is needed, e.g., for the verification of
2159 digital signatures. Instead, DER or a DER-reversible encoding should
2162 When interpreting security-sensitive fields, and in particular fields
2163 used to grant or deny access, implementations MUST ensure that any
2164 matching rule comparisons are done on the underlying abstract value,
2165 regardless of the particular encoding used.
2169 This document is an revision of RFC 2252 by M. Wahl, A. Coulbeck, T.
2170 Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working
2173 This document is based upon input of the IETF LDAPBIS working group.
2174 The authors wish to thank J. Sermersheim and K. Zeilenga for their
2175 significant contribution to this revision.
2177 7. IANA Considerations
2179 The Internet Assigned Numbers Authority (IANA) is requested to update
2180 the LDAP descriptors registry [BCP64] as indicated by the following
2186 Legg & Dally Expires 27 April 2004 [Page 39]
2188 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2191 Subject: Request for LDAP Descriptor Registration Update
2192 Descriptor (short name): see comment
2193 Object Identifier: see comment
2194 Person & email address to contact for further information:
2195 Steven Legg <steven.legg@adacel.com.au>
2197 Specification: RFC XXXX
2198 Author/Change Controller: IESG
2201 The following descriptors (short names) should be updated to refer
2205 ------------------------------------------------------------------
2206 bitStringMatch M 2.5.13.16
2207 caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
2208 caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
2209 caseIgnoreListMatch M 2.5.13.11
2210 caseIgnoreMatch M 2.5.13.2
2211 caseIgnoreOrderingMatch M 2.5.13.3
2212 caseIgnoreSubstringsMatch M 2.5.13.4
2213 distinguishedNameMatch M 2.5.13.1
2214 generalizedTimeMatch M 2.5.13.27
2215 generalizedTimeOrderingMatch M 2.5.13.28
2216 integerFirstComponentMatch M 2.5.13.29
2217 integerMatch M 2.5.13.14
2218 numericStringMatch M 2.5.13.8
2219 numericStringSubstringsMatch M 2.5.13.10
2220 objectIdentifierFirstComponentMatch M 2.5.13.31
2221 octetStringMatch M 2.5.13.17
2222 telephoneNumberMatch M 2.5.13.20
2223 telephoneNumberSubstringsMatch M 2.5.13.21
2224 uniqueMemberMatch M 2.5.13.23
2226 The descriptor for the object identifier 2.5.13.0 was incorrectly
2227 registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
2228 It should be changed to the following with a reference to RFC
2232 ------------------------------------------------------------------
2233 objectIdentifierMatch M 2.5.13.0
2236 Subject: Request for LDAP Descriptor Registration
2237 Descriptor (short name): caseIgnoreIA5SubstringsMatch
2238 Object Identifier: 1.3.6.1.4.1.1466.109.114.3
2242 Legg & Dally Expires 27 April 2004 [Page 40]
2244 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2247 Person & email address to contact for further information:
2248 Steven Legg <steven.legg@adacel.com.au>
2250 Specification: RFC XXXX
2251 Author/Change Controller: IESG
2254 Subject: Request for LDAP Descriptor Registration
2255 Descriptor (short name): caseIgnoreListSubstringsMatch
2256 Object Identifier: 2.5.13.12
2257 Person & email address to contact for further information:
2258 Steven Legg <steven.legg@adacel.com.au>
2260 Specification: RFC XXXX
2261 Author/Change Controller: IESG
2265 8.1. Normative References
2267 [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
2268 Requirement Levels", BCP 14, RFC 2119, March 1997.
2270 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
2271 Specifications: ABNF", RFC 2234, November 1997.
2273 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
2274 10646", draft-yergeau-rfc2279bis-xx.txt, a work in
2275 progress, June 2003.
2277 [BCP64] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
2278 Considerations for the Lightweight Directory Access
2279 Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
2281 [LDAPDN] Zeilenga, K., "LDAP: String Representation of
2282 Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
2283 in progress, June 2003.
2285 [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
2286 protocol-xx.txt, a work in progress, September 2003.
2288 [E.123] Notation for national and international telephone numbers,
2289 ITU-T Recommendation E.123, 1988.
2291 [FAX] Standardization of Group 3 facsimile apparatus for
2292 document transmission - Terminal Equipment and Protocols
2293 for Telematic Services, ITU-T Recommendation T.4, 1993
2298 Legg & Dally Expires 27 April 2004 [Page 41]
2300 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2303 [T.50] International Reference Alphabet (IRA) (Formerly
2304 International Alphabet No. 5 or IA5) Information
2305 Technology - 7-Bit Coded Character Set for Information
2306 Interchange, ITU-T Recommendation T.50, 1992
2308 [X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
2309 Information Technology - Message Handling Systems (MHS):
2310 Interpersonal messaging system
2312 [X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
2313 Information Technology - Open Systems Interconnection -
2314 The Directory: Models
2316 [X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
2317 Information Technology - Open Systems Interconnection -
2318 The Directory: Selected attribute types
2320 [ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
2321 Information technology - Abstract Syntax Notation One
2322 (ASN.1): Specification of basic notation
2324 [ISO3166] ISO 3166, "Codes for the representation of names of
2327 [UCS] Universal Multiple-Octet Coded Character Set (UCS) -
2328 Architecture and Basic Multilingual Plane, ISO/IEC
2329 10646-1: 1993 (with amendments).
2331 [JPEG] JPEG File Interchange Format (Version 1.02). Eric
2332 Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
2335 [ROADMAP] Zeilenga, K., "LDAP: Technical Specification Road Map",
2336 draft-ietf-ldapbis-roadmap-xx.txt, a work in progress,
2339 [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-
2340 ietf-ldapbis-models-xx.txt, a work in progress, June 2003.
2342 [PREP] Zeilenga, K., "LDAP: Internationalized String
2343 Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
2344 progress, June 2003.
2346 8.2. Informative References
2348 [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
2349 "Lightweight Directory Access Protocol (v3): Attribute
2350 Syntax Definitions", RFC 2252, December 1997.
2354 Legg & Dally Expires 27 April 2004 [Page 42]
2356 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2359 [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use
2360 with LDAPv3", RFC 2256, December 1997.
2362 [RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
2363 Protocol (v3): Technical Specification", RFC 3377,
2366 [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft-
2367 ietf-ldapbis-user-schema-xx.txt, a work in progress, June
2370 [LDAP-PKI] Chadwick, D. W. and S. Legg, "LDAP Schema and Syntaxes for
2371 PKIs", draft-ietf-pkix-ldap-pki-schema-xx.txt, a work in
2372 progress, July 2002.
2374 [X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
2375 Information Technology - Open Systems Interconnection -
2376 The Directory: Overview of concepts, models and services
2378 [BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
2379 Information technology - ASN.1 encoding rules:
2380 Specification of Basic Encoding Rules (BER), Canonical
2381 Encoding Rules (CER) and Distinguished Encoding Rules
2384 9. Authors' Addresses
2387 Adacel Technologies Ltd.
2389 Brighton, Victoria 3186
2392 Phone: +61 3 8530 7710
2393 Fax: +61 3 8530 7888
2394 Email: steven.legg@adacel.com.au
2399 7515 Colshire Dr., ms-W650
2403 Phone: +1 703 883 6058
2404 Fax: +1 703 883 7142
2405 Email: kdally@mitre.org
2410 Legg & Dally Expires 27 April 2004 [Page 43]
2412 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2415 10. Intellectual Property Notice
2417 The IETF takes no position regarding the validity or scope of any
2418 intellectual property or other rights that might be claimed to
2419 pertain to the implementation or use of the technology described in
2420 this document or the extent to which any license under such rights
2421 might or might not be available; neither does it represent that it
2422 has made any effort to identify any such rights. Information on the
2423 IETF's procedures with respect to rights in standards-track and
2424 standards-related documentation can be found in BCP-11. Copies of
2425 claims of rights made available for publication and any assurances of
2426 licenses to be made available, or the result of an attempt made to
2427 obtain a general license or permission for the use of such
2428 proprietary rights by implementors or users of this specification can
2429 be obtained from the IETF Secretariat.
2431 The IETF invites any interested party to bring to its attention any
2432 copyrights, patents or patent applications, or other proprietary
2433 rights which may cover technology that may be required to practice
2434 this standard. Please address the information to the IETF Executive
2437 Appendix A. Summary of Syntax Object Identifiers
2439 The following list summarizes the object identifiers assigned to the
2440 syntaxes defined in this document.
2442 Syntax OBJECT IDENTIFIER
2443 ==============================================================
2444 Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
2445 Bit String 1.3.6.1.4.1.1466.115.121.1.6
2446 Boolean 1.3.6.1.4.1.1466.115.121.1.7
2447 Country String 1.3.6.1.4.1.1466.115.121.1.11
2448 Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
2449 Directory String 1.3.6.1.4.1.1466.115.121.1.15
2450 DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
2451 DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
2452 DN 1.3.6.1.4.1.1466.115.121.1.12
2453 Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
2454 Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
2455 Fax 1.3.6.1.4.1.1466.115.121.1.23
2456 Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
2457 Guide 1.3.6.1.4.1.1466.115.121.1.25
2458 IA5 String 1.3.6.1.4.1.1466.115.121.1.26
2459 Integer 1.3.6.1.4.1.1466.115.121.1.27
2460 JPEG 1.3.6.1.4.1.1466.115.121.1.28
2461 LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
2462 Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
2466 Legg & Dally Expires 27 April 2004 [Page 44]
2468 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2471 Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
2472 Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
2473 Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
2474 Numeric String 1.3.6.1.4.1.1466.115.121.1.36
2475 Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
2476 Octet String 1.3.6.1.4.1.1466.115.121.1.40
2477 OID 1.3.6.1.4.1.1466.115.121.1.38
2478 Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
2479 Postal Address 1.3.6.1.4.1.1466.115.121.1.41
2480 Printable String 1.3.6.1.4.1.1466.115.121.1.44
2481 Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
2482 Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
2483 Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
2484 Telex Number 1.3.6.1.4.1.1466.115.121.1.52
2485 UTC Time 1.3.6.1.4.1.1466.115.121.1.53
2487 Appendix B. Changes from RFC 2252 & RFC 2256
2489 This annex lists the significant differences between this
2490 specification and RFC 2252 and Sections 6 and 8 of RFC 2256.
2492 This annex is provided for informational purposes only. It is not a
2493 normative part of this specification.
2495 1. The IESG Note has been removed.
2497 2. The major part of Sections 4, 5 and 7 has been moved to [MODELS]
2498 and revised. Changes to the parts of these sections moved to
2499 [MODELS] are detailed in [MODELS].
2501 3. BNF descriptions of syntax formats have been replaced by ABNF
2502 [ABNF] specifications.
2504 4. The ambiguous statement in RFC 2252, Section 4.3 regarding the
2505 use of a backslash quoting mechanism to escape separator symbols
2506 has been removed. The escaping mechanism is now explicitly
2507 represented in the ABNF for the syntaxes where this provision
2510 5. The description of each of the LDAP syntaxes has been expanded so
2511 that they are less dependent on knowledge of X.500 for
2514 6. The relationship of LDAP syntaxes to corresponding ASN.1 type
2515 definitions has been made explicit.
2517 7. The set of characters allowed in a <PrintableString> (formerly
2518 <printablestring>) has been corrected to align with the
2522 Legg & Dally Expires 27 April 2004 [Page 45]
2524 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2527 PrintableString ASN.1 type in [ASN.1]. Specifically, the double
2528 quote character has been removed and the single quote character
2529 and equals sign have been added.
2531 8. Values of the Directory String, Printable String and Telephone
2532 Number syntaxes are now required to have at least one character.
2534 9. The <DITContentRuleDescription>, <NameFormDescription> and
2535 <DITStructureRuleDescription> rules have been moved to [MODELS].
2537 10. The corresponding ASN.1 type for the Other Mailbox syntax has
2538 been incorporated from RFC 1274.
2540 11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
2543 12. The Binary syntax has been removed because it was not adequately
2544 specified, implementations with different incompatible
2545 interpretations exist, and it was confused with the ;binary
2548 13. All discussion of transfer options, including the ";binary"
2549 option, has been removed. All imperatives regarding binary
2550 transfer of values have been removed.
2552 14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
2553 Terminal Identifier and Telex Number syntaxes from RFC 2256 have
2556 15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
2557 been extended to accommodate empty "and" and "or" expressions.
2559 16. An encoding for the <ttx-value> rule in the Teletex Terminal
2560 Identifier syntax has been defined.
2562 17. The PKI-related syntaxes (Certificate, Certificate List and
2563 Certificate Pair from RFC 2252, and Supported Algorithm syntax
2564 from RFC 2256) have been removed. They are to be reintroduced in
2567 18. The MHS OR Address syntax has been removed since its
2568 specification (in RFC 2156) is not at draft standard maturity.
2570 19. The DL Submit Permission syntax has been removed as it depends on
2571 the MHS OR Address syntax.
2573 20. The Presentation Address syntax has been removed since its
2574 specification (in RFC 1278) is not at draft standard maturity.
2578 Legg & Dally Expires 27 April 2004 [Page 46]
2580 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2583 21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
2584 Type, LDAP Schema Description, Master And Shadow Access Points,
2585 Modify Rights, Protocol Information, Subtree Specification,
2586 Supplier Information, Supplier Or Consumer and Supplier And
2587 Consumer syntaxes have been removed. These syntaxes are
2588 referenced in RFC 2252, but not defined.
2590 22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
2591 Mail Preference syntax have been removed on the grounds that they
2592 are out of scope for a core specification.
2594 23. The description of each of the matching rules has been expanded
2595 so that they are less dependent on knowledge of X.500 for
2598 24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
2601 25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
2602 caseIgnoreSubstringsMatch matching rules have been added to the
2603 list of matching rules for which the provisions for handling
2604 leading, trailing and multiple adjoining whitespace characters
2605 apply (now through string preparation). This is consistent with
2606 the definitions of these matching rules in X.500. The
2607 caseIgnoreIA5SubstringsMatch rule has also been added to the
2610 26. The specification of the octetStringMatch matching rule from RFC
2611 2256 has been added to this document.
2613 27. The presentationAddressMatch matching rule has been removed as it
2614 depends on an assertion syntax (Presentation Address) that is not
2615 at draft standard maturity.
2617 28. The protocolInformationMatch matching rule has been removed as it
2618 depends on an undefined assertion syntax (Protocol Information).
2620 29. The definitive reference for ASN.1 has been changed from X.208 to
2621 X.680 since X.680 is the version of ASN.1 referred to by X.500.
2623 30. The specification of the caseIgnoreListSubstringsMatch matching
2624 rule from RFC 2798 & X.520 has been added to this document.
2626 31. String preparation algorithms have been applied to the character
2627 string matching rules.
2629 Full Copyright Statement
2634 Legg & Dally Expires 27 April 2004 [Page 47]
2636 INTERNET-DRAFT LDAP: Syntaxes and Matching Rules October 27, 2003
2639 Copyright (C) The Internet Society (2003). All Rights Reserved.
2641 This document and translations of it may be copied and furnished to
2642 others, and derivative works that comment on or otherwise explain it
2643 or assist in its implementation may be prepared, copied, published
2644 and distributed, in whole or in part, without restriction of any
2645 kind, provided that the above copyright notice and this paragraph are
2646 included on all such copies and derivative works. However, this
2647 document itself may not be modified in any way, such as by removing
2648 the copyright notice or references to the Internet Society or other
2649 Internet organizations, except as needed for the purpose of
2650 developing Internet standards in which case the procedures for
2651 copyrights defined in the Internet Standards process must be
2652 followed, or as required to translate it into languages other than
2655 The limited permissions granted above are perpetual and will not be
2656 revoked by the Internet Society or its successors or assignees.
2658 This document and the information contained herein is provided on an
2659 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2660 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2661 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2662 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2663 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2690 Legg & Dally Expires 27 April 2004 [Page 48]