git.sur5r.net Git - openldap/blob - doc/drafts/draft-ietf-ldapbis-syntaxes-xx.txt

   1
   2
   3
   4
   5
   6
   7 INTERNET-DRAFT                                                   S. Legg
   8 draft-ietf-ldapbis-syntaxes-11.txt                               eB2Bcom
   9 Intended Category: Standards Track                          23 June 2005
  10 Obsoletes: RFC 2252, RFC 2256 Updates: RFC 3698
  11
  12
  13              Lightweight Directory Access Protocol (LDAP):
  14                       Syntaxes and Matching Rules
  15
  16     Copyright (C) The Internet Society (2005). All Rights Reserved.
  17
  18    Status of this Memo
  19
  20    By submitting this Internet-draft, each author represents that any
  21    applicable patent or other IPR claims of which he or she is aware
  22    have been or will be disclosed, and any of which he or she becomes
  23    aware will be disclosed, in accordance with Section 6 of BCP 79.
  24
  25    By submitting this Internet-draft, I accept the provisions of Section
  26    3 of BCP 78.
  27
  28    Internet-Drafts are working documents of the Internet Engineering
  29    Task Force (IETF), its areas, and its working groups.  Note that
  30    other groups may also distribute working documents as
  31    Internet-Drafts.
  32
  33    Internet-Drafts are draft documents valid for a maximum of six months
  34    and may be updated, replaced, or obsoleted by other documents at any
  35    time.  It is inappropriate to use Internet-Drafts as reference
  36    material or to cite them other than as "work in progress".
  37
  38    The list of current Internet-Drafts can be accessed at
  39    http://www.ietf.org/1id-abstracts.html
  40
  41    The list of Internet-Draft Shadow Directories can be accessed at
  42    http://www.ietf.org/shadow.html
  43
  44    This document is intended to be, after appropriate review and
  45    revision, submitted to the RFC Editor as a Standard Track document.
  46    Distribution of this document is unlimited.  Technical discussion of
  47    this document should take place on the IETF LDAP Revision Working
  48    Group (LDAPbis) mailing list <ietf-ldapbis@openldap.org>.  Please
  49    send editorial comments directly to the editor
  50    <steven.legg@eb2bcom.com>.
  51
  52    This Internet-Draft expires on 23 December 2005.
  53
  54 Abstract
  55
  56
  57
  58 Legg                    Expires 23 December 2005                [Page 1]
  59 \f
  60 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
  61
  62
  63    Each attribute stored in a Lightweight Directory Access Protocol
  64    (LDAP) directory, and whose values may be transfered in the LDAP
  65    protocol, has a defined syntax which constrains the structure and
  66    format of its values.  The comparison semantics for values of a
  67    syntax are not part of the syntax definition but are instead provided
  68    through separately defined matching rules.  Matching rules specify an
  69    argument, an assertion value, which also has a defined syntax.  This
  70    document defines a base set of syntaxes and matching rules for use in
  71    defining attributes for LDAP directories.
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Legg                    Expires 23 December 2005                [Page 2]
 115 \f
 116 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 117
 118
 119 Table of Contents
 120
 121    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
 122    2.  Conventions. . . . . . . . . . . . . . . . . . . . . . . . . .  5
 123    3.  Syntaxes . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
 124        3.1.  General Considerations . . . . . . . . . . . . . . . . .  6
 125        3.2.  Common Definitions . . . . . . . . . . . . . . . . . . .  7
 126        3.3.  Syntax Definitions . . . . . . . . . . . . . . . . . . .  7
 127              3.3.1.  Attribute Type Description . . . . . . . . . . .  7
 128              3.3.2.  Bit String . . . . . . . . . . . . . . . . . . .  8
 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 . . . . . . . . . . . . . . . . . . . 16
 142              3.3.16. Integer. . . . . . . . . . . . . . . . . . . . . 16
 143              3.3.17. JPEG . . . . . . . . . . . . . . . . . . . . . . 16
 144              3.3.18. LDAP Syntax Description. . . . . . . . . . . . . 17
 145              3.3.19. Matching Rule Description. . . . . . . . . . . . 17
 146              3.3.20. Matching Rule Use Description. . . . . . . . . . 18
 147              3.3.21. Name and Optional UID. . . . . . . . . . . . . . 18
 148              3.3.22. Name Form Description. . . . . . . . . . . . . . 19
 149              3.3.23. Numeric String . . . . . . . . . . . . . . . . . 19
 150              3.3.24. Object Class Description . . . . . . . . . . . . 19
 151              3.3.25. Octet String . . . . . . . . . . . . . . . . . . 20
 152              3.3.26. OID. . . . . . . . . . . . . . . . . . . . . . . 20
 153              3.3.27. Other Mailbox. . . . . . . . . . . . . . . . . . 21
 154              3.3.28. Postal Address . . . . . . . . . . . . . . . . . 21
 155              3.3.29. Printable String . . . . . . . . . . . . . . . . 22
 156              3.3.30. Substring Assertion. . . . . . . . . . . . . . . 23
 157              3.3.31. Telephone Number . . . . . . . . . . . . . . . . 23
 158              3.3.32. Teletex Terminal Identifier. . . . . . . . . . . 24
 159              3.3.33. Telex Number . . . . . . . . . . . . . . . . . . 25
 160              3.3.34. UTC Time . . . . . . . . . . . . . . . . . . . . 25
 161    4.  Matching Rules . . . . . . . . . . . . . . . . . . . . . . . . 26
 162        4.1.  General Considerations . . . . . . . . . . . . . . . . . 26
 163        4.2.  Matching Rule Definitions. . . . . . . . . . . . . . . . 28
 164              4.2.1.  bitStringMatch . . . . . . . . . . . . . . . . . 28
 165              4.2.2.  booleanMatch . . . . . . . . . . . . . . . . . . 29
 166              4.2.3.  caseExactIA5Match. . . . . . . . . . . . . . . . 29
 167
 168
 169
 170 Legg                    Expires 23 December 2005                [Page 3]
 171 \f
 172 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 173
 174
 175              4.2.4.  caseExactMatch . . . . . . . . . . . . . . . . . 30
 176              4.2.5.  caseExactOrderingMatch . . . . . . . . . . . . . 30
 177              4.2.6.  caseExactSubstringsMatch . . . . . . . . . . . . 31
 178              4.2.7.  caseIgnoreIA5Match . . . . . . . . . . . . . . . 31
 179              4.2.8.  caseIgnoreIA5SubstringsMatch . . . . . . . . . . 32
 180              4.2.9.  caseIgnoreListMatch. . . . . . . . . . . . . . . 32
 181              4.2.10. caseIgnoreListSubstringsMatch. . . . . . . . . . 33
 182              4.2.11. caseIgnoreMatch. . . . . . . . . . . . . . . . . 33
 183              4.2.12. caseIgnoreOrderingMatch. . . . . . . . . . . . . 34
 184              4.2.13. caseIgnoreSubstringsMatch. . . . . . . . . . . . 34
 185              4.2.14. directoryStringFirstComponentMatch . . . . . . . 35
 186              4.2.15. distinguishedNameMatch . . . . . . . . . . . . . 36
 187              4.2.16. generalizedTimeMatch . . . . . . . . . . . . . . 36
 188              4.2.17. generalizedTimeOrderingMatch . . . . . . . . . . 37
 189              4.2.18. integerFirstComponentMatch . . . . . . . . . . . 37
 190              4.2.19. integerMatch . . . . . . . . . . . . . . . . . . 38
 191              4.2.20. integerOrderingMatch . . . . . . . . . . . . . . 38
 192              4.2.21. keywordMatch . . . . . . . . . . . . . . . . . . 38
 193              4.2.22. numericStringMatch . . . . . . . . . . . . . . . 39
 194              4.2.23. numericStringOrderingMatch . . . . . . . . . . . 39
 195              4.2.24. numericStringSubstringsMatch . . . . . . . . . . 40
 196              4.2.25. objectIdentifierFirstComponentMatch. . . . . . . 40
 197              4.2.26. objectIdentifierMatch. . . . . . . . . . . . . . 41
 198              4.2.27. octetStringMatch . . . . . . . . . . . . . . . . 41
 199              4.2.28. octetStringOrderingMatch . . . . . . . . . . . . 42
 200              4.2.29. telephoneNumberMatch . . . . . . . . . . . . . . 42
 201              4.2.30. telephoneNumberSubstringsMatch . . . . . . . . . 43
 202              4.2.31. uniqueMemberMatch. . . . . . . . . . . . . . . . 44
 203              4.2.32. wordMatch. . . . . . . . . . . . . . . . . . . . 44
 204    5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 44
 205    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 45
 206    7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 45
 207    Appendix A. Summary of Syntax Object Identifiers . . . . . . . . . 47
 208    Appendix B. Changes from RFC 2252. . . . . . . . . . . . . . . . . 48
 209    Normative References . . . . . . . . . . . . . . . . . . . . . . . 50
 210    Informative References . . . . . . . . . . . . . . . . . . . . . . 52
 211    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53
 212    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
 213
 214 1.  Introduction
 215
 216    Each attribute stored in a Lightweight Directory Access Protocol
 217    (LDAP) directory [ROADMAP], and whose values may be transfered in the
 218    LDAP protocol [PROT], has a defined syntax (i.e., data type) which
 219    constrains the structure and format of its values.  The comparison
 220    semantics for values of a syntax are not part of the syntax
 221    definition but are instead provided through separately defined
 222    matching rules.  Matching rules specify an argument, an assertion
 223
 224
 225
 226 Legg                    Expires 23 December 2005                [Page 4]
 227 \f
 228 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 229
 230
 231    value, which also has a defined syntax.  This document defines a base
 232    set of syntaxes and matching rules for use in defining attributes for
 233    LDAP directories.
 234
 235    Readers are advised to familiarize themselves with the Directory
 236    Information Models [MODELS] before reading the rest of this document.
 237    Section 3 provides definitions for the base set of LDAP syntaxes.
 238    Section 4 provides definitions for the base set of matching rules for
 239    LDAP.
 240
 241    This document is a integral part of the LDAP technical specification
 242    [ROADMAP] which obsoletes the previously defined LDAP technical
 243    specification [RFC3377] in its entirety.
 244
 245    Sections 4, 5 and 7 of RFC 2252 [RFC2252] are obsoleted by [MODELS].
 246    The remainder of RFC 2252 is obsoleted by this document.  Sections 6
 247    and 8 of RFC 2256 [RFC2256] are obsoleted by this document.  The
 248    remainder of RFC 2256 is obsoleted by [SCHEMA] and [MODELS].  All but
 249    Section 2.11 of RFC 3698 [RFC3698] is obsoleted by this document.
 250
 251    A number of schema elements which were included in the previous
 252    revision of the LDAP technical specification are not included in this
 253    revision of LDAP.  Public Key Infrastructure schema elements are now
 254    specified in [LDAP-PKI].  Unless reintroduced in future technical
 255    specifications, the remainder are to be considered Historic.
 256
 257    The changes with respect to RFC 2252 are described in Appendix B of
 258    this document.
 259
 260 2.  Conventions
 261
 262    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 263    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
 264    document are to be interpreted as described in BCP 14, RFC 2119
 265    [KEYWORD].
 266
 267    Syntax definitions are written according to the <SyntaxDescription>
 268    ABNF [ABNF] rule specified in [MODELS], and matching rule definitions
 269    are written according to the <MatchingRuleDescription> ABNF rule
 270    specified in [MODELS], except that the syntax and matching rule
 271    definitions provided in this document are line-wrapped for
 272    readability.  When such definitions are transfered as attribute
 273    values in the LDAP protocol (e.g., as values of the ldapSyntaxes and
 274    matchingRules attributes [MODELS] respectively) then those values
 275    would not contain line breaks.
 276
 277 3.  Syntaxes
 278
 279
 280
 281
 282 Legg                    Expires 23 December 2005                [Page 5]
 283 \f
 284 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 285
 286
 287    Syntax definitions constrain the structure of attribute values stored
 288    in an LDAP directory, and determine the representation of attribute
 289    and assertion values transfered in the LDAP protocol.
 290
 291    Syntaxes that are required for directory operation, or that are in
 292    common use, are specified in this section.  Servers SHOULD recognize
 293    all the syntaxes listed in this document, but are not required to
 294    otherwise support them, and MAY recognise or support other syntaxes.
 295    However, the definition of additional arbitrary syntaxes is
 296    discouraged since it will hinder interoperability.  Client and server
 297    implementations typically do not have the ability to dynamically
 298    recognize new syntaxes.
 299
 300 3.1.  General Considerations
 301
 302    The description of each syntax specifies how attribute or assertion
 303    values conforming to the syntax are to be represented when transfered
 304    in the LDAP protocol [PROT].  This representation is referred to as
 305    the LDAP-specific encoding to distinguish it from other methods of
 306    encoding attribute values (e.g., the Basic Encoding Rules (BER)
 307    encoding [BER] used by X.500 [X.500] directories).
 308
 309    The LDAP-specific encoding of a given attribute syntax always
 310    produces octet-aligned values.  To the greatest extent possible,
 311    encoding rules for LDAP syntaxes should produce character strings
 312    that can be displayed with little or no translation by clients
 313    implementing LDAP.  However, clients MUST NOT assume that the
 314    LDAP-specific encoding of a value of an unrecognized syntax is a
 315    human-readable character string.  There are a few cases (e.g., the
 316    JPEG syntax) when it is not reasonable to produce a human-readable
 317    representation.
 318
 319    Each LDAP syntax is uniquely identified with an object identifier
 320    [ASN.1] represented in the dotted-decimal format (short descriptive
 321    names are not defined for syntaxes).  These object identifiers are
 322    not intended to be displayed to users.  The object identifiers for
 323    the syntaxes defined in this document are summarized in Appendix A.
 324
 325    A suggested minimum upper bound on the number of characters in an
 326    attribute value with a string-based syntax, or the number of octets
 327    in a value for all other syntaxes, MAY be indicated by appending the
 328    bound inside of curly braces following the syntax's OBJECT IDENTIFIER
 329    in an attribute type definition (see the <noidlen> rule in [MODELS]).
 330    Such a bound is not considered part of the syntax identifier.
 331
 332    For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute
 333    definition suggests that the directory server will allow a value of
 334    the attribute to be up to 64 characters long, although it may allow
 335
 336
 337
 338 Legg                    Expires 23 December 2005                [Page 6]
 339 \f
 340 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 341
 342
 343    longer character strings.  Note that a single character of the
 344    Directory String syntax can be encoded in more than one octet since
 345    UTF-8 [UTF8] is a variable-length encoding.  Therefore a 64 character
 346    string may be more than 64 octets in length.
 347
 348 3.2.  Common Definitions
 349
 350    The following ABNF rules are used in a number of the syntax
 351    definitions in Section 3.3.
 352
 353       PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN /
 354                            PLUS / COMMA / HYPHEN / DOT / EQUALS /
 355                            SLASH / COLON / QUESTION / SPACE
 356       PrintableString    = 1*PrintableCharacter
 357       IA5String          = *(%x00-7F)
 358       SLASH              = %x2F  ; forward slash ("/")
 359       COLON              = %x3A  ; colon (":")
 360       QUESTION           = %x3F  ; question mark ("?")
 361
 362    The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>,
 363    <HYPHEN>, <DOT>, <EQUALS> and <SPACE> rules are defined in [MODELS].
 364
 365 3.3.  Syntax Definitions
 366
 367 3.3.1.  Attribute Type Description
 368
 369    A value of the Attribute Type Description syntax is the definition of
 370    an attribute type.  The LDAP-specific encoding of a value of this
 371    syntax is defined by the <AttributeTypeDescription> rule in [MODELS].
 372
 373       For example, the following definition of the createTimestamp
 374       attribute type from [MODELS] is also a value of the Attribute Type
 375       Description syntax (note: line breaks have been added for
 376       readability - they are not part of the value when transfered in
 377       protocol).
 378
 379          ( 2.5.18.1 NAME 'createTimestamp'
 380             EQUALITY generalizedTimeMatch
 381             ORDERING generalizedTimeOrderingMatch
 382             SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
 383             SINGLE-VALUE NO-USER-MODIFICATION
 384             USAGE directoryOperation )
 385
 386    The LDAP definition for the Attribute Type Description syntax is:
 387
 388       ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
 389
 390    This syntax corresponds to the AttributeTypeDescription ASN.1 type
 391
 392
 393
 394 Legg                    Expires 23 December 2005                [Page 7]
 395 \f
 396 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 397
 398
 399    from [X.501].
 400
 401 3.3.2.  Bit String
 402
 403    A value of the Bit String syntax is a sequence of binary digits.  The
 404    LDAP-specific encoding of a value of this syntax is defined by the
 405    following ABNF:
 406
 407       BitString    = SQUOTE *binary-digit SQUOTE "B"
 408       binary-digit = "0" / "1"
 409
 410    The <SQUOTE> rule is defined in [MODELS].
 411
 412       Example:
 413          '0101111101'B
 414
 415    The LDAP definition for the Bit String syntax is:
 416
 417       ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
 418
 419    This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
 420
 421 3.3.3.  Boolean
 422
 423    A value of the Boolean syntax is one of the Boolean values, true or
 424    false.  The LDAP-specific encoding of a value of this syntax is
 425    defined by the following ABNF:
 426
 427       Boolean = "TRUE" / "FALSE"
 428
 429    The LDAP definition for the Boolean syntax is:
 430
 431       ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
 432
 433    This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
 434
 435 3.3.4.  Country String
 436
 437    A value of the Country String syntax is one of the two-character
 438    codes from ISO 3166 [ISO3166] for representing a country.  The
 439    LDAP-specific encoding of a value of this syntax is defined by the
 440    following ABNF:
 441
 442       CountryString  = 2(PrintableCharacter)
 443
 444    The <PrintableCharacter> rule is defined in Section 3.2.
 445
 446       Examples:
 447
 448
 449
 450 Legg                    Expires 23 December 2005                [Page 8]
 451 \f
 452 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 453
 454
 455          US
 456          AU
 457
 458    The LDAP definition for the Country String syntax is:
 459
 460       ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
 461
 462    This syntax corresponds to the following ASN.1 type from [X.520]:
 463
 464       PrintableString (SIZE (2)) -- ISO 3166 codes only
 465
 466 3.3.5.  Delivery Method
 467
 468    A value of the Delivery Method syntax is a sequence of items that
 469    indicate, in preference order, the service(s) by which an entity is
 470    willing and/or capable of receiving messages.  The LDAP-specific
 471    encoding of a value of this syntax is defined by the following ABNF:
 472
 473       DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
 474
 475       pdm = "any" / "mhs" / "physical" / "telex" / "teletex" /
 476             "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
 477
 478    The <WSP> and <DOLLAR> rules are defined in [MODELS].
 479
 480       Example:
 481          telephone $ videotex
 482
 483    The LDAP definition for the Delivery Method syntax is:
 484
 485       ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
 486
 487    This syntax corresponds to the following ASN.1 type from [X.520]:
 488
 489       SEQUENCE OF INTEGER {
 490           any-delivery-method     (0),
 491           mhs-delivery            (1),
 492           physical-delivery       (2),
 493           telex-delivery          (3),
 494           teletex-delivery        (4),
 495           g3-facsimile-delivery   (5),
 496           g4-facsimile-delivery   (6),
 497           ia5-terminal-delivery   (7),
 498           videotex-delivery       (8),
 499           telephone-delivery      (9) }
 500
 501 3.3.6.  Directory String
 502
 503
 504
 505
 506 Legg                    Expires 23 December 2005                [Page 9]
 507 \f
 508 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 509
 510
 511    A value of the Directory String syntax is a string of one or more
 512    arbitrary characters from the Universal Character Set (UCS) [UCS].  A
 513    zero length character string is not permitted.  The LDAP-specific
 514    encoding of a value of this syntax is the UTF-8 encoding [UTF8] of
 515    the character string.  Such encodings conform to the following ABNF:
 516
 517       DirectoryString = 1*UTF8
 518
 519    The <UTF8> rule is defined in [MODELS].
 520
 521       Example:
 522          This is a value of Directory String containing #!%#@.
 523
 524    Servers and clients MUST be prepared to receive arbitrary UCS code
 525    points, including code points outside the range of printable ASCII
 526    and code points not presently assigned to any character.
 527
 528    Attribute type definitions using the Directory String syntax should
 529    not restrict the format of Directory String values, e.g., by
 530    requiring that the character string conforms to specific patterns
 531    described by ABNF.  A new syntax should be defined in such cases.
 532
 533    The LDAP definition for the Directory String syntax is:
 534
 535       ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
 536
 537    This syntax corresponds to the DirectoryString parameterized ASN.1
 538    type from [X.520].
 539
 540    The DirectoryString ASN.1 type allows a choice between the
 541    TeletexString, PrintableString or UniversalString ASN.1 types from
 542    [ASN.1].  However, note that the chosen alternative is not indicated
 543    in the LDAP-specific encoding of a Directory String value.
 544
 545    Implementations which convert Directory String values from the
 546    LDAP-specific encoding to the BER encoding used by X.500 must choose
 547    an alternative that permits the particular characters in the string,
 548    and must convert the characters from the UTF-8 encoding into the
 549    character encoding of the chosen alternative.  When converting
 550    Directory String values from the BER encoding to the LDAP-specific
 551    encoding the characters must be converted from the character encoding
 552    of the chosen alternative into the UTF-8 encoding.  These conversions
 553    SHOULD be done in a manner consistent with the Transcode step of the
 554    string preparation algorithms [PREP] for LDAP.
 555
 556 3.3.7.  DIT Content Rule Description
 557
 558    A value of the DIT Content Rule Description syntax is the definition
 559
 560
 561
 562 Legg                    Expires 23 December 2005               [Page 10]
 563 \f
 564 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 565
 566
 567    of a DIT (Directory Information Tree) content rule.  The
 568    LDAP-specific encoding of a value of this syntax is defined by the
 569    <DITContentRuleDescription> rule in [MODELS].
 570
 571       Example:
 572          ( 2.5.6.4 DESC 'content rule for organization'
 573             NOT ( x121Address $ telexNumber ) )
 574
 575       Note: a line break has been added for readability - it is not part
 576       of the value.
 577
 578    The LDAP definition for the DIT Content Rule Description syntax is:
 579
 580       ( 1.3.6.1.4.1.1466.115.121.1.16
 581          DESC 'DIT Content Rule Description' )
 582
 583    This syntax corresponds to the DITContentRuleDescription ASN.1 type
 584    from [X.501].
 585
 586 3.3.8.  DIT Structure Rule Description
 587
 588    A value of the DIT Structure Rule Description syntax is the
 589    definition of a DIT structure rule.  The LDAP-specific encoding of a
 590    value of this syntax is defined by the <DITStructureRuleDescription>
 591    rule in [MODELS].
 592
 593       Example:
 594          ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
 595
 596    The LDAP definition for the DIT Structure Rule Description syntax is:
 597
 598       ( 1.3.6.1.4.1.1466.115.121.1.17
 599          DESC 'DIT Structure Rule Description' )
 600
 601    This syntax corresponds to the DITStructureRuleDescription ASN.1 type
 602    from [X.501].
 603
 604 3.3.9.  DN
 605
 606    A value of the DN syntax is the (purported) distinguished name (DN)
 607    of an entry [MODELS].  The LDAP-specific encoding of a value of this
 608    syntax is defined by the <distinguishedName> rule from the string
 609    representation of distinguished names [LDAPDN].
 610
 611       Examples (from [LDAPDN]):
 612          UID=jsmith,DC=example,DC=net
 613          OU=Sales+CN=J. Smith,DC=example,DC=net
 614          CN=John Smith\, III,DC=example,DC=net
 615
 616
 617
 618 Legg                    Expires 23 December 2005               [Page 11]
 619 \f
 620 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 621
 622
 623          CN=Before\0dAfter,DC=example,DC=net
 624          1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com
 625          CN=Lu\C4\8Di\C4\87
 626
 627    The LDAP definition for the DN syntax is:
 628
 629       ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
 630
 631    The DN syntax corresponds to the DistinguishedName ASN.1 type from
 632    [X.501].  Note that a BER encoded distinguished name (as used by
 633    X.500) re-encoded into the LDAP-specific encoding is not necessarily
 634    reversible to the original BER encoding since the chosen string type
 635    in any DirectoryString components of the distinguished name is not
 636    indicated in the LDAP-specific encoding of the distinguished name
 637    (see Section 3.3.6).
 638
 639 3.3.10.  Enhanced Guide
 640
 641    A value of the Enhanced Guide syntax suggests criteria, which consist
 642    of combinations of attribute types and filter operators, to be used
 643    in constructing filters to search for entries of particular object
 644    classes.  The Enhanced Guide syntax improves upon the Guide syntax by
 645    allowing the recommended depth of the search to be specified.
 646
 647    The LDAP-specific encoding of a value of this syntax is defined by
 648    the following ABNF:
 649
 650       EnhancedGuide = object-class SHARP WSP criteria WSP
 651                          SHARP WSP subset
 652       object-class  = WSP oid WSP
 653       subset        = "baseobject" / "oneLevel" / "wholeSubtree"
 654
 655       criteria   = and-term *( BAR and-term )
 656       and-term   = term *( AMPERSAND term )
 657       term       = EXCLAIM term /
 658                    attributetype DOLLAR match-type /
 659                    LPAREN criteria RPAREN /
 660                    true /
 661                    false
 662       match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX"
 663       true       = "?true"
 664       false      = "?false"
 665       BAR        = %x7C  ; vertical bar ("|")
 666       AMPERSAND  = %x26  ; ampersand ("&")
 667       EXCLAIM    = %x21  ; exclamation mark ("!")
 668
 669    The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype> and
 670    <DOLLAR> rules are defined in [MODELS].
 671
 672
 673
 674 Legg                    Expires 23 December 2005               [Page 12]
 675 \f
 676 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 677
 678
 679    The LDAP definition for the Enhanced Guide syntax is:
 680
 681       ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
 682
 683
 684       Example:
 685          person#(sn$EQ)#oneLevel
 686
 687    The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type
 688    from [X.520].  The EnhancedGuide type references the Criteria ASN.1
 689    type, also from [X.520].  The <true> rule above represents an empty
 690    "and" expression in a value of the Criteria type.  The <false> rule
 691    above represents an empty "or" expression in a value of the Criteria
 692    type.
 693
 694 3.3.11.  Facsimile Telephone Number
 695
 696    A value of the Facsimile Telephone Number syntax is a subscriber
 697    number of a facsimile device on the public switched telephone
 698    network.  The LDAP-specific encoding of a value of this syntax is
 699    defined by the following ABNF:
 700
 701       fax-number       = telephone-number *( DOLLAR fax-parameter )
 702       telephone-number = PrintableString
 703       fax-parameter    = "twoDimensional" /
 704                          "fineResolution" /
 705                          "unlimitedLength" /
 706                          "b4Length" /
 707                          "a3Width" /
 708                          "b4Width" /
 709                          "uncompressed"
 710
 711    The <telephone-number> is a string of printable characters that
 712    complies with the internationally agreed format for representing
 713    international telephone numbers [E.123].  The <PrintableString> rule
 714    is defined in Section 3.2.  The <DOLLAR> rule is defined in [MODELS].
 715
 716    The LDAP definition for the Facsimile Telephone Number syntax is:
 717
 718       ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
 719
 720    The Facsimile Telephone Number syntax corresponds to the
 721    FacsimileTelephoneNumber ASN.1 type from [X.520].
 722
 723 3.3.12.  Fax
 724
 725    A value of the Fax syntax is an image which is produced using the
 726    Group 3 facsimile process [FAX] to duplicate an object, such as a
 727
 728
 729
 730 Legg                    Expires 23 December 2005               [Page 13]
 731 \f
 732 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 733
 734
 735    memo.  The LDAP-specific encoding of a value of this syntax is the
 736    string of octets for a Group 3 Fax image as defined in [FAX].
 737
 738    The LDAP definition for the Fax syntax is:
 739
 740       ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
 741
 742    The ASN.1 type corresponding to the Fax syntax is defined as follows,
 743    assuming EXPLICIT TAGS:
 744
 745       Fax ::= CHOICE {
 746         g3-facsimile  [3] G3FacsimileBodyPart
 747       }
 748
 749    The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
 750
 751 3.3.13.  Generalized Time
 752
 753    A value of the Generalized Time syntax is a character string
 754    representing a date and time.  The LDAP-specific encoding of a value
 755    of this syntax is a restriction of the format defined in [ISO8601],
 756    and is described by the following ABNF:
 757
 758       GeneralizedTime = century year month day hour
 759                            [ minute [ second / leap-second ] ]
 760                            [ fraction ]
 761                            g-time-zone
 762
 763       century = 2(%x30-39) ; "00" to "99"
 764       year    = 2(%x30-39) ; "00" to "99"
 765       month   =   ( %x30 %x31-39 ) ; "01" (January) to "09"
 766                 / ( %x31 %x30-32 ) ; "10" to "12"
 767       day     =   ( %x30 %x31-39 )    ; "01" to "09"
 768                 / ( %x31-32 %x30-39 ) ; "10" to "29"
 769                 / ( %x33 %x30-31 )    ; "30" to "31"
 770       hour    = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23"
 771       minute  = %x30-35 %x30-39                        ; "00" to "59"
 772
 773       second      = ( %x30-35 %x30-39 ) ; "00" to "59"
 774       leap-second = ( %x36 %x30 )       ; "60"
 775
 776       fraction        = ( DOT / COMMA ) 1*(%x30-39)
 777       g-time-zone     = %x5A  ; "Z"
 778                         / g-differential
 779       g-differential  = ( MINUS / PLUS ) hour [ minute ]
 780       MINUS           = %x2D  ; minus sign ("-")
 781
 782    The <DOT>, <COMMA> and <PLUS> rules are defined in [MODELS].
 783
 784
 785
 786 Legg                    Expires 23 December 2005               [Page 14]
 787 \f
 788 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 789
 790
 791    The above ABNF allows character strings which do not represent valid
 792    dates (in the Gregorian calendar) and/or valid times (e.g., February
 793    31, 1994).  Such character strings SHOULD be considered invalid for
 794    this syntax.
 795
 796    The time value represents coordinated universal time (equivalent to
 797    Greenwich Mean Time) if the "Z" form of <g-time-zone> is used,
 798    otherwise the value represents a local time in the time zone
 799    indicated by <g-differential>.  In the latter case, coordinated
 800    universal time can be calculated by subtracting the differential from
 801    the local time.  The "Z" form of <g-time-zone> SHOULD be used in
 802    preference to <g-differential>.
 803
 804    If <minute> is omitted then <fraction> represents a fraction of an
 805    hour, otherwise if <second> and <leap-second> are omitted then
 806    <fraction> represents a fraction of a minute, otherwise <fraction>
 807    represents a fraction of a second.
 808
 809       Examples:
 810          199412161032Z
 811          199412160532-0500
 812
 813    Both example values represent the same coordinated universal time:
 814    10:32 AM, December 16, 1994.
 815
 816    The LDAP definition for the Generalized Time syntax is:
 817
 818       ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
 819
 820    This syntax corresponds to the GeneralizedTime ASN.1 type from
 821    [ASN.1], with the constraint that local time without a differential
 822    SHALL NOT be used.
 823
 824 3.3.14.  Guide
 825
 826    A value of the Guide syntax suggests criteria, which consist of
 827    combinations of attribute types and filter operators, to be used in
 828    constructing filters to search for entries of particular object
 829    classes.  The Guide syntax is obsolete and should not be used for
 830    defining new attribute types.
 831
 832    The LDAP-specific encoding of a value of this syntax is defined by
 833    the following ABNF:
 834
 835       Guide = [ object-class SHARP ] criteria
 836
 837    The <object-class> and <criteria> rules are defined in Section
 838    3.3.10.  The <SHARP> rule is defined in [MODELS].
 839
 840
 841
 842 Legg                    Expires 23 December 2005               [Page 15]
 843 \f
 844 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 845
 846
 847    The LDAP definition for the Guide syntax is:
 848
 849       ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
 850
 851    The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
 852
 853 3.3.15.  IA5 String
 854
 855    A value of the IA5 String syntax is a string of zero, one or more
 856    characters from International Alphabet 5 (IA5) [T.50], the
 857    international version of the ASCII character set.  The LDAP-specific
 858    encoding of a value of this syntax is the unconverted string of
 859    characters, which conforms to the <IA5String> rule in Section 3.2.
 860
 861    The LDAP definition for the IA5 String syntax is:
 862
 863       ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
 864
 865    This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
 866
 867 3.3.16.  Integer
 868
 869    A value of the Integer syntax is a whole number of unlimited
 870    magnitude.  The LDAP-specific encoding of a value of this syntax is
 871    the optionally signed decimal digit character string representation
 872    of the number (so, for example, the number 1321 is represented by the
 873    character string "1321").  The encoding is defined by the following
 874    ABNF:
 875
 876       Integer = ( HYPHEN LDIGIT *DIGIT ) / number
 877
 878    The <HYPHEN>, <LDIGIT>, <DIGIT> and <number> rules are defined in
 879    [MODELS].
 880
 881    The LDAP definition for the Integer syntax is:
 882
 883       ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
 884
 885    This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
 886
 887 3.3.17.  JPEG
 888
 889    A value of the JPEG syntax is an image in the JPEG File Interchange
 890    Format (JFIF), as described in [JPEG].  The LDAP-specific encoding of
 891    a value of this syntax is the sequence of octets of the JFIF encoding
 892    of the image.
 893
 894    The LDAP definition for the JPEG syntax is:
 895
 896
 897
 898 Legg                    Expires 23 December 2005               [Page 16]
 899 \f
 900 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 901
 902
 903       ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
 904
 905    The JPEG syntax corresponds to the following ASN.1 type:
 906
 907       JPEG ::= OCTET STRING (CONSTRAINED BY
 908                    { -- contents octets are an image in the --
 909                      -- JPEG File Interchange Format -- })
 910
 911 3.3.18.  LDAP Syntax Description
 912
 913    A value of the LDAP Syntax Description syntax is the description of
 914    an LDAP syntax.  The LDAP-specific encoding of a value of this syntax
 915    is defined by the <SyntaxDescription> rule in [MODELS].
 916
 917    The LDAP definition for the LDAP Syntax Description syntax is:
 918
 919       ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
 920
 921    The above LDAP definition for the LDAP Syntax Description syntax is
 922    itself a legal value of the LDAP Syntax Description syntax.
 923
 924    The ASN.1 type corresponding to the LDAP Syntax Description syntax is
 925    defined as follows, assuming EXPLICIT TAGS:
 926
 927       LDAPSyntaxDescription ::= SEQUENCE {
 928           identifier      OBJECT IDENTIFIER,
 929           description     DirectoryString { ub-schema } OPTIONAL }
 930
 931    The DirectoryString parameterized ASN.1 type is defined in [X.520].
 932
 933    The value of ub-schema (an integer) is implementation defined.  A
 934    non-normative definition appears in [X.520].
 935
 936 3.3.19.  Matching Rule Description
 937
 938    A value of the Matching Rule Description syntax is the definition of
 939    a matching rule.  The LDAP-specific encoding of a value of this
 940    syntax is defined by the <MatchingRuleDescription> rule in [MODELS].
 941
 942       Example:
 943          ( 2.5.13.2 NAME 'caseIgnoreMatch'
 944             SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
 945
 946    Note: a line break has been added for readability - it is not part of
 947    the syntax.
 948
 949    The LDAP definition for the Matching Rule Description syntax is:
 950
 951
 952
 953
 954 Legg                    Expires 23 December 2005               [Page 17]
 955 \f
 956 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
 957
 958
 959       ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
 960
 961    This syntax corresponds to the MatchingRuleDescription ASN.1 type
 962    from [X.501].
 963
 964 3.3.20.  Matching Rule Use Description
 965
 966    A value of the Matching Rule Use Description syntax indicates the
 967    attribute types to which a matching rule may be applied in an
 968    extensibleMatch search filter [PROT].  The LDAP-specific encoding of
 969    a value of this syntax is defined by the <MatchingRuleUseDescription>
 970    rule in [MODELS].
 971
 972       Example:
 973          ( 2.5.13.16 APPLIES ( givenName $ surname ) )
 974
 975    The LDAP definition for the Matching Rule Use Description syntax is:
 976
 977       ( 1.3.6.1.4.1.1466.115.121.1.31
 978          DESC 'Matching Rule Use Description' )
 979
 980    This syntax corresponds to the MatchingRuleUseDescription ASN.1 type
 981    from [X.501].
 982
 983 3.3.21.  Name and Optional UID
 984
 985    A value of the Name and Optional UID syntax is the distinguished name
 986    [MODELS] of an entity optionally accompanied by a unique identifier
 987    that serves to differentiate the entity from others with an identical
 988    distinguished name.
 989
 990    The LDAP-specific encoding of a value of this syntax is defined by
 991    the following ABNF:
 992
 993       NameAndOptionalUID = distinguishedName [ SHARP BitString ]
 994
 995    The <BitString> rule is defined in Section 3.3.2.  The
 996    <distinguishedName> rule is defined in [LDAPDN].  The <SHARP> rule is
 997    defined in [MODELS].
 998
 999    Note that although the '#' character may occur in the string
1000    representation of a distinguished name, no additional escaping of
1001    this character is performed when a <distinguishedName> is encoded in
1002    a <NameAndOptionalUID>.
1003
1004       Example:
1005          1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
1006
1007
1008
1009
1010 Legg                    Expires 23 December 2005               [Page 18]
1011 \f
1012 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1013
1014
1015    The LDAP definition for the Name and Optional UID syntax is:
1016
1017       ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
1018
1019    This syntax corresponds to the NameAndOptionalUID ASN.1 type from
1020    [X.520].
1021
1022 3.3.22.  Name Form Description
1023
1024    A value of the Name Form Description syntax is the definition of a
1025    name form, which regulates how entries may be named.  The
1026    LDAP-specific encoding of a value of this syntax is defined by the
1027    <NameFormDescription> rule in [MODELS].
1028
1029       Example:
1030          ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
1031
1032    The LDAP definition for the Name Form Description syntax is:
1033
1034       ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
1035
1036    This syntax corresponds to the NameFormDescription ASN.1 type from
1037    [X.501].
1038
1039 3.3.23.  Numeric String
1040
1041    A value of the Numeric String syntax is a sequence of one or more
1042    numerals and spaces.  The LDAP-specific encoding of a value of this
1043    syntax is the unconverted string of characters, which conforms to the
1044    following ABNF:
1045
1046       NumericString = 1*(DIGIT / SPACE)
1047
1048    The <DIGIT> and <SPACE> rules are defined in [MODELS].
1049
1050       Example:
1051          15 079 672 281
1052
1053    The LDAP definition for the Numeric String syntax is:
1054
1055       ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
1056
1057    This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
1058
1059 3.3.24.  Object Class Description
1060
1061    A value of the Object Class Description syntax is the definition of
1062    an object class.  The LDAP-specific encoding of a value of this
1063
1064
1065
1066 Legg                    Expires 23 December 2005               [Page 19]
1067 \f
1068 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1069
1070
1071    syntax is defined by the <ObjectClassDescription> rule in [MODELS].
1072
1073       Example:
1074          ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c
1075             MAY ( searchGuide $ description ) )
1076
1077    Note: a line break has been added for readability - it is not part of
1078    the syntax.
1079
1080    The LDAP definition for the Object Class Description syntax is:
1081
1082       ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
1083
1084    This syntax corresponds to the ObjectClassDescription ASN.1 type from
1085    [X.501].
1086
1087 3.3.25.  Octet String
1088
1089    A value of the Octet String syntax is a sequence of zero, one or more
1090    arbitrary octets.  The LDAP-specific encoding of a value of this
1091    syntax is the unconverted sequence of octets, which conforms to the
1092    following ABNF:
1093
1094       OctetString = *OCTET
1095
1096    The <OCTET> rule is defined in [MODELS].  Values of this syntax are
1097    not generally human-readable.
1098
1099    The LDAP definition for the Octet String syntax is:
1100
1101       ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
1102
1103    This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
1104
1105 3.3.26.  OID
1106
1107    A value of the OID syntax is an object identifier; a sequence of two
1108    or more non-negative integers that uniquely identify some object or
1109    item of specification.  Many of the object identifiers used in LDAP
1110    also have IANA registered names [RFC3383].
1111
1112    The LDAP-specific encoding of a value of this syntax is defined by
1113    the <oid> rule in [MODELS].
1114
1115       Examples:
1116          1.2.3.4
1117          cn
1118
1119
1120
1121
1122 Legg                    Expires 23 December 2005               [Page 20]
1123 \f
1124 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1125
1126
1127    The LDAP definition for the OID syntax is:
1128
1129       ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
1130
1131    This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from
1132    [ASN.1].
1133
1134 3.3.27.  Other Mailbox
1135
1136    A value of the Other Mailbox syntax identifies an electronic mailbox,
1137    in a particular named mail system.  The LDAP-specific encoding of a
1138    value of this syntax is defined by the following ABNF:
1139
1140       OtherMailbox = mailbox-type DOLLAR mailbox
1141       mailbox-type = PrintableString
1142       mailbox      = IA5String
1143
1144    The <mailbox-type> rule represents the type of mail system in which
1145    the mailbox resides, for example "MCIMail", and <mailbox> is the
1146    actual mailbox in the mail system described by <mailbox-type>.  The
1147    <PrintableString> and <IA5String> rules are defined in Section 3.2.
1148    The <DOLLAR> rule is defined in [MODELS].
1149
1150    The LDAP definition for the Other Mailbox syntax is:
1151
1152       ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
1153
1154    The ASN.1 type corresponding to the Other Mailbox syntax is defined
1155    as follows, assuming EXPLICIT TAGS:
1156
1157       OtherMailbox ::= SEQUENCE {
1158           mailboxType  PrintableString,
1159           mailbox      IA5String
1160       }
1161
1162 3.3.28.  Postal Address
1163
1164    A value of the Postal Address syntax is a sequence of strings of one
1165    or more arbitrary UCS characters, which form an address in a physical
1166    mail system.
1167
1168    The LDAP-specific encoding of a value of this syntax is defined by
1169    the following ABNF:
1170
1171       PostalAddress = line *( DOLLAR line )
1172       line          = 1*line-char
1173       line-char     = %x00-23
1174                       / (%x5C "24")  ; escaped "$"
1175
1176
1177
1178 Legg                    Expires 23 December 2005               [Page 21]
1179 \f
1180 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1181
1182
1183                       / %x25-5B
1184                       / (%x5C "5C")  ; escaped "\"
1185                       / %x5D-7F
1186                       / UTFMB
1187
1188    Each character string (i.e., <line>) of a postal address value is
1189    encoded as a UTF-8 [UTF8] string except that "\" and "$" characters,
1190    if they occur in the string, are escaped by a "\" character followed
1191    by the two hexadecimal digit code for the character.  The <DOLLAR>
1192    and <UTFMB> rules are defined in [MODELS].
1193
1194    Many servers limit the postal address to no more than six lines of no
1195    more than thirty characters each.
1196
1197       Example:
1198          1234 Main St.$Anytown, CA 12345$USA
1199          \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
1200
1201    The LDAP definition for the Postal Address syntax is:
1202
1203       ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
1204
1205    This syntax corresponds to the PostalAddress ASN.1 type from [X.520],
1206    i.e.,
1207
1208       PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
1209           DirectoryString { ub-postal-string }
1210
1211    The values of ub-postal-line and ub-postal-string (both integers) are
1212    implementation defined.  Non-normative definitions appear in [X.520].
1213
1214 3.3.29.  Printable String
1215
1216    A value of the Printable String syntax is a string of one or more
1217    latin alphabetic, numeric, and selected punctuation characters as
1218    specified by the <PrintableCharacter> rule in Section 3.2.
1219
1220    The LDAP-specific encoding of a value of this syntax is the
1221    unconverted string of characters, which conforms to the
1222    <PrintableString> rule in Section 3.2.
1223
1224       Example:
1225          This is a PrintableString.
1226
1227    The LDAP definition for the PrintableString syntax is:
1228
1229       ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
1230
1231
1232
1233
1234 Legg                    Expires 23 December 2005               [Page 22]
1235 \f
1236 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1237
1238
1239    This syntax corresponds to the PrintableString ASN.1 type from
1240    [ASN.1].
1241
1242 3.3.30.  Substring Assertion
1243
1244    A value of the Substring Assertion syntax is a sequence of zero, one
1245    or more character substrings used as an argument for substring
1246    extensible matching of character string attribute values, i.e., as
1247    the matchValue of a MatchingRuleAssertion [PROT].  Each substring is
1248    a string of one or more arbitrary characters from the Universal
1249    Character Set (UCS) [UCS].  A zero length substring is not permitted.
1250
1251    The LDAP-specific encoding of a value of this syntax is defined by
1252    the following ABNF:
1253
1254       SubstringAssertion = [ initial ] any [ final ]
1255
1256       initial  = substring
1257       any      = ASTERISK *(substring ASTERISK)
1258       final    = substring
1259       ASTERISK = %x2A  ; asterisk ("*")
1260
1261       substring           = 1*substring-character
1262       substring-character = %x00-29
1263                             / (%x5C "2A")  ; escaped "*"
1264                             / %x2B-5B
1265                             / (%x5C "5C")  ; escaped "\"
1266                             / %x5D-7F
1267                             / UTFMB
1268
1269    Each <substring> of a Substring Assertion value is encoded as a UTF-8
1270    [UTF8] string, except that "\" and "*" characters, if they occur in
1271    the substring, are escaped by a "\" character followed by the two
1272    hexadecimal digit code for the character.
1273
1274    The Substring Assertion syntax is used only as the syntax of
1275    assertion values in the extensible match.  It is not used as an
1276    attribute syntax, or in the SubstringFilter [PROT].
1277
1278    The LDAP definition for the Substring Assertion syntax is:
1279
1280       ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
1281
1282    This syntax corresponds to the SubstringAssertion ASN.1 type from
1283    [X.520].
1284
1285 3.3.31.  Telephone Number
1286
1287
1288
1289
1290 Legg                    Expires 23 December 2005               [Page 23]
1291 \f
1292 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1293
1294
1295    A value of the Telephone Number syntax is a string of printable
1296    characters that complies with the internationally agreed format for
1297    representing international telephone numbers [E.123].
1298
1299    The LDAP-specific encoding of a value of this syntax is the
1300    unconverted string of characters, which conforms to the
1301    <PrintableString> rule in Section 3.2.
1302
1303       Examples:
1304          +1 512 315 0280
1305          +1-512-315-0280
1306          +61 3 9896 7830
1307
1308    The LDAP definition for the Telephone Number syntax is:
1309
1310       ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
1311
1312    The Telephone Number syntax corresponds to the following ASN.1 type
1313    from [X.520]:
1314
1315       PrintableString (SIZE(1..ub-telephone-number))
1316
1317    The value of ub-telephone-number (an integer) is implementation
1318    defined.  A non-normative definition appears in [X.520].
1319
1320 3.3.32.  Teletex Terminal Identifier
1321
1322    A value of this syntax specifies the identifier and (optionally)
1323    parameters of a teletex terminal.
1324
1325    The LDAP-specific encoding of a value of this syntax is defined by
1326    the following ABNF:
1327
1328       teletex-id = ttx-term *(DOLLAR ttx-param)
1329       ttx-term   = PrintableString          ; terminal identifier
1330       ttx-param  = ttx-key COLON ttx-value  ; parameter
1331       ttx-key    = "graphic" / "control" / "misc" / "page" / "private"
1332       ttx-value  = *ttx-value-octet
1333
1334       ttx-value-octet = %x00-23
1335                         / (%x5C "24")  ; escaped "$"
1336                         / %x25-5B
1337                         / (%x5C "5C")  ; escaped "\"
1338                         / %x5D-FF
1339
1340    The <PrintableString> and <COLON> rules are defined in Section 3.2.
1341    The <DOLLAR> rule is defined in [MODELS].
1342
1343
1344
1345
1346 Legg                    Expires 23 December 2005               [Page 24]
1347 \f
1348 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1349
1350
1351    The LDAP definition for the Teletex Terminal Identifier syntax is:
1352
1353       ( 1.3.6.1.4.1.1466.115.121.1.51
1354          DESC 'Teletex Terminal Identifier' )
1355
1356    This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type
1357    from [X.520].
1358
1359 3.3.33.  Telex Number
1360
1361    A value of the Telex Number syntax specifies the telex number,
1362    country code and answerback code of a telex terminal.
1363
1364    The LDAP-specific encoding of a value of this syntax is defined by
1365    the following ABNF:
1366
1367       telex-number  = actual-number DOLLAR country-code
1368                          DOLLAR answerback
1369       actual-number = PrintableString
1370       country-code  = PrintableString
1371       answerback    = PrintableString
1372
1373    The <PrintableString> rule is defined in Section 3.2.  The <DOLLAR>
1374    rule is defined in [MODELS].
1375
1376    The LDAP definition for the Telex Number syntax is:
1377
1378       ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
1379
1380    This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
1381
1382 3.3.34.  UTC Time
1383
1384    A value of the UTC Time syntax is a character string representing a
1385    date and time to a precision of one minute or one second.  The year
1386    is given as a two-digit number.  The LDAP-specific encoding of a
1387    value of this syntax follows the format defined in [ASN.1] for the
1388    UTCTime type and is described by the following ABNF:
1389
1390       UTCTime         = year month day hour minute [ second ]
1391                            [ u-time-zone ]
1392       u-time-zone     = %x5A  ; "Z"
1393                         / u-differential
1394       u-differential  = ( MINUS / PLUS ) hour minute
1395
1396    The <year>, <month>, <day>, <hour>, <minute>, <second> and <MINUS>
1397    rules are defined in Section 3.3.13.  The <PLUS> rule is defined in
1398    [MODELS].
1399
1400
1401
1402 Legg                    Expires 23 December 2005               [Page 25]
1403 \f
1404 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1405
1406
1407    The above ABNF allows character strings which do not represent valid
1408    dates (in the Gregorian calendar) and/or valid times.  Such character
1409    strings SHOULD be considered invalid for this syntax.
1410
1411    The time value represents coordinated universal time if the "Z" form
1412    of <u-time-zone> is used, otherwise the value represents a local
1413    time.  In the latter case, if <u-differential> is provided then
1414    coordinated universal time can be calculated by subtracting the
1415    differential from the local time.  The <u-time-zone> SHOULD be
1416    present in time values and the "Z" form of <u-time-zone> SHOULD be
1417    used in preference to <u-differential>.
1418
1419    The LDAP definition for the UTC Time syntax is:
1420
1421       ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
1422
1423    Note: This syntax is deprecated in favor of the Generalized Time
1424    syntax.
1425
1426    The UTC Time syntax corresponds to the UTCTime ASN.1 type from
1427    [ASN.1].
1428
1429 4.  Matching Rules
1430
1431    Matching rules are used by directory implementations to compare
1432    attribute values against assertion values when performing Search and
1433    Compare operations [PROT].  They are also used when comparing a
1434    purported distinguished name [MODELS] with the name of an entry.
1435    When modifying entries, matching rules are used to identify values to
1436    be deleted and to prevent an attribute from containing two equal
1437    values.
1438
1439    Matching rules that are required for directory operation, or that are
1440    in common use, are specified in this section.
1441
1442 4.1.  General Considerations
1443
1444    A matching rule is applied to attribute values through an
1445    AttributeValueAssertion or MatchingRuleAssertion [PROT].  The
1446    conditions under which an AttributeValueAssertion or
1447    MatchingRuleAssertion evaluates to Undefined are specified elsewhere
1448    [PROT].  If an assertion is not Undefined then the result of the
1449    assertion is the result of applying the selected matching rule.  A
1450    matching rule evaluates to TRUE, and in some cases Undefined, as
1451    specified in the description of the matching rule, otherwise it
1452    evaluates to FALSE.
1453
1454    Each assertion contains an assertion value.  The definition of each
1455
1456
1457
1458 Legg                    Expires 23 December 2005               [Page 26]
1459 \f
1460 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1461
1462
1463    matching rule specifies the syntax for the assertion value.  The
1464    syntax of the assertion value is typically, but not necessarily, the
1465    same as the syntax of the attribute values to which the matching rule
1466    may be applied.  Note that an AssertionValue in a SubstringFilter
1467    [PROT] conforms to the assertion syntax of the equality matching rule
1468    for the attribute type rather than the assertion syntax of the
1469    substrings matching rule for the attribute type.  Conceptually, the
1470    entire SubstringFilter is converted into an assertion value of the
1471    substrings matching rule prior to applying the rule.
1472
1473    The definition of each matching rule indicates the attribute syntaxes
1474    to which the rule may be applied, by specifying conditions the
1475    corresponding ASN.1 type of a candidate attribute syntax must
1476    satisfy.  These conditions are also satisfied if the corresponding
1477    ASN.1 type is a tagged or constrained derivative of the ASN.1 type
1478    explicitly mentioned in the rule description (i.e., ASN.1 tags and
1479    constraints are ignored in checking applicability), or an alternative
1480    reference notation for the explicitly mentioned type.  Each rule
1481    description lists as examples of applicable attribute syntaxes, the
1482    complete list of the syntaxes defined in this document to which the
1483    matching rule applies.  A matching rule may be applicable to
1484    additional syntaxes defined in other documents if those syntaxes
1485    satisfy the conditions on the corresponding ASN.1 type.
1486
1487    The description of each matching rule indicates whether the rule is
1488    suitable for use as the equality matching rule (EQUALITY), ordering
1489    matching rule (ORDERING) or substrings matching rule (SUBSTR) in an
1490    attribute type definition [MODELS].
1491
1492    Each matching rule is uniquely identified with an object identifier.
1493    The definition of a matching rule should not be subsequently changed.
1494    If a change is desirable then a new matching rule with a different
1495    object identifier should be defined instead.
1496
1497    Servers MAY implement the wordMatch and keywordMatch matching rules,
1498    but SHOULD implement the other matching rules in Section 4.2.
1499    Servers MAY implement additional matching rules.
1500
1501    Servers which implement the extensibleMatch filter SHOULD allow the
1502    matching rules listed in Section 4.2 to be used in the
1503    extensibleMatch filter and SHOULD allow matching rules to be used
1504    with all attribute types known to the server, where the assertion
1505    syntax of the matching rule is the same as the value syntax of the
1506    attribute.
1507
1508    Servers MUST publish in the matchingRules attribute, the definitions
1509    of matching rules referenced by values of the attributeTypes and
1510    matchingRuleUse attributes in the same subschema entry.  Other
1511
1512
1513
1514 Legg                    Expires 23 December 2005               [Page 27]
1515 \f
1516 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1517
1518
1519    unreferenced matching rules MAY be published in the matchingRules
1520    attribute.
1521
1522    If the server supports the extensibleMatch filter, then the server
1523    MAY use the matchingRuleUse attribute to indicate the applicability
1524    (in an extensibleMatch filter) of selected matching rules to
1525    nominated attribute types.
1526
1527 4.2.  Matching Rule Definitions
1528
1529    Nominated character strings in assertion and attribute values are
1530    prepared according to the string preparation algorithms [PREP] for
1531    LDAP when evaluating the following matching rules:
1532
1533       numericStringMatch,
1534       numericStringSubstringsMatch,
1535       caseExactMatch,
1536       caseExactOrderingMatch,
1537       caseExactSubstringsMatch,
1538       caseExactIA5Match,
1539       caseIgnoreIA5Match,
1540       caseIgnoreIA5SubstringsMatch,
1541       caseIgnoreListMatch,
1542       caseIgnoreListSubstringsMatch,
1543       caseIgnoreMatch,
1544       caseIgnoreOrderingMatch,
1545       caseIgnoreSubstringsMatch,
1546       directoryStringFirstComponentMatch,
1547       telephoneNumberMatch,
1548       telephoneNumberSubstringsMatch and
1549       wordMatch.
1550
1551    The Transcode, Normalize, Prohibit and Check bidi steps are the same
1552    for each of the matching rules.  However, the Map and Insignificant
1553    Character Handling steps depends on the specific rule, as detailed in
1554    the description of these matching rules in the sections that follow.
1555
1556 4.2.1.  bitStringMatch
1557
1558    The bitStringMatch rule compares an assertion value of the Bit String
1559    syntax to an attribute value of a syntax (e.g., the Bit String
1560    syntax) whose corresponding ASN.1 type is BIT STRING.
1561
1562    If the corresponding ASN.1 type of the attribute syntax does not have
1563    a named bit list [ASN.1] (which is the case for the Bit String
1564    syntax) then the rule evaluates to TRUE if and only if the attribute
1565    value has the same number of bits as the assertion value and the bits
1566    match on a bitwise basis.
1567
1568
1569
1570 Legg                    Expires 23 December 2005               [Page 28]
1571 \f
1572 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1573
1574
1575    If the corresponding ASN.1 type does have a named bit list then
1576    bitStringMatch operates as above except that trailing zero bits in
1577    the attribute and assertion values are treated as absent.
1578
1579    The LDAP definition for the bitStringMatch rule is:
1580
1581       ( 2.5.13.16 NAME 'bitStringMatch'
1582          SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
1583
1584    The bitStringMatch rule is an equality matching rule.
1585
1586 4.2.2.  booleanMatch
1587
1588    The booleanMatch rule compares an assertion value of the Boolean
1589    syntax to an attribute value of a syntax (e.g., the Boolean syntax)
1590    whose corresponding ASN.1 type is BOOLEAN.
1591
1592    The rule evaluates to TRUE if and only if the attribute value and the
1593    assertion value are both TRUE or both FALSE.
1594
1595    The LDAP definition for the booleanMatch rule is:
1596
1597       ( 2.5.13.13 NAME 'booleanMatch'
1598          SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
1599
1600    The booleanMatch rule is an equality matching rule.
1601
1602 4.2.3.  caseExactIA5Match
1603
1604    The caseExactIA5Match rule compares an assertion value of the IA5
1605    String syntax to an attribute value of a syntax (e.g the IA5 String
1606    syntax) whose corresponding ASN.1 type is IA5String.
1607
1608    The rule evaluates to TRUE if and only if the prepared attribute
1609    value character string and the prepared assertion value character
1610    string have the same number of characters and corresponding
1611    characters have the same code point.
1612
1613    In preparing the attribute value and assertion value for comparison,
1614    characters are not case folded in the Map preparation step, and only
1615    Insignificant Space Handling is applied in the Insignificant
1616    Character Handling step.
1617
1618    The LDAP definition for the caseExactIA5Match rule is:
1619
1620       ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
1621          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1622
1623
1624
1625
1626 Legg                    Expires 23 December 2005               [Page 29]
1627 \f
1628 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1629
1630
1631    The caseExactIA5Match rule is an equality matching rule.
1632
1633 4.2.4.  caseExactMatch
1634
1635    The caseExactMatch rule compares an assertion value of the Directory
1636    String syntax to an attribute value of a syntax (e.g., the Directory
1637    String, Printable String, Country String or Telephone Number syntax)
1638    whose corresponding ASN.1 type is DirectoryString or one of the
1639    alternative string types of DirectoryString, e.g., PrintableString
1640    (the other alternatives do not correspond to any syntax defined in
1641    this document).
1642
1643    The rule evaluates to TRUE if and only if the prepared attribute
1644    value character string and the prepared assertion value character
1645    string have the same number of characters and corresponding
1646    characters have the same code point.
1647
1648    In preparing the attribute value and assertion value for comparison,
1649    characters are not case folded in the Map preparation step, and only
1650    Insignificant Space Handling is applied in the Insignificant
1651    Character Handling step.
1652
1653    The LDAP definition for the caseExactMatch rule is:
1654
1655       ( 2.5.13.5 NAME 'caseExactMatch'
1656          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1657
1658    The caseExactMatch rule is an equality matching rule.
1659
1660 4.2.5.  caseExactOrderingMatch
1661
1662    The caseExactOrderingMatch rule compares an assertion value of the
1663    Directory String syntax to an attribute value of a syntax (e.g., the
1664    Directory String, Printable String, Country String or Telephone
1665    Number syntax) whose corresponding ASN.1 type is DirectoryString or
1666    one of its alternative string types.
1667
1668    The rule evaluates to TRUE if, and only if, in the code point
1669    collation order, the prepared attribute value character string
1670    appears earlier than the prepared assertion value character string,
1671    i.e., the attribute value is "less than" the assertion value.
1672
1673    In preparing the attribute value and assertion value for comparison,
1674    characters are not case folded in the Map preparation step, and only
1675    Insignificant Space Handling is applied in the Insignificant
1676    Character Handling step.
1677
1678    The LDAP definition for the caseExactOrderingMatch rule is:
1679
1680
1681
1682 Legg                    Expires 23 December 2005               [Page 30]
1683 \f
1684 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1685
1686
1687       ( 2.5.13.6 NAME 'caseExactOrderingMatch'
1688          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1689
1690    The caseExactOrderingMatch rule is an ordering matching rule.
1691
1692 4.2.6.  caseExactSubstringsMatch
1693
1694    The caseExactSubstringsMatch rule compares an assertion value of the
1695    Substring Assertion syntax to an attribute value of a syntax (e.g.,
1696    the Directory String, Printable String, Country String or Telephone
1697    Number syntax) whose corresponding ASN.1 type is DirectoryString or
1698    one of its alternative string types.
1699
1700    The rule evaluates to TRUE if and only if the prepared substrings of
1701    the assertion value match disjoint portions of the prepared attribute
1702    value character string in the order of the substrings in the
1703    assertion value, and an <initial> substring, if present, matches the
1704    beginning of the prepared attribute value character string, and a
1705    <final> substring, if present, matches the end of the prepared
1706    attribute value character string.  A prepared substring matches a
1707    portion of the prepared attribute value character string if
1708    corresponding characters have the same code point.
1709
1710    In preparing the attribute value and assertion value substrings for
1711    comparison, characters are not case folded in the Map preparation
1712    step, and only Insignificant Space Handling is applied in the
1713    Insignificant Character Handling step.
1714
1715    The LDAP definition for the caseExactSubstringsMatch rule is:
1716
1717       ( 2.5.13.7 NAME 'caseExactSubstringsMatch'
1718          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1719
1720    The caseExactSubstringsMatch rule is a substrings matching rule.
1721
1722 4.2.7.  caseIgnoreIA5Match
1723
1724    The caseIgnoreIA5Match rule compares an assertion value of the IA5
1725    String syntax to an attribute value of a syntax (e.g the IA5 String
1726    syntax) whose corresponding ASN.1 type is IA5String.
1727
1728    The rule evaluates to TRUE if and only if the prepared attribute
1729    value character string and the prepared assertion value character
1730    string have the same number of characters and corresponding
1731    characters have the same code point.
1732
1733    In preparing the attribute value and assertion value for comparison,
1734    characters are case folded in the Map preparation step, and only
1735
1736
1737
1738 Legg                    Expires 23 December 2005               [Page 31]
1739 \f
1740 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1741
1742
1743    Insignificant Space Handling is applied in the Insignificant
1744    Character Handling step.
1745
1746    The LDAP definition for the caseIgnoreIA5Match rule is:
1747
1748       ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
1749          SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1750
1751    The caseIgnoreIA5Match rule is an equality matching rule.
1752
1753 4.2.8.  caseIgnoreIA5SubstringsMatch
1754
1755    The caseIgnoreIA5SubstringsMatch rule compares an assertion value of
1756    the Substring Assertion syntax to an attribute value of a syntax (e.g
1757    the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
1758
1759    The rule evaluates to TRUE if and only if the prepared substrings of
1760    the assertion value match disjoint portions of the prepared attribute
1761    value character string in the order of the substrings in the
1762    assertion value, and an <initial> substring, if present, matches the
1763    beginning of the prepared attribute value character string, and a
1764    <final> substring, if present, matches the end of the prepared
1765    attribute value character string.  A prepared substring matches a
1766    portion of the prepared attribute value character string if
1767    corresponding characters have the same code point.
1768
1769    In preparing the attribute value and assertion value substrings for
1770    comparison, characters are case folded in the Map preparation step,
1771    and only Insignificant Space Handling is applied in the Insignificant
1772    Character Handling step.
1773
1774       ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch'
1775          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1776
1777    The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
1778
1779 4.2.9.  caseIgnoreListMatch
1780
1781    The caseIgnoreListMatch rule compares an assertion value that is a
1782    sequence of strings to an attribute value of a syntax (e.g., the
1783    Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE
1784    OF the DirectoryString ASN.1 type.
1785
1786    The rule evaluates to TRUE if and only if the attribute value and the
1787    assertion value have the same number of strings and corresponding
1788    strings (by position) match according to the caseIgnoreMatch matching
1789    rule.
1790
1791
1792
1793
1794 Legg                    Expires 23 December 2005               [Page 32]
1795 \f
1796 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1797
1798
1799    In [X.520] the assertion syntax for this matching rule is defined to
1800    be:
1801
1802       SEQUENCE OF DirectoryString {ub-match}
1803
1804    i.e., different from the corresponding type for the Postal Address
1805    syntax.  The choice of the Postal Address syntax for the assertion
1806    syntax of the caseIgnoreListMatch in LDAP should not be seen as
1807    limiting the matching rule to only apply to attributes with the
1808    Postal Address syntax.
1809
1810    The LDAP definition for the caseIgnoreListMatch rule is:
1811
1812       ( 2.5.13.11 NAME 'caseIgnoreListMatch'
1813          SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
1814
1815    The caseIgnoreListMatch rule is an equality matching rule.
1816
1817 4.2.10.  caseIgnoreListSubstringsMatch
1818
1819    The caseIgnoreListSubstringsMatch rule compares an assertion value of
1820    the Substring Assertion syntax to an attribute value of a syntax
1821    (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a
1822    SEQUENCE OF the DirectoryString ASN.1 type.
1823
1824    The rule evaluates to TRUE if and only if the assertion value
1825    matches, per the caseIgnoreSubstringsMatch rule, the character string
1826    formed by concatenating the strings of the attribute value, except
1827    that none of the <initial>, <any>, or <final> substrings of the
1828    assertion value are considered to match a substring of the
1829    concatenated string which spans more than one of the original strings
1830    of the attribute value.
1831
1832    Note that, in terms of the LDAP-specific encoding of the Postal
1833    Address syntax, the concatenated string omits the <DOLLAR> line
1834    separator and the escaping of "\" and "$" characters.
1835
1836    The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
1837
1838       ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
1839          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1840
1841    The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
1842
1843 4.2.11.  caseIgnoreMatch
1844
1845    The caseIgnoreMatch rule compares an assertion value of the Directory
1846    String syntax to an attribute value of a syntax (e.g., the Directory
1847
1848
1849
1850 Legg                    Expires 23 December 2005               [Page 33]
1851 \f
1852 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1853
1854
1855    String, Printable String, Country String or Telephone Number syntax)
1856    whose corresponding ASN.1 type is DirectoryString or one of its
1857    alternative string types.
1858
1859    The rule evaluates to TRUE if and only if the prepared attribute
1860    value character string and the prepared assertion value character
1861    string have the same number of characters and corresponding
1862    characters have the same code point.
1863
1864    In preparing the attribute value and assertion value for comparison,
1865    characters are case folded in the Map preparation step, and only
1866    Insignificant Space Handling is applied in the Insignificant
1867    Character Handling step.
1868
1869    The LDAP definition for the caseIgnoreMatch rule is:
1870
1871       ( 2.5.13.2 NAME 'caseIgnoreMatch'
1872          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1873
1874    The caseIgnoreMatch rule is an equality matching rule.
1875
1876 4.2.12.  caseIgnoreOrderingMatch
1877
1878    The caseIgnoreOrderingMatch rule compares an assertion value of the
1879    Directory String syntax to an attribute value of a syntax (e.g., the
1880    Directory String, Printable String, Country String or Telephone
1881    Number syntax) whose corresponding ASN.1 type is DirectoryString or
1882    one of its alternative string types.
1883
1884    The rule evaluates to TRUE if, and only if, in the code point
1885    collation order, the prepared attribute value character string
1886    appears earlier than the prepared assertion value character string,
1887    i.e., the attribute value is "less than" the assertion value.
1888
1889    In preparing the attribute value and assertion value for comparison,
1890    characters are case folded in the Map preparation step, and only
1891    Insignificant Space Handling is applied in the Insignificant
1892    Character Handling step.
1893
1894    The LDAP definition for the caseIgnoreOrderingMatch rule is:
1895
1896       ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
1897          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1898
1899    The caseIgnoreOrderingMatch rule is an ordering matching rule.
1900
1901 4.2.13.  caseIgnoreSubstringsMatch
1902
1903
1904
1905
1906 Legg                    Expires 23 December 2005               [Page 34]
1907 \f
1908 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1909
1910
1911    The caseIgnoreSubstringsMatch rule compares an assertion value of the
1912    Substring Assertion syntax to an attribute value of a syntax (e.g.,
1913    the Directory String, Printable String, Country String or Telephone
1914    Number syntax) whose corresponding ASN.1 type is DirectoryString or
1915    one of its alternative string types.
1916
1917    The rule evaluates to TRUE if and only if the prepared substrings of
1918    the assertion value match disjoint portions of the prepared attribute
1919    value character string in the order of the substrings in the
1920    assertion value, and an <initial> substring, if present, matches the
1921    beginning of the prepared attribute value character string, and a
1922    <final> substring, if present, matches the end of the prepared
1923    attribute value character string.  A prepared substring matches a
1924    portion of the prepared attribute value character string if
1925    corresponding characters have the same code point.
1926
1927    In preparing the attribute value and assertion value substrings for
1928    comparison, characters are case folded in the Map preparation step,
1929    and only Insignificant Space Handling is applied in the Insignificant
1930    Character Handling step.
1931
1932    The LDAP definition for the caseIgnoreSubstringsMatch rule is:
1933
1934       ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
1935          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1936
1937    The caseIgnoreSubstringsMatch rule is a substrings matching rule.
1938
1939 4.2.14.  directoryStringFirstComponentMatch
1940
1941    The directoryStringFirstComponentMatch rule compares an assertion
1942    value of the Directory String syntax to an attribute value of a
1943    syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
1944    first component of the DirectoryString ASN.1 type.
1945
1946    Note that the assertion syntax of this matching rule differs from the
1947    attribute syntax of attributes for which this is the equality
1948    matching rule.
1949
1950    The rule evaluates to TRUE if and only if the assertion value matches
1951    the first component of the attribute value using the rules of
1952    caseIgnoreMatch.
1953
1954    The LDAP definition for the directoryStringFirstComponentMatch
1955    matching rule is:
1956
1957       ( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
1958          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1959
1960
1961
1962 Legg                    Expires 23 December 2005               [Page 35]
1963 \f
1964 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
1965
1966
1967    The directoryStringFirstComponentMatch rule is an equality matching
1968    rule.  When using directoryStringFirstComponentMatch to compare two
1969    attribute values (of an applicable syntax), an assertion value must
1970    first be derived from one of the attribute values.  An assertion
1971    value can be derived from an attribute value by taking the first
1972    component of that attribute value.
1973
1974 4.2.15.  distinguishedNameMatch
1975
1976    The distinguishedNameMatch rule compares an assertion value of the DN
1977    syntax to an attribute value of a syntax (e.g., the DN syntax) whose
1978    corresponding ASN.1 type is DistinguishedName.
1979
1980    The rule evaluates to TRUE if and only if the attribute value and the
1981    assertion value have the same number of relative distinguished names
1982    and corresponding relative distinguished names (by position) are the
1983    same.  A relative distinguished name (RDN) of the assertion value is
1984    the same as an RDN of the attribute value if and only if they have
1985    the same number of attribute value assertions and each attribute
1986    value assertion (AVA) of the first RDN is the same as the AVA of the
1987    second RDN with the same attribute type.  The order of the AVAs is
1988    not significant.  Also note that a particular attribute type may
1989    appear in at most one AVA in an RDN.  Two AVAs with the same
1990    attribute type are the same if their values are equal according to
1991    the equality matching rule of the attribute type.  If one or more of
1992    the AVA comparisons evaluate to Undefined and the remaining AVA
1993    comparisons return TRUE then the distinguishedNameMatch rule
1994    evaluates to Undefined.
1995
1996    The LDAP definition for the distinguishedNameMatch rule is:
1997
1998       ( 2.5.13.1 NAME 'distinguishedNameMatch'
1999          SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
2000
2001    The distinguishedNameMatch rule is an equality matching rule.
2002
2003 4.2.16.  generalizedTimeMatch
2004
2005    The generalizedTimeMatch rule compares an assertion value of the
2006    Generalized Time syntax to an attribute value of a syntax (e.g the
2007    Generalized Time syntax) whose corresponding ASN.1 type is
2008    GeneralizedTime.
2009
2010    The rule evaluates to TRUE if and only if the attribute value
2011    represents the same universal coordinated time as the assertion
2012    value.  If a time is specified with the minutes or seconds absent
2013    then the number of minutes or seconds (respectively) is assumed to be
2014    zero.
2015
2016
2017
2018 Legg                    Expires 23 December 2005               [Page 36]
2019 \f
2020 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2021
2022
2023    The LDAP definition for the generalizedTimeMatch rule is:
2024
2025       ( 2.5.13.27 NAME 'generalizedTimeMatch'
2026          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
2027
2028    The generalizedTimeMatch rule is an equality matching rule.
2029
2030 4.2.17.  generalizedTimeOrderingMatch
2031
2032    The generalizedTimeOrderingMatch rule compares the time ordering of
2033    an assertion value of the Generalized Time syntax to an attribute
2034    value of a syntax (e.g the Generalized Time syntax) whose
2035    corresponding ASN.1 type is GeneralizedTime.
2036
2037    The rule evaluates to TRUE if and only if the attribute value
2038    represents a universal coordinated time which is earlier than the
2039    universal coordinated time represented by the assertion value.
2040
2041    The LDAP definition for the generalizedTimeOrderingMatch rule is:
2042
2043       ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
2044          SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
2045
2046    The generalizedTimeOrderingMatch rule is an ordering matching rule.
2047
2048 4.2.18.  integerFirstComponentMatch
2049
2050    The integerFirstComponentMatch rule compares an assertion value of
2051    the Integer syntax to an attribute value of a syntax (e.g the DIT
2052    Structure Rule Description syntax) whose corresponding ASN.1 type is
2053    a SEQUENCE with a mandatory first component of the INTEGER ASN.1
2054    type.
2055
2056    Note that the assertion syntax of this matching rule differs from the
2057    attribute syntax of attributes for which this is the equality
2058    matching rule.
2059
2060    The rule evaluates to TRUE if and only if the assertion value and the
2061    first component of the attribute value are the same integer value.
2062
2063    The LDAP definition for the integerFirstComponentMatch matching rule
2064    is:
2065
2066       ( 2.5.13.29 NAME 'integerFirstComponentMatch'
2067          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2068
2069    The integerFirstComponentMatch rule is an equality matching rule.
2070    When using integerFirstComponentMatch to compare two attribute values
2071
2072
2073
2074 Legg                    Expires 23 December 2005               [Page 37]
2075 \f
2076 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2077
2078
2079    (of an applicable syntax), an assertion value must first be derived
2080    from one of the attribute values.  An assertion value can be derived
2081    from an attribute value by taking the first component of that
2082    attribute value.
2083
2084 4.2.19.  integerMatch
2085
2086    The integerMatch rule compares an assertion value of the Integer
2087    syntax to an attribute value of a syntax (e.g the Integer syntax)
2088    whose corresponding ASN.1 type is INTEGER.
2089
2090    The rule evaluates to TRUE if and only if the attribute value and the
2091    assertion value are the same integer value.
2092
2093    The LDAP definition for the integerMatch matching rule is:
2094
2095       ( 2.5.13.14 NAME 'integerMatch'
2096          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2097
2098    The integerMatch rule is an equality matching rule.
2099
2100 4.2.20.  integerOrderingMatch
2101
2102    The integerOrderingMatch rule compares an assertion value of the
2103    Integer syntax to an attribute value of a syntax (e.g the Integer
2104    syntax) whose corresponding ASN.1 type is INTEGER.
2105
2106    The rule evaluates to TRUE if and only if the integer value of the
2107    attribute value is less than the integer value the assertion value.
2108
2109    The LDAP definition for the integerOrderingMatch matching rule is:
2110
2111       ( 2.5.13.15 NAME 'integerOrderingMatch'
2112          SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
2113
2114    The integerOrderingMatch rule is an ordering matching rule.
2115
2116 4.2.21.  keywordMatch
2117
2118    The keywordMatch rule compares an assertion value of the Directory
2119    String syntax to an attribute value of a syntax (e.g., the Directory
2120    String syntax) whose corresponding ASN.1 type is DirectoryString.
2121
2122    The rule evaluates to TRUE if and only if the assertion value
2123    character string matches any keyword in the attribute value.  The
2124    identification of keywords in the attribute value and the exactness
2125    of the match are both implementation specific.
2126
2127
2128
2129
2130 Legg                    Expires 23 December 2005               [Page 38]
2131 \f
2132 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2133
2134
2135    The LDAP definition for the keywordMatch rule is:
2136
2137       ( 2.5.13.33 NAME 'keywordMatch'
2138          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2139
2140 4.2.22.  numericStringMatch
2141
2142    The numericStringMatch rule compares an assertion value of the
2143    Numeric String syntax to an attribute value of a syntax (e.g the
2144    Numeric String syntax) whose corresponding ASN.1 type is
2145    NumericString.
2146
2147    The rule evaluates to TRUE if and only if the prepared attribute
2148    value character string and the prepared assertion value character
2149    string have the same number of characters and corresponding
2150    characters have the same code point.
2151
2152    In preparing the attribute value and assertion value for comparison,
2153    characters are not case folded in the Map preparation step, and only
2154    numericString Insignificant Character Handling is applied in the
2155    Insignificant Character Handling step.
2156
2157    The LDAP definition for the numericStringMatch matching rule is:
2158
2159       ( 2.5.13.8 NAME 'numericStringMatch'
2160          SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
2161
2162    The numericStringMatch rule is an equality matching rule.
2163
2164 4.2.23.  numericStringOrderingMatch
2165
2166    The numericStringOrderingMatch rule compares an assertion value of
2167    the Numeric String syntax to an attribute value of a syntax (e.g the
2168    Numeric String syntax) whose corresponding ASN.1 type is
2169    NumericString.
2170
2171    The rule evaluates to TRUE if, and only if, in the code point
2172    collation order, the prepared attribute value character string
2173    appears earlier than the prepared assertion value character string,
2174    i.e., the attribute value is "less than" the assertion value.
2175
2176    In preparing the attribute value and assertion value for comparison,
2177    characters are not case folded in the Map preparation step, and only
2178    numericString Insignificant Character Handling is applied in the
2179    Insignificant Character Handling step.
2180
2181    The rule is identical to the caseIgnoreOrderingMatch rule except that
2182    all space characters are skipped during comparison (case is
2183
2184
2185
2186 Legg                    Expires 23 December 2005               [Page 39]
2187 \f
2188 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2189
2190
2191    irrelevant as characters are numeric).
2192
2193    The LDAP definition for the numericStringOrderingMatch matching rule
2194    is:
2195
2196       ( 2.5.13.9 NAME 'numericStringOrderingMatch'
2197          SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
2198
2199    The numericStringOrderingMatch rule is an ordering matching rule.
2200
2201 4.2.24.  numericStringSubstringsMatch
2202
2203    The numericStringSubstringsMatch rule compares an assertion value of
2204    the Substring Assertion syntax to an attribute value of a syntax (e.g
2205    the Numeric String syntax) whose corresponding ASN.1 type is
2206    NumericString.
2207
2208    The rule evaluates to TRUE if and only if the prepared substrings of
2209    the assertion value match disjoint portions of the prepared attribute
2210    value character string in the order of the substrings in the
2211    assertion value, and an <initial> substring, if present, matches the
2212    beginning of the prepared attribute value character string, and a
2213    <final> substring, if present, matches the end of the prepared
2214    attribute value character string.  A prepared substring matches a
2215    portion of the prepared attribute value character string if
2216    corresponding characters have the same code point.
2217
2218    In preparing the attribute value and assertion value for comparison,
2219    characters are not case folded in the Map preparation step, and only
2220    numericString Insignificant Character Handling is applied in the
2221    Insignificant Character Handling step.
2222
2223    The LDAP definition for the numericStringSubstringsMatch matching
2224    rule is:
2225
2226       ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
2227          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2228
2229    The numericStringSubstringsMatch rule is a substrings matching rule.
2230
2231 4.2.25.  objectIdentifierFirstComponentMatch
2232
2233    The objectIdentifierFirstComponentMatch rule compares an assertion
2234    value of the OID syntax to an attribute value of a syntax (e.g the
2235    Attribute Type Description, DIT Content Rule Description, LDAP Syntax
2236    Description, Matching Rule Description, Matching Rule Use
2237    Description, Name Form Description or Object Class Description
2238    syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory
2239
2240
2241
2242 Legg                    Expires 23 December 2005               [Page 40]
2243 \f
2244 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2245
2246
2247    first component of the OBJECT IDENTIFIER ASN.1 type.
2248
2249    Note that the assertion syntax of this matching rule differs from the
2250    attribute syntax of attributes for which this is the equality
2251    matching rule.
2252
2253    The rule evaluates to TRUE if and only if the assertion value matches
2254    the first component of the attribute value using the rules of
2255    objectIdentifierMatch.
2256
2257    The LDAP definition for the objectIdentifierFirstComponentMatch
2258    matching rule is:
2259
2260       ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
2261          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
2262
2263    The objectIdentifierFirstComponentMatch rule is an equality matching
2264    rule.  When using objectIdentifierFirstComponentMatch to compare two
2265    attribute values (of an applicable syntax), an assertion value must
2266    first be derived from one of the attribute values.  An assertion
2267    value can be derived from an attribute value by taking the first
2268    component of that attribute value.
2269
2270 4.2.26.  objectIdentifierMatch
2271
2272    The objectIdentifierMatch rule compares an assertion value of the OID
2273    syntax to an attribute value of a syntax (e.g the OID syntax) whose
2274    corresponding ASN.1 type is OBJECT IDENTIFIER.
2275
2276    The rule evaluates to TRUE if and only if the assertion value and the
2277    attribute value represent the same object identifier, that is, the
2278    same sequence of integers, whether represented explicitly in the
2279    <numericoid> form of <oid> or implicitly in the <descr> form (see
2280    [MODELS]).
2281
2282    If an LDAP client supplies an assertion value in the <descr> form,
2283    and the chosen descriptor is not recognized by the server, then the
2284    objectIdentifierMatch rule evaluates to Undefined.
2285
2286    The LDAP definition for the objectIdentifierMatch matching rule is:
2287
2288       ( 2.5.13.0 NAME 'objectIdentifierMatch'
2289          SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
2290
2291    The objectIdentifierMatch rule is an equality matching rule.
2292
2293 4.2.27.  octetStringMatch
2294
2295
2296
2297
2298 Legg                    Expires 23 December 2005               [Page 41]
2299 \f
2300 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2301
2302
2303    The octetStringMatch rule compares an assertion value of the Octet
2304    String syntax to an attribute value of a syntax (e.g the Octet String
2305    or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING
2306    ASN.1 type.
2307
2308    The rule evaluates to TRUE if and only if the attribute value and the
2309    assertion value are the same length and corresponding octets (by
2310    position) are the same.
2311
2312    The LDAP definition for the octetStringMatch matching rule is:
2313
2314       ( 2.5.13.17 NAME 'octetStringMatch'
2315          SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2316
2317    The octetStringMatch rule is an equality matching rule.
2318
2319 4.2.28.  octetStringOrderingMatch
2320
2321    The octetStringOrderingMatch rule compares an assertion value of the
2322    Octet String syntax to an attribute value of a syntax (e.g the Octet
2323    String or JPEG syntax) whose corresponding ASN.1 type is the OCTET
2324    STRING ASN.1 type.
2325
2326    The rule evaluates to TRUE if and only if the attribute value appears
2327    earlier in the collation order than the assertion value.  The rule
2328    compares octet strings from the first octet to the last octet, and
2329    from the most significant bit to the least significant bit within the
2330    octet.  The first occurrence of a different bit determines the
2331    ordering of the strings.  A zero bit precedes a one bit.  If the
2332    strings contain different numbers of octets but the longer string is
2333    identical to the shorter string up to the length of the shorter
2334    string then the shorter string precedes the longer string.
2335
2336    The LDAP definition for the octetStringOrderingMatch matching rule
2337    is:
2338
2339       ( 2.5.13.18 NAME 'octetStringOrderingMatch'
2340          SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
2341
2342    The octetStringOrderingMatch rule is an ordering matching rule.
2343
2344 4.2.29.  telephoneNumberMatch
2345
2346    The telephoneNumberMatch rule compares an assertion value of the
2347    Telephone Number syntax to an attribute value of a syntax (e.g the
2348    Telephone Number syntax) whose corresponding ASN.1 type is a
2349    PrintableString representing a telephone number.
2350
2351
2352
2353
2354 Legg                    Expires 23 December 2005               [Page 42]
2355 \f
2356 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2357
2358
2359    The rule evaluates to TRUE if and only if the prepared attribute
2360    value character string and the prepared assertion value character
2361    string have the same number of characters and corresponding
2362    characters have the same code point.
2363
2364    In preparing the attribute value and assertion value for comparison,
2365    characters are case folded in the Map preparation step, and only
2366    telephoneNumber Insignificant Character Handling is applied in the
2367    Insignificant Character Handling step.
2368
2369    The LDAP definition for the telephoneNumberMatch matching rule is:
2370
2371       ( 2.5.13.20 NAME 'telephoneNumberMatch'
2372          SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
2373
2374    The telephoneNumberMatch rule is an equality matching rule.
2375
2376 4.2.30.  telephoneNumberSubstringsMatch
2377
2378    The telephoneNumberSubstringsMatch rule compares an assertion value
2379    of the Substring Assertion syntax to an attribute value of a syntax
2380    (e.g the Telephone Number syntax) whose corresponding ASN.1 type is a
2381    PrintableString representing a telephone number.
2382
2383    The rule evaluates to TRUE if and only if the prepared substrings of
2384    the assertion value match disjoint portions of the prepared attribute
2385    value character string in the order of the substrings in the
2386    assertion value, and an <initial> substring, if present, matches the
2387    beginning of the prepared attribute value character string, and a
2388    <final> substring, if present, matches the end of the prepared
2389    attribute value character string.  A prepared substring matches a
2390    portion of the prepared attribute value character string if
2391    corresponding characters have the same code point.
2392
2393    In preparing the attribute value and assertion value substrings for
2394    comparison, characters are case folded in the Map preparation step,
2395    and only telephoneNumber Insignificant Character Handling is applied
2396    in the Insignificant Character Handling step.
2397
2398    The LDAP definition for the telephoneNumberSubstringsMatch matching
2399    rule is:
2400
2401       ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
2402          SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
2403
2404    The telephoneNumberSubstringsMatch rule is a substrings matching
2405    rule.
2406
2407
2408
2409
2410 Legg                    Expires 23 December 2005               [Page 43]
2411 \f
2412 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2413
2414
2415 4.2.31.  uniqueMemberMatch
2416
2417    The uniqueMemberMatch rule compares an assertion value of the Name
2418    And Optional UID syntax to an attribute value of a syntax (e.g the
2419    Name And Optional UID syntax) whose corresponding ASN.1 type is
2420    NameAndOptionalUID.
2421
2422    The rule evaluates to TRUE if and only if the <distinguishedName>
2423    components of the assertion value and attribute value match according
2424    to the distinguishedNameMatch rule and either, the <BitString>
2425    component is absent from both the attribute value and assertion
2426    value, or the <BitString> component is present in both the attribute
2427    value and the assertion value and the <BitString> component of the
2428    assertion value matches the <BitString> component of the attribute
2429    value according to the bitStringMatch rule.
2430
2431    Note that this matching rule has been altered from its description in
2432    X.520 [X.520] in order to make the matching rule commutative.  Server
2433    implementors should consider using the original X.520 semantics
2434    (where the matching was less exact) for approximate matching of
2435    attributes with uniqueMemberMatch as the equality matching rule.
2436
2437    The LDAP definition for the uniqueMemberMatch matching rule is:
2438
2439       ( 2.5.13.23 NAME 'uniqueMemberMatch'
2440          SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
2441
2442    The uniqueMemberMatch rule is an equality matching rule.
2443
2444 4.2.32.  wordMatch
2445
2446    The wordMatch rule compares an assertion value of the Directory
2447    String syntax to an attribute value of a syntax (e.g., the Directory
2448    String syntax) whose corresponding ASN.1 type is DirectoryString.
2449
2450    The rule evaluates to TRUE if and only if the assertion value word
2451    matches, according to the semantics of caseIgnoreMatch, any word in
2452    the attribute value.  The precise definition of a word is
2453    implementation specific.
2454
2455    The LDAP definition for the wordMatch rule is:
2456
2457       ( 2.5.13.32 NAME 'wordMatch'
2458          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
2459
2460 5.  Security Considerations
2461
2462    In general, the LDAP-specific encodings for syntaxes defined in this
2463
2464
2465
2466 Legg                    Expires 23 December 2005               [Page 44]
2467 \f
2468 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2469
2470
2471    document do not define canonical encodings.  That is, a
2472    transformation from an LDAP-specific encoding into some other
2473    encoding (e.g., BER) and back into the LDAP-specific encoding will
2474    not necessarily reproduce exactly the original octets of the
2475    LDAP-specific encoding.  Therefore an LDAP-specific encoding should
2476    not be used where a canonical encoding is required.
2477
2478    Furthermore, the LDAP-specific encodings do not necessarily enable an
2479    alternative encoding of values of the Directory String and DN
2480    syntaxes to be reconstructed, e.g., a transformation from a
2481    Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific
2482    encoding and back to a DER encoding may not reproduce the original
2483    DER encoding.  Therefore LDAP-specific encodings should not be used
2484    where reversibility to DER is needed, e.g., for the verification of
2485    digital signatures.  Instead, DER or a DER-reversible encoding should
2486    be used.
2487
2488    When interpreting security-sensitive fields, and in particular fields
2489    used to grant or deny access, implementations MUST ensure that any
2490    matching rule comparisons are done on the underlying abstract value,
2491    regardless of the particular encoding used.
2492
2493 6.  Acknowledgements
2494
2495    This document is primarily a revision of RFC 2252 by M. Wahl, A.
2496    Coulbeck, T. Howes, and S. Kille.  RFC 2252 was a product of the IETF
2497    ASID Working Group.
2498
2499    This document is based upon input of the IETF LDAPBIS working group.
2500    The author would like to thank Kathy Dally for editing the early
2501    drafts of this revision, and Jim Sermersheim and Kurt Zeilenga for
2502    their significant contributions to this revision.
2503
2504 7.  IANA Considerations
2505
2506    The Internet Assigned Numbers Authority (IANA) is requested to update
2507    the LDAP descriptors registry [BCP64] as indicated by the following
2508    templates:
2509
2510       Subject: Request for LDAP Descriptor Registration Update
2511       Descriptor (short name): see comment
2512       Object Identifier: see comment
2513       Person & email address to contact for further information:
2514         Steven Legg <steven.legg@eb2bcom.com>
2515       Usage: see comment
2516       Specification: RFC XXXX
2517       Author/Change Controller: IESG
2518       Comments:
2519
2520
2521
2522 Legg                    Expires 23 December 2005               [Page 45]
2523 \f
2524 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2525
2526
2527       The following descriptors (short names) should be updated to refer
2528       to RFC XXXX.
2529
2530       NAME                              Type  OID
2531       ------------------------------------------------------------------
2532       bitStringMatch                       M  2.5.13.16
2533       booleanMatch                         M  2.5.13.13
2534       caseExactIA5Match                    M  1.3.6.1.4.1.1466.109.114.1
2535       caseExactMatch                       M  2.5.13.5
2536       caseExactOrderingMatch               M  2.5.13.6
2537       caseExactSubstringsMatch             M  2.5.13.7
2538       caseIgnoreIA5Match                   M  1.3.6.1.4.1.1466.109.114.2
2539       caseIgnoreListMatch                  M  2.5.13.11
2540       caseIgnoreListSubstringsMatch        M  2.5.13.12
2541       caseIgnoreMatch                      M  2.5.13.2
2542       caseIgnoreOrderingMatch              M  2.5.13.3
2543       caseIgnoreSubstringsMatch            M  2.5.13.4
2544       directoryStringFirstComponentMatch   M  2.5.13.31
2545       distinguishedNameMatch               M  2.5.13.1
2546       generalizedTimeMatch                 M  2.5.13.27
2547       generalizedTimeOrderingMatch         M  2.5.13.28
2548       integerFirstComponentMatch           M  2.5.13.29
2549       integerMatch                         M  2.5.13.14
2550       integerOrderingMatch                 M  2.5.13.15
2551       keywordMatch                         M  2.5.13.33
2552       numericStringMatch                   M  2.5.13.8
2553       numericStringOrderingMatch           M  2.5.13.9
2554       numericStringSubstringsMatch         M  2.5.13.10
2555       objectIdentifierFirstComponentMatch  M  2.5.13.30
2556       octetStringMatch                     M  2.5.13.17
2557       octetStringOrderingMatch             M  2.5.13.18
2558       telephoneNumberMatch                 M  2.5.13.20
2559       telephoneNumberSubstringsMatch       M  2.5.13.21
2560       uniqueMemberMatch                    M  2.5.13.23
2561       wordMatch                            M  2.5.13.32
2562
2563       The descriptor for the object identifier 2.5.13.0 was incorrectly
2564       registered as objectIdentifiersMatch (extraneous `s') in BCP 64.
2565       It should be changed to the following with a reference to
2566       RFC XXXX.
2567
2568       NAME                              Type  OID
2569       ------------------------------------------------------------------
2570       objectIdentifierMatch                M  2.5.13.0
2571
2572
2573       Subject: Request for LDAP Descriptor Registration
2574       Descriptor (short name): caseIgnoreIA5SubstringsMatch
2575
2576
2577
2578 Legg                    Expires 23 December 2005               [Page 46]
2579 \f
2580 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2581
2582
2583       Object Identifier: 1.3.6.1.4.1.1466.109.114.3
2584       Person & email address to contact for further information:
2585         Steven Legg <steven.legg@eb2bcom.com>
2586       Usage: other (M)
2587       Specification: RFC XXXX
2588       Author/Change Controller: IESG
2589
2590 Appendix A. Summary of Syntax Object Identifiers
2591
2592    The following list summarizes the object identifiers assigned to the
2593    syntaxes defined in this document.
2594
2595       Syntax                           OBJECT IDENTIFIER
2596       ==============================================================
2597       Attribute Type Description       1.3.6.1.4.1.1466.115.121.1.3
2598       Bit String                       1.3.6.1.4.1.1466.115.121.1.6
2599       Boolean                          1.3.6.1.4.1.1466.115.121.1.7
2600       Country String                   1.3.6.1.4.1.1466.115.121.1.11
2601       Delivery Method                  1.3.6.1.4.1.1466.115.121.1.14
2602       Directory String                 1.3.6.1.4.1.1466.115.121.1.15
2603       DIT Content Rule Description     1.3.6.1.4.1.1466.115.121.1.16
2604       DIT Structure Rule Description   1.3.6.1.4.1.1466.115.121.1.17
2605       DN                               1.3.6.1.4.1.1466.115.121.1.12
2606       Enhanced Guide                   1.3.6.1.4.1.1466.115.121.1.21
2607       Facsimile Telephone Number       1.3.6.1.4.1.1466.115.121.1.22
2608       Fax                              1.3.6.1.4.1.1466.115.121.1.23
2609       Generalized Time                 1.3.6.1.4.1.1466.115.121.1.24
2610       Guide                            1.3.6.1.4.1.1466.115.121.1.25
2611       IA5 String                       1.3.6.1.4.1.1466.115.121.1.26
2612       Integer                          1.3.6.1.4.1.1466.115.121.1.27
2613       JPEG                             1.3.6.1.4.1.1466.115.121.1.28
2614       LDAP Syntax Description          1.3.6.1.4.1.1466.115.121.1.54
2615       Matching Rule Description        1.3.6.1.4.1.1466.115.121.1.30
2616       Matching Rule Use Description    1.3.6.1.4.1.1466.115.121.1.31
2617       Name And Optional UID            1.3.6.1.4.1.1466.115.121.1.34
2618       Name Form Description            1.3.6.1.4.1.1466.115.121.1.35
2619       Numeric String                   1.3.6.1.4.1.1466.115.121.1.36
2620       Object Class Description         1.3.6.1.4.1.1466.115.121.1.37
2621       Octet String                     1.3.6.1.4.1.1466.115.121.1.40
2622       OID                              1.3.6.1.4.1.1466.115.121.1.38
2623       Other Mailbox                    1.3.6.1.4.1.1466.115.121.1.39
2624       Postal Address                   1.3.6.1.4.1.1466.115.121.1.41
2625       Printable String                 1.3.6.1.4.1.1466.115.121.1.44
2626       Substring Assertion              1.3.6.1.4.1.1466.115.121.1.58
2627       Telephone Number                 1.3.6.1.4.1.1466.115.121.1.50
2628       Teletex Terminal Identifier      1.3.6.1.4.1.1466.115.121.1.51
2629       Telex Number                     1.3.6.1.4.1.1466.115.121.1.52
2630       UTC Time                         1.3.6.1.4.1.1466.115.121.1.53
2631
2632
2633
2634 Legg                    Expires 23 December 2005               [Page 47]
2635 \f
2636 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2637
2638
2639 Appendix B. Changes from RFC 2252
2640
2641    This annex lists the significant differences between this
2642    specification and RFC 2252.
2643
2644    This annex is provided for informational purposes only.  It is not a
2645    normative part of this specification.
2646
2647    1.  The IESG Note has been removed.
2648
2649    2.  The major part of Sections 4, 5 and 7 has been moved to [MODELS]
2650        and revised.  Changes to the parts of these sections moved to
2651        [MODELS] are detailed in [MODELS].
2652
2653    3.  BNF descriptions of syntax formats have been replaced by ABNF
2654        [ABNF] specifications.
2655
2656    4.  The ambiguous statement in RFC 2252, Section 4.3 regarding the
2657        use of a backslash quoting mechanism to escape separator symbols
2658        has been removed.  The escaping mechanism is now explicitly
2659        represented in the ABNF for the syntaxes where this provision
2660        applies.
2661
2662    5.  The description of each of the LDAP syntaxes has been expanded so
2663        that they are less dependent on knowledge of X.500 for
2664        interpretation.
2665
2666    6.  The relationship of LDAP syntaxes to corresponding ASN.1 type
2667        definitions has been made explicit.
2668
2669    7.  The set of characters allowed in a <PrintableString> (formerly
2670        <printablestring>) has been corrected to align with the
2671        PrintableString ASN.1 type in [ASN.1].  Specifically, the double
2672        quote character has been removed and the single quote character
2673        and equals sign have been added.
2674
2675    8.  Values of the Directory String, Printable String and Telephone
2676        Number syntaxes are now required to have at least one character.
2677
2678    9.  The <DITContentRuleDescription>, <NameFormDescription> and
2679        <DITStructureRuleDescription> rules have been moved to [MODELS].
2680
2681    10. The corresponding ASN.1 type for the Other Mailbox syntax has
2682        been incorporated from RFC 1274.
2683
2684    11. A corresponding ASN.1 type for the LDAP Syntax Description syntax
2685        has been invented.
2686
2687
2688
2689
2690 Legg                    Expires 23 December 2005               [Page 48]
2691 \f
2692 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2693
2694
2695    12. The Binary syntax has been removed because it was not adequately
2696        specified, implementations with different incompatible
2697        interpretations exist, and it was confused with the ;binary
2698        transfer encoding.
2699
2700    13. All discussion of transfer options, including the ";binary"
2701        option, has been removed.  All imperatives regarding binary
2702        transfer of values have been removed.
2703
2704    14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex
2705        Terminal Identifier and Telex Number syntaxes from RFC 2256 have
2706        been incorporated.
2707
2708    15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has
2709        been extended to accommodate empty "and" and "or" expressions.
2710
2711    16. An encoding for the <ttx-value> rule in the Teletex Terminal
2712        Identifier syntax has been defined.
2713
2714    17. The PKI-related syntaxes (Certificate, Certificate List and
2715        Certificate Pair) have been removed.  They are reintroduced in
2716        [LDAP-PKI] (as is the Supported Algorithm syntax from RFC 2256).
2717
2718    18. The MHS OR Address syntax has been removed since its
2719        specification (in RFC 2156) is not at draft standard maturity.
2720
2721    19. The DL Submit Permission syntax has been removed as it depends on
2722        the MHS OR Address syntax.
2723
2724    20. The Presentation Address syntax has been removed since its
2725        specification (in RFC 1278) is not at draft standard maturity.
2726
2727    21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE
2728        Type, LDAP Schema Description, Master And Shadow Access Points,
2729        Modify Rights, Protocol Information, Subtree Specification,
2730        Supplier Information, Supplier Or Consumer and Supplier And
2731        Consumer syntaxes have been removed.  These syntaxes are
2732        referenced in RFC 2252, but not defined.
2733
2734    22. The LDAP Schema Definition syntax (defined in RFC 2927) and the
2735        Mail Preference syntax have been removed on the grounds that they
2736        are out of scope for the core specification.
2737
2738    23. The description of each of the matching rules has been expanded
2739        so that they are less dependent on knowledge of X.500 for
2740        interpretation.
2741
2742    24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has
2743
2744
2745
2746 Legg                    Expires 23 December 2005               [Page 49]
2747 \f
2748 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2749
2750
2751        been added.
2752
2753    25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and
2754        caseIgnoreSubstringsMatch matching rules have been added to the
2755        list of matching rules for which the provisions for handling
2756        leading, trailing and multiple adjoining whitespace characters
2757        apply (now through string preparation).  This is consistent with
2758        the definitions of these matching rules in X.500.  The
2759        caseIgnoreIA5SubstringsMatch rule has also been added to the
2760        list.
2761
2762    26. The specification of the octetStringMatch matching rule from
2763        RFC 2256 has been added to this document.
2764
2765    27. The presentationAddressMatch matching rule has been removed as it
2766        depends on an assertion syntax (Presentation Address) that is not
2767        at draft standard maturity.
2768
2769    28. The protocolInformationMatch matching rule has been removed as it
2770        depends on an undefined assertion syntax (Protocol Information).
2771
2772    29. The definitive reference for ASN.1 has been changed from X.208 to
2773        X.680 since X.680 is the version of ASN.1 referred to by X.500.
2774
2775    30. The specification of the caseIgnoreListSubstringsMatch matching
2776        rule from RFC 2798 & X.520 has been added.
2777
2778    31. String preparation algorithms have been applied to the character
2779        string matching rules.
2780
2781    32. The specifications of the booleanMatch, caseExactMatch,
2782        caseExactOrderingMatch, caseExactSubstringsMatch,
2783        directoryStringFirstComponentMatch, integerOrderingMatch,
2784        keywordMatch, numericStringOrderingMatch,
2785        octetStringOrderingMatch and wordMatch matching rules from
2786        RFC 3698 & X.520 have been added.
2787
2788 Normative References
2789
2790    [KEYWORD]  Bradner, S., "Key words for use in RFCs to Indicate
2791               Requirement Levels", BCP 14, RFC 2119, March 1997.
2792
2793    [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
2794               10646", RFC 3629, November 2003.
2795
2796    [BCP64]    Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
2797               Considerations for the Lightweight Directory Access
2798               Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
2799
2800
2801
2802 Legg                    Expires 23 December 2005               [Page 50]
2803 \f
2804 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2805
2806
2807    [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
2808               Specifications: ABNF", draft-crocker-abnf-rfc2234bis-
2809               xx.txt, a work in progress, March 2005.
2810
2811    [ROADMAP]  Zeilenga, K., "Lightweight Directory Access Protocol
2812               (LDAP): Technical Specification Road Map", draft-ietf-
2813               ldapbis-roadmap-xx.txt, a work in progress, February 2005.
2814
2815    [MODELS]   Zeilenga, K., "LDAP: Directory Information Models", draft-
2816               ietf-ldapbis-models-xx.txt, a work in progress, February
2817               2005.
2818
2819    [PROT]     Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-
2820               protocol-xx.txt, a work in progress, May 2005.
2821
2822    [LDAPDN]   Zeilenga, K., "LDAP: String Representation of
2823               Distinguished Names", draft-ietf-ldapbis-dn-xx.txt, a work
2824               in progress, February 2005.
2825
2826    [PREP]     Zeilenga, K., "LDAP: Internationalized String
2827               Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
2828               progress, February 2005.
2829
2830    [E.123]    Notation for national and international telephone numbers,
2831               ITU-T Recommendation E.123, 1988.
2832
2833    [FAX]      Standardization of Group 3 facsimile apparatus for
2834               document transmission - Terminal Equipment and Protocols
2835               for Telematic Services, ITU-T Recommendation T.4, 1993
2836
2837    [T.50]     International Reference Alphabet (IRA) (Formerly
2838               International Alphabet No. 5 or IA5) Information
2839               Technology - 7-Bit Coded Character Set for Information
2840               Interchange, ITU-T Recommendation T.50, 1992
2841
2842    [X.420]    ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997,
2843               Information Technology - Message Handling Systems (MHS):
2844               Interpersonal messaging system
2845
2846    [X.501]    ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
2847               Information Technology - Open Systems Interconnection -
2848               The Directory: Models
2849
2850    [X.520]    ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
2851               Information Technology - Open Systems Interconnection -
2852               The Directory: Selected attribute types
2853
2854    [ASN.1]    ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002,
2855
2856
2857
2858 Legg                    Expires 23 December 2005               [Page 51]
2859 \f
2860 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2861
2862
2863               Information technology - Abstract Syntax Notation One
2864               (ASN.1): Specification of basic notation
2865
2866    [ISO3166]  ISO 3166, "Codes for the representation of names of
2867               countries".
2868
2869    [ISO8601]  ISO 8601:2004, "Data elements and interchange formats --
2870               Information interchange -- Representation of dates and
2871               times".
2872
2873    [UCS]      Universal Multiple-Octet Coded Character Set (UCS) -
2874               Architecture and Basic Multilingual Plane, ISO/IEC
2875               10646-1:  1993 (with amendments).
2876
2877    [JPEG]     JPEG File Interchange Format (Version 1.02).  Eric
2878               Hamilton, C-Cube Microsystems, Milpitas, CA, September 1,
2879               1992.
2880
2881 Informative References
2882
2883    [RFC2252]  Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
2884               "Lightweight Directory Access Protocol (v3): Attribute
2885               Syntax Definitions", RFC 2252, December 1997.
2886
2887    [RFC2256]  Wahl, M., "A Summary of the X.500(96) User Schema for use
2888               with LDAPv3", RFC 2256, December 1997.
2889
2890    [RFC3377]  Hodges, J. and R. Morgan, "Lightweight Directory Access
2891               Protocol (v3): Technical Specification", RFC 3377,
2892               September 2002.
2893
2894    [RFC3698]  Zeilenga, K., "Lightweight Directory Access Protocol
2895               (LDAP): Additional Matching Rules", RFC 3698, February
2896               2004.
2897
2898    [SCHEMA]   Sciberras, A., "LDAP: Schema for User Applications",
2899               draft-ietf-ldapbis-user-schema-xx.txt, a work in progress,
2900               April 2005.
2901
2902    [LDAP-PKI] Zeilenga, K. D., "Lightweight Directory Access Protocol
2903               (LDAP) schema definitions for X.509 Certificates", draft-
2904               zeilenga-ldap-x509-xx.txt, a work in progress, February
2905               2005.
2906
2907    [X.500]    ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
2908               Information Technology - Open Systems Interconnection -
2909               The Directory: Overview of concepts, models and services
2910
2911
2912
2913
2914 Legg                    Expires 23 December 2005               [Page 52]
2915 \f
2916 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2917
2918
2919    [BER]      ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002,
2920               Information technology - ASN.1 encoding rules:
2921               Specification of Basic Encoding Rules (BER), Canonical
2922               Encoding Rules (CER) and Distinguished Encoding Rules
2923               (DER)
2924
2925 Author's Address
2926
2927    Steven Legg
2928    eB2Bcom
2929    Suite3, Woodhouse Corporate Centre
2930    935 Station Street
2931    Box Hill North, Victoria 3129
2932    AUSTRALIA
2933
2934    Phone: +61 3 9896 7830
2935      Fax: +61 3 9896 7801
2936    EMail: steven.legg@eb2bcom.com
2937
2938 Full Copyright Statement
2939
2940    Copyright (C) The Internet Society (2005).
2941
2942    This document is subject to the rights, licenses and restrictions
2943    contained in BCP 78, and except as set forth therein, the authors
2944    retain all their rights.
2945
2946    This document and the information contained herein are provided on an
2947    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
2948    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
2949    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
2950    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
2951    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
2952    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2953
2954 Intellectual Property
2955
2956    The IETF takes no position regarding the validity or scope of any
2957    Intellectual Property Rights or other rights that might be claimed to
2958    pertain to the implementation or use of the technology described in
2959    this document or the extent to which any license under such rights
2960    might or might not be available; nor does it represent that it has
2961    made any independent effort to identify any such rights.  Information
2962    on the procedures with respect to rights in RFC documents can be
2963    found in BCP 78 and BCP 79.
2964
2965    Copies of IPR disclosures made to the IETF Secretariat and any
2966    assurances of licenses to be made available, or the result of an
2967
2968
2969
2970 Legg                    Expires 23 December 2005               [Page 53]
2971 \f
2972 INTERNET-DRAFT      LDAP: Syntaxes and Matching Rules      June 23, 2005
2973
2974
2975    attempt made to obtain a general license or permission for the use of
2976    such proprietary rights by implementers or users of this
2977    specification can be obtained from the IETF on-line IPR repository at
2978    http://www.ietf.org/ipr.
2979
2980    The IETF invites any interested party to bring to its attention any
2981    copyrights, patents or patent applications, or other proprietary
2982    rights that may cover technology that may be required to implement
2983    this standard.  Please address the information to the IETF at
2984    ietf-ipr@ietf.org.
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026 Legg                    Expires 23 December 2005               [Page 54]
3027 \f