Internet DRAFT - draft-andersen-isss-ws-dir-ldifext


Extended LDAP Data Interchange Format (LDIFext)          CEN/ISSS/WS-DIR
INTERNET-DRAFT                                     Editor: Erik Andersen
                                                    Fischer & Lorenz A/S
                                                            8 June, 1998

           The Extended LDAP Data Interchange Format (LDIFext)
                         Technical Specification
            Filename: draft-andersen-isss-ws-dir-ldifext-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 view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on (Africa),
   (Northern Europe), (Southern Europe),
   (Pacific Rim), (US East Coast), or
   (US West Coast).

   This Internet Draft expires 13 December, 1998.


   This document describes a file format known as Extended LDAP Data
   Interchange Format (LDIFext) that builds on the LDAP Data Interchange
   Format (LDIF). LDIFext is backward compatible with LDIF. Based on the
   LDIFext specification it is possible to build either a basic LDIF
   file or an LDIFext file.  LDIFext is in particular applicable in
   situation where several participating systems are masters of pieces
   of information about the same object and where the participating
   systems do not necessarily use the same name space. LDIFext also
   allows for more efficient bulk transfer.

ISSS/WS-DIR                    June 8, 1998                    [Page 1]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

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. LDIFext further
   extends the LDAP capabilities by providing means for more efficient
   transfer of large amount of data in a heterogeneous, multi-master

   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

   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.

   The LDIFext is a multi-master synchronization format. In contrast to
   basic LDIF, it does not assume that a single system is the master of
   all the information about a given object, but that different systems
   maintain their own part of this information. The purpose of LDIFext
   is to allow such systems to synchronize with each other resulting in
   entries that potentially have both master and shadowing information.

   In contrast to basic LDIF, LDIFext does not assume that participating
   systems share a common name space. It can be used to synchronize
   systems having different naming structures.

   The LDIFext specification allows an implementation to operate in
   either LDIF mode, where files are generated according to the
   specifications given in [10]; or in LDIFext mode utilizing the added
   capabilities of LDIFext.

   While the LDIFext is primarily developed with synchronization of
   LDAP/X.500 servers in mind, it can also be used for synchronization
   among directories and/or databases of different technologies.

   Although the LDIFext specification relates to LDAP/X.500 concepts,
   the way such concepts have been applied should make it easy to map
   them to other types of directories, e.g. to private mail directories,
   and to databases.

ISSS/WS-DIR                    June 8, 1998                    [Page 2]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

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/LDIFext, for conveying directory information.
   The LDIF/LDIFext 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.

   The key words "MUST", "MAY", and "SHOULD" used in this document are
   to be interpreted as described in [7].

Definition of the Extended LDAP Data Interchange Format

   The LDIF/LDIFext format is used to convey directory information, or a
   description of a set of changes made to directory entries.  An
   LDIF/LDIFext file consists of a series of records separated by at
   least two line separators.  A record consists of a sequence of lines
   separated by a single line separator. A record describes a directory
   entry or a set of changes to a single directory entry.  An
   LDIF/LDIFext file specifies a set of directory entries, or a set of
   changes to be applied to directory entries, but not both.

   There is a one-to-one correlation between LDAP operations that modify
   the directory (add, delete, modify, and modrdn), and the types of
   changerecords described below ("add", "delete", "modify", and
   "modrdn" or "moddn").  This correspondence is intentional, and
   permits a straightforward translation from LDIF changerecords to
   protocol operations.

ISSS/WS-DIR                    June 8, 1998                    [Page 3]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

