home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / ldapsdk.zip / doc / rfc / rfc2849.txt < prev    next >
Text File  |  2000-06-18  |  26KB  |  788 lines
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  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.  
  788.