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 ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
(US West Coast).
This Internet Draft expires 13 December, 1998.
Abstract
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
environment.
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.
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
ldif-change-record
*(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 =
base64-dn =
rdn =
base64-rdn =
attrval-spec = attribute-description ((":") /
(":" *SPACE value *(*SPACE "\" *SPACE value)) /
("::" *SPACE base64-value
*(*SPACE "\" *SPACE base64-value)) /
(":<" *SPACE url*(*SPACE "\" *SPACE url)))
url = ; (See Note 6, below)
ISSS/WS-DIR June 8, 1998 [Page 4]
INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998
attribute-description =
value = 1*safe-initval *safe
safe =
safe-initval =
base64-value =
changerecord = change-add / change-delete / change-modify /
change-moddn
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-replace-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 =
SEP = (CR LF / LF)
CR =
LF =
DIGIT =
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
included.
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
length.
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:"
specification.
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
back-slash.
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
entries.
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
identification.
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
information.
ISSS/WS-DIR June 8, 1998 [Page 9]
INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998
Agreements
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
value
dn:cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US
objectclass:top
ISSS/WS-DIR June 8, 1998 [Page 11]
INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998
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: 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
description::
V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ
hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0ICh
hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu
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=,o=Airius
objectclass: top
objectclass: organizationalUnit
ou:: 5Za25qWt6YOo
# ou::
ou;lang-ja:: 5Za25qWt6YOo
# ou;lang-ja::
ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
# ou;lang-ja::
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=,ou=,o=Airius
userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: rogasawara
mail: rogasawara@airius.co.jp
givenname;lang-ja:: 44Ot44OJ44OL44O8
# givenname;lang-ja::
sn;lang-ja:: 5bCP56yg5Y6f
# sn;lang-ja::
cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn;lang-ja::
title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
# title;lang-ja::
preferredlanguage: ja
givenname:: 44Ot44OJ44OL44O8
# givenname::
sn:: 5bCP56yg5Y6f
# sn::
cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn::
title:: 5Za25qWt6YOoIOmDqOmVtw==
# title::
givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
# givenname;lang-ja;phonetic::
sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
# sn;lang-ja;phonetic::
cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
# cn;lang-ja;phonetic::
title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
# title;lang-ja;phonetic::
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
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:< 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
total
version 0
agreement-id: op1-to-op2, ver.1
dn:o=F&L,c=DK
mobile:+4533333333\+4544444444
other
tel:+4539450700
fax:+4539450777
dn:2 cn=Tom Finkelstein
mobile:+4512345678
key
objcl:orgPers
sn:Finkdelstein
gn:Tom
tel:+4539450999
822:tfs@fl.dk
dn:2 cn=Per Futtesen
mobile:+4587654321
key
sn:Futtesen
gn:Per
tel:+4539450998
822:tfs@fl.dk
s:L=Frederiksberg C,ST=Copenhagen
mobile:+4520971490
key
objcl:resPers
sn:Andersen
ISSS/WS-DIR June 8, 1998 [Page 15]
INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998
gn:Erik
street:Paludan Mullersvej
num:3
floor:2
floorentity:tv
tel:+4531230490
mobile:+4587654321
key
sn:Petersen
gn:Peter
street:Paludan Mullersvej
num:114
floor:3
tel:+4523456789
Example 8: A simple LDIF file with a few update records sent from a
mobile telephone operator to some central information service
incremental
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
s:L=1815,ST=Copenhagen
changetype:delete
mobile:+4520971490
key
sn:Andersen
gn:Erik
# Update existing entry
replace:
mobile:+4587654321
mobile:+4598765432
-
key
sn:Petersen
gn:Peter
# Add new entry
s:L=Hellerup,ST=Copenhagen
mobile:+4534567890
key
objcl:resPers
sn:Frederiksen
ISSS/WS-DIR June 8, 1998 [Page 16]
INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998
gn:John
street:Grundtvigsvej
num:245
floor:5
floorentity:tv
tel:+4531230490
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
LDAP.
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.
Acknowledgements
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.
References
[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.,
[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,
[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.
[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.,
Author's Address
Erik Andersen
Fischer & Lorenz A/S
Tuborgvej 10
DK-2900 Hellerup
Denmark
Phone: +45 20 97 14 90
EMail: era@fl.dk
This Internet Draft expires 13 December, 1998.
ISSS/WS-DIR June 8, 1998 [Page 18]