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

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                           T. Howes
   8 Request for Comments: 1778                        University of Michigan
   9 Obsoletes: 1488                                                 S. Kille
  10 Category: Standards Track                               ISODE Consortium
  11                                                                 W. Yeong
  12                                        Performance Systems International
  13                                                               C. Robbins
  14                                                               NeXor Ltd.
  15                                                               March 1995
  16
  17
  18         The String Representation of Standard Attribute Syntaxes
  19
  20 Status of this Memo
  21
  22    This document specifies an Internet standards track protocol for the
  23    Internet community, and requests discussion and suggestions for
  24    improvements.  Please refer to the current edition of the "Internet
  25    Official Protocol Standards" (STD 1) for the standardization state
  26    and status of this protocol.  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 X.500 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 1778                    Syntax Encoding                   March 1995
  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, with the string value being the BER-encoded version of
 104    the value.
 105
 106 2.2.  Case Ignore String
 107
 108    A string of type caseIgnoreStringSyntax is encoded as the string
 109    value itself.
 110
 111
 112
 113
 114 Howes, Kille, Yeong & Robbins                                   [Page 2]
 115 \f
 116 RFC 1778                    Syntax Encoding                   March 1995
 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 for Case
 163                        Ignore String as above.
 164
 165
 166
 167
 168
 169
 170 Howes, Kille, Yeong & Robbins                                   [Page 3]
 171 \f
 172 RFC 1778                    Syntax Encoding                   March 1995
 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 Case
 184                       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 1778                    Syntax Encoding                   March 1995
 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*('$' <ttx-parm>)
 267
 268      <ttx-param> ::= <ttx-key> ':' <ttx-value>
 269
 270      <ttx-key> ::= 'graphic' | 'control' | 'misc' | 'page' | 'private'
 271
 272      <ttx-value> ::= <octetstring>
 273
 274    In the above, the first <printablestring> is the encoding of the
 275    first portion of the teletex terminal identifier to be encoded, and
 276    the subsequent 0 or more <printablestrings> are subsequent portions
 277    of the teletex terminal identifier.
 278
 279
 280
 281
 282 Howes, Kille, Yeong & Robbins                                   [Page 5]
 283 \f
 284 RFC 1778                    Syntax Encoding                   March 1995
 285
 286
 287 2.19.  Facsimile Telephone Number
 288
 289    Values of type FacsimileTelephoneNumber are encoded according to the
 290    following BNF:
 291
 292 <fax-number> ::= <printablestring> [ '$' <faxparameters> ]
 293
 294 <faxparameters> ::= <faxparm> | <faxparm> '$' <faxparameters>
 295
 296 <faxparm> ::= 'twoDimensional' | 'fineResolution' | 'unlimitedLength' |
 297               'b4Length' | 'a3Width' | 'b4Width' | 'uncompressed'
 298
 299    In the above, the first <printablestring> is the actual fax number,
 300    and the <faxparm> tokens represent fax parameters.
 301
 302 2.20.  Presentation Address
 303
 304    Values of type PresentationAddress are encoded to have the
 305    representation described in [6].
 306
 307 2.21.  UTC Time
 308
 309    Values of type uTCTimeSyntax are encoded as if they were Printable
 310    Strings with the strings containing a UTCTime value.
 311
 312 2.22.  Guide (search guide)
 313
 314    Values of type Guide, such as values of the searchGuide attribute,
 315    are encoded according to the following BNF:
 316
 317 <guide-value> ::= [ <object-class> '#' ] <criteria>
 318
 319 <object-class> ::= an encoded value of type objectIdentifierSyntax
 320
 321 <criteria> ::= <criteria-item> | <criteria-set> | '!' <criteria>
 322
 323 <criteria-set> ::= [ '(' ] <criteria> '&' <criteria-set> [ ')' ] |
 324                    [ '(' ] <criteria> '|' <criteria-set> [ ')' ]
 325
 326 <criteria-item> ::= [ '(' ] <attributetype> '$' <match-type> [ ')' ]
 327
 328 <match-type> ::= "EQ" | "SUBSTR" | "GE" | "LE" | "APPROX"
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Howes, Kille, Yeong & Robbins                                   [Page 6]
 339 \f
 340 RFC 1778                    Syntax Encoding                   March 1995
 341
 342
 343 2.23.  Postal Address
 344
 345    Values of type PostalAddress are encoded according to the following
 346    BNF:
 347
 348      <postal-address> ::= <t61string> | <t61string> '$' <postal-address>
 349
 350    In the above, each <t61string> component of a postal address value is
 351    encoded as a value of type t61StringSyntax.
 352
 353 2.24.  User Password
 354
 355    Values of type userPasswordSyntax are encoded as if they were of type
 356    octetStringSyntax.
 357
 358 2.25.  User Certificate
 359
 360    Values of type userCertificate are encoded according to the following
 361    BNF:
 362
 363      <certificate> ::= <version> '#' <serial> '#' <signature-algorithm-id>
 364                      '#' <issuer> '#' <validity> '#' <subject>
 365                      '#' <public-key-info> '#' <encrypted-sign-value>
 366
 367      <version> ::= <integervalue>
 368
 369      <serial> ::= <integervalue>
 370
 371      <signature-algorithm-id> ::= <algorithm-id>
 372
 373      <issuer> ::= an encoded Distinguished Name
 374
 375      <validity> ::= <not-before-time> '#' <not-after-time>
 376
 377      <not-before-time> ::= <utc-time>
 378
 379      <not-after-time> ::= <utc-time>
 380
 381      <algorithm-parameters> ::=  <null> | <integervalue> |
 382                                  '{ASN}' <hex-string>
 383
 384      <subject> ::= an encoded Distinguished Name
 385
 386      <public-key-info> ::= <algorithm-id> '#' <encrypted-sign-value>
 387
 388      <encrypted-sign-value> ::= <hex-string> | <hex-string> '-' <d>
 389
 390      <algorithm-id> ::= <oid> '#' <algorithm-parameters>
 391
 392
 393
 394 Howes, Kille, Yeong & Robbins                                   [Page 7]
 395 \f
 396 RFC 1778                    Syntax Encoding                   March 1995
 397
 398
 399      <utc-time> ::= an encoded UTCTime value
 400
 401      <hex-string> ::= <hex-digit> | <hex-digit> <hex-string>
 402
 403 2.26.  CA Certificate
 404
 405    Values of type cACertificate are encoded as if the values were of
 406    type userCertificate.
 407
 408 2.27.  Authority Revocation List
 409
 410    Values of type authorityRevocationList are encoded according to the
 411    following BNF:
 412
 413 <certificate-list> ::= <signature-algorithm-id> '#' <issuer> '#' <utc-time>
 414                         [ '#' <revoked-certificates> ]
 415                         '#' <signature-algorithm-id>
 416                         '#' <encrypted-sign-value>
 417
 418 <revoked-certificates> ::= 1*( '#' <revoked-certificate> )
 419                         <signature-algorithm-id> '#' <encrypted-sign-value>
 420
 421 <revoked-certificate> ::= <signature-algorithm-id> '#' <issuer> '#'
 422                         <serial> '#' <utc-time>
 423
 424    The syntactic components <signature-algorithm-id>, <issuer>,
 425    <encrypted-sign-value>, <utc-time>, <subject> and <serial> have the
 426    same definitions as in the BNF for the userCertificate attribute
 427    syntax.
 428
 429 2.28.  Certificate Revocation List
 430
 431    Values of type certificateRevocationList are encoded as if the values
 432    were of type authorityRevocationList.
 433
 434 2.29.  Cross Certificate Pair
 435
 436    Values of type crossCertificatePair are encoded according to the
 437    following BNF:
 438
 439      <certificate-pair> ::= <forward> '#' <reverse>
 440                              | <forward>
 441                              | <reverse>
 442
 443      <forward> ::= 'forward:' <certificate>
 444
 445      <reverse> ::= 'reverse:' <certificate>
 446
 447
 448
 449
 450 Howes, Kille, Yeong & Robbins                                   [Page 8]
 451 \f
 452 RFC 1778                    Syntax Encoding                   March 1995
 453
 454
 455    The syntactic component <certificate> has the same definition as in
 456    the BNF for the userCertificate attribute syntax.
 457
 458 2.30.  Delivery Method
 459
 460    Values of type deliveryMethod are encoded according to the following
 461    BNF:
 462
 463      <delivery-value> ::= <pdm> | <pdm> '$' <delivery-value>
 464
 465      <pdm> ::= 'any' | 'mhs' | 'physical' | 'telex' | 'teletex' |
 466                'g3fax' | 'g4fax' | 'ia5' | 'videotex' | 'telephone'
 467
 468 2.31.  Other Mailbox
 469
 470    Values of the type otherMailboxSyntax are encoded according to the
 471    following BNF:
 472
 473      <otherMailbox> ::= <mailbox-type> '$' <mailbox>
 474
 475      <mailbox-type> ::= an encoded Printable String
 476
 477      <mailbox> ::= an encoded IA5 String
 478
 479    In the above, <mailbox-type> represents the type of mail system in
 480    which the mailbox resides, for example "Internet" or "MCIMail"; and
 481    <mailbox> is the actual mailbox in the mail system defined by
 482    <mailbox-type>.
 483
 484 2.32.  Mail Preference
 485
 486    Values of type mailPreferenceOption are encoded according to the
 487    following BNF:
 488
 489      <mail-preference> ::= "NO-LISTS" | "ANY-LIST" | "PROFESSIONAL-LISTS"
 490
 491 2.33.  MHS OR Address
 492
 493    Values of type MHS OR Address are encoded as strings, according to
 494    the format defined in [10].
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504
 505
 506 Howes, Kille, Yeong & Robbins                                   [Page 9]
 507 \f
 508 RFC 1778                    Syntax Encoding                   March 1995
 509
 510
 511 2.34.  Distribution List Submit Permission
 512
 513    Values of type DLSubmitPermission are encoded as strings, according
 514    to the following BNF:
 515
 516      <dlsubmit-perm> ::= <dlgroup_label> ':' <dlgroup-value>
 517                              | <dl-label> ':' <dl-value>
 518
 519      <dlgroup-label> ::= 'group_member'
 520
 521      <dlgroup-value> ::= <name>
 522
 523      <name> ::= an encoded Distinguished Name
 524
 525      <dl-label> ::= 'individual' | 'dl_member' | 'pattern'
 526
 527      <dl-value> ::= <orname>
 528
 529      <orname> ::= <address> '#' <dn>
 530             |  <address>
 531
 532      <address> ::= <add-label> ':' <oraddress>
 533
 534      <dn> ::= <dn-label> ':' <name>
 535
 536      <add-label> = 'X400'
 537
 538      <dn-label> = 'X500'
 539
 540    where <oraddress> is as defined in RFC 1327.
 541
 542 2.35.  Photo
 543
 544    Values of type Photo are encoded as if they were octet strings
 545    containing JPEG images in the JPEG File Interchange Format (JFIF), as
 546    described in [8].
 547
 548 2.36.  Fax
 549
 550    Values of type Fax are encoded as if they were octet strings
 551    containing Group 3 Fax images as defined in [7].
 552
 553
 554
 555
 556
 557
 558
 559
 560
 561
 562 Howes, Kille, Yeong & Robbins                                  [Page 10]
 563 \f
 564 RFC 1778                    Syntax Encoding                   March 1995
 565
 566
 567 3.  Security Considerations
 568
 569    Security issues are not discussed in this memo.
 570
 571 4.  Acknowledgements
 572
 573    Many of the attribute syntax encodings defined in this document are
 574    adapted from those used in the QUIPU X.500 implementation. The
 575    contributions of the authors of the QUIPU implementation in the
 576    specification of the QUIPU syntaxes [4] are gratefully acknowledged.
 577
 578 5.  Bibliography
 579
 580    [1] The Directory: Selected Attribute Syntaxes.  CCITT,
 581        Recommendation X.520.
 582
 583    [2] Information Processing Systems -- Open Systems Interconnection --
 584        The Directory: Selected Attribute Syntaxes.
 585
 586    [3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
 587        RFC 1274, University College London, November 1991.
 588
 589    [4] The ISO Development Environment: User's Manual -- Volume 5:
 590        QUIPU.  Colin Robbins, Stephen E. Kille.
 591
 592    [5] Kille, S., "A String Representation of Distinguished Names", RFC
 593        1779, ISODE Consortium, March 1995.
 594
 595    [6] Kille, S., "A String Representation for Presentation Addresses",
 596        RFC 1278, University College London, November 1991.
 597
 598    [7] Terminal Equipment and Protocols for Telematic Services -
 599        Standardization of Group 3 facsimile apparatus for document
 600        transmission.  CCITT, Recommendation T.4.
 601
 602    [8] JPEG File Interchange Format (Version 1.02).  Eric Hamilton, C-
 603        Cube Microsystems, Milpitas, CA, September 1, 1992.
 604
 605    [9] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
 606        Protocol", RFC 1777, Performance Systems International,
 607        University of Michigan, ISODE Consortium, March 1995.
 608
 609   [10] Alvestrand, H., Kille, S., Miles, R., Rose, M., and S.  Thompson,
 610        "Mapping between X.400 and RFC-822 Message Bodies", RFC 1495,
 611        SINTEF DELAB, ISODE Consortium, Soft*Switch, Inc., Dover Beach
 612        Consulting, Inc., Soft*Switch, Inc., August 1993.
 613
 614
 615
 616
 617
 618 Howes, Kille, Yeong & Robbins                                  [Page 11]
 619 \f
 620 RFC 1778                    Syntax Encoding                   March 1995
 621
 622
 623 6.  Authors' Addresses
 624
 625        Tim Howes
 626        University of Michigan
 627        ITD Research Systems
 628        535 W William St.
 629        Ann Arbor, MI 48103-4943
 630        USA
 631
 632        Phone: +1 313 747-4454
 633        EMail: tim@umich.edu
 634
 635
 636        Steve Kille
 637        ISODE Consortium
 638        PO Box 505
 639        London
 640        SW11 1DX
 641        UK
 642
 643        Phone: +44-71-223-4062
 644        EMail: S.Kille@isode.com
 645
 646
 647        Wengyik Yeong
 648        PSI Inc.
 649        510 Huntmar Park Drive
 650        Herndon, VA 22070
 651        USA
 652
 653        Phone: +1 703-450-8001
 654        EMail: yeongw@psilink.com
 655
 656
 657        Colin Robbins
 658        NeXor Ltd
 659        University Park
 660        Nottingham
 661        NG7 2RD
 662        UK
 663
 664
 665
 666
 667
 668
 669
 670
 671
 672
 673
 674 Howes, Kille, Yeong & Robbins                                  [Page 12]
 675 \f