[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02

LDAP Data Interchange Format (LDIF)                         Gordon Good
INTERNET-DRAFT                                  Netscape Communications
                                                       25 November 1996

                The LDAP Data Interchange Format (LDIF)
                 Filename: draft-ietf-asid-ldif-00.txt

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-
   Drafts Shadow Directories on ds.internic.net (US East Coast),
   nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or
   munnari.oz.au (Pacific Rim).

   Distribution of this memo is unlimited.  Editorial comments should be
   sent to the author (ggood@netscape.com).  Technical discussion will take
   place on the IETF ASID mailing list (ietf-asid@umich.edu).

   This Internet Draft expires May 1st, 1997.


Abstract

   This document describes a file format suitable for describing
   directory information and modifications made to directory
   information.  The file format, known as LDIF, for LDAP Data
   Interchange Format, is typically used to import and export directory
   information between LDAP-based directory servers, and to describe a
   set of changes which are to be applied to a directory.

   There are a number of situations where a common interchange format is
   desirable.  For example, one might wish to export a copy of the
   contents of a directory server to a file, move that file to a
   different machine, and import the contents into a second directory
   server.




Good                    IETF ASID Working Group                 [Page 1]


INTERNET-DRAFT        LDAP Data Interchange Format      25 November 1996


   Additionally, by using a well-defined interchange format, development
   of data import tools from legacy systems is facilitated.  A fairly
   simple set of tools written in awk or perl can, for example, convert
   a database of personnel information into an LDIF file, which can then
   be imported into a directory server, regardless of the internal
   database representation the target directory server uses.


Background and Intended Usage

   The LDIF format was originally developed and used in the University
   of Michigan LDAP implementation.  The first use of LDIF was in
   describing directory entries.  Later, the format was expanded to
   allow representation of changes to directory entries.

   Relationship to the application/directory MIME content-type

   The application/directory MIME content-type [1] is a general
   framework and format for conveying directory information, and is
   independent of any particular directory service.  It is preferred, in
   most cases, to LDIF, for conveying directory information.  The LDIF
   format is a simpler format which is perhaps easier to create, and
   also may be used, as noted, to describe a set of changes to be
   applied to a directory.



Definition of the LDAP Data Interchange Format


   The LDIF format is used to convey directory information, or a
   description of a set of changes made to directory entries.  An LDIF
   file consists of a series of records separated by a line separator.
   Each record consists of a sequence of lines describing a directory
   entry, or a sequence of lines describing a set of changes to a single
   directory entry.


Formal Syntax Definition of LDIF

   The following definition uses the augmented Backus-Naur Form
   specified in RFC 822 [2].

   ldif-file            = 0,1*(version-spec SEP) ldif-record *(SEP ldif-record)

   version-spec         = "version:" *SPACE version-number
   version-number       = 1*DIGIT  ; version-number must be "1" for the
                                   ; LDIF format described in this document.



Good                    IETF ASID Working Group                 [Page 2]


INTERNET-DRAFT        LDAP Data Interchange Format      25 November 1996


   ldif-record          = dn-spec SEP ldif-content SEP

   dn-spec              = "dn:" *SPACE dn
   dn                   = <a distinguished name, as defined in RFC 1779 [3]>
   rdn                  = <a relative distinguished name, as defined in RFC
                          1779 [3]>

   ldif-content         = 1*(attrval-spec SEP) / (changerecord SEP)
   attrval-spec         = attrname (":" *SPACE value) /
                          ("::" *SPACE base64-value) /
                          (":<" *SPACE file-spec)
   file-spec            = <a file name, as defined by local operating
                           system conventions>
   attrname             = <an attribute name, as defined in
                           draft-ietf-asid-ldapv3-attributes-03.txt [4]
                           Attribute names may not contain a colon ":">
   value                = 1*safe-initval *safe
   safe                 = <ASCII values 040 - 0176 octal (32 - 126 decimal)>
   safe-initval         = <ASCII values 040 - 0176 octal (32 - 126 decimal),
                          excluding colon (":", ASCII 58 decimal), SPACE, and
                          less-than ("<" , ASCII 60 decimal)>
   base64-value         = <base-64-encoded value, as defined in RFC 1521 [5]>

   changerecord         = change-add / change-delete / change-modify /
                          change-moddn
   change-add           = "changetype:" *SPACE "add" 1*(SEP attrval-spec)
   change-delete        = "changetype:" *SPACE "delete"
   change-moddn         = "changetype:" *SPACE ("modrdn" / "moddn") SEP
                          "newrdn:" *SPACE rdn SEP
                          "deleteoldrdn:" *SPACE ("0" / "1")
                          0,1*(SEP "newsuperior:" *SPACE dn)
   change-modify        = "changetype:" *SPACE "modify" 1*(SEP mod-spec)
   mod-spec             = mod-add-spec / mod-delete-spec / mod-replace-spec
   mod-add-spec         = "add:" *SPACE attrname 1*(SEP attrval-spec) SEP "-"
   mod-delete-spec      = "delete:" *SPACE attrname *(SEP attrval-spec) SEP "-"
   mod-replace-spec     = "replace:" *SPACE attrname *(SEP attrval-spec) SEP
                          "-"
   SPACE                = <ASCII SP, space>
   SEP                  = (CR LF / LF)
   CR                   = <ASCII CR, carriage return>
   LF                   = <ASCII LF, line feed>
   DIGIT                = <any ASCII decimal digit (60 - 71 decimal) >


   Notes on LDIF Syntax

   1) The version number is optional.  If absent, version 0 is assumed,
   which corresponds to the version of LDIF supported by the University



