source4/ldap_server/devdocs/rfc2849.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                             G. Good
   8 Request for Comments: 2849                   iPlanet e-commerce Solutions
   9 Category: Standards Track                                       June 2000
  10
  11
  12    The LDAP Data Interchange Format (LDIF) - Technical Specification
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (2000).  All Rights Reserved.
  25
  26 Abstract
  27
  28    This document describes a file format suitable for describing
  29    directory information or modifications made to directory information.
  30    The file format, known as LDIF, for LDAP Data Interchange Format, is
  31    typically used to import and export directory information between
  32    LDAP-based directory servers, or to describe a set of changes which
  33    are to be applied to a directory.
  34
  35 Background and Intended Usage
  36
  37    There are a number of situations where a common interchange format is
  38    desirable.  For example, one might wish to export a copy of the
  39    contents of a directory server to a file, move that file to a
  40    different machine, and import the contents into a second directory
  41    server.
  42
  43    Additionally, by using a well-defined interchange format, development
  44    of data import tools from legacy systems is facilitated.  A fairly
  45    simple set of tools written in awk or perl can, for example, convert
  46    a database of personnel information into an LDIF file. This file can
  47    then be imported into a directory server, regardless of the internal
  48    database representation the target directory server uses.
  49
  50    The LDIF format was originally developed and used in the University
  51    of Michigan LDAP implementation.  The first use of LDIF was in
  52    describing directory entries.  Later, the format was expanded to
  53    allow representation of changes to directory entries.
  54
  55
  56
  57
  58 Good                        Standards Track                     [Page 1]
  59 \f
  60 RFC 2849              LDAP Data Interchange Format             June 2000
  61
  62
  63    Relationship to the application/directory MIME content-type:
  64
  65    The application/directory MIME content-type [1] is a general
  66    framework and format for conveying directory information, and is
  67    independent of any particular directory service.  The LDIF format is
  68    a simpler format which is perhaps easier to create, and may also be
  69    used, as noted, to describe a set of changes to be applied to a
  70    directory.
  71
  72    The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
  73    used in this document are to be interpreted as described in [7].
  74
  75 Definition of the LDAP Data Interchange Format
  76
  77    The LDIF format is used to convey directory information, or a
  78    description of a set of changes made to directory entries.  An LDIF
  79    file consists of a series of records separated by line separators.  A
  80    record consists of a sequence of lines describing a directory entry,
  81    or a sequence of lines describing a set of changes to a directory
  82    entry.  An LDIF file specifies a set of directory entries, or a set
  83    of changes to be applied to directory entries, but not both.
  84
  85    There is a one-to-one correlation between LDAP operations that modify
  86    the directory (add, delete, modify, and modrdn), and the types of
  87    changerecords described below ("add", "delete", "modify", and
  88    "modrdn" or "moddn").  This correspondence is intentional, and
  89    permits a straightforward translation from LDIF changerecords to
  90    protocol operations.
  91
  92 Formal Syntax Definition of LDIF
  93
  94    The following definition uses the augmented Backus-Naur Form
  95    specified in RFC 2234 [2].
  96
  97 ldif-file                = ldif-content / ldif-changes
  98
  99 ldif-content             = version-spec 1*(1*SEP ldif-attrval-record)
 100
 101 ldif-changes             = version-spec 1*(1*SEP ldif-change-record)
 102
 103 ldif-attrval-record      = dn-spec SEP 1*attrval-spec
 104
 105 ldif-change-record       = dn-spec SEP *control changerecord
 106
 107 version-spec             = "version:" FILL version-number
 108
 109
 110
 111
 112
 113
 114 Good                        Standards Track                     [Page 2]
 115 \f
 116 RFC 2849              LDAP Data Interchange Format             June 2000
 117
 118
 119 version-number           = 1*DIGIT
 120                            ; version-number MUST be "1" for the
 121                            ; LDIF format described in this document.
 122
 123 dn-spec                  = "dn:" (FILL distinguishedName /
 124                                   ":" FILL base64-distinguishedName)
 125
 126 distinguishedName        = SAFE-STRING
 127                            ; a distinguished name, as defined in [3]
 128
 129 base64-distinguishedName = BASE64-UTF8-STRING
 130                            ; a distinguishedName which has been base64
 131                            ; encoded (see note 10, below)
 132
 133 rdn                      = SAFE-STRING
 134                            ; a relative distinguished name, defined as
 135                            ; <name-component> in [3]
 136
 137 base64-rdn               = BASE64-UTF8-STRING
 138                            ; an rdn which has been base64 encoded (see
 139                            ; note 10, below)
 140
 141 control                  = "control:" FILL ldap-oid        ; controlType
 142                            0*1(1*SPACE ("true" / "false")) ; criticality
 143                            0*1(value-spec)                ; controlValue
 144                            SEP
 145                            ; (See note 9, below)
 146
 147 ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
 148                            ; An LDAPOID, as defined in [4]
 149
 150 attrval-spec             = AttributeDescription value-spec SEP
 151
 152 value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
 153                                 ":" FILL (BASE64-STRING) /
 154                                 "<" FILL url)
 155                            ; See notes 7 and 8, below
 156
 157 url                      = <a Uniform Resource Locator,
 158                             as defined in [6]>
 159                                    ; (See Note 6, below)
 160
 161 AttributeDescription     = AttributeType [";" options]
 162                            ; Definition taken from [4]
 163
 164 AttributeType            = ldap-oid / (ALPHA *(attr-type-chars))
 165
 166 options                  = option / (option ";" options)
 167
 168
 169
 170 Good                        Standards Track                     [Page 3]
 171 \f
 172 RFC 2849              LDAP Data Interchange Format             June 2000
 173
 174
 175 option                   = 1*opt-char
 176
 177 attr-type-chars          = ALPHA / DIGIT / "-"
 178
 179 opt-char                 = attr-type-chars
 180
 181 changerecord             = "changetype:" FILL
 182                            (change-add / change-delete /
 183                             change-modify / change-moddn)
 184
 185 change-add               = "add"                SEP 1*attrval-spec
 186
 187 change-delete            = "delete"             SEP
 188
 189 change-moddn             = ("modrdn" / "moddn") SEP
 190                             "newrdn:" (    FILL rdn /
 191                                        ":" FILL base64-rdn) SEP
 192                             "deleteoldrdn:" FILL ("0" / "1")  SEP
 193                             0*1("newsuperior:"
 194                             (    FILL distinguishedName /
 195                              ":" FILL base64-distinguishedName) SEP)
 196
 197 change-modify            = "modify"             SEP *mod-spec
 198
 199 mod-spec                 = ("add:" / "delete:" / "replace:")
 200                            FILL AttributeDescription SEP
 201                            *attrval-spec
 202                            "-" SEP
 203
 204 SPACE                    = %x20
 205                            ; ASCII SP, space
 206
 207 FILL                     = *SPACE
 208
 209 SEP                      = (CR LF / LF)
 210
 211 CR                       = %x0D
 212                            ; ASCII CR, carriage return
 213
 214 LF                       = %x0A
 215                            ; ASCII LF, line feed
 216
 217 ALPHA                    = %x41-5A / %x61-7A
 218                            ; A-Z / a-z
 219
 220 DIGIT                    = %x30-39
 221                            ; 0-9
 222
 223
 224
 225
 226 Good                        Standards Track                     [Page 4]
 227 \f
 228 RFC 2849              LDAP Data Interchange Format             June 2000
 229
 230
 231 UTF8-1                   = %x80-BF
 232
 233 UTF8-2                   = %xC0-DF UTF8-1
 234
 235 UTF8-3                   = %xE0-EF 2UTF8-1
 236
 237 UTF8-4                   = %xF0-F7 3UTF8-1
 238
 239 UTF8-5                   = %xF8-FB 4UTF8-1
 240
 241 UTF8-6                   = %xFC-FD 5UTF8-1
 242
 243 SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
 244                            ; any value <= 127 decimal except NUL, LF,
 245                            ; and CR
 246
 247 SAFE-INIT-CHAR           = %x01-09 / %x0B-0C / %x0E-1F /
 248                            %x21-39 / %x3B / %x3D-7F
 249                            ; any value <= 127 except NUL, LF, CR,
 250                            ; SPACE, colon (":", ASCII 58 decimal)
 251                            ; and less-than ("<" , ASCII 60 decimal)
 252
 253 SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]
 254
 255 UTF8-CHAR                = SAFE-CHAR / UTF8-2 / UTF8-3 /
 256                            UTF8-4 / UTF8-5 / UTF8-6
 257
 258 UTF8-STRING              = *UTF8-CHAR
 259
 260 BASE64-UTF8-STRING       = BASE64-STRING
 261                            ; MUST be the base64 encoding of a
 262                            ; UTF8-STRING
 263
 264 BASE64-CHAR              = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
 265                            %x61-7A
 266                            ; +, /, 0-9, =, A-Z, and a-z
 267                            ; as specified in [5]
 268
 269 BASE64-STRING            = [*(BASE64-CHAR)]
 270
 271
 272    Notes on LDIF Syntax
 273
 274       1)  For the LDIF format described in this document, the version
 275           number MUST be "1". If the version number is absent,
 276           implementations MAY choose to interpret the contents as an
 277           older LDIF file format, supported by the University of
 278           Michigan ldap-3.3 implementation [8].
 279
 280
 281
 282 Good                        Standards Track                     [Page 5]
 283 \f
 284 RFC 2849              LDAP Data Interchange Format             June 2000
 285
 286
 287       2)  Any non-empty line, including comment lines, in an LDIF file
 288           MAY be folded by inserting a line separator (SEP) and a SPACE.
 289           Folding MUST NOT occur before the first character of the line.
 290           In other words, folding a line into two lines, the first of
 291           which is empty, is not permitted. Any line that begins with a
 292           single space MUST be treated as a continuation of the previous
 293           (non-empty) line. When joining folded lines, exactly one space
 294           character at the beginning of each continued line must be
 295           discarded. Implementations SHOULD NOT fold lines in the middle
 296           of a multi-byte UTF-8 character.
 297
 298       3)  Any line that begins with a pound-sign ("#", ASCII 35) is a
 299           comment line, and MUST be ignored when parsing an LDIF file.
 300
 301       4)  Any dn or rdn that contains characters other than those
 302           defined as "SAFE-UTF8-CHAR", or begins with a character other
 303           than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be
 304           base-64 encoded.  Other values MAY be base-64 encoded.  Any
 305           value that contains characters other than those defined as
 306           "SAFE-CHAR", or begins with a character other than those
 307           defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
 308           Other values MAY be base-64 encoded.
 309
 310       5)  When a zero-length attribute value is to be included directly
 311           in an LDIF file, it MUST be represented as
 312           AttributeDescription ":" FILL SEP.  For example, "seeAlso:"
 313           followed by a newline represents a zero-length "seeAlso"
 314           attribute value.  It is also permissible for the value
 315           referred to by a URL to be of zero length.
 316
 317       6) When a URL is specified in an attrval-spec, the following
 318           conventions apply:
 319
 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
 324             semantics associated with each supported URL will be
 325             documented in an associated Applicability Statement.
 326
 327       7)  Distinguished names, relative distinguished names, and
 328           attribute values of DirectoryString syntax MUST be valid UTF-8
 329           strings.  Implementations that read LDIF MAY interpret files
 330           in which these entities are stored in some other character set
 331           encoding, but implementations MUST NOT generate LDIF content
 332           which does not contain valid UTF-8 data.
 333
 334
 335
 336
 337
 338 Good                        Standards Track                     [Page 6]
 339 \f
 340 RFC 2849              LDAP Data Interchange Format             June 2000
 341
 342
 343       8)  Values or distinguished names that end with SPACE SHOULD be
 344           base-64 encoded.
 345
 346       9)  When controls are included in an LDIF file, implementations
 347           MAY choose to ignore some or all of them. This may be
 348           necessary if the changes described in the LDIF file are being
 349           sent on an LDAPv2 connection (LDAPv2 does not support
 350           controls), or the particular controls are not supported by the
 351           remote server. If the criticality of a control is "true", then
 352           the implementation MUST either include the control, or MUST
 353           NOT send the operation to a remote server.
 354
 355       10) When an attrval-spec, distinguishedName, or rdn is base64-
 356           encoded, the encoding rules specified in [5] are used with the
 357           following exceptions:  a) The requirement that base64 output
 358           streams must be represented as lines of no more than 76
 359           characters is removed. Lines in LDIF files may only be folded
 360           according to the folding rules described in note 2, above.  b)
 361           Base64 strings in [5] may contain characters other than those
 362           defined in BASE64-CHAR, and are ignored. LDIF does not permit
 363           any extraneous characters, other than those used for line
 364           folding.
 365
 366 Examples of LDAP Data Interchange Format
 367
 368 Example 1: An simple LDAP file with two entries
 369
 370 version: 1
 371 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
 372 objectclass: top
 373 objectclass: person
 374 objectclass: organizationalPerson
 375 cn: Barbara Jensen
 376 cn: Barbara J Jensen
 377 cn: Babs Jensen
 378 sn: Jensen
 379 uid: bjensen
 380 telephonenumber: +1 408 555 1212
 381 description: A big sailing fan.
 382
 383 dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
 384 objectclass: top
 385 objectclass: person
 386 objectclass: organizationalPerson
 387 cn: Bjorn Jensen
 388 sn: Jensen
 389 telephonenumber: +1 408 555 1212
 390
 391
 392
 393
 394 Good                        Standards Track                     [Page 7]
 395 \f
 396 RFC 2849              LDAP Data Interchange Format             June 2000
 397
 398
 399 Example 2: A file containing an entry with a folded attribute value
 400
 401 version: 1
 402 dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
 403 objectclass:top
 404 objectclass:person
 405 objectclass:organizationalPerson
 406 cn:Barbara Jensen
 407 cn:Barbara J Jensen
 408 cn:Babs Jensen
 409 sn:Jensen
 410 uid:bjensen
 411 telephonenumber:+1 408 555 1212
 412 description:Babs is a big sailing fan, and travels extensively in sea
 413  rch of perfect sailing conditions.
 414 title:Product Manager, Rod and Reel Division
 415
 416 Example 3: A file containing a base-64-encoded value
 417
 418 version: 1
 419 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
 420 objectclass: top
 421 objectclass: person
 422 objectclass: organizationalPerson
 423 cn: Gern Jensen
 424 cn: Gern O Jensen
 425 sn: Jensen
 426 uid: gernj
 427 telephonenumber: +1 408 555 1212
 428 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
 429 IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
 430 VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
 431 b3V0IG1vcmUu
 432
 433 Example 4: A file containing an entries with UTF-8-encoded attribute
 434 values, including language tags.  Comments indicate the contents
 435 of UTF-8-encoded attributes and distinguished names.
 436
 437 version: 1
 438 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
 439 # dn:: ou=<JapaneseOU>,o=Airius
 440 objectclass: top
 441 objectclass: organizationalUnit
 442 ou:: 5Za25qWt6YOo
 443 # ou:: <JapaneseOU>
 444 ou;lang-ja:: 5Za25qWt6YOo
 445 # ou;lang-ja:: <JapaneseOU>
 446 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
 447
 448
 449
 450 Good                        Standards Track                     [Page 8]
 451 \f
 452 RFC 2849              LDAP Data Interchange Format             June 2000
 453
 454
 455 # ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
 456 ou;lang-en: Sales
 457 description: Japanese office
 458
 459 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
 460 # dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
 461 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
 462 objectclass: top
 463 objectclass: person
 464 objectclass: organizationalPerson
 465 objectclass: inetOrgPerson
 466 uid: rogasawara
 467 mail: rogasawara@airius.co.jp
 468 givenname;lang-ja:: 44Ot44OJ44OL44O8
 469 # givenname;lang-ja:: <JapaneseGivenname>
 470 sn;lang-ja:: 5bCP56yg5Y6f
 471 # sn;lang-ja:: <JapaneseSn>
 472 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
 473 # cn;lang-ja:: <JapaneseCn>
 474 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
 475 # title;lang-ja:: <JapaneseTitle>
 476 preferredlanguage: ja
 477 givenname:: 44Ot44OJ44OL44O8
 478 # givenname:: <JapaneseGivenname>
 479 sn:: 5bCP56yg5Y6f
 480 # sn:: <JapaneseSn>
 481 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
 482 # cn:: <JapaneseCn>
 483 title:: 5Za25qWt6YOoIOmDqOmVtw==
 484 # title:: <JapaneseTitle>
 485 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
 486 # givenname;lang-ja;phonetic::
 487 <JapaneseGivenname_in_phonetic_representation_kana>
 488 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
 489 # sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
 490 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
 491 # cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
 492 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
 493 # title;lang-ja;phonetic::
 494 # <JapaneseTitle_in_phonetic_representation_kana>
 495 givenname;lang-en: Rodney
 496 sn;lang-en: Ogasawara
 497 cn;lang-en: Rodney Ogasawara
 498 title;lang-en: Sales, Director
 499
 500
 501
 502
 503
 504
 505
 506 Good                        Standards Track                     [Page 9]
 507 \f
 508 RFC 2849              LDAP Data Interchange Format             June 2000
 509
 510
 511 Example 5: A file containing a reference to an external file
 512
 513 version: 1
 514 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
 515 objectclass: top
 516 objectclass: person
 517 objectclass: organizationalPerson
 518 cn: Horatio Jensen
 519
 520 cn: Horatio N Jensen
 521 sn: Jensen
 522 uid: hjensen
 523 telephonenumber: +1 408 555 1212
 524 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
 525
 526 Example 6: A file containing a series of change records and comments
 527
 528 version: 1
 529 # Add a new entry
 530 dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
 531 changetype: add
 532 objectclass: top
 533 objectclass: person
 534 objectclass: organizationalPerson
 535 cn: Fiona Jensen
 536 sn: Jensen
 537 uid: fiona
 538 telephonenumber: +1 408 555 1212
 539 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
 540
 541 # Delete an existing entry
 542 dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
 543 changetype: delete
 544
 545 # Modify an entry's relative distinguished name
 546 dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
 547 changetype: modrdn
 548 newrdn: cn=Paula Jensen
 549 deleteoldrdn: 1
 550
 551 # Rename an entry and move all of its children to a new location in
 552 # the directory tree (only implemented by LDAPv3 servers).
 553 dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
 554 changetype: modrdn
 555 newrdn: ou=Product Development Accountants
 556 deleteoldrdn: 0
 557 newsuperior: ou=Accounting, dc=airius, dc=com
 558
 559
 560
 561
 562 Good                        Standards Track                    [Page 10]
 563 \f
 564 RFC 2849              LDAP Data Interchange Format             June 2000
 565
 566
 567 # Modify an entry: add an additional value to the postaladdress
 568 # attribute, completely delete the description attribute, replace
 569 # the telephonenumber attribute with two values, and delete a specific
 570 # value from the facsimiletelephonenumber attribute
 571 dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
 572 changetype: modify
 573 add: postaladdress
 574 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
 575 -
 576
 577 delete: description
 578 -
 579 replace: telephonenumber
 580 telephonenumber: +1 408 555 1234
 581 telephonenumber: +1 408 555 5678
 582 -
 583 delete: facsimiletelephonenumber
 584 facsimiletelephonenumber: +1 408 555 9876
 585 -
 586
 587 # Modify an entry: replace the postaladdress attribute with an empty
 588 # set of values (which will cause the attribute to be removed), and
 589 # delete the entire description attribute. Note that the first will
 590 # always succeed, while the second will only succeed if at least
 591 # one value for the description attribute is present.
 592 dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
 593 changetype: modify
 594 replace: postaladdress
 595 -
 596 delete: description
 597 -
 598
 599 Example 7: An LDIF file containing a change record with a control
 600 version: 1
 601 # Delete an entry. The operation will attach the LDAPv3
 602 # Tree Delete Control defined in [9]. The criticality
 603 # field is "true" and the controlValue field is
 604 # absent, as required by [9].
 605 dn: ou=Product Development, dc=airius, dc=com
 606 control: 1.2.840.113556.1.4.805 true
 607 changetype: delete
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Good                        Standards Track                    [Page 11]
 619 \f
 620 RFC 2849              LDAP Data Interchange Format             June 2000
 621
 622
 623 Security Considerations
 624
 625    Given typical directory applications, an LDIF file is likely to
 626    contain sensitive personal data.  Appropriate measures should be
 627    taken to protect the privacy of those persons whose data is contained
 628    in an LDIF file.
 629
 630    Since ":<" directives can cause external content to be included when
 631    processing an LDIF file, one should be cautious of accepting LDIF
 632    files from external sources.  A "trojan" LDIF file could name a file
 633    with sensitive contents and cause it to be included in a directory
 634    entry, which a hostile entity could read via LDAP.
 635
 636    LDIF does not provide any method for carrying authentication
 637    information with an LDIF file.  Users of LDIF files must take care to
 638    verify the integrity of an LDIF file received from an external
 639    source.
 640
 641 Acknowledgments
 642
 643    The LDAP Interchange Format was developed as part of the University
 644    of Michigan LDAP reference implementation, and was developed by Tim
 645    Howes, Mark Smith, and Gordon Good.  It is based in part upon work
 646    supported by the National Science Foundation under Grant No.  NCR-
 647    9416667.
 648
 649    Members of the IETF LDAP Extensions Working group provided many
 650    helpful suggestions. In particular, Hallvard B. Furuseth of the
 651    University of Oslo made many significant contributions to this
 652    document, including a thorough review and rewrite of the BNF.
 653
 654 References
 655
 656    [1]  Howes, T. and M. Smith, "A MIME Content-Type for Directory
 657         Information", RFC 2425, September 1998.
 658
 659    [2]  Crocker, D., and P. Overell, "Augmented BNF for Syntax
 660         Specifications: ABNF", RFC 2234, November 1997.
 661
 662    [3]  Wahl, M., Kille, S. and T. Howes, "A String Representation of
 663         Distinguished Names", RFC 2253, December 1997.
 664
 665    [4]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
 666         Protocol (v3)", RFC 2251, July 1997.
 667
 668    [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
 669         Extensions (MIME) Part One: Format of Internet Message Bodies",
 670         RFC 2045, November 1996.
 671
 672
 673
 674 Good                        Standards Track                    [Page 12]
 675 \f
 676 RFC 2849              LDAP Data Interchange Format             June 2000
 677
 678
 679    [6]  Berners-Lee,  T., Masinter, L. and M. McCahill, "Uniform
 680         Resource Locators (URL)", RFC 1738, December 1994.
 681
 682    [7]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
 683         Levels", BCP 14, RFC 2119, March 1997.
 684
 685    [8]  The SLAPD and SLURPD Administrators Guide.  University of
 686         Michigan, April 1996.  <URL:
 687         http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
 688
 689    [9]  M. P. Armijo, "Tree Delete Control", Work in Progress.
 690
 691 Author's Address
 692
 693    Gordon Good
 694    iPlanet e-commerce Solutions
 695    150 Network Circle
 696    Mailstop USCA17-201
 697    Santa Clara, CA 95054, USA
 698
 699    Phone: +1 408 276 4351
 700    EMail:  ggood@netscape.com
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730 Good                        Standards Track                    [Page 13]
 731 \f
 732 RFC 2849              LDAP Data Interchange Format             June 2000
 733
 734
 735 Full Copyright Statement
 736
 737    Copyright (C) The Internet Society (2000).  All Rights Reserved.
 738
 739    This document and translations of it may be copied and furnished to
 740    others, and derivative works that comment on or otherwise explain it
 741    or assist in its implementation may be prepared, copied, published
 742    and distributed, in whole or in part, without restriction of any
 743    kind, provided that the above copyright notice and this paragraph are
 744    included on all such copies and derivative works.  However, this
 745    document itself may not be modified in any way, such as by removing
 746    the copyright notice or references to the Internet Society or other
 747    Internet organizations, except as needed for the purpose of
 748    developing Internet standards in which case the procedures for
 749    copyrights defined in the Internet Standards process must be
 750    followed, or as required to translate it into languages other than
 751    English.
 752
 753    The limited permissions granted above are perpetual and will not be
 754    revoked by the Internet Society or its successors or assigns.
 755
 756    This document and the information contained herein is provided on an
 757    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 758    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 759    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 760    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 761    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 762
 763 Acknowledgement
 764
 765    Funding for the RFC Editor function is currently provided by the
 766    Internet Society.
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783
 784
 785
 786 Good                        Standards Track                    [Page 14]
 787 \f