Formal Syntax Definition of LDIF

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

  ldif-file            = ldif-content / ldif-changes
  ldif-content         = ["total" 1*SEP] heading ldif-attrval-record
                         *(1*SEP ldif-attrval-record)
  ldif-changes         = ["incremental" 1*SEP] heading
                         *(1*SEP ldif-change-record)
  heading              = 0,1*(version-spec 1*SEP)
                         ["agreement-id:" *SPACE agreement-id 1*SEP]
                         [charset: *SPACE charset-name 1*SEP]
  agreement-id         = 1*safe-initval
  charset-name         = a character set name, as registered
                         with IANA [9]
  ldif-attrval-record  = dn-spec SEP 1*(attrval-spec SEP)
                         ["key" SEP 1*(attrval-spec SEP)]
  ldif-change-record   = dn-spec SEP 1*(changerecord SEP)
                         ["key" SEP 1*(attrval-spec SEP)]

  version-spec         = "version:" *SPACE version-number
  version-number       = 1*DIGIT ; version-number MUST be "1" for the
                                 ; LDIFext format described in this
                                 ; document if operating in LDIF mode.

  dn-spec              = ("dn:" *SPACE dn) /
                         ("dn::" *SPACE base64-dn) /
                         ("dn:" *SPACE 1*DIGIT rdn
                         *(("," / ";") *SPACE rdn)) /
                         ("dn::" *SPACE 1*DIGIT base64-rdn
                         *(("," / ";") *SPACE base64-rdn )) /
                         ("s:" [*SPACE dn]) / ("s::" *SPACE base64-dn)
  dn                   = <a distinguished name, as defined in
                         RFC 1779 [3]>
  base64-dn            = <a dn which has been base-64 encoded, as
                         defined in RFC 1521 [5]>
  rdn                  = <a relative distinguished name, as defined in
                         RFC 1779 [3]>
  base64-rdn           = <an rdn which has been base-64 encoded, as
                         defined in RFC 1521 [5]>

  attrval-spec         = attribute-description ((":") /
                         (":" *SPACE value *(*SPACE "\" *SPACE value)) /
                         ("::" *SPACE base64-value
                         *(*SPACE "\" *SPACE base64-value)) /
                         (":<" *SPACE url*(*SPACE "\" *SPACE url)))
  url                  = <a Uniform Resource Locator, as defined in
                         [19]>  ; (See Note 6, below)

ISSS/WS-DIR                    June 8, 1998                    [Page 4]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

  attribute-description = <an attribute description, as defined in [4].
                         An attribute description MAY NOT contain a
                         colon ":">
  value                = 1*safe-initval *safe
  safe                 = <any value except CR or LF>
  safe-initval         = <any value except CR, LF, colon (":", ASCII 58
                         decimal), SPACE, and less-than ("<" , ASCII 60
  base64-value         = <base-64-encoded value, as defined in
                         RFC 1521 [5]>
  changerecord         = change-add / change-delete / change-modify /
  change-add           = ["changetype:" *SPACE "add" SEP] attrval-spec
                         *(SEP attrval-spec)
  change-delete        = "changetype:" *SPACE "delete"
  change-moddn         = "changetype:" *SPACE ("modrdn" / "moddn") SEP
                         ("newrdn:" *SPACE rdn /
                         "newrdn::" *SPACE base-64-rdn) SEP
                         "deleteoldrdn:" *SPACE ("0" / "1")
                         0,1*(SEP (("newsuperior:" *SPACE dn) /
                         ("newsuperior:: *SPACE base-64-dn)))
  change-modify        = "changetype:" *SPACE "modify" 1*(SEP mod-spec)
  mod-spec             = mod-add-spec / mod-delete-spec /
  mod-add-spec         = "add:" *(*SPACE attribute-description)
                         1*(SEP attrval-spec) SEP "-"
  mod-delete-spec      = "delete:" *(*SPACE attribute-description)
                         *(SEP attrval-spec) SEP "-"
  mod-replace-spec     = "replace:" *(*SPACE attribute-description)
                         *(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 LDIFext Syntax

   1) All fields in the in the above Backus-Naur notation that are
   mandatory are mandatory in both LDIF and LDIFext mode. Some of the
   optional fields in the notation are mandatory in LDIF mode, while
   other such fields are mandatory in LDIFext mode

   2) LDIFext mode is signalled by including the agreement-id
   specification. If agreement-id is not included, LDIF mode MUST be
   used. If the agreement-id is included, LDIFext mode MUST be used.

   3) ldif-content records and ldif-changes records cannot be included

ISSS/WS-DIR                    June 8, 1998                    [Page 5]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   in the same LDIF/LDIFext file. In LDIFext mode, a file MUST have the
   "total" or the "incremental" specification, as appropriate, in the
   heading section. In LDIF mode, such a specification MUST NOT be

   4) In LDIF mode an ldif-content record is assumed to represent a
   complete entry at the sender side to be copied as a complete entry
   into the recipient system. In LDIFext mode this assumption is
   relaxed. An ldif-content record may only represent part of an entry
   at the sender's side. It may only contain the information relevant
   for the recipient system. Also at the recipient system, there may
   already be a corresponding entry representing the same object. The
   ldif-content record may then be merged with such an existing record.

   5) In situations where a recipient system merges ldif-content
   records, possibly from several systems, with own information, it MUST
   tag each piece of information with agreement id. In an X.500
   environment, tagging can be done using the contexts feature.

   6) The version number is optional.  If absent, version 0 is assumed.
   This corresponds to either using LDIF mode according to the version
   of LDIF supported by the University of Michigan ldap-3.3 reference
   implementation [8]; or to using LDIFext mode according to the
   specification in this document.  For use of LDIF mode as specified in
   this document, the version number MUST be "1".

   7) Any line in an LDIF/LDIFext file MAY be wrapped by inserting a
   line separator (SEP) and a SPACE.  Any line that begins with a
   single space MUST be treated as a continuation of the previous line.
   The LDIFext specification does not put any restriction on the line

   8) Any line which begins with a pound-sign ("#", ASCII 35) is a
   comment line, and MUST be ignored when parsing an LDIF/LDIFext file.

   9) In LDIF mode the UTF-8 character set MUST be used and the
   charset-name in the heading specification MUST NOT be included. In
   LDIFext mode the UTF-8 character set SHOULD be used. However, in
   closed communities as part an agreement, other named character sets
   can be specified to be used for all attribute values in attributes
   and RDNs. As an example, ISO_8859-1:1987 could be specified to be
   used within many European countries. This will allow special national
   characters to be encoded in a single octet, which could be of
   significance when millions of records are to be transferred.

   10) Any dn or 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.  Other
   values MAY be base-64 encoded.

ISSS/WS-DIR                    June 8, 1998                    [Page 6]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   11) It is possible in the dn-spec field to use either the "dn:" or
   the "s:" specification. The "s:" specification MUST NOT be used in
   LDIF mode. In LDIF mode, the "dn:" specification MUST include a
   complete distinguished name. In LDIFext mode it is possible to use a
   truncated form where some implied RDNs are not included.

   12) The "dn:" specification SHOULD only be used in LDIFext mode if
   the complete distinguished name is understood by both parties to
   denote the same object. As an example, the name of a reasonable
   seized company is assumed to be unique within a certain geographical
   area. This specification MUST be used in a directory environment if
   the record refers to an entry that has subordinate entries.

   13) An abbreviated form of distinguished name MAY be used in LDIFext
   in addition to the truncated form. This abbreviated form MUST NOT be
   used unless the preceding record has a "dn:" specification. The first
   item in the abbreviated specification is a level indication telling
   how large a part of the distinguished name of the preceding record
   that is inherited. This item MUST include the defaulted part of the
   distinguished name. As an example, if the country name is implied,
   the country name component is still counted. The remaining items are
   one or more RDNs that when prefixed the inherited part comprise a
   complete distinguished name.

   14) The "s:" specification can be used if it is not possible to
   establish distinguished names that are globally recognized. It MUST
   NOT be used in LDIF mode. In a directory environment it SHOULD
   include the distinguished name of the superior entry. This field can
   then only be used for leaf entries, e.g. residential persons. When
   this field is present, it is assumed that the recipient from other
   included information, e.g. name, telephone number, postal address,
   etc., can determine the entity of a possible corresponding local
   entry. If an existing entry is not found, the receiver can generate
   an RDN based on local algorithms to produce a complete distinguished
   name for its own use.

   15) In a non-directory environment, the "s:" specification MAY be
   empty. It is outside the scope of this specification how a directory
   system handles an LDIFext file from a non-directory system having an
   empty "s:" specification. In a mixed environment with both directory
   systems and non-directory systems a non-system SHOULD generate a
   valid "s:" specification.

   16) If there is no "s:" or "dn:" specification, an "s:" specification
   field is implied having the same value as in the previous record. The
   absence of both the "dn:" and the "s:" specification is only allowed
   if the previous record had an explicit or implicit "s:"

