git.sur5r.net Git - openldap/blob - doc/rfc/rfc2252.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                            M. Wahl
   8 Request for Comments: 2252                           Critical Angle Inc.
   9 Category: Standards Track                                    A. Coulbeck
  10                                                               Isode Inc.
  11                                                                 T. Howes
  12                                            Netscape Communications Corp.
  13                                                                 S. Kille
  14                                                            Isode Limited
  15                                                            December 1997
  16
  17
  18               Lightweight Directory Access Protocol (v3):
  19                       Attribute Syntax Definitions
  20
  21 1. Status of this Memo
  22
  23    This document specifies an Internet standards track protocol for the
  24    Internet community, and requests discussion and suggestions for
  25    improvements.  Please refer to the current edition of the "Internet
  26    Official Protocol Standards" (STD 1) for the standardization state
  27    and status of this protocol.  Distribution of this memo is unlimited.
  28
  29 Copyright Notice
  30
  31    Copyright (C) The Internet Society (1997).  All Rights Reserved.
  32
  33 IESG Note
  34
  35    This document describes a directory access protocol that provides
  36    both read and update access.  Update access requires secure
  37    authentication, but this document does not mandate implementation of
  38    any satisfactory authentication mechanisms.
  39
  40    In accordance with RFC 2026, section 4.4.1, this specification is
  41    being approved by IESG as a Proposed Standard despite this
  42    limitation, for the following reasons:
  43
  44    a. to encourage implementation and interoperability testing of
  45       these protocols (with or without update access) before they
  46       are deployed, and
  47
  48    b. to encourage deployment and use of these protocols in read-only
  49       applications.  (e.g. applications where LDAPv3 is used as
  50       a query language for directories which are updated by some
  51       secure mechanism other than LDAP), and
  52
  53
  54
  55
  56
  57
  58 Wahl, et. al.               Standards Track                     [Page 1]
  59 \f
  60 RFC 2252                   LADPv3 Attributes               December 1997
  61
  62
  63    c. to avoid delaying the advancement and deployment of other Internet
  64       standards-track protocols which require the ability to query, but
  65       not update, LDAPv3 directory servers.
  66
  67    Readers are hereby warned that until mandatory authentication
  68    mechanisms are standardized, clients and servers written according to
  69    this specification which make use of update functionality are
  70    UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION
  71    IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
  72
  73    Implementors are hereby discouraged from deploying LDAPv3 clients or
  74    servers which implement the update functionality, until a Proposed
  75    Standard for mandatory authentication in LDAPv3 has been approved and
  76    published as an RFC.
  77
  78 2. Abstract
  79
  80    The Lightweight Directory Access Protocol (LDAP) [1] requires that
  81    the contents of AttributeValue fields in protocol elements be octet
  82    strings.  This document defines a set of syntaxes for LDAPv3, and the
  83    rules by which attribute values of these syntaxes are represented as
  84    octet strings for transmission in the LDAP protocol.  The syntaxes
  85    defined in this document are referenced by this and other documents
  86    that define attribute types.  This document also defines the set of
  87    attribute types which LDAP servers should support.
  88
  89 3. Overview
  90
  91    This document defines the framework for developing schemas for
  92    directories accessible via the Lightweight Directory Access Protocol.
  93
  94    Schema is the collection of attribute type definitions, object class
  95    definitions and other information which a server uses to determine
  96    how to match a filter or attribute value assertion (in a compare
  97    operation) against the attributes of an entry, and whether to permit
  98    add and modify operations.
  99
 100    Section 4 states the general requirements and notations for attribute
 101    types, object classes, syntax and matching rule definitions.
 102
 103    Section 5 lists attributes, section 6 syntaxes and section 7 object
 104    classes.
 105
 106    Additional documents define schemas for representing real-world
 107    objects as directory entries.
 108
 109
 110
 111
 112
 113
 114 Wahl, et. al.               Standards Track                     [Page 2]
 115 \f
 116 RFC 2252                   LADPv3 Attributes               December 1997
 117
 118
 119 4. General Issues
 120
 121    This document describes encodings used in an Internet protocol.
 122
 123    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 124    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 125    document are to be interpreted as described in RFC 2119 [4].
 126
 127    Attribute Type and Object Class definitions are written in a string
 128    representation of the AttributeTypeDescription and
 129    ObjectClassDescription data types defined in X.501(93) [3].
 130    Implementors are strongly advised to first read the description of
 131    how schema is represented in X.500 before reading the rest of this
 132    document.
 133
 134 4.1. Common Encoding Aspects
 135
 136    For the purposes of defining the encoding rules for attribute
 137    syntaxes, the following BNF definitions will be used.  They are based
 138    on the BNF styles of RFC 822 [13].
 139
 140     a     = "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" /
 141             "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" /
 142             "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "A" /
 143             "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" /
 144             "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" /
 145             "T" / "U" / "V" / "W" / "X" / "Y" / "Z"
 146
 147     d               = "0" / "1" / "2" / "3" / "4" /
 148                       "5" / "6" / "7" / "8" / "9"
 149
 150     hex-digit       =  d / "a" / "b" / "c" / "d" / "e" / "f" /
 151                            "A" / "B" / "C" / "D" / "E" / "F"
 152
 153     k               = a / d / "-" / ";"
 154
 155     p               = a / d / """ / "(" / ")" / "+" / "," /
 156                       "-" / "." / "/" / ":" / "?" / " "
 157
 158     letterstring    = 1*a
 159
 160     numericstring   = 1*d
 161
 162     anhstring       = 1*k
 163
 164     keystring       = a [ anhstring ]
 165
 166     printablestring = 1*p
 167
 168
 169
 170 Wahl, et. al.               Standards Track                     [Page 3]
 171 \f
 172 RFC 2252                   LADPv3 Attributes               December 1997
 173
 174
 175     space           = 1*" "
 176
 177     whsp            = [ space ]
 178
 179     utf8            = <any sequence of octets formed from the UTF-8 [9]
 180                        transformation of a character from ISO10646 [10]>
 181
 182     dstring         = 1*utf8
 183
 184     qdstring        = whsp "'" dstring "'" whsp
 185
 186     qdstringlist    = [ qdstring *( qdstring ) ]
 187
 188     qdstrings       = qdstring / ( whsp "(" qdstringlist ")" whsp )
 189
 190    In the following BNF for the string representation of OBJECT
 191    IDENTIFIERs, descr is the syntactic representation of an object
 192    descriptor, which consists of letters and digits, starting with a
 193    letter.  An OBJECT IDENTIFIER in the numericoid format should not
 194    have leading zeroes (e.g. "0.9.3" is permitted but "0.09.3" should
 195    not be generated).
 196
 197    When encoding 'oid' elements in a value, the descr encoding option
 198    SHOULD be used in preference to the numericoid. An object descriptor
 199    is a more readable alias for a number OBJECT IDENTIFIER, and these
 200    (where assigned and known by the implementation) SHOULD be used in
 201    preference to numeric oids to the greatest extent possible.  Examples
 202    of object descriptors in LDAP are attribute type, object class and
 203    matching rule names.
 204
 205      oid             = descr / numericoid
 206
 207      descr           = keystring
 208
 209      numericoid      = numericstring *( "." numericstring )
 210
 211      woid            = whsp oid whsp
 212
 213      ; set of oids of either form
 214      oids            = woid / ( "(" oidlist ")" )
 215
 216      oidlist         = woid *( "$" woid )
 217
 218      ; object descriptors used as schema element names
 219      qdescrs         = qdescr / ( whsp "(" qdescrlist ")" whsp )
 220
 221      qdescrlist      = [ qdescr *( qdescr ) ]
 222
 223
 224
 225
 226 Wahl, et. al.               Standards Track                     [Page 4]
 227 \f
 228 RFC 2252                   LADPv3 Attributes               December 1997
 229
 230
 231      qdescr          = whsp "'" descr "'" whsp
 232
 233 4.2. Attribute Types
 234
 235    The attribute types are described by sample values for the subschema
 236    "attributeTypes" attribute, which is written in the
 237    AttributeTypeDescription syntax.  While lines have been folded for
 238    readability, the values transferred in protocol would not contain
 239    newlines.
 240
 241    The AttributeTypeDescription is encoded according to the following
 242    BNF, and the productions for oid, qdescrs and qdstring are given in
 243    section 4.1.  Implementors should note that future versions of this
 244    document may have expanded this BNF to include additional terms.
 245    Terms which begin with the characters "X-" are reserved for private
 246    experiments, and MUST be followed by a <qdstrings>.
 247
 248       AttributeTypeDescription = "(" whsp
 249             numericoid whsp              ; AttributeType identifier
 250           [ "NAME" qdescrs ]             ; name used in AttributeType
 251           [ "DESC" qdstring ]            ; description
 252           [ "OBSOLETE" whsp ]
 253           [ "SUP" woid ]                 ; derived from this other
 254                                          ; AttributeType
 255           [ "EQUALITY" woid              ; Matching Rule name
 256           [ "ORDERING" woid              ; Matching Rule name
 257           [ "SUBSTR" woid ]              ; Matching Rule name
 258           [ "SYNTAX" whsp noidlen whsp ] ; see section 4.3
 259           [ "SINGLE-VALUE" whsp ]        ; default multi-valued
 260           [ "COLLECTIVE" whsp ]          ; default not collective
 261           [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
 262           [ "USAGE" whsp AttributeUsage ]; default userApplications
 263           whsp ")"
 264
 265       AttributeUsage =
 266           "userApplications"     /
 267           "directoryOperation"   /
 268           "distributedOperation" / ; DSA-shared
 269           "dSAOperation"          ; DSA-specific, value depends on server
 270
 271    Servers are not required to provide the same or any text in the
 272    description part of the subschema values they maintain.  Servers
 273    SHOULD provide at least one of the "SUP" and "SYNTAX" fields for each
 274    AttributeTypeDescription.
 275
 276    Servers MUST implement all the attribute types referenced in sections
 277    5.1, 5.2 and 5.3.
 278
 279
 280
 281
 282 Wahl, et. al.               Standards Track                     [Page 5]
 283 \f
 284 RFC 2252                   LADPv3 Attributes               December 1997
 285
 286
 287    Servers MAY recognize additional names and attributes not listed in
 288    this document, and if they do so, MUST publish the definitions of the
 289    types in the attributeTypes attribute of their subschema entries.
 290
 291    Schema developers MUST NOT create attribute definitions whose names
 292    conflict with attributes defined for use with LDAP in existing
 293    standards-track RFCs.
 294
 295    An AttributeDescription can be used as the value in a NAME part of an
 296    AttributeTypeDescription.  Note that these are case insensitive.
 297
 298    Note that the AttributeTypeDescription does not list the matching
 299    rules which can can be used with that attribute type in an
 300    extensibleMatch search filter.  This is done using the
 301    matchingRuleUse attribute described in section 4.5.
 302
 303    This document refines the schema description of X.501 by requiring
 304    that the syntax field in an AttributeTypeDescription be a string
 305    representation of an OBJECT IDENTIFIER for the LDAP string syntax
 306    definition, and an optional indication of the maximum length of a
 307    value of this attribute (defined in section 4.3.2).
 308
 309 4.3. Syntaxes
 310
 311    This section defines general requirements for LDAP attribute value
 312    syntax encodings. All documents defining attribute syntax encodings
 313    for use with LDAP are expected to conform to these requirements.
 314
 315    The encoding rules defined for a given attribute syntax must produce
 316    octet strings.  To the greatest extent possible, encoded octet
 317    strings should be usable in their native encoded form for display
 318    purposes. In particular, encoding rules for attribute syntaxes
 319    defining non-binary values should produce strings that can be
 320    displayed with little or no translation by clients implementing LDAP.
 321    There are a few cases (e.g. audio) however, when it is not sensible
 322    to produce a printable representation, and clients MUST NOT assume
 323    that an unrecognized syntax is a string representation.
 324
 325    In encodings where an arbitrary string, not a Distinguished Name, is
 326    used as part of a larger production, and other than as part of a
 327    Distinguished Name, a backslash quoting mechanism is used to escape
 328    the following separator symbol character (such as "'", "$" or "#") if
 329    it should occur in that string.  The backslash is followed by a pair
 330    of hexadecimal digits representing the next character.  A backslash
 331    itself in the string which forms part of a larger syntax is always
 332    transmitted as '\5C' or '\5c'. An example is given in section 6.27.
 333
 334
 335
 336
 337
 338 Wahl, et. al.               Standards Track                     [Page 6]
 339 \f
 340 RFC 2252                   LADPv3 Attributes               December 1997
 341
 342
 343    Syntaxes are also defined for matching rules whose assertion value
 344    syntax is different from the attribute value syntax.
 345
 346 4.3.1  Binary Transfer of Values
 347
 348    This encoding format is used if the binary encoding is requested by
 349    the client for an attribute, or if the attribute syntax name is
 350    "1.3.6.1.4.1.1466.115.121.1.5".  The contents of the LDAP
 351    AttributeValue or AssertionValue field is a BER-encoded instance of
 352    the attribute value or a matching rule assertion value ASN.1 data
 353    type as defined for use with X.500. (The first byte inside the OCTET
 354    STRING wrapper is a tag octet.  However, the OCTET STRING is still
 355    encoded in primitive form.)
 356
 357    All servers MUST implement this form for both generating attribute
 358    values in search responses, and parsing attribute values in add,
 359    compare and modify requests, if the attribute type is recognized and
 360    the attribute syntax name is that of Binary.  Clients which request
 361    that all attributes be returned from entries MUST be prepared to
 362    receive values in binary (e.g. userCertificate;binary), and SHOULD
 363    NOT simply display binary or unrecognized values to users.
 364
 365 4.3.2. Syntax Object Identifiers
 366
 367    Syntaxes for use with LDAP are named by OBJECT IDENTIFIERs, which are
 368    dotted-decimal strings.  These are not intended to be displayed to
 369    users.
 370
 371    noidlen = numericoid [ "{" len "}" ]
 372
 373    len     = numericstring
 374
 375    The following table lists some of the syntaxes that have been defined
 376    for LDAP thus far.  The H-R column suggests whether a value in that
 377    syntax would likely be a human readable string.  Clients and servers
 378    need not implement all the syntaxes listed here, and MAY implement
 379    other syntaxes.
 380
 381    Other documents may define additional syntaxes.  However, the
 382    definition of additional arbitrary syntaxes is strongly deprecated
 383    since it will hinder interoperability: today's client and server
 384    implementations generally do not have the ability to dynamically
 385    recognize new syntaxes.  In most cases attributes will be defined
 386    with the syntax for directory strings.
 387
 388
 389
 390
 391
 392
 393
 394 Wahl, et. al.               Standards Track                     [Page 7]
 395 \f
 396 RFC 2252                   LADPv3 Attributes               December 1997
 397
 398
 399    Value being represented        H-R OBJECT IDENTIFIER
 400    =================================================================
 401    ACI Item                        N  1.3.6.1.4.1.1466.115.121.1.1
 402    Access Point                    Y  1.3.6.1.4.1.1466.115.121.1.2
 403    Attribute Type Description      Y  1.3.6.1.4.1.1466.115.121.1.3
 404    Audio                           N  1.3.6.1.4.1.1466.115.121.1.4
 405    Binary                          N  1.3.6.1.4.1.1466.115.121.1.5
 406    Bit String                      Y  1.3.6.1.4.1.1466.115.121.1.6
 407    Boolean                         Y  1.3.6.1.4.1.1466.115.121.1.7
 408    Certificate                     N  1.3.6.1.4.1.1466.115.121.1.8
 409    Certificate List                N  1.3.6.1.4.1.1466.115.121.1.9
 410    Certificate Pair                N  1.3.6.1.4.1.1466.115.121.1.10
 411    Country String                  Y  1.3.6.1.4.1.1466.115.121.1.11
 412    DN                              Y  1.3.6.1.4.1.1466.115.121.1.12
 413    Data Quality Syntax             Y  1.3.6.1.4.1.1466.115.121.1.13
 414    Delivery Method                 Y  1.3.6.1.4.1.1466.115.121.1.14
 415    Directory String                Y  1.3.6.1.4.1.1466.115.121.1.15
 416    DIT Content Rule Description    Y  1.3.6.1.4.1.1466.115.121.1.16
 417    DIT Structure Rule Description  Y  1.3.6.1.4.1.1466.115.121.1.17
 418    DL Submit Permission            Y  1.3.6.1.4.1.1466.115.121.1.18
 419    DSA Quality Syntax              Y  1.3.6.1.4.1.1466.115.121.1.19
 420    DSE Type                        Y  1.3.6.1.4.1.1466.115.121.1.20
 421    Enhanced Guide                  Y  1.3.6.1.4.1.1466.115.121.1.21
 422    Facsimile Telephone Number      Y  1.3.6.1.4.1.1466.115.121.1.22
 423    Fax                             N  1.3.6.1.4.1.1466.115.121.1.23
 424    Generalized Time                Y  1.3.6.1.4.1.1466.115.121.1.24
 425    Guide                           Y  1.3.6.1.4.1.1466.115.121.1.25
 426    IA5 String                      Y  1.3.6.1.4.1.1466.115.121.1.26
 427    INTEGER                         Y  1.3.6.1.4.1.1466.115.121.1.27
 428    JPEG                            N  1.3.6.1.4.1.1466.115.121.1.28
 429    LDAP Syntax Description         Y  1.3.6.1.4.1.1466.115.121.1.54
 430    LDAP Schema Definition          Y  1.3.6.1.4.1.1466.115.121.1.56
 431    LDAP Schema Description         Y  1.3.6.1.4.1.1466.115.121.1.57
 432    Master And Shadow Access Points Y  1.3.6.1.4.1.1466.115.121.1.29
 433    Matching Rule Description       Y  1.3.6.1.4.1.1466.115.121.1.30
 434    Matching Rule Use Description   Y  1.3.6.1.4.1.1466.115.121.1.31
 435    Mail Preference                 Y  1.3.6.1.4.1.1466.115.121.1.32
 436    MHS OR Address                  Y  1.3.6.1.4.1.1466.115.121.1.33
 437    Modify Rights                   Y  1.3.6.1.4.1.1466.115.121.1.55
 438    Name And Optional UID           Y  1.3.6.1.4.1.1466.115.121.1.34
 439    Name Form Description           Y  1.3.6.1.4.1.1466.115.121.1.35
 440    Numeric String                  Y  1.3.6.1.4.1.1466.115.121.1.36
 441    Object Class Description        Y  1.3.6.1.4.1.1466.115.121.1.37
 442    Octet String                    Y  1.3.6.1.4.1.1466.115.121.1.40
 443    OID                             Y  1.3.6.1.4.1.1466.115.121.1.38
 444    Other Mailbox                   Y  1.3.6.1.4.1.1466.115.121.1.39
 445    Postal Address                  Y  1.3.6.1.4.1.1466.115.121.1.41
 446    Protocol Information            Y  1.3.6.1.4.1.1466.115.121.1.42
 447
 448
 449
 450 Wahl, et. al.               Standards Track                     [Page 8]
 451 \f
 452 RFC 2252                   LADPv3 Attributes               December 1997
 453
 454
 455    Presentation Address            Y  1.3.6.1.4.1.1466.115.121.1.43
 456    Printable String                Y  1.3.6.1.4.1.1466.115.121.1.44
 457    Substring Assertion             Y  1.3.6.1.4.1.1466.115.121.1.58
 458    Subtree Specification           Y  1.3.6.1.4.1.1466.115.121.1.45
 459    Supplier Information            Y  1.3.6.1.4.1.1466.115.121.1.46
 460    Supplier Or Consumer            Y  1.3.6.1.4.1.1466.115.121.1.47
 461    Supplier And Consumer           Y  1.3.6.1.4.1.1466.115.121.1.48
 462    Supported Algorithm             N  1.3.6.1.4.1.1466.115.121.1.49
 463    Telephone Number                Y  1.3.6.1.4.1.1466.115.121.1.50
 464    Teletex Terminal Identifier     Y  1.3.6.1.4.1.1466.115.121.1.51
 465    Telex Number                    Y  1.3.6.1.4.1.1466.115.121.1.52
 466    UTC Time                        Y  1.3.6.1.4.1.1466.115.121.1.53
 467
 468    A suggested minimum upper bound on the number of characters in value
 469    with a string-based syntax, or the number of bytes in a value for all
 470    other syntaxes, may be indicated by appending this bound count inside
 471    of curly braces following the syntax name's OBJECT IDENTIFIER in an
 472    Attribute Type Description.  This bound is not part of the syntax
 473    name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests that
 474    server implementations should allow a string to be 64 characters
 475    long, although they may allow longer strings.  Note that a single
 476    character of the Directory String syntax may be encoded in more than
 477    one byte since UTF-8 is a variable-length encoding.
 478
 479 4.3.3. Syntax Description
 480
 481    The following BNF may be used to associate a short description with a
 482    syntax OBJECT IDENTIFIER. Implementors should note that future
 483    versions of this document may expand this definition to include
 484    additional terms.  Terms whose identifier begins with "X-" are
 485    reserved for private experiments, and MUST be followed by a
 486    <qdstrings>.
 487
 488       SyntaxDescription = "(" whsp
 489           numericoid whsp
 490           [ "DESC" qdstring ]
 491           whsp ")"
 492
 493 4.4. Object Classes
 494
 495    The format for representation of object classes is defined in X.501
 496    [3]. In general every entry will contain an abstract class ("top" or
 497    "alias"), at least one structural object class, and zero or more
 498    auxiliary object classes.  Whether an object class is abstract,
 499    structural or auxiliary is defined when the object class identifier
 500    is assigned.  An object class definition should not be changed
 501    without having a new identifier assigned to it.
 502
 503
 504
 505
 506 Wahl, et. al.               Standards Track                     [Page 9]
 507 \f
 508 RFC 2252                   LADPv3 Attributes               December 1997
 509
 510
 511    Object class descriptions are written according to the following BNF.
 512    Implementors should note that future versions of this document may
 513    expand this definition to include additional terms.  Terms whose
 514    identifier begins with "X-" are reserved for private experiments, and
 515    MUST be followed by a <qdstrings> encoding.
 516
 517       ObjectClassDescription = "(" whsp
 518           numericoid whsp      ; ObjectClass identifier
 519           [ "NAME" qdescrs ]
 520           [ "DESC" qdstring ]
 521           [ "OBSOLETE" whsp ]
 522           [ "SUP" oids ]       ; Superior ObjectClasses
 523           [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
 524                                ; default structural
 525           [ "MUST" oids ]      ; AttributeTypes
 526           [ "MAY" oids ]       ; AttributeTypes
 527       whsp ")"
 528
 529    These are described as sample values for the subschema
 530    "objectClasses" attribute for a server which implements the LDAP
 531    schema. While lines have been folded for readability, the values
 532    transferred in protocol would not contain newlines.
 533
 534    Servers SHOULD implement all the object classes referenced in section
 535    7, except for extensibleObject, which is optional. Servers MAY
 536    implement additional object classes not listed in this document, and
 537    if they do so, MUST publish the definitions of the classes in the
 538    objectClasses attribute of their subschema entries.
 539
 540    Schema developers MUST NOT create object class definitions whose
 541    names conflict with attributes defined for use with LDAP in existing
 542    standards-track RFCs.
 543
 544 4.5. Matching Rules
 545
 546    Matching rules are used by servers to compare attribute values
 547    against assertion values when performing Search and Compare
 548    operations.  They are also used to identify the value to be added or
 549    deleted when modifying entries, and are used when comparing a
 550    purported distinguished name with the name of an entry.
 551
 552    Most of the attributes given in this document will have an equality
 553    matching rule defined.
 554
 555    Matching rule descriptions are written according to the following
 556    BNF.  Implementors should note that future versions of this document
 557    may have expanded this BNF to include additional terms.  Terms whose
 558    identifier begins with "X-" are reserved for private experiments, and
 559
 560
 561
 562 Wahl, et. al.               Standards Track                    [Page 10]
 563 \f
 564 RFC 2252                   LADPv3 Attributes               December 1997
 565
 566
 567    MUST be followed by a <qdstrings> encoding.
 568
 569       MatchingRuleDescription = "(" whsp
 570           numericoid whsp  ; MatchingRule identifier
 571           [ "NAME" qdescrs ]
 572           [ "DESC" qdstring ]
 573           [ "OBSOLETE" whsp ]
 574           "SYNTAX" numericoid
 575       whsp ")"
 576
 577    Values of the matchingRuleUse list the attributes which are suitable
 578    for use with an extensible matching rule.
 579
 580       MatchingRuleUseDescription = "(" whsp
 581           numericoid whsp  ; MatchingRule identifier
 582           [ "NAME" qdescrs ]
 583           [ "DESC" qdstring ]
 584           [ "OBSOLETE" ]
 585          "APPLIES" oids    ; AttributeType identifiers
 586       whsp ")"
 587
 588    Servers which support matching rules and the extensibleMatch SHOULD
 589    implement all the matching rules in section 8.
 590
 591    Servers MAY implement additional matching rules not listed in this
 592    document, and if they do so, MUST publish the definitions of the
 593    matching rules in the matchingRules attribute of their subschema
 594    entries. If the server supports the extensibleMatch, then the server
 595    MUST publish the relationship between the matching rules and
 596    attributes in the matchingRuleUse attribute.
 597
 598    For example, a server which implements a privately-defined matching
 599    rule for performing sound-alike matches on Directory String-valued
 600    attributes would include the following in the subschema entry
 601    (1.2.3.4.5 is an example, the OID of an actual matching rule would be
 602    different):
 603
 604    matchingRule: ( 1.2.3.4.5 NAME 'soundAlikeMatch'
 605     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
 606
 607    If this matching rule could be used with the attributes 2.5.4.41 and
 608    2.5.4.15, the following would also be present:
 609
 610    matchingRuleUse: ( 1.2.3.4.5 APPLIES (2.5.4.41 $ 2.5.4.15) )
 611
 612
 613
 614
 615
 616
 617
 618 Wahl, et. al.               Standards Track                    [Page 11]
 619 \f
 620 RFC 2252                   LADPv3 Attributes               December 1997
 621
 622
 623    A client could then make use of this matching rule by sending a
 624    search operation in which the filter is of the extensibleMatch
 625    choice, the matchingRule field is "soundAlikeMatch", and the type
 626    field is "2.5.4.41" or "2.5.4.15".
 627
 628 5. Attribute Types
 629
 630    All LDAP server implementations MUST recognize the attribute types
 631    defined in this section.
 632
 633    Servers SHOULD also recognize all the attributes from section 5 of
 634    [12].
 635
 636 5.1. Standard Operational Attributes
 637
 638    Servers MUST maintain values of these attributes in accordance with
 639    the definitions in X.501(93).
 640
 641 5.1.1. createTimestamp
 642
 643    This attribute SHOULD appear in entries which were created using the
 644    Add operation.
 645
 646     ( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch
 647       ORDERING generalizedTimeOrderingMatch
 648       SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
 649       SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
 650
 651 5.1.2. modifyTimestamp
 652
 653    This attribute SHOULD appear in entries which have been modified
 654    using the Modify operation.
 655
 656     ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY generalizedTimeMatch
 657       ORDERING generalizedTimeOrderingMatch
 658       SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
 659       SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
 660
 661 5.1.3. creatorsName
 662
 663    This attribute SHOULD appear in entries which were created using the
 664    Add operation.
 665
 666     ( 2.5.18.3 NAME 'creatorsName' EQUALITY distinguishedNameMatch
 667       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
 668       SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
 669
 670
 671
 672
 673
 674 Wahl, et. al.               Standards Track                    [Page 12]
 675 \f
 676 RFC 2252                   LADPv3 Attributes               December 1997
 677
 678
 679 5.1.4. modifiersName
 680
 681    This attribute SHOULD appear in entries which have been modified
 682    using the Modify operation.
 683
 684     ( 2.5.18.4 NAME 'modifiersName' EQUALITY distinguishedNameMatch
 685       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
 686       SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
 687
 688 5.1.5. subschemaSubentry
 689
 690    The value of this attribute is the name of a subschema entry (or
 691    subentry if the server is based on X.500(93)) in which the server
 692    makes available attributes specifying the schema.
 693
 694     ( 2.5.18.10 NAME 'subschemaSubentry'
 695       EQUALITY distinguishedNameMatch
 696       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION
 697       SINGLE-VALUE USAGE directoryOperation )
 698
 699 5.1.6. attributeTypes
 700
 701    This attribute is typically located in the subschema entry.
 702
 703     ( 2.5.21.5 NAME 'attributeTypes'
 704       EQUALITY objectIdentifierFirstComponentMatch
 705       SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
 706
 707 5.1.7. objectClasses
 708
 709    This attribute is typically located in the subschema entry.
 710
 711     ( 2.5.21.6 NAME 'objectClasses'
 712       EQUALITY objectIdentifierFirstComponentMatch
 713       SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation )
 714
 715 5.1.8. matchingRules
 716
 717    This attribute is typically located in the subschema entry.
 718
 719     ( 2.5.21.4 NAME 'matchingRules'
 720       EQUALITY objectIdentifierFirstComponentMatch
 721       SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation )
 722
 723
 724
 725
 726
 727
 728
 729
 730 Wahl, et. al.               Standards Track                    [Page 13]
 731 \f
 732 RFC 2252                   LADPv3 Attributes               December 1997
 733
 734
 735 5.1.9. matchingRuleUse
 736
 737    This attribute is typically located in the subschema entry.
 738
 739     ( 2.5.21.8 NAME 'matchingRuleUse'
 740       EQUALITY objectIdentifierFirstComponentMatch
 741       SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation )
 742
 743 5.2. LDAP Operational Attributes
 744
 745    These attributes are only present in the root DSE (see [1] and [3]).
 746
 747    Servers MUST recognize these attribute names, but it is not required
 748    that a server provide values for these attributes, when the attribute
 749    corresponds to a feature which the server does not implement.
 750
 751 5.2.1. namingContexts
 752
 753    The values of this attribute correspond to naming contexts which this
 754    server masters or shadows.  If the server does not master any
 755    information (e.g. it is an LDAP gateway to a public X.500 directory)
 756    this attribute will be absent.  If the server believes it contains
 757    the entire directory, the attribute will have a single value, and
 758    that value will be the empty string (indicating the null DN of the
 759    root). This attribute will allow a client to choose suitable base
 760    objects for searching when it has contacted a server.
 761
 762     ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
 763      SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation )
 764
 765 5.2.2. altServer
 766
 767    The values of this attribute are URLs of other servers which may be
 768    contacted when this server becomes unavailable.  If the server does
 769    not know of any other servers which could be used this attribute will
 770    be absent. Clients may cache this information in case their preferred
 771    LDAP server later becomes unavailable.
 772
 773     ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
 774      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation )
 775
 776 5.2.3. supportedExtension
 777
 778    The values of this attribute are OBJECT IDENTIFIERs identifying the
 779    supported extended operations which the server supports.
 780
 781    If the server does not support any extensions this attribute will be
 782    absent.
 783
 784
 785
 786 Wahl, et. al.               Standards Track                    [Page 14]
 787 \f
 788 RFC 2252                   LADPv3 Attributes               December 1997
 789
 790
 791     ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
 792      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
 793
 794 5.2.4. supportedControl
 795
 796    The values of this attribute are the OBJECT IDENTIFIERs identifying
 797    controls which the server supports.  If the server does not support
 798    any controls, this attribute will be absent.
 799
 800     ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
 801      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation )
 802
 803 5.2.5. supportedSASLMechanisms
 804
 805    The values of this attribute are the names of supported SASL
 806    mechanisms which the server supports.  If the server does not support
 807    any mechanisms this attribute will be absent.
 808
 809     ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
 810      SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation )
 811
 812 5.2.6. supportedLDAPVersion
 813
 814    The values of this attribute are the versions of the LDAP protocol
 815    which the server implements.
 816
 817     ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
 818      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation )
 819
 820 5.3. LDAP Subschema Attribute
 821
 822    This attribute is typically located in the subschema entry.
 823
 824 5.3.1. ldapSyntaxes
 825
 826    Servers MAY use this attribute to list the syntaxes which are
 827    implemented.  Each value corresponds to one syntax.
 828
 829     ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
 830       EQUALITY objectIdentifierFirstComponentMatch
 831       SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation )
 832
 833 5.4. X.500 Subschema attributes
 834
 835    These attributes are located in the subschema entry.  All servers
 836    SHOULD recognize their name, although typically only X.500 servers
 837    will implement their functionality.
 838
 839
 840
 841
 842 Wahl, et. al.               Standards Track                    [Page 15]
 843 \f
 844 RFC 2252                   LADPv3 Attributes               December 1997
 845
 846
 847 5.4.1. dITStructureRules
 848
 849  ( 2.5.21.1 NAME 'dITStructureRules' EQUALITY integerFirstComponentMatch
 850    SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation )
 851
 852 5.4.2. nameForms
 853
 854     ( 2.5.21.7 NAME 'nameForms'
 855       EQUALITY objectIdentifierFirstComponentMatch
 856       SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation )
 857
 858 5.4.3. ditContentRules
 859
 860     ( 2.5.21.2 NAME 'dITContentRules'
 861       EQUALITY objectIdentifierFirstComponentMatch
 862       SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation )
 863
 864 6. Syntaxes
 865
 866    Servers SHOULD recognize all the syntaxes described in this section.
 867
 868 6.1. Attribute Type Description
 869
 870    ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
 871
 872    Values in this syntax are encoded according to the BNF given at the
 873    start of section 4.2. For example,
 874
 875         ( 2.5.4.0 NAME 'objectClass'
 876           SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
 877
 878 6.2. Binary
 879
 880    ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' )
 881
 882    Values in this syntax are encoded as described in section 4.3.1.
 883
 884 6.3. Bit String
 885
 886    ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
 887
 888    Values in this syntax are encoded according to the following BNF:
 889
 890       bitstring = "'" *binary-digit "'B"
 891
 892       binary-digit = "0" / "1"
 893
 894
 895
 896
 897
 898 Wahl, et. al.               Standards Track                    [Page 16]
 899 \f
 900 RFC 2252                   LADPv3 Attributes               December 1997
 901
 902
 903    Example:
 904
 905         '0101111101'B
 906
 907 6.4. Boolean
 908
 909    ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
 910
 911    Values in this syntax are encoded according to the following BNF:
 912
 913       boolean = "TRUE" / "FALSE"
 914
 915    Boolean values have an encoding of "TRUE" if they are logically true,
 916    and have an encoding of "FALSE" otherwise.
 917
 918 6.5. Certificate
 919
 920    ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
 921
 922    Because of the changes from X.509(1988) and X.509(1993) and
 923    additional changes to the ASN.1 definition to support certificate
 924    extensions, no string representation is defined, and values in this
 925    syntax MUST only be transferred using the binary encoding, by
 926    requesting or returning the attributes with descriptions
 927    "userCertificate;binary" or "caCertificate;binary".  The BNF notation
 928    in RFC 1778 for "User Certificate" is not recommended to be used.
 929
 930 6.6. Certificate List
 931
 932    ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' )
 933
 934    Because of the incompatibility of the X.509(1988) and X.509(1993)
 935    definitions of revocation lists, values in this syntax MUST only be
 936    transferred using a binary encoding, by requesting or returning the
 937    attributes with descriptions "certificateRevocationList;binary" or
 938    "authorityRevocationList;binary".  The BNF notation in RFC 1778 for
 939    "Authority Revocation List" is not recommended to be used.
 940
 941 6.7. Certificate Pair
 942
 943    ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' )
 944
 945    Because the Certificate is being carried in binary, values in this
 946    syntax MUST only be transferred using a binary encoding, by
 947    requesting or returning the attribute description
 948    "crossCertificatePair;binary". The BNF notation in RFC 1778 for
 949    "Certificate Pair" is not recommended to be used.
 950
 951
 952
 953
 954 Wahl, et. al.               Standards Track                    [Page 17]
 955 \f
 956 RFC 2252                   LADPv3 Attributes               December 1997
 957
 958
 959 6.8. Country String
 960
 961    ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
 962
 963    A value in this syntax is encoded the same as a value of Directory
 964    String syntax.  Note that this syntax is limited to values of exactly
 965    two printable string characters, as listed in ISO 3166 [14].
 966
 967       CountryString  = p p
 968
 969    Example:
 970       US
 971
 972 6.9. DN
 973
 974    ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
 975
 976    Values in the Distinguished Name syntax are encoded to have the
 977    representation defined in [5].  Note that this representation is not
 978    reversible to an ASN.1 encoding used in X.500 for Distinguished
 979    Names, as the CHOICE of any DirectoryString element in an RDN is no
 980    longer known.
 981
 982    Examples (from [5]):
 983       CN=Steve Kille,O=Isode Limited,C=GB
 984       OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
 985       CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
 986       CN=Before\0DAfter,O=Test,C=GB
 987       1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
 988       SN=Lu\C4\8Di\C4\87
 989
 990 6.10. Directory String
 991
 992    ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
 993
 994    A string in this syntax is encoded in the UTF-8 form of ISO 10646 (a
 995    superset of Unicode).  Servers and clients MUST be prepared to
 996    receive encodings of arbitrary Unicode characters, including
 997    characters not presently assigned to any character set.
 998
 999    For characters in the PrintableString form, the value is encoded as
1000    the string value itself.
1001
1002    If it is of the TeletexString form, then the characters are
1003    transliterated to their equivalents in UniversalString, and encoded
1004    in UTF-8 [9].
1005
1006
1007
1008
1009
1010 Wahl, et. al.               Standards Track                    [Page 18]
1011 \f
1012 RFC 2252                   LADPv3 Attributes               December 1997
1013
1014
1015    If it is of the UniversalString or BMPString forms [10], UTF-8 is
1016    used to encode them.
1017
1018    Note: the form of DirectoryString is not indicated in protocol unless
1019    the attribute value is carried in binary.  Servers which convert to
1020    DAP MUST choose an appropriate form.  Servers MUST NOT reject values
1021    merely because they contain legal Unicode characters outside of the
1022    range of printable ASCII.
1023
1024    Example:
1025
1026       This is a string of DirectoryString containing #!%#@
1027
1028 6.11. DIT Content Rule Description
1029
1030
1031    ues in this syntax are encoded according to the following BNF.
1032    lementors should note that future versions of this document
1033     have expanded this BNF to include additional terms.
1034
1035     0
1036
1037       DITContentRuleDescription = "("
1038           numericoid   ; Structural ObjectClass identifier
1039           [ "NAME" qdescrs ]
1040           [ "DESC" qdstring ]
1041           [ "OBSOLETE" ]
1042           [ "AUX" oids ]    ; Auxiliary ObjectClasses
1043           [ "MUST" oids ]   ; AttributeType identifiers
1044           [ "MAY" oids ]    ; AttributeType identifiers
1045           [ "NOT" oids ]    ; AttributeType identifiers
1046          ")"
1047
1048     0 2. Facsimile Telephone Number
1049
1050     3
1051
1052    ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' )
1053
1054    Values in this syntax are encoded according to the following BNF:
1055
1056       fax-number    = printablestring [ "$" faxparameters ]
1057
1058       faxparameters = faxparm / ( faxparm "$" faxparameters )
1059
1060       faxparm = "twoDimensional" / "fineResolution" /
1061                 "unlimitedLength" /
1062                 "b4Length" / "a3Width" / "b4Width" / "uncompressed"
1063
1064
1065
1066 Wahl, et. al.               Standards Track                    [Page 19]
1067 \f
1068 RFC 2252                   LADPv3 Attributes               December 1997
1069
1070
1071    In the above, the first printablestring is the telephone number,
1072    based on E.123 [15], and the faxparm tokens represent fax parameters.
1073
1074 6.13. Fax
1075
1076    ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
1077
1078    Values in this syntax are encoded as if they were octet strings
1079    containing Group 3 Fax images as defined in [7].
1080
1081 6.14. Generalized Time
1082
1083    ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
1084
1085    Values in this syntax are encoded as printable strings, represented
1086    as specified in X.208.  Note that the time zone must be specified.
1087    It is strongly recommended that GMT time be used.  For example,
1088
1089                 199412161032Z
1090
1091 6.15. IA5 String
1092
1093    ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
1094
1095    The encoding of a value in this syntax is the string value itself.
1096
1097 6.16. INTEGER
1098
1099    ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
1100
1101    Values in this syntax are encoded as the decimal representation of
1102    their values, with each decimal digit represented by the its
1103    character equivalent. So the number 1321 is represented by the
1104    character string "1321".
1105
1106 6.17. JPEG
1107
1108    ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
1109
1110    Values in this syntax are encoded as strings containing JPEG images
1111    in the JPEG File Interchange Format (JFIF), as described in [8].
1112
1113 6.18. Matching Rule Description
1114
1115    ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
1116
1117    Values of type matchingRules are encoded as strings according to the
1118    BNF given in section 4.5.
1119
1120
1121
1122 Wahl, et. al.               Standards Track                    [Page 20]
1123 \f
1124 RFC 2252                   LADPv3 Attributes               December 1997
1125
1126
1127 6.19. Matching Rule Use Description
1128
1129    ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description'
1130    )
1131
1132    Values of type matchingRuleUse are encoded as strings according to
1133    the BNF given in section 4.5.
1134
1135 6.20. MHS OR Address
1136
1137    ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' )
1138
1139    Values in this syntax are encoded as strings, according to the format
1140    defined in [11].
1141
1142 6.21. Name And Optional UID
1143
1144    ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
1145
1146    Values in this syntax are encoded according to the following BNF:
1147
1148       NameAndOptionalUID = DistinguishedName [ "#" bitstring ]
1149
1150    Although the '#' character may occur in a string representation of a
1151    distinguished name, no additional special quoting is done.  This
1152    syntax has been added subsequent to RFC 1778.
1153
1154    Example:
1155
1156       1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
1157
1158 6.22. Name Form Description
1159
1160    ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
1161
1162    Values in this syntax are encoded according to the following BNF.
1163    Implementors should note that future versions of this document may
1164    have expanded this BNF to include additional terms.
1165
1166       NameFormDescription = "(" whsp
1167           numericoid whsp  ; NameForm identifier
1168           [ "NAME" qdescrs ]
1169           [ "DESC" qdstring ]
1170           [ "OBSOLETE" whsp ]
1171           "OC" woid         ; Structural ObjectClass
1172           "MUST" oids       ; AttributeTypes
1173           [ "MAY" oids ]    ; AttributeTypes
1174       whsp ")"
1175
1176
1177
1178 Wahl, et. al.               Standards Track                    [Page 21]
1179 \f
1180 RFC 2252                   LADPv3 Attributes               December 1997
1181
1182
1183 6.23. Numeric String
1184
1185    ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
1186
1187    The encoding of a string in this syntax is the string value itself.
1188    Example:
1189
1190       1997
1191
1192 6.24. Object Class Description
1193
1194    ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
1195
1196    Values in this syntax are encoded according to the BNF in section
1197    4.4.
1198
1199 6.25. OID
1200
1201    ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
1202
1203    Values in the Object Identifier syntax are encoded according to
1204    the BNF in section 4.1 for "oid".
1205
1206    Example:
1207
1208       1.2.3.4
1209       cn
1210
1211 6.26. Other Mailbox
1212
1213    ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
1214
1215    Values in this syntax are encoded according to the following BNF:
1216
1217       otherMailbox = mailbox-type "$" mailbox
1218
1219       mailbox-type = printablestring
1220
1221       mailbox = <an encoded IA5 String>
1222
1223    In the above, mailbox-type represents the type of mail system in
1224    which the mailbox resides, for example "MCIMail"; and mailbox is the
1225    actual mailbox in the mail system defined by mailbox-type.
1226
1227 6.27. Postal Address
1228
1229    ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
1230
1231
1232
1233
1234 Wahl, et. al.               Standards Track                    [Page 22]
1235 \f
1236 RFC 2252                   LADPv3 Attributes               December 1997
1237
1238
1239    Values in this syntax are encoded according to the following BNF:
1240
1241       postal-address = dstring *( "$" dstring )
1242
1243    In the above, each dstring component of a postal address value is
1244    encoded as a value of type Directory String syntax.  Backslashes and
1245    dollar characters, if they occur in the component, are quoted as
1246    described in section 4.3.   Many servers limit the postal address to
1247    six lines of up to thirty characters.
1248
1249    Example:
1250
1251       1234 Main St.$Anytown, CA 12345$USA
1252       \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
1253
1254 6.28. Presentation Address
1255
1256    ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' )
1257
1258    Values in this syntax are encoded with the representation described
1259    in RFC 1278 [6].
1260
1261 6.29. Printable String
1262
1263    ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
1264
1265    The encoding of a value in this syntax is the string value itself.
1266    PrintableString is limited to the characters in production p of
1267    section 4.1.
1268
1269    Example:
1270
1271       This is a PrintableString
1272
1273 6.30. Telephone Number
1274
1275    ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
1276
1277    Values in this syntax are encoded as if they were Printable String
1278    types.  Telephone numbers are recommended in X.520 to be in
1279    international form, as described in E.123 [15].
1280
1281    Example:
1282
1283       +1 512 305 0280
1284
1285
1286
1287
1288
1289
1290 Wahl, et. al.               Standards Track                    [Page 23]
1291 \f
1292 RFC 2252                   LADPv3 Attributes               December 1997
1293
1294
1295 6.31. UTC Time
1296
1297    ( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
1298
1299    Values in this syntax are encoded as if they were printable strings
1300    with the strings containing a UTCTime value.  This is historical; new
1301    attribute definitions SHOULD use GeneralizedTime instead.
1302
1303 6.32. LDAP Syntax Description
1304
1305    ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
1306
1307    Values in this syntax are encoded according to the BNF in section
1308    4.3.3.
1309
1310 6.33. DIT Structure Rule Description
1311
1312    ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description'
1313    )
1314
1315    Values with this syntax are encoded according to the following BNF:
1316
1317       DITStructureRuleDescription = "(" whsp
1318           ruleidentifier whsp            ; DITStructureRule identifier
1319           [ "NAME" qdescrs ]
1320           [ "DESC" qdstring ]
1321           [ "OBSOLETE" whsp ]
1322           "FORM" woid whsp               ; NameForm
1323           [ "SUP" ruleidentifiers whsp ] ; superior DITStructureRules
1324       ")"
1325
1326       ruleidentifier = integer
1327
1328       ruleidentifiers = ruleidentifier |
1329           "(" whsp ruleidentifierlist whsp ")"
1330
1331       ruleidentifierlist = [ ruleidentifier *( ruleidentifier ) ]
1332
1333 7. Object Classes
1334
1335    Servers SHOULD recognize all the names of standard classes from
1336    section 7 of [12].
1337
1338 7.1. Extensible Object Class
1339
1340    The extensibleObject object class, if present in an entry, permits
1341    that entry to optionally hold any attribute.  The MAY attribute list
1342    of this class is implicitly the set of all attributes.
1343
1344
1345
1346 Wahl, et. al.               Standards Track                    [Page 24]
1347 \f
1348 RFC 2252                   LADPv3 Attributes               December 1997
1349
1350
1351     ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
1352       SUP top AUXILIARY )
1353
1354    The mandatory attributes of the other object classes of this entry
1355    are still required to be present.
1356
1357    Note that not all servers will implement this object class, and those
1358    which do not will reject requests to add entries which contain this
1359    object class, or modify an entry to add this object class.
1360
1361 7.2. subschema
1362
1363    This object class is used in the subschema entry.
1364
1365     ( 2.5.20.1 NAME 'subschema' AUXILIARY
1366       MAY ( dITStructureRules $ nameForms $ ditContentRules $
1367       objectClasses $ attributeTypes $ matchingRules $
1368       matchingRuleUse ) )
1369
1370    The ldapSyntaxes operational attribute may also be present in
1371    subschema entries.
1372
1373 8. Matching Rules
1374
1375    Servers which implement the extensibleMatch filter SHOULD allow all
1376    the matching rules listed in this section to be used in the
1377    extensibleMatch.  In general these servers SHOULD allow matching
1378    rules to be used with all attribute types known to the server, when
1379    the assertion syntax of the matching rule is the same as the value
1380    syntax of the attribute.
1381
1382    Servers MAY implement additional matching rules.
1383
1384 8.1. Matching Rules used in Equality Filters
1385
1386    Servers SHOULD be capable of performing the following matching rules.
1387
1388    For all these rules, the assertion syntax is the same as the value
1389    syntax.
1390
1391     ( 2.5.13.0 NAME 'objectIdentifierMatch'
1392       SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
1393
1394    If the client supplies a filter using an objectIdentifierMatch whose
1395    matchValue oid is in the "descr" form, and the oid is not recognized
1396    by the server, then the filter is Undefined.
1397
1398     ( 2.5.13.1 NAME 'distinguishedNameMatch'
1399
1400
1401
1402 Wahl, et. al.               Standards Track                    [Page 25]
1403 \f
1404 RFC 2252                   LADPv3 Attributes               December 1997
1405
1406
1407       SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
1408
1409     ( 2.5.13.2 NAME 'caseIgnoreMatch'
1410       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1411
1412     ( 2.5.13.8 NAME 'numericStringMatch'
1413       SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
1414
1415     ( 2.5.13.11 NAME 'caseIgnoreListMatch'
1416       SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
1417
1418     ( 2.5.13.14 NAME 'integerMatch'
1419       SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
1420
1421     ( 2.5.13.16 NAME 'bitStringMatch'
1422       SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
1423
1424     ( 2.5.13.20 NAME 'telephoneNumberMatch'
1425       SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
1426
1427     ( 2.5.13.22 NAME 'presentationAddressMatch'
1428       SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 )
1429
1430     ( 2.5.13.23 NAME 'uniqueMemberMatch'
1431       SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
1432
1433     ( 2.5.13.24 NAME 'protocolInformationMatch'
1434       SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 )
1435
1436     ( 2.5.13.27 NAME 'generalizedTimeMatch'
1437       SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1438
1439     ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match'
1440       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1441
1442     ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match'
1443       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
1444
1445    When performing the caseIgnoreMatch, caseIgnoreListMatch,
1446    telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
1447    multiple adjoining whitespace characters are treated the same as an
1448    individual space, and leading and trailing whitespace is ignored.
1449
1450    Clients MUST NOT assume that servers are capable of transliteration
1451    of Unicode values.
1452
1453
1454
1455
1456
1457
1458 Wahl, et. al.               Standards Track                    [Page 26]
1459 \f
1460 RFC 2252                   LADPv3 Attributes               December 1997
1461
1462
1463 8.2. Matching Rules used in Inequality Filters
1464
1465    Servers SHOULD be capable of performing the following matching rules,
1466    which are used in greaterOrEqual and lessOrEqual filters.
1467
1468     ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch'
1469       SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
1470
1471     ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch'
1472       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
1473
1474    The sort ordering for a caseIgnoreOrderingMatch is implementation-
1475    dependent.
1476
1477 8.3. Syntax and Matching Rules used in Substring Filters
1478
1479    The Substring Assertion syntax is used only as the syntax of
1480    assertion values in the extensible match.  It is not used as the
1481    syntax of attributes, or in the substring filter.
1482
1483    ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
1484
1485    The Substring Assertion is encoded according to the following BNF:
1486
1487       substring = [initial] any [final]
1488       initial = value
1489       any = "*" *(value "*")
1490       final = value
1491
1492    The <value> production is UTF-8 encoded string.  Should the backslash
1493    or asterix characters be present in a production of <value>, they are
1494    quoted as described in section 4.3.
1495
1496    Servers SHOULD be capable of performing the following matching rules,
1497    which are used in substring filters.
1498
1499    ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch'
1500     SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1501
1502    ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch'
1503     SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1504
1505    ( 2.5.13.10 NAME 'numericStringSubstringsMatch'
1506     SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
1507
1508
1509
1510
1511
1512
1513
1514 Wahl, et. al.               Standards Track                    [Page 27]
1515 \f
1516 RFC 2252                   LADPv3 Attributes               December 1997
1517
1518
1519 8.4. Matching Rules for Subschema Attributes
1520
1521    Servers which allow subschema entries to be modified by clients MUST
1522    support the following matching rules, as they are the equality
1523    matching rules for several of the subschema attributes.
1524
1525    ( 2.5.13.29 NAME 'integerFirstComponentMatch'
1526      SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
1527
1528    ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch'
1529      SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
1530
1531    Implementors should note that the assertion syntax of these matching
1532    rules, an INTEGER or OID, is different from the value syntax of
1533    attributes for which this is the equality matching rule.
1534
1535    If the client supplies an extensible filter using an
1536    objectIdentifierFirstComponentMatch whose matchValue is in the
1537    "descr" form, and the OID is not recognized by the server, then the
1538    filter is Undefined.
1539
1540 9. Security Considerations
1541
1542 9.1. Disclosure
1543
1544    Attributes of directory entries are used to provide descriptive
1545    information about the real-world objects they represent, which can be
1546    people, organizations or devices.  Most countries have privacy laws
1547    regarding the publication of information about people.
1548
1549 9.2. Use of Attribute Values in Security Applications
1550
1551    The transformations of an AttributeValue value from its X.501 form to
1552    an LDAP string representation are not always reversible back to the
1553    same BER or DER form.  An example of a situation which requires the
1554    DER form of a distinguished name is the verification of an X.509
1555    certificate.
1556
1557    For example, a distinguished name consisting of one RDN with one AVA,
1558    in which the type is commonName and the value is of the TeletexString
1559    choice with the letters 'Sam' would be represented in LDAP as the
1560    string CN=Sam.  Another distinguished name in which the value is
1561    still 'Sam' but of the PrintableString choice would have the same
1562    representation CN=Sam.
1563
1564    Applications which require the reconstruction of the DER form of the
1565    value SHOULD NOT use the string representation of attribute syntaxes
1566    when converting a value to LDAP format.  Instead it SHOULD use the
1567
1568
1569
1570 Wahl, et. al.               Standards Track                    [Page 28]
1571 \f
1572 RFC 2252                   LADPv3 Attributes               December 1997
1573
1574
1575    Binary syntax.
1576
1577 10. Acknowledgements
1578
1579    This document is based substantially on RFC 1778, written by Tim
1580    Howes, Steve Kille, Wengyik Yeong and Colin Robbins.
1581
1582    Many of the attribute syntax encodings defined in this and related
1583    documents are adapted from those used in the QUIPU and the IC R3
1584    X.500 implementations. The contributions of the authors of both these
1585    implementations in the specification of syntaxes are gratefully
1586    acknowledged.
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626 Wahl, et. al.               Standards Track                    [Page 29]
1627 \f
1628 RFC 2252                   LADPv3 Attributes               December 1997
1629
1630
1631 11. Authors' Addresses
1632
1633    Mark Wahl
1634    Critical Angle Inc.
1635    4815 West Braker Lane #502-385
1636    Austin, TX 78759
1637    USA
1638
1639    Phone:  +1 512 372-3160
1640    EMail:  M.Wahl@critical-angle.com
1641
1642    Andy Coulbeck
1643    Isode Inc.
1644    9390 Research Blvd Suite 305
1645    Austin, TX 78759
1646    USA
1647
1648    Phone:  +1 512 231-8993
1649    EMail:  A.Coulbeck@isode.com
1650
1651    Tim Howes
1652    Netscape Communications Corp.
1653    501 E. Middlefield Rd, MS MV068
1654    Mountain View, CA 94043
1655    USA
1656
1657    Phone:  +1 650 937-3419
1658    EMail:   howes@netscape.com
1659
1660    Steve Kille
1661    Isode Limited
1662    The Dome, The Square
1663    Richmond
1664    TW9 1DT
1665    UK
1666
1667    Phone:  +44-181-332-9091
1668    EMail:  S.Kille@isode.com
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682 Wahl, et. al.               Standards Track                    [Page 30]
1683 \f
1684 RFC 2252                   LADPv3 Attributes               December 1997
1685
1686
1687 12. Bibliography
1688
1689    [1] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
1690        Protocol (v3)", RFC 2251, December 1997.
1691
1692    [2] The Directory: Selected Attribute Types.  ITU-T Recommendation
1693        X.520, 1993.
1694
1695    [3] The Directory: Models. ITU-T Recommendation X.501, 1993.
1696
1697    [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
1698        Levels", RFC 2119, March 1997.
1699
1700    [5] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access
1701        Protocol (v3): UTF-8 String Representation of
1702        Distinguished Names", RFC 2253, December 1997.
1703
1704    [6] Kille, S., "A String Representation for Presentation Addresses",
1705        RFC 1278, November 1991.
1706
1707    [7] Terminal Equipment and Protocols for Telematic Services -
1708        Standardization of Group 3 facsimile apparatus for document
1709        transmission.  CCITT, Recommendation T.4.
1710
1711    [8] JPEG File Interchange Format (Version 1.02).  Eric Hamilton,
1712        C-Cube Microsystems, Milpitas, CA, September 1, 1992.
1713
1714    [9] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
1715        10646", RFC 2044, October 1996.
1716
1717    [10] Universal Multiple-Octet Coded Character Set (UCS) -
1718         Architecture and Basic Multilingual Plane, ISO/IEC 10646-1 :
1719         1993 (With amendments).
1720
1721    [11] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
1722         and RFC 822", RFC 1327, May 1992.
1723
1724    [12] Wahl, M., "A Summary of the X.500(96) User Schema for use
1725         with LDAPv3", RFC 2256, December 1997.
1726
1727    [13] Crocker, D., "Standard of the Format of ARPA-Internet Text
1728         Messages", STD 11, RFC 822, August 1982.
1729
1730    [14] ISO 3166, "Codes for the representation of names of countries".
1731
1732    [15] ITU-T Rec. E.123, Notation for national and international
1733         telephone numbers, 1988.
1734
1735
1736
1737
1738 Wahl, et. al.               Standards Track                    [Page 31]
1739 \f
1740 RFC 2252                   LADPv3 Attributes               December 1997
1741
1742
1743 13.  Full Copyright Statement
1744
1745    Copyright (C) The Internet Society (1997).  All Rights Reserved.
1746
1747    This document and translations of it may be copied and furnished to
1748    others, and derivative works that comment on or otherwise explain it
1749    or assist in its implementation may be prepared, copied, published
1750    and distributed, in whole or in part, without restriction of any
1751    kind, provided that the above copyright notice and this paragraph are
1752    included on all such copies and derivative works.  However, this
1753    document itself may not be modified in any way, such as by removing
1754    the copyright notice or references to the Internet Society or other
1755    Internet organizations, except as needed for the purpose of
1756    developing Internet standards in which case the procedures for
1757    copyrights defined in the Internet Standards process must be
1758    followed, or as required to translate it into languages other than
1759    English.
1760
1761    The limited permissions granted above are perpetual and will not be
1762    revoked by the Internet Society or its successors or assigns.
1763
1764    This document and the information contained herein is provided on an
1765    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1766    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1767    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1768    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1769    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794 Wahl, et. al.               Standards Track                    [Page 32]
1795 \f