Good                    IETF ASID Working Group                 [Page 3]


INTERNET-DRAFT        LDAP Data Interchange Format      25 November 1996


   of Michigan ldap-3.3 reference implementation.  For the LDIF format
   described in this document, the version number must be "1".

   2) Any line in an LDIF file may be wrapped by inserting a line
   separator (SEP) and a SPACE.  Any line which begins with a single
   space must be treated as a continuation of the previous line.

   3) Any line which begins with a pound-sign ("#", ASCII 35) is taken
   to be a comment line, and must be ignored when parsing an LDIF file.

   4) Any value which contains characters other than those defined as
   "safe," or begins with a character other than those defined as
   "safe-initval", above, must be base-64 encoded.

   5) Since a filespec is expressed in the native naming context of a
   particular operating system, such file names are inherently non-
   portable.



Differences from the University of Michigan LDAP-3.3 implementation

   The LDIF format described in this document differs from the format
   recognized by the University of Michigan LDAP reference
   implementation in several ways:

   1) The syntax of the attrval-spec has been extended.  The U-M
   implementation only recognized two formats:  "attribute-name:
   attribute-value" and "attribute-name::  base-64-encoded-attribute-
   value".  The new definition now also supports a format "attribute-
   name:< file-spec", which specifies that the value for the attribute
   named "attribute-name" can be found in the file named by "file-spec".

   2) Comment lines are supported in this version.

   3) A file format version number is supported in this version.

   4) Support for describing the LDAPv3 modifyDN operation is included
   in this version.


Examples of LDAP Data Interchange Format


   Example 1: An simple LDAP file with two entries

   dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
   objectclass: top



Good                    IETF ASID Working Group                 [Page 4]


INTERNET-DRAFT        LDAP Data Interchange Format      25 November 1996


   objectclass: person
   objectclass: organizationalPerson
   cn: Barbara Jensen
   cn: Barbara J Jensen
   cn: Babs Jensen
   sn: Jensen
   uid: bjensen
   telephonenumber: +1 408 555 1212
   description: A big sailing fan.

   dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   cn: Bjorn Jensen
   sn: Jensen
   telephonenumber: +1 408 555 1212

   Example 2: A file containing an entry with a folded attribute

   dn:cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
   objectclass:top
   objectclass:person
   objectclass:organizationalPerson
   cn:Barbara Jensen
   cn:Barbara J Jensen
   cn:Babs Jensen
   sn:Jensen
   uid:bjensen
   telephonenumber:+1 408 555 1212
   description:Babs is a big sailing fan, and travels extensively in search of
    perfect sailing conditions.
   title:Product Manager, Rod and Reel Division

   Example 3: A file containing a base-64-encoded value

   dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   cn: Gern Jensen
   cn: Gern O Jensen
   sn: Jensen
   uid: gernj
   telephonenumber: +1 408 555 1212
   description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ
    hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0ICh
    hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu



Good                    IETF ASID Working Group                 [Page 5]


INTERNET-DRAFT        LDAP Data Interchange Format      25 November 1996


   Example 4: A file containing a reference to an external file

   dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   cn: Horatio Jensen
   cn: Horatio N Jensen
   sn: Jensen
   uid: hjensen
   telephonenumber: +1 408 555 1212
   jpegphoto:< /usr/local/directory/photos/hjensen.jpg

   Example 5: A file containing a series of change records and comments

   # Add a new entry
   dn: cn=Fiona Jensen, ou=Marketing, o=Ace Industry, c=US
   changetype: add
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   cn: Fiona Jensen
   sn: Jensen
   uid: fiona
   telephonenumber: +1 408 555 1212
   jpegphoto:< /usr/local/directory/photos/fiona.jpg

   # Delete an existing entry
   dn: cn=Robert Jensen, ou=Marketing, o=Ace Industry, c=US
   changetype: delete

   # Modify an entry's relative distinguished name
   dn: cn=Paul Jensen, ou=Product Development, o=Ace Industry, c=US
   changetype: modrdn
   newrdn: cn=Paula Jensen
   deleteoldrdn: 1

   # Rename and entry and move all of its children to a new location in
   # the directory tree (only implemented by LDAPv3 servers).
   dn: ou=PD Accountants, ou=Product Development, o=Ace Industry, c=US
   changetype: modrdn
   newrdn: ou=Product Development Accountants
   deleteoldrdn: 0
   newsuperior: ou=Accounting, o=Ace Industry, c=US

   # Modify an entry: add an additional value to the postaladdress attribute,
   # completely delete the description attribute, replace the telephonenumber
   # attribute with two values, and delete a specific value from the



Good                    IETF ASID Working Group                 [Page 6]


INTERNET-DRAFT        LDAP Data Interchange Format      25 November 1996


   # facsimiletelephonenumber attribute
   dn: cn=Paula Jensen, ou=Product Development, o=Ace Industry, c=US
   changetype: modify
   add: postaladdress
   postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
   -
   delete: description
   -
   replace: telephonenumber
   telephonenumber: +1 408 555 1234
   telephonenumber: +1 408 555 5678
   -
   delete: facsimiletelephonenumber
   facsimiletelephonenumber: +1 408 555 9876
   -


Security Considerations

   Given typical directory applications, an LDIF file is likely to
   contain sensitive personal data.  Appropriate measures should be
   taken to protect the privacy of those persons whose data is contained
   in an LDIF file.

   Since ":<" directives can cause any external file to be included when
   processing an LDIF file, one should be cautious of accepting LDIF
   files from external sources.  A "trojan" LDIF file could name a file
   with sensitive contents and cause it to be included in a directory
   entry, which a hostile entity could read via LDAP.


Acknowledgments

   The LDAP Interchange Format was developed as part of the University
   of Michigan LDAP reference implementation, and was developed by Tim
   Howes, Mark Smith, and Gordon Good.  It is based in part upon work
   supported by the National Science Foundation under Grant No.  NCR-
   9416667.


References

   [1] Howes, T., Smith, M., "A MIME Content-Type for Directory
   Information", INTERNET-DRAFT draft-ietf-asid-mime-direct-02.txt,
   Netscape Communications Corp., <URL:ftp://ietf.org/internet-
   drafts/draft-ietf-asid-mime-direct-02.txt>

   [2] Crocker,  D.H., "Standard for the Format of ARPA Internet Text



Good                    IETF ASID Working Group                 [Page 7]


INTERNET-DRAFT        LDAP Data Interchange Format      25 November 1996


   Messages", RFC 822, University of Delaware, August 1982,
   <URL:http://ds.internic.net/rfc/rfc822.txt>

   [3] Kille, S., "A String Representation of Distinguished Names", RFC
   1779, ISODE Consortium, March 1995,
   <URL:http://ds.internic.net/rfc/rfc1779.txt>

   [4] Wahl, M., Coulbeck, A., Howes, T., Kille, S., "Lightweight
   Directory Access Protocol: Standard and Pilot Attribute Definitions",
   INTERNET-DRAFT draft-ietf-asid-ldapv3-attributes-03.txt, Critical
   Angle, Inc., ISODE Consortium, Netscape Communications Corp.,
   October, 1996, <URL:ftp://ietf.org/internet-drafts/draft-ietf-asid-
   ldapv3-attributes-03.txt>

   [5] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail
   Extensions) Part One: Mechanisms for Specifying and Describing the
   Format of Internet Message Bodies", section 5.2, "Base64 Content-
   Transfer-Encoding", RFC 1521, Bellcore, Innosoft, December 1993,
   <URL:http://ds.internic.net/rfc/rfc1521.txt>


Author's Address

   Gordon Good
   Netscape Communications Corp.
   501 E. Middlefield Rd.
   Mountain View, CA 94043, USA
   Phone:  +1 415 937-3825
   EMail:  ggood@netscape.com

                This Internet Draft expires May 1st, 1997.




















Good                    IETF ASID Working Group                 [Page 8]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/