ISSS/WS-DIR                    June 8, 1998                    [Page 7]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   17) In LDIF mode, the attrval-spec MUST NOT hold several attribute
   values. In LDIFext mode, the attrval-spec MAY hold several attribute
   values separated by back-slashes ("\"). In LDIFext mode, any
   back-slash within an attribute value MUST be replace by a double

   18) To represent a zero-length attribute value, use an attrval-spec
   of "attribute-description:".  For example, "seeAlso:" represents a
   zero-length "seeAlso" attribute value.

   19) When a URL is specified in an attrval-spec, the following
   conventions apply:
      a) Implementations SHOULD support the file:// URL format.  The
         contents of the referenced file are to be included verbatim
         in the interpreted output of the LDIF file.
      b) Implementations MAY support other URL formats.  The semantics
         associated with each supported URL will be documented in
         an associated Applicability Statement.

   20) While it is permissible for character values larger than 126 to
   be contained in an attribute value, implementations SHOULD base-64
   encode any value which contains such characters when generating an
   LDIF/LDIFext file. However, implementations MAY leave the values
   unencoded.  This relaxation is designed to allow editing of
   LDIF/LDIFext files containing, for example, Latin-1 content, with
   existing tools.

   21) In LDIFext mode, some of the information in a record is owned by
   the sender, i.e. the sender is master for that information. This
   information is located just after the "dn:" or the "s:"
   specification, and it may be the only information in a record.
   Additional information (see below) may be supplied in a record to
   allow the recipient to uniquely identify a corresponding local entry,
   if any.

   22) The optional "key" specification starts a block of information,
   which is not to be considered master information owned by the sender.
   Such information is intended for identifying a possible already
   existing entry at the recipient. As an example, a mobile operator may
   supply the fixed telephone number in a record, although the fixed
   telephone is subscribed from another operator. If there is
   information in these blocks that is currently not present at the
   recipient, it a local option for the recipient whether to store it or
   dispose of it in any other way. The "key" specification MUST NOT be
   used in LDIF mode.

   23) In the change-add field the "changetype:" specification is
   optional. However, it MUST be present in LDIF mode.

ISSS/WS-DIR                    June 8, 1998                    [Page 8]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   24) When doing total update in LDIFext mode:

      a) All information related to the agreement SHOULD be purged and
      replaced by the information in the current transfer. This does not
      necessarily mean that current entries are completely deleted
      during the first part of this process, as there may be local
      information or information from other agreements within those

      b) Information following the "key" specification is only intended
      for entry identification. Such information SHOULD be included if
      the "s:" specification is used.

      c) If the object class attribute is not included for a record, the
      value(s) is the same as for the previous record.

   25) When doing incremental update in LDIFext mode:

      a) Only information owned by the sender can be changed. Additional
      information may be transmitted to allow identification of the
      entries to be changed. If the "dn:" specification is used, only
      the distinguished name SHOULD be supplied in addition to change or
      delete specifications to ensure compatibility with earlier
      versions. For records starting with an implicit or explicit "s:"
      specification, additional information MUST be supplied for entry

      b) Records without any "changetype" specification are to be
      considered as new entries to be added. For records starting with
      an implicit or explicit "s:" specification, a "key" part MUST be
      supplied for entry identification.

      c) A record with "changetype" equal to "delete" only applies to
      the part of the entry holding information owned by the sender
      according to the current agreement. Records starting with an
      implicit or explicit "s:" specification MUST besides the delete
      specification have a "key" part for entry identification.

      d) A record with "changetype" equal to "modify" and which starts
      with an implicit or explicit "s:" specification MUST besides the
      change specifications have a "key" part for entry identification.

   26) In some cases it may not be possible to denote some pieces of
   information belonging to anyone. As an example, object class
   specification, postal address, etc. may be considered general
   information maintained independently by each system. If such
   information is not consistent across systems, correlation may not be
   possible. Such general information should be in the "key" block. It
   is recommended to establish an authoritative source for such

ISSS/WS-DIR                    June 8, 1998                    [Page 9]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998


   An agreement ID MUST be in the first part of an LDIFext file. This
   agreement specification is used to give a unique identification of
   the scope of an information exchange. The concept of agreement is not
   relevant in LDIF mode although some implicit understanding is
   probably required. An agreement can include such things as:

   1) What information has to be transferred and possibly kept updated
   by the sender.

   2) The attribute types and object classes that are part of the
   transport including what textual representations that are going to be
   used. In case of high-volume exchanges, the two parties can agree on
   an abbreviated form of textual representation. As an example "tel"
   could be an abbreviated form of TelephoneNumber. Textual
   representations of attribute types MUST be unique within an
   agreement. Likewise for textual representation of object classes.

   3) An understanding of what information is necessary to transfer in
   the "key" block to ensure the correlation process, i.e. locating an
   existing entry, if any, at the recipient.

   4) How much of a distinguished name that needs to be transferred. As
   an example, the country name could be implied.

   5) Maximum line length. If a file is to be displayed on a screen, it
   may be useful to limit the line length accordingly. For high volume
   bulk transfer, it saves overhead to have unlimited line length.

   6) How much information that is needed for the objectClass attribute.
   If the object class for the entry information is, say,
   residentialPerson, it may not be necessary also to specify the super-
   classes person and top. They could be implied. Also auxiliary object
   classes can be implied. It MUST be completely understood by both
   parties what set of object classes is behind a single object class
   textual specification.

   7) Agreement on not to use spaces where they are optional.

   8) Agreement not to use any unnecessary SEPs, i.e. consider the 1*SEP
   specification equals to just SEP.

   9) Agreement on only using LF for SEP.

   10) Update frequency.

   Establishment of an agreement is an off-line activity not directly
   reflected in the protocol.

ISSS/WS-DIR                    June 8, 1998                    [Page 10]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

Differences from Version 1 of LDIF

   1) It is possible in a header besides giving version information to
   indicate whether an LDIF file is a complete transfer of all
   information or whether is an updating file

   2) It is possible in the header to indicate an agreement ID

   3) It is possible for each record to include information that is not
   intended for storage by the receiver, but is aiding the recipient in
   identifying a particular entry.

   4) It is possible to only transfer the distinguished name of the
   superior of an entry in case the receiver is expected to generate the
   complete distinguished following local algorithms.

   5) Several values for a multi-valued attribute can be on the same,
   possibly folded line. The separator between values is a back-slash

Example 1: An simple LDIF file with two entries

   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: 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: An LDIF file containing an entry with a folded attribute

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

ISSS/WS-DIR                    June 8, 1998                    [Page 11]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   cn:Barbara Jensen
   cn:Barbara J Jensen
   cn:Babs Jensen
   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: An LDIF 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


Example 4: A file containing an entries with UTF-8-encoded attribute
values, including language tags.  Comments indicate the contents
of UTF-8-encoded attributes and distinguished names.

   dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
   # dn:: ou=<JapaneseOU>,o=Airius
   objectclass: top
   objectclass: organizationalUnit
   ou:: 5Za25qWt6YOo
   # ou:: <JapaneseOU>
   ou;lang-ja:: 5Za25qWt6YOo
   # ou;lang-ja:: <JapaneseOU>
   ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
   # ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
   ou;lang-en: Sales
   description: Japanese office

ISSS/WS-DIR                    June 8, 1998                    [Page 12]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
   # dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
   userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   objectclass: inetOrgPerson
   uid: rogasawara
   givenname;lang-ja:: 44Ot44OJ44OL44O8
   # givenname;lang-ja:: <JapaneseGivenname>
   sn;lang-ja:: 5bCP56yg5Y6f
   # sn;lang-ja:: <JapaneseSn>
   cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
   # cn;lang-ja:: <JapaneseCn>
   title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
   # title;lang-ja:: <JapaneseTitle>
   preferredlanguage: ja
   givenname:: 44Ot44OJ44OL44O8
   # givenname:: <JapaneseGivenname>
   sn:: 5bCP56yg5Y6f
   # sn:: <JapaneseSn>
   cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
   # cn:: <JapaneseCn>
   title:: 5Za25qWt6YOoIOmDqOmVtw==
   # title:: <JapaneseTitle>
   givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
   # givenname;lang-ja;phonetic::
   sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
   # sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
   cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
   # cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
   title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
   # title;lang-ja;phonetic:: <JapaneseTitle_in_phonetic_representation_kana>
   givenname;lang-en: Rodney
   sn;lang-en: Ogasawara
   cn;lang-en: Rodney Ogasawara
   title;lang-en: Sales, Director

Example 5: An LDIF 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

ISSS/WS-DIR                    June 8, 1998                    [Page 13]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   cn: Horatio Jensen
   cn: Horatio N Jensen
   sn: Jensen
   uid: hjensen
   telephonenumber: +1 408 555 1212
   jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg

Example 6: An LDIF file containing a series of change records and

   # 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:< file:///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 an 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
   # facsimiletelephonenumber attribute
   dn: cn=Paula Jensen, ou=Product Development, o=Ace Industry, c=US
   changetype: modify

ISSS/WS-DIR                    June 8, 1998                    [Page 14]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   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

Example 7: A simple LDIFext file with a few records sent from a mobile
telephone operator to some central information service

   version 0
   agreement-id: op1-to-op2, ver.1


   dn:2 cn=Tom Finkelstein

   dn:2 cn=Per Futtesen

   s:L=Frederiksberg C,ST=Copenhagen

ISSS/WS-DIR                    June 8, 1998                    [Page 15]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   street:Paludan Mullersvej

   street:Paludan Mullersvej

Example 8: A simple LDIF file with a few update records sent from a
mobile telephone operator to some central information service

   version 0
   agreement-id: op1-to-op2, ver.1

   # Delete an entry. The mobile number and the name is considered
   # sufficient information for locating the right entry

   # Update existing entry

   # Add new entry

ISSS/WS-DIR                    June 8, 1998                    [Page 16]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998


Security Considerations

   Given typical directory applications, an LDIF/LDIFext 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/LDIFext file.

   Since ":<" directives can cause external content to be included when
   processing an LDIF/LDIFext file, one should be cautious of accepting
   LDIF/LDIFext files from external sources.  A "trojan" LDIF/LDIFext
   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

   LDIF/LDIFext does not provide any method for carrying authentication
   information with an LDIF/LDIFext file.  Users of LDIF/LDIFext files
   must take care to verify the integrity of an LDIF file received from
   an external source.


   The extensions to LDAP Data Interchange Format presented in this
   document has been considered too extensive to reflect a new version
   of LDIF. As suggested by the LDIF editor, Gordon Good, Netscape
   Communications Corp., the extensions are issued as a separate
   Internet Draft to be progressed in parallel with the basic LDIF
   specifications. This document has benefited greatly from the work
   done on LDIF and has re-used considerable amount of the text.


   [1]  Howes, T., Smith, M., "A MIME Content-Type for Directory Infor-
        mation", INTERNET-DRAFT draft-ietf-asid-mime-direct-06.txt,
        Netscape Communications Corp., <URL:

   [2]  Crocker,  D.H., "Standard for the Format of ARPA Internet Text
        Messages", RFC 822, University of Delaware, August 1982,

ISSS/WS-DIR                    June 8, 1998                    [Page 17]

INTERNET-DRAFT     Extended LDAP Data Interchange Format     9 June 1998

   [3]  Kille, S., "A String Representation of Distinguished Names", RFC
        1779, ISODE Consortium, March 1995,

   [4]  Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access
        Protocol (v3)", RFC 2251, Critical Angle, Inc., ISODE Consor-
        tium, Netscape Communications Corp., July, 1997,

   [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:>

   [6]  T. Berners-Lee,  L.  Masinter, M. McCahill, "Uniform Resource
        Locators (URL)", CERN, Xerox Corporation, University of Min-
        nesota, Request for Comment (RFC) 1738, December 1994,

   [7]  S. Bradner, "Key Words for use in RFCs to Indicate Requirement
        Levels", Harvard University, RFC 2119, March 1997,

   [8]  The SLAPD and SLURPD Administrators Guide.  University of Michi-
        gan, April 1996.  <URL:>

   [9]  Internet Assigned Numbers Authority, "CHARACTER SETS",

   [10] Good, G, " The LDAP Data Interchange Format (LDIF) - Technical
        Specification", INTERNET-DRAFT draft-good-ldap-ldif-00.txt,
        Netscape Communications Corp., <URL:

Author's Address

        Erik Andersen
        Fischer & Lorenz A/S
        Tuborgvej 10
        DK-2900 Hellerup
        Phone:  +45 20 97 14 90

                 This Internet Draft expires 13 December, 1998.

ISSS/WS-DIR                    June 8, 1998                    [Page 18]