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