git.sur5r.net Git - openldap/blob - doc/drafts/draft-good-ldap-ldif-xx.txt

   1 LDAP Data Interchange Format (LDIF)                         Gordon Good
   2 INTERNET-DRAFT                                  Netscape Communications
   3 Status: Standards-Track                                 19 October 1999
   4
   5    The LDAP Data Interchange Format (LDIF) - Technical Specification
   6                  Filename: draft-good-ldap-ldif-05.txt
   7
   8 Status of this Memo
   9
  10    This document is an Internet-Draft and is in full conformance
  11    with all provisions of Section 10 of RFC2026.
  12
  13    Internet-Drafts are working documents of the Internet Engineering
  14    Task Force (IETF), its areas, and its working groups. Note that
  15    other groups may also distribute working documents as
  16    Internet-Drafts.
  17
  18    Internet-Drafts are draft documents valid for a maximum of six
  19    months and may be updated, replaced, or obsoleted by other
  20    documents at any time.  It is inappropriate to use Internet-
  21    Drafts as reference material or to cite them other than as
  22    "work in progress."
  23
  24    To view the list Internet-Draft Shadow Directories, see
  25    http://www.ietf.org/shadow.html.
  26
  27    This Internet Draft expires 19 April, 2000.
  28
  29
  30 Abstract
  31
  32    This document describes a file format suitable for describing
  33    directory information or modifications made to directory information.
  34    The file format, known as LDIF, for LDAP Data Interchange Format, is
  35    typically used to import and export directory information between
  36    LDAP-based directory servers, or to describe a set of changes which
  37    are to be applied to a directory.
  38
  39
  40 Background and Intended Usage
  41
  42    There are a number of situations where a common interchange format is
  43    desirable.  For example, one might wish to export a copy of the
  44    contents of a directory server to a file, move that file to a
  45    different machine, and import the contents into a second directory
  46    server.
  47
  48    Additionally, by using a well-defined interchange format, development
  49
  50
  51
  52 Good                        October 18, 1999                    [Page 1]
  53 \f
  54 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
  55
  56
  57    of data import tools from legacy systems is facilitated.  A fairly
  58    simple set of tools written in awk or perl can, for example, convert
  59    a database of personnel information into an LDIF file. This file can
  60    then be imported into a directory server, regardless of the internal
  61    database representation the target directory server uses.
  62
  63    The LDIF format was originally developed and used in the University
  64    of Michigan LDAP implementation.  The first use of LDIF was in
  65    describing directory entries.  Later, the format was expanded to
  66    allow representation of changes to directory entries.
  67
  68    Relationship to the application/directory MIME content-type:
  69
  70    The application/directory MIME content-type [1] is a general
  71    framework and format for conveying directory information, and is
  72    independent of any particular directory service.  The LDIF format is
  73    a simpler format which is perhaps easier to create, and may also be
  74    used, as noted, to describe a set of changes to be applied to a
  75    directory.
  76
  77    The key words "MUST", "MAY", and "SHOULD" used in this document are
  78    to be interpreted as described in [7].
  79
  80
  81 Definition of the LDAP Data Interchange Format
  82
  83
  84    The LDIF format is used to convey directory information, or a
  85    description of a set of changes made to directory entries.  An LDIF
  86    file consists of a series of records separated by line separators.  A
  87    record consists of a sequence of lines describing a directory entry,
  88    or a sequence of lines describing a set of changes to a directory
  89    entry.  An LDIF file specifies a set of directory entries, or a set
  90    of changes to be applied to directory entries, but not both.
  91
  92    There is a one-to-one correlation between LDAP operations that modify
  93    the directory (add, delete, modify, and modrdn), and the types of
  94    changerecords described below ("add", "delete", "modify", and
  95    "modrdn" or "moddn").  This correspondence is intentional, and
  96    permits a straightforward translation from LDIF changerecords to
  97    protocol operations.
  98
  99 Formal Syntax Definition of LDIF
 100
 101    The following definition uses the augmented Backus-Naur Form
 102    specified in RFC 2234 [2].
 103
 104    ldif-file                = ldif-content / ldif-changes
 105
 106
 107
 108 Good                        October 18, 1999                    [Page 2]
 109 \f
 110 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 111
 112
 113    ldif-content             = version-spec 1*(1*SEP ldif-attrval-record)
 114
 115    ldif-changes             = version-spec 1*(1*SEP ldif-change-record)
 116
 117    ldif-attrval-record      = dn-spec SEP 1*attrval-spec
 118
 119    ldif-change-record       = dn-spec SEP *control changerecord
 120
 121    version-spec             = "version:" FILL version-number
 122
 123    version-number           = 1*DIGIT
 124                               ; version-number MUST be "1" for the
 125                               ; LDIF format described in this document.
 126
 127    dn-spec                  = "dn:" (FILL distinguishedName /
 128                                      ":" FILL base64-distinguishedName)
 129
 130    distinguishedName        = SAFE-UTF8-STRING
 131                               ; a distinguished name, as defined in [3]
 132
 133    base64-distinguishedName = BASE64-UTF8-STRING
 134                               ; a distinguishedName which has been base64
 135                               ; encoded (see note 10, below)
 136
 137    rdn                      = SAFE-UTF8-STRING
 138                               ; a relative distinguished name, defined as
 139                               ; <name-component> in [3]
 140
 141    base64-rdn               = BASE64-UTF8-STRING
 142                               ; an rdn which has been base64 encoded (see
 143                               ; note 10, below)
 144
 145    control                  = "control:" FILL ldap-oid        ; controlType
 146                               0*1(1*SPACE ("true" / "false")) ; criticality
 147                               0*1(value-spec)                 ; controlValue
 148                               SEP
 149                               ; (See note 9, below)
 150
 151    ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
 152                               ; An LDAPOID, as defined in [4]
 153
 154    attrval-spec             = AttributeDescription value-spec SEP
 155
 156    value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
 157                                    ":" FILL (BASE64-STRING) /
 158                                    "<" FILL url)
 159                               ; See notes 7 and 8, below
 160
 161
 162
 163
 164 Good                        October 18, 1999                    [Page 3]
 165 \f
 166 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 167
 168
 169    url                      = <a Uniform Resource Locator, as defined in [6]>
 170                                       ; (See Note 6, below)
 171
 172    AttributeDescription     = AttributeType [";" options]
 173                               ; Definition taken from [4]
 174
 175    AttributeType            = ldap-oid / (ALPHA *(attr-type-chars))
 176
 177    options                  = option / (option ";" options)
 178
 179    option                   = 1*opt-char
 180
 181    attr-type-chars          = ALPHA / DIGIT / "-"
 182
 183    opt-char                 = attr-type-chars
 184
 185    changerecord             = "changetype:" FILL
 186                               (change-add / change-delete /
 187                                change-modify / change-moddn)
 188
 189    change-add               = "add"                SEP 1*attrval-spec
 190
 191    change-delete            = "delete"             SEP
 192
 193    change-moddn             = ("modrdn" / "moddn") SEP
 194                                "newrdn:" (    FILL rdn /
 195                                           ":" FILL base64-rdn) SEP
 196                                "deleteoldrdn:" FILL ("0" / "1")  SEP
 197                                0*1("newsuperior:"
 198                                (    FILL distinguishedName /
 199                                 ":" FILL base64-distinguishedName) SEP)
 200
 201    change-modify            = "modify"             SEP *mod-spec
 202
 203    mod-spec                 = ("add:" / "delete:" / "replace:")
 204                               FILL AttributeDescription SEP
 205                               *attrval-spec
 206                               "-" SEP
 207
 208    SPACE                    = %x20
 209                               ; ASCII SP, space
 210
 211    FILL                     = *SPACE
 212
 213    SEP                      = (CR LF / LF)
 214
 215    CR                       = %x0D
 216                               ; ASCII CR, carriage return
 217
 218
 219
 220 Good                        October 18, 1999                    [Page 4]
 221 \f
 222 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 223
 224
 225    LF                       = %x0A
 226                               ; ASCII LF, line feed
 227
 228    ALPHA                    = %x41-5A / %x61-7A
 229                               ; A-Z / a-z
 230
 231    DIGIT                    = %x30-39
 232                               ; 0-9
 233
 234    UTF8-1                   = %x80-BF
 235
 236    UTF8-2                   = %xC0-DF UTF8-1
 237
 238    UTF8-3                   = %xE0-EF 2UTF8-1
 239
 240    UTF8-4                   = %xF0-F7 3UTF8-1
 241
 242    UTF8-5                   = %xF8-FB 4UTF8-1
 243
 244    UTF8-6                   = %xFC-FD 5UTF8-1
 245
 246    SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
 247                               ; any value <= 127 decimal except NUL, LF, and CR
 248
 249    SAFE-INIT-CHAR           = %x01-09 / %x0B-0C / %x0E-1F /
 250                               %x21-39 / %x3B / %x3D-7F
 251                               ; any value <= 127 except NUL, LF, CR,
 252                               ; SPACE, colon (":", ASCII 58 decimal)
 253                               ; and less-than ("<" , ASCII 60 decimal)
 254
 255    SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]
 256
 257    SAFE-UTF8-CHAR           = SAFE-CHAR / UTF8-2 / UTF8-3 /
 258                               UTF8-4 / UTF8-5 / UTF8-6
 259
 260    SAFE-INIT-UTF8-CHAR      = SAFE-INIT-CHAR / UTF8-2 / UTF8-3 /
 261                               UTF8-4 / UTF8-5 / UTF8-6
 262
 263    SAFE-UTF8-STRING         = [SAFE-INIT-UTF8-CHAR *SAFE-UTF8-CHAR]
 264
 265    BASE64-UTF8-STRING       = BASE64-STRING
 266                               ; MUST be the base64 encoding of a valid
 267                               ; string of UTF-8 characters
 268
 269    BASE64-CHAR              = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / %x61-7A
 270                               ; +, /, 0-9, =, A-Z, and a-z
 271                               ; as specified in [5]
 272
 273
 274
 275
 276 Good                        October 18, 1999                    [Page 5]
 277 \f
 278 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 279
 280
 281    BASE64-STRING            = [*(BASE64-CHAR)]
 282
 283
 284    Notes on LDIF Syntax
 285
 286    1) For the LDIF format described in this document, the version number
 287    MUST be "1". If the version number is absent, implementations MAY
 288    choose to interpret the contents as an older LDIF file format,
 289    supported by the University of Michigan ldap-3.3 implementation [8].
 290
 291    2) Any non-empty line, including comment lines, in an LDIF file MAY
 292    be folded by inserting a line separator (SEP) and a SPACE.  Folding
 293    MUST NOT occur before the first character of the line. In other
 294    words, folding a line into two lines, the first of which is empty, is
 295    not permitted. Any line that begins with a single space MUST be
 296    treated as a continuation of the previous (non-empty) line. When
 297    joining folded lines, exactly one space character at the beginning of
 298    each continued line must be discarded. Implementations SHOULD NOT
 299    fold lines in the middle of a multi-byte UTF-8 character.
 300
 301    3) Any line that begins with a pound-sign ("#", ASCII 35) is a
 302    comment line, and MUST be ignored when parsing an LDIF file.
 303
 304    4) Any dn or rdn that contains characters other than those defined as
 305    "SAFE-UTF8-CHAR", or begins with a character other than those defined
 306    as "SAFE-INIT-UTF8-CHAR", above, MUST be base-64 encoded.  Other
 307    values MAY be base-64 encoded.  Any value that contains characters
 308    other than those defined as "SAFE-CHAR", or begins with a character
 309    other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64
 310    encoded.  Other values MAY be base-64 encoded.
 311
 312    5) When a zero-length attribute value is to be included directly in
 313    an LDIF file, it MUST be represented as AttributeDescription ":" FILL
 314    SEP.  For example, "seeAlso:" followed by a newline represents a
 315    zero-length "seeAlso" attribute value.  It is also permissible for
 316    the value referred to by a URL to be of zero length.
 317
 318    6) When a URL is specified in an attrval-spec, the following
 319    conventions apply:
 320       a) Implementations SHOULD support the file:// URL format.  The
 321          contents of the referenced file are to be included verbatim
 322          in the interpreted output of the LDIF file.
 323       b) Implementations MAY support other URL formats.  The semantics
 324          associated with each supported URL will be documented in
 325          an associated Applicability Statement.
 326
 327    7) Distinguished names, relative distinguished names, and attribute
 328    values of DirectoryString syntax MUST be valid UTF-8 strings.
 329
 330
 331
 332 Good                        October 18, 1999                    [Page 6]
 333 \f
 334 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 335
 336
 337    Implementations that read LDIF MAY interpret files in which these
 338    entities are stored in some other character set encoding, but
 339    implementations MUST NOT generate LDIF content which does not contain
 340    valid UTF-8 data.
 341
 342    8) Values or distinguished names that end with SPACE SHOULD be base-
 343    64 encoded.
 344
 345    9) When controls are included in an LDIF file, implementations MAY
 346    choose to ignore some or all of them. This may be necessary if the
 347    changes described in the LDIF file are being sent on an LDAPv2
 348    connection (LDAPv2 does not support controls), or the particular
 349    controls are not supported by the remote server. If the criticality
 350    of a control is "true", then the implementation MUST either include
 351    the control, or MUST NOT send the operation to a remote server.
 352
 353    10) When an attrval-spec, distinguishedName, or rdn is base64-
 354    encoded, the encoding rules specified in [5] are used with the
 355    following exceptions:  a) The requirement that base64 output streams
 356    must be represented as lines of no more than 76 characters is
 357    removed. Lines in LDIF files may only be folded according to the
 358    folding rules described in note 2, above.  b) Base64 strings in [5]
 359    may contain characters other than those defined in BASE64-CHAR, and
 360    are ignored. LDIF does not permit any extraneous characters, other
 361    than those used for line folding.
 362
 363 Examples of LDAP Data Interchange Format
 364
 365
 366    Example 1: An simple LDAP file with two entries
 367
 368    version: 1
 369    dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
 370    objectclass: top
 371    objectclass: person
 372    objectclass: organizationalPerson
 373    cn: Barbara Jensen
 374    cn: Barbara J Jensen
 375    cn: Babs Jensen
 376    sn: Jensen
 377    uid: bjensen
 378    telephonenumber: +1 408 555 1212
 379    description: A big sailing fan.
 380
 381    dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
 382    objectclass: top
 383    objectclass: person
 384    objectclass: organizationalPerson
 385
 386
 387
 388 Good                        October 18, 1999                    [Page 7]
 389 \f
 390 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 391
 392
 393    cn: Bjorn Jensen
 394    sn: Jensen
 395    telephonenumber: +1 408 555 1212
 396
 397    Example 2: A file containing an entry with a folded attribute value
 398
 399    version: 1
 400    dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
 401    objectclass:top
 402    objectclass:person
 403    objectclass:organizationalPerson
 404    cn:Barbara Jensen
 405    cn:Barbara J Jensen
 406    cn:Babs Jensen
 407    sn:Jensen
 408    uid:bjensen
 409    telephonenumber:+1 408 555 1212
 410    description:Babs is a big sailing fan, and travels extensively in sea
 411     rch of perfect sailing conditions.
 412    title:Product Manager, Rod and Reel Division
 413
 414    Example 3: A file containing a base-64-encoded value
 415
 416    version: 1
 417    dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
 418    objectclass: top
 419    objectclass: person
 420    objectclass: organizationalPerson
 421    cn: Gern Jensen
 422    cn: Gern O Jensen
 423    sn: Jensen
 424    uid: gernj
 425    telephonenumber: +1 408 555 1212
 426    description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ
 427     hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0ICh
 428     hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu
 429
 430    Example 4: A file containing an entries with UTF-8-encoded attribute
 431    values, including language tags.  Comments indicate the contents
 432    of UTF-8-encoded attributes and distinguished names.
 433
 434    version: 1
 435    dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
 436    # dn:: ou=<JapaneseOU>,o=Airius
 437    objectclass: top
 438    objectclass: organizationalUnit
 439    ou:: 5Za25qWt6YOo
 440    # ou:: <JapaneseOU>
 441
 442
 443
 444 Good                        October 18, 1999                    [Page 8]
 445 \f
 446 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 447
 448
 449    ou;lang-ja:: 5Za25qWt6YOo
 450    # ou;lang-ja:: <JapaneseOU>
 451    ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
 452    # ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
 453    ou;lang-en: Sales
 454    description: Japanese office
 455
 456    dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
 457    # dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
 458    userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
 459    objectclass: top
 460    objectclass: person
 461    objectclass: organizationalPerson
 462    objectclass: inetOrgPerson
 463    uid: rogasawara
 464    mail: rogasawara@airius.co.jp
 465    givenname;lang-ja:: 44Ot44OJ44OL44O8
 466    # givenname;lang-ja:: <JapaneseGivenname>
 467    sn;lang-ja:: 5bCP56yg5Y6f
 468    # sn;lang-ja:: <JapaneseSn>
 469    cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
 470    # cn;lang-ja:: <JapaneseCn>
 471    title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
 472    # title;lang-ja:: <JapaneseTitle>
 473    preferredlanguage: ja
 474    givenname:: 44Ot44OJ44OL44O8
 475    # givenname:: <JapaneseGivenname>
 476    sn:: 5bCP56yg5Y6f
 477    # sn:: <JapaneseSn>
 478    cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
 479    # cn:: <JapaneseCn>
 480    title:: 5Za25qWt6YOoIOmDqOmVtw==
 481    # title:: <JapaneseTitle>
 482    givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
 483    # givenname;lang-ja;phonetic::
 484    <JapaneseGivenname_in_phonetic_representation_kana>
 485    sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
 486    # sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
 487    cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
 488    # cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
 489    title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
 490    # title;lang-ja;phonetic:: <JapaneseTitle_in_phonetic_representation_kana>
 491    givenname;lang-en: Rodney
 492    sn;lang-en: Ogasawara
 493    cn;lang-en: Rodney Ogasawara
 494    title;lang-en: Sales, Director
 495
 496    Example 5: A file containing a reference to an external file
 497
 498
 499
 500 Good                        October 18, 1999                    [Page 9]
 501 \f
 502 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 503
 504
 505    version: 1
 506    dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
 507    objectclass: top
 508    objectclass: person
 509    objectclass: organizationalPerson
 510    cn: Horatio Jensen
 511    cn: Horatio N Jensen
 512    sn: Jensen
 513    uid: hjensen
 514    telephonenumber: +1 408 555 1212
 515    jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
 516
 517    Example 6: A file containing a series of change records and comments
 518
 519    version: 1
 520    # Add a new entry
 521    dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
 522    changetype: add
 523    objectclass: top
 524    objectclass: person
 525    objectclass: organizationalPerson
 526    cn: Fiona Jensen
 527    sn: Jensen
 528    uid: fiona
 529    telephonenumber: +1 408 555 1212
 530    jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
 531
 532    # Delete an existing entry
 533    dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
 534    changetype: delete
 535
 536    # Modify an entry's relative distinguished name
 537    dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
 538    changetype: modrdn
 539    newrdn: cn=Paula Jensen
 540    deleteoldrdn: 1
 541
 542    # Rename an entry and move all of its children to a new location in
 543    # the directory tree (only implemented by LDAPv3 servers).
 544    dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
 545    changetype: modrdn
 546    newrdn: ou=Product Development Accountants
 547    deleteoldrdn: 0
 548    newsuperior: ou=Accounting, dc=airius, dc=com
 549
 550    # Modify an entry: add an additional value to the postaladdress attribute,
 551    # completely delete the description attribute, replace the telephonenumber
 552    # attribute with two values, and delete a specific value from the
 553
 554
 555
 556 Good                        October 18, 1999                   [Page 10]
 557 \f
 558 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 559
 560
 561    # facsimiletelephonenumber attribute
 562    dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
 563    changetype: modify
 564    add: postaladdress
 565    postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
 566    -
 567    delete: description
 568    -
 569    replace: telephonenumber
 570    telephonenumber: +1 408 555 1234
 571    telephonenumber: +1 408 555 5678
 572    -
 573    delete: facsimiletelephonenumber
 574    facsimiletelephonenumber: +1 408 555 9876
 575    -
 576
 577    # Modify an entry: replace the postaladdress attribute with an empty
 578    # set of values (which will cause the attribute to be removed), and
 579    # delete the entire description attribute. Note that the first will
 580    # always succeed, while the second will only succeed if at least
 581    # one value for the description attribute is present.
 582    dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
 583    changetype: modify
 584    replace: postaladdress
 585    -
 586    delete: description
 587    -
 588
 589    Example 7: An LDIF file containing a change record with a control
 590    version: 1
 591    # Delete an entry. The operation will attach the LDAPv3
 592    # Tree Delete Control defined in [9]. The criticality
 593    # field is "true" and the controlValue field is
 594    # absent, as required by [9].
 595    dn: ou=Product Development, dc=airius, dc=com
 596    control: 1.2.840.113556.1.4.805 true
 597    changetype: delete
 598
 599
 600 Security Considerations
 601
 602    Given typical directory applications, an LDIF file is likely to
 603    contain sensitive personal data.  Appropriate measures should be
 604    taken to protect the privacy of those persons whose data is contained
 605    in an LDIF file.
 606
 607    Since ":<" directives can cause external content to be included when
 608    processing an LDIF file, one should be cautious of accepting LDIF
 609
 610
 611
 612 Good                        October 18, 1999                   [Page 11]
 613 \f
 614 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 615
 616
 617    files from external sources.  A "trojan" LDIF file could name a file
 618    with sensitive contents and cause it to be included in a directory
 619    entry, which a hostile entity could read via LDAP.
 620
 621    LDIF does not provide any method for carrying authentication
 622    information with an LDIF file.  Users of LDIF files must take care to
 623    verify the integrity of an LDIF file received from an external
 624    source.
 625
 626 Appendix A: Differences from previous versions of this document
 627
 628    This section summarizes the differences between previous revisions of
 629    this draft, as an aid to document reviewers. This section will be
 630    deleted prior to publication as an RFC.
 631
 632    Differences between draft-ietf-asid-ldif-00.txt and draft-ietf-asid-
 633    ldif-01.txt
 634
 635    1) The BNF has been modified to explicitly disallow ldif content and
 636    change records in the same file.  In other words, a given LDIF file
 637    is either a series of directory entries, or a series of
 638    modifications.  An LDIF file MUST NOT contain both types of records.
 639
 640    2) External references are now URLs, instead of simple filenames.
 641
 642    3) The BNF has been modified to allow base-64-encoded distinguished
 643    names.
 644
 645    4) Multiple separators are now permitted between records.
 646
 647    Differences between draft-ietf-asid-ldif-01.txt and draft-ietf-asid-
 648    ldif-02.txt
 649
 650    1) The BNF has been modified such that a simple attribute name
 651    ("attrname") has been replaced with an "attribute-description" as
 652    defined in the LDAPv3 protocol document [4].  This permits language
 653    codes and other attribute options to be carried in an LDIF file.
 654
 655    2) A new option, "charset", may be used in attribute descriptions.
 656    This facilitates multi-lingual character set conversion.
 657
 658    3) The definition of the "safe" and "safe-initval" productions has
 659    been relaxed to allow non-ASCII characters with values greater than
 660    126.  This permits more natural expression of character sets such as
 661    Latin-1 in LDIF files.
 662
 663    Differences between draft-ietf-asid-ldif-02.txt and draft-good-ldap-
 664    ldif-00.txt
 665
 666
 667
 668 Good                        October 18, 1999                   [Page 12]
 669 \f
 670 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 671
 672
 673    1) The "charset-option" and "charset-name" productions were removed
 674    from the BNF, due to objections within the working group.  UTF-8 is
 675    the only character set that may be used in LDIF.
 676
 677    2) Examples were reworked to reflect the above change, and to include
 678    an example of a non-western language represented in UTF-8.
 679
 680    Differences between draft-ietf-good-ldif-00.txt and draft-good-ldap-
 681    ldif-01.txt
 682
 683    1) Added version identifiers to the examples - they were missing.
 684
 685    2) Clarified that LDIF files must use UTF-8.
 686
 687    Differences between draft-good-ldap-ldif-01.txt and draft-good-ldap-
 688    ldif-02.txt
 689
 690    1) Added a recommendation that values ending in SPACE should be
 691    base-64 encoded.
 692
 693    2) Clarified the procedure for joining folded lines.
 694
 695    3) Updated header to reflect new IETF I-D guidelines.
 696
 697    Differences between draft-good-ldap-ldif-02.txt and draft-good-ldap-
 698    ldif-03.txt
 699
 700    1) Fixed reference from RFC 1779 to RFC 2253.
 701
 702    2) Version string is now required.
 703
 704    3) Comment lines may be folded (this is now explicitly mentioned in
 705    note 2).
 706
 707    4) Moved this section (differences between draft versions) to an
 708    appendix.
 709
 710    5) Updated examples to use "dc=airius, dc=com" instead of "o=Ace
 711    Industry, c=US"
 712
 713    6) Cleaned up references section.
 714
 715    Differences between draft-good-ldap-ldif-03.txt and draft-good-ldap-
 716    ldif-04.txt
 717
 718    1) The grammar now requires that an LDIF file end with one or more
 719    SEP sequences (newlines). This was inadvertently prohibited in
 720    earlier revisions of the grammar.
 721
 722
 723
 724 Good                        October 18, 1999                   [Page 13]
 725 \f
 726 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 727
 728
 729    2) Several minor spelling and typographical errors were fixed.
 730
 731    3) Reworked the grammar to make it more readable. Hallvard Furuseth
 732    (University of Oslo) provided the new BNF.
 733
 734    4) Excluded NUL from "safe" production.
 735
 736    5) Changed "0,1*xxx" "0*1xxx" in compliance with RFC822.
 737
 738    6) Fixed a glitch in the grammar that allowed multiple changetypes
 739    within a single LDIF change record. The intent is that only one
 740    changetype per change record is permitted.
 741
 742    7) Fixed a mistake in example 2 (folded attribute value).
 743
 744    8) The BNF now explicitly requires that zero-length attribute values
 745    be encoded as attribute-description ":" FILL SEP.
 746
 747    9) Factored "changetype: FILL" out of the productions for change-add,
 748    change-delete, change-moddn, and change-modify.
 749
 750    10) RFC 2251 permits an LDAP modify operation with no modifications,
 751    and also permits an attribute with no values. Although it's unclear
 752    what the purpose of these constructs might be, I altered the BNF to
 753    allow these to be described in LDIF.
 754
 755    11) The BNF may now carry LDAP v3 controls in ldif-change-records.
 756    The "value-spec" production was factored out to allow it to be used
 757    in the definition of a control.
 758
 759    12) Clarified the rules for line-folding to prohibit a line from
 760    being folded into two lines, the first of which is empty. This
 761    guarantees that the sequence SEP SEP terminates an LDIF record, and
 762    allows, for example, "perl -n00" to be used to read an entire LDIF
 763    record into the $_ variable.
 764
 765    Differences between draft-good-ldap-ldif-04.txt and draft-good-ldap-
 766    ldif-05.txt
 767
 768    1) The grammar has been rewritten to use the RFC2234 ABNF, replacing
 769    the RFC822 ABNF.
 770
 771    2) The grammar makes fewer uses of <prose-val>.
 772
 773    3) DNs, RDNs, and attribute values with DirectoryString are now
 774    explicitly called out as UTF-8 strings.
 775
 776    4) An error in the BNF for "control" was fixed.
 777
 778
 779
 780 Good                        October 18, 1999                   [Page 14]
 781 \f
 782 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 783
 784
 785    5) An additional ldif-change-record was added to example 6.
 786
 787    6) Since RFC 1521 defines base-64 encoding with different folding
 788    rules, and permits illegal characters (which should be ignored), an
 789    explanatory note has been added. This note explains that lines must
 790    be folded according to LDIF rules, not RFC 1521 rules, and that
 791    extraneous characters are not permitted.
 792
 793    7) DNs, values, and rdns containing octets > 127 must be base-64
 794    encoded.
 795
 796
 797 Acknowledgments
 798
 799    The LDAP Interchange Format was developed as part of the University
 800    of Michigan LDAP reference implementation, and was developed by Tim
 801    Howes, Mark Smith, and Gordon Good.  It is based in part upon work
 802    supported by the National Science Foundation under Grant No.  NCR-
 803    9416667.
 804
 805    Members of the IETF LDAP Extensions Working group provided many
 806    helpful suggestions. In particular, Hallvard B. Furuseth of the
 807    University of Oslo made many significant contributions to this
 808    document, including a thorough review and rewrite of the BNF.
 809
 810 References
 811
 812
 813    [1]  Howes, T., Smith, M., "A MIME Content-Type for Directory Infor-
 814         mation", RFC 2425, September 1998,
 815         <URL:http://www.ietf.org/rfc/rfc2245.txt>
 816
 817    [2]  Crocker,  D., Overell, P., "Augmented BNF for Syntax Specifica-
 818         tions: ABNF" , RFC 2234, November 1997,
 819         <URL:http://ds.internic.net/rfc/rfc2234.txt>
 820
 821    [3]  Wahl, M., Kille, S., Howes, T., "A String Representation of Dis-
 822         tinguished Names", RFC 2253,
 823         <URL:http://www.ietf.org/rfc/rfc2253.txt>
 824
 825    [4]  Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
 826         Protocol (v3)", RFC 2251, July, 1997,
 827         <URL:ftp://www.ietf.org/rfc/rfc2251.txt>
 828
 829    [5]  Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail
 830         Extensions) Part One: Mechanisms for Specifying and Describing
 831         the Format of Internet Message Bodies", section 5.2, "Base64
 832         Content-Transfer-Encoding", RFC 1521, December 1993,
 833
 834
 835
 836 Good                        October 18, 1999                   [Page 15]
 837 \f
 838 INTERNET-DRAFT        LDAP Data Interchange Format       19 October 1999
 839
 840
 841         <URL:http://ds.internic.net/rfc/rfc1521.txt>
 842
 843    [6]  T. Berners-Lee,  L.  Masinter, M. McCahill, "Uniform Resource
 844         Locators (URL)", RFC 1738, December 1994,
 845         <URL:http://ds.internic.net/rfc/rfc1738.txt>
 846
 847    [7]  S. Bradner, "Key Words for use in RFCs to Indicate Requirement
 848         Levels", Harvard University, RFC 2119, March 1997,
 849         <URL:http://ds.internic.net/rfc/rfc2119.txt>
 850
 851    [8]  The SLAPD and SLURPD Administrators Guide.  University of Michi-
 852         gan, April 1996.  <URL:
 853         http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
 854
 855    [9]  M. P. Armijo, "Tree Delete Control", Microsoft Corporation,
 856         INTERNET-DRAFT June 1999, <URL:http://www.ietf.org/internet-
 857         drafts/draft-armijo-ldap-treedelete-01.txt>
 858
 859
 860
 861
 862 Author's Address
 863
 864         Gordon Good
 865         Netscape Communications Corp.
 866         501 E. Middlefield Rd.
 867         Mailstop MV068
 868         Mountain View, CA 94043, USA
 869         Phone:  +1 650 937-3825
 870         EMail:  ggood@netscape.com
 871
 872                   This Internet Draft expires 19 April, 2000.
 873
 874
 875
 876
 877
 878
 879
 880
 881
 882
 883
 884
 885
 886
 887
 888
 889
 890
 891
 892 Good                        October 18, 1999                   [Page 16]
 893 \f