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

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                         T. Howes
   8 Request for Comments: 1488                      University of Michigan
   9                                                               S. Kille
  10                                                       ISODE Consortium
  11                                                               W. Yeong
  12                                      Performance Systems International
  13                                                             C. Robbins
  14                                                             NeXor Ltd.
  15                                                              July 1993
  16
  17
  18      The X.500 String Representation of Standard Attribute Syntaxes
  19
  20 Status of this Memo
  21
  22    This RFC specifies an IAB standards track protocol for the Internet
  23    community, and requests discussion and suggestions for improvements.
  24    Please refer to the current edition of the "IAB Official Protocol
  25    Standards" for the standardization state and status of this protocol.
  26    Distribution of this memo is unlimited.
  27
  28 Abstract
  29
  30    The Lightweight Directory Access Protocol (LDAP) [9] requires that
  31    the contents of AttributeValue fields in protocol elements be octet
  32    strings.  This document defines the requirements that must be
  33    satisfied by encoding rules used to render Directory attribute
  34    syntaxes into a form suitable for use in the LDAP, then goes on to
  35    define the encoding rules for the standard set of attribute syntaxes
  36    defined in [1,2] and [3].
  37
  38 1.  Attribute Syntax Encoding Requirements
  39
  40    This section defines general requirements for lightweight directory
  41    protocol attribute syntax encodings. All documents defining attribute
  42    syntax encodings for use by the lightweight directory protocols are
  43    expected to conform to these requirements.
  44
  45    The encoding rules defined for a given attribute syntax must produce
  46    octet strings.  To the greatest extent possible, encoded octet
  47    strings should be usable in their native encoded form for display
  48    purposes. In particular, encoding rules for attribute syntaxes
  49    defining non-binary values should produce strings that can be
  50    displayed with little or no translation by clients implementing the
  51    lightweight directory protocols.
  52
  53
  54
  55
  56
  57
  58 Howes, Kille, Yeong & Robbins                                   [Page 1]
  59 \f
  60 RFC 1488                 X.500 Syntax Encoding                 July 1993
  61
  62
  63 2.  Standard Attribute Syntax Encodings
  64
  65    For the purposes of defining the encoding rules for the standard
  66    attribute syntaxes, the following auxiliary BNF definitions will be
  67    used:
  68
  69      <a> ::= 'a' | 'b' | 'c' | 'd' | 'e' | 'f' | 'g' | 'h' | 'i' |
  70              'j' | 'k' | 'l' | 'm' | 'n' | 'o' | 'p' | 'q' | 'r' |
  71              's' | 't' | 'u' | 'v' | 'w' | 'x' | 'y' | 'z' | 'A' |
  72              'B' | 'C' | 'D' | 'E' | 'F' | 'G' | 'H' | 'I' | 'J' |
  73              'K' | 'L' | 'M' | 'N' | 'O' | 'P' | 'Q' | 'R' | 'S' |
  74              'T' | 'U' | 'V' | 'W' | 'X' | 'Y' | 'Z'
  75
  76      <d> ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
  77
  78      <hex-digit> ::= <d> | 'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
  79                       'A' | 'B' | 'C' | 'D' | 'E' | 'F'
  80
  81      <k> ::= <a> | <d> | '-'
  82
  83      <p> ::= <a> | <d> | ''' | '(' | ')' | '+' | ',' | '-' | '.' |
  84              '/' | ':' | '?' | ' '
  85
  86      <CRLF> ::= The ASCII newline character with hexadecimal value 0x0A
  87
  88      <letterstring> ::= <a> | <a> <letterstring>
  89
  90      <numericstring> ::= <d> | <d> <numericstring>
  91
  92      <keystring> ::= <a> | <a> <anhstring>
  93
  94      <anhstring> ::= <k> | <k> <anhstring>
  95
  96      <printablestring> ::= <p> | <p> <printablestring>
  97
  98      <space> ::= ' ' | ' ' <space>
  99
 100 2.1.  Undefined
 101
 102    Values of type Undefined are encoded as if they were values of type
 103    Octet String.
 104
 105 2.2.  Case Ignore String
 106
 107    A string of type caseIgnoreStringSyntax is encoded as the string
 108    value itself.
 109
 110
 111
 112
 113
 114 Howes, Kille, Yeong & Robbins                                   [Page 2]
 115 \f
 116 RFC 1488                 X.500 Syntax Encoding                 July 1993
 117
 118
 119 2.3.  Case Exact String
 120
 121    The encoding of a string of type caseExactStringSyntax is the string
 122    value itself.
 123
 124 2.4.  Printable String
 125
 126    The encoding of a string of type printableStringSyntax is the string
 127    value itself.
 128
 129 2.5.  Numeric String
 130
 131    The encoding of a string of type numericStringSyntax is the string
 132    value itself.
 133
 134 2.6.  Octet String
 135
 136    The encoding of a string of type octetStringSyntax is the string
 137    value itself.
 138
 139 2.7.  Case Ignore IA5 String
 140
 141    The encoding of a string of type caseIgnoreIA5String is the string
 142    value itself.
 143
 144 2.8.  IA5 String
 145
 146    The encoding of a string of type iA5StringSyntax is the string value
 147    itself.
 148
 149 2.9.  T61 String
 150
 151    The encoding of a string of type t61StringSyntax is the string value
 152    itself.
 153
 154 2.10.  Case Ignore List
 155
 156    Values of type caseIgnoreListSyntax are encoded according to the
 157    following BNF:
 158
 159      <caseignorelist> ::= <caseignorestring> |
 160                           <caseignorestring> '$' <caseignorelist>
 161
 162      <caseignorestring> ::= a string encoded according to the rules
 163                              for Case Ignore String as above.
 164
 165
 166
 167
 168
 169
 170 Howes, Kille, Yeong & Robbins                                   [Page 3]
 171 \f
 172 RFC 1488                 X.500 Syntax Encoding                 July 1993
 173
 174
 175 2.11.  Case Exact List
 176
 177    Values of type caseExactListSyntax are encoded according to the
 178    following BNF:
 179
 180      <caseexactlist> ::= <caseexactstring> |
 181                           <caseexactstring> '$' <caseexactlist>
 182
 183      <caseexactstring> ::= a string encoded according to the rules for
 184                             Case Exact String as above.
 185
 186 2.12.  Distinguished Name
 187
 188    Values of type distinguishedNameSyntax are encoded to have the
 189    representation defined in [5].
 190
 191 2.13.  Boolean
 192
 193    Values of type booleanSyntax are encoded according to the following
 194    BNF:
 195
 196      <boolean> ::= "TRUE" | "FALSE"
 197
 198    Boolean values have an encoding of "TRUE" if they are logically true,
 199    and have an encoding of "FALSE" otherwise.
 200
 201 2.14.  Integer
 202
 203    Values of type integerSyntax are encoded as the decimal
 204    representation of their values, with each decimal digit represented
 205    by the its character equivalent. So the digit 1 is represented by the
 206    character
 207
 208 2.15.  Object Identifier
 209
 210    Values of type objectIdentifierSyntax are encoded according to the
 211    following BNF:
 212
 213      <oid> ::= <descr> | <descr> '.' <numericoid> | <numericoid>
 214
 215      <descr> ::= <keystring>
 216
 217      <numericoid> ::= <numericstring> | <numericstring> '.' <numericoid>
 218
 219    In the above BNF, <descr> is the syntactic representation of an
 220    object descriptor. When encoding values of type
 221    objectIdentifierSyntax, the first encoding option should be used in
 222    preference to the second, which should be used in preference to the
 223
 224
 225
 226 Howes, Kille, Yeong & Robbins                                   [Page 4]
 227 \f
 228 RFC 1488                 X.500 Syntax Encoding                 July 1993
 229
 230
 231    third wherever possible. That is, in encoding object identifiers,
 232    object descriptors (where assigned and known by the implementation)
 233    should be used in preference to numeric oids to the greatest extent
 234    possible. For example, in encoding the object identifier representing
 235    an organizationName, the descriptor "organizationName" is preferable
 236    to "ds.4.10", which is in turn preferable to the string "2.5.4.10".
 237
 238 2.16.  Telephone Number
 239
 240    Values of type telephoneNumberSyntax are encoded as if they were
 241    Printable String types.
 242
 243 2.17.  Telex Number
 244
 245    Values of type telexNumberSyntax are encoded according to the
 246    following BNF:
 247
 248      <telex-number> ::= <actual-number> '$' <country> '$' <answerback>
 249
 250      <actual-number> ::= <printablestring>
 251
 252      <country> ::= <printablestring>
 253
 254      <answerback> ::= <printablestring>
 255
 256    In the above, <actual-number> is the syntactic representation of the
 257    number portion of the TELEX number being encoded, <country> is the
 258    TELEX country code, and <answerback> is the answerback code of a
 259    TELEX terminal.
 260
 261 2.18.  Teletex Terminal Identifier
 262
 263    Values of type teletexTerminalIdentifier are encoded according to the
 264    following BNF:
 265
 266      <teletex-id> ::= <printablestring> 0*( '$' <printablestring>)
 267
 268    In the above, the first <printablestring> is the encoding of the
 269    first portion of the teletex terminal identifier to be encoded, and
 270    the subsequent 0 or more <printablestrings> are subsequent portions
 271    of the teletex terminal identifier.
 272
 273 2.19.  Facsimile Telephone Number
 274
 275    Values of type FacsimileTelephoneNumber are encoded according to the
 276    following BNF:
 277
 278  <fax-number> ::= <printablestring> [ '$' <faxparameters> ]
 279
 280
 281
 282 Howes, Kille, Yeong & Robbins                                   [Page 5]
 283 \f
 284 RFC 1488                 X.500 Syntax Encoding                 July 1993
 285
 286
 287  <faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
 288
 289  <faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
 290                'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
 291
 292    In the above, the first <printablestring> is the actual fax number,
 293    and the <faxparm> tokens represent fax parameters.
 294
 295 2.20.  Presentation Address
 296
 297    Values of type PresentationAddress are encoded to have the
 298    representation described in [6].
 299
 300 2.21.  UTC Time
 301
 302    Values of type uTCTimeSyntax are encoded as if they were Printable
 303    Strings with the strings containing a UTCTime value.
 304
 305 2.22.  Guide (search guide)
 306
 307    Values of type Guide, such as values of the searchGuide attribute,
 308    are encoded according to the following BNF:
 309
 310      <guide-value> ::= [ <object-class> '#' ] <criteria>
 311
 312      <object-class> ::= an encoded value of type objectIdentifierSyntax
 313
 314      <criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
 315
 316      <criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
 317                         [ '(' ] <criteria> '|' <criteria-set> [ ')' ]
 318
 319      <criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
 320
 321      <match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
 322
 323 2.23.  Postal Address
 324
 325 Values of type PostalAddress are encoded according to the following BNF:
 326
 327      <postal-address> ::= <t61string> | <t61string> '$' <postal-address>
 328
 329    In the above, each <t61string> component of a postal address value is
 330    encoded as a value of type t61StringSyntax.
 331
 332
 333
 334
 335
 336
 337
 338 Howes, Kille, Yeong & Robbins                                   [Page 6]
 339 \f
 340 RFC 1488                 X.500 Syntax Encoding                 July 1993
 341
 342
 343 2.24.  User Password
 344
 345    Values of type userPasswordSyntax are encoded as if they were of type
 346    octetStringSyntax.
 347
 348 2.25.  User Certificate
 349
 350    Values of type userCertificate are encoded according to the following
 351    BNF:
 352
 353  <certificate> ::= <signature> '#' <issuer> '#' <validity> '#' <subject>
 354                    '#' <public-key-info>
 355
 356  <signature> ::= <algorithm-id>
 357
 358  <issuer> ::= an encoded Distinguished Name
 359
 360  <validity> ::= <not-before-time> '#' <not-after-time>
 361
 362  <not-before-time> ::= <utc-time>
 363
 364  <not-after-time> ::= <utc-time>
 365
 366  <algorithm-parameters> ::=  <null> | <integervalue> |
 367                              '{ASN}' <hex-string>
 368
 369  <subject> ::= an encoded Distinguished Name
 370
 371  <public-key-info> ::= <algorithm-id> '#' <encrypted-value>
 372
 373  <encrypted-value> ::= <hex-string> | <hex-string> '-' <d>
 374
 375  <algorithm-id> ::= <oid> '#' <algorithm-parameters>
 376
 377  <utc-time> ::= an encoded UTCTime value
 378
 379  <hex-string> ::= <hex-digit> | <hex-digit> <hex-string>
 380
 381 2.26.  CA Certificate
 382
 383    Values of type cACertificate are encoded as if the values were of
 384    type userCertificate.
 385
 386 2.27.  Authority Revocation List
 387
 388    Values of type authorityRevocationList are encoded according to the
 389    following BNF:
 390
 391
 392
 393
 394 Howes, Kille, Yeong & Robbins                                   [Page 7]
 395 \f
 396 RFC 1488                 X.500 Syntax Encoding                 July 1993
 397
 398
 399      <certificate-list> ::= <signature> '#' <issuer> '#'
 400                             <utc-time> [ '#' <revoked-certificates> ]
 401
 402      <revoked-certificates> ::= <algorithm> '#' <encrypted-value>
 403                                 [ '#' 0*(<revoked-certificate>) '#']
 404
 405      <revoked-certificates> ::= <subject> '#' <algorithm> '#'
 406                                 <serial> '#' <utc-time>
 407
 408    The syntactic components <algorithm>, <issuer>, <encrypted-value>,
 409    <utc-time>, <subject> and <serial> have the same definitions as in
 410    the BNF for the userCertificate attribute syntax.
 411
 412 2.28.  Certificate Revocation List
 413
 414    Values of type certificateRevocationList are encoded as if the values
 415    were of type authorityRevocationList.
 416
 417 2.29.  Cross Certificate Pair
 418
 419    Values of type crossCertificatePair are encoded according to the
 420    following BNF:
 421
 422      <certificate-pair> ::= <certificate> '|' <certificate>
 423
 424    The syntactic component <certificate> has the same definition as in
 425    the BNF for the userCertificate attribute syntax.
 426
 427 2.30.  Delivery Method
 428
 429    Values of type deliveryMethod are encoded according to the following
 430    BNF:
 431
 432      <delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
 433
 434      <pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
 435                'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
 436
 437 2.31.  Other Mailbox
 438
 439    Values of the type otherMailboxSyntax are encoded according to the
 440    following BNF:
 441
 442      <otherMailbox> ::= <mailbox-type> '$' <mailbox>
 443
 444      <mailbox-type> ::= an encoded Printable String
 445
 446      <mailbox> ::= an encoded IA5 String
 447
 448
 449
 450 Howes, Kille, Yeong & Robbins                                   [Page 8]
 451 \f
 452 RFC 1488                 X.500 Syntax Encoding                 July 1993
 453
 454
 455    In the above, <mailbox-type> represents the type of mail system in
 456    which the mailbox resides, for example "Internet" or "MCIMail"; and
 457    <mailbox> is the actual mailbox in the mail system defined by
 458    <mailbox-type>.
 459
 460 2.32.  Mail Preference
 461
 462    Values of type mailPreferenceOption are encoded according to the
 463    following BNF:
 464
 465  <mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
 466
 467 2.33.  MHS OR Address
 468
 469    Values of type MHS OR Address are encoded as strings, according to
 470    the format defined in [10].
 471
 472 2.34.  Photo
 473
 474    Values of type Photo are encoded as if they were octet strings
 475    containing JPEG images in the JPEG File Interchange Format (JFIF), as
 476    described in [8].
 477
 478 2.35.  Fax
 479
 480    Values of type Fax are encoded as if they were octet strings
 481    containing Group 3 Fax images as defined in [7].
 482
 483 3.  Acknowledgements
 484
 485    Many of the attribute syntax encodings defined in this document are
 486    adapted from those used in the QUIPU X.500 implementation. The
 487    contribu- tions of the authors of the QUIPU implementation in the
 488    specification of the QUIPU syntaxes [4] are gratefully acknowledged.
 489
 490 4.  Bibliography
 491
 492    [1] The Directory: Selected Attribute Syntaxes.  CCITT,
 493        Recommendation X.520.
 494
 495    [2] Information Processing Systems -- Open Systems Interconnection --
 496        The Directory: Selected Attribute Syntaxes.
 497
 498    [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
 499        RFC 1274, University College London, November 1991.
 500
 501    [4] The ISO Development Environment: User's Manual -- Volume 5:
 502        QUIPU.  Colin Robbins, Stephen E. Kille.
 503
 504
 505
 506 Howes, Kille, Yeong & Robbins                                   [Page 9]
 507 \f
 508 RFC 1488                 X.500 Syntax Encoding                 July 1993
 509
 510
 511    [5] Kille, S., "A String Representation of Distinguished Names", RFC
 512        1485, July 1993.
 513
 514    [6] Kille, S., "A String Representation for Presentation Addresses",
 515        RFC 1278, University College London, November 1991.
 516
 517    [7] Terminal Equipment and Protocols for Telematic Services -
 518        Standardization of Group 3 facsimile apparatus for document
 519        transmission.  CCITT, Recommendation T.4.
 520
 521    [8] JPEG File Interchange Format (Version 1.02).  Eric Hamilton, C-
 522        Cube Microsystems, Milpitas, CA, September 1, 1992.
 523
 524    [9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
 525        Protocol", RFC 1487, Performance Systems International,
 526        University of Michigan, ISODE Consortium, July 1993.
 527
 528   [10] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC 822",
 529        RFC 1327, University College London, May 1992.
 530
 531 5.  Security Considerations
 532
 533    Security issues are not discussed in this memo.
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Howes, Kille, Yeong & Robbins                                  [Page 10]
 563 \f
 564 RFC 1488                 X.500 Syntax Encoding                 July 1993
 565
 566
 567 6.  Authors' Addresses
 568
 569    Tim Howes
 570    University of Michigan
 571    ITD Research Systems
 572    535 W William St.
 573    Ann Arbor, MI 48103-4943
 574    USA
 575
 576    Phone: +1 313 747-4454
 577    EMail: tim@umich.edu
 578
 579
 580    Steve Kille
 581    ISODE Consortium
 582    PO Box 505
 583    London
 584    SW11 1DX
 585    UK
 586
 587    Phone: +44-71-223-4062
 588    EMail: S.Kille@isode.com
 589
 590
 591    Wengyik Yeong
 592    PSI, Inc.
 593    510 Huntmar Park Drive
 594    Herndon, VA 22070
 595    USA
 596
 597    Phone: +1 703-450-8001
 598    EMail: yeongw@psilink.com
 599
 600
 601    Colin Robbins
 602    NeXor Ltd
 603    University Park
 604    Nottingham
 605    NG7 2RD
 606    UK
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Howes, Kille, Yeong & Robbins                                  [Page 11]
 619 \f