As per Relevance of the word interchange, we have this rfc below:
Network Working Group G.
Request for Comments: 2849 iPlanet e-commerce
Category: Standards Track June 2000
The LDAP Data Interchange Format (LDIF) - Technical
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document describes a file format suitable for
directory information or modifications made to directory information
The file format, known as LDIF, for LDAP Data Interchange Format,
typically used to import and export directory information
LDAP-based directory servers, or to describe a set of changes
are to be applied to a directory
Background and Intended
There are a number of situations where a common interchange format
desirable. For example, one might wish to export a copy of
contents of a directory server to a file, move that file to
different machine, and import the contents into a second
server
Additionally, by using a well-defined interchange format,
of data import tools from legacy systems is facilitated. A
simple set of tools written in awk or perl can, for example,
a database of personnel information into an LDIF file. This file
then be imported into a directory server, regardless of the
database representation the target directory server uses
The LDIF format was originally developed and used in the
of Michigan LDAP implementation. The first use of LDIF was
describing directory entries. Later, the format was expanded
allow representation of changes to directory entries
Good Standards Track [Page 1]
RFC 2849 LDAP Data Interchange Format June 2000
Relationship to the application/directory MIME content-type
The application/directory MIME content-type [1] is a
framework and format for conveying directory information, and
independent of any particular directory service. The LDIF format
a simpler format which is perhaps easier to create, and may also
used, as noted, to describe a set of changes to be applied to
directory
The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT
used in this document are to be interpreted as described in [7].
Definition of the LDAP Data Interchange
The LDIF format is used to convey directory information, or
description of a set of changes made to directory entries. An
file consists of a series of records separated by line separators.
record consists of a sequence of lines describing a directory entry
or a sequence of lines describing a set of changes to a
entry. An LDIF file specifies a set of directory entries, or a
of changes to be applied to directory entries, but not both
There is a one-to-one correlation between LDAP operations that
the directory (add, delete, modify, and modrdn), and the types
changerecords described below ("add", "delete", "modify",
"modrdn" or "moddn"). This correspondence is intentional,
permits a straightforward translation from LDIF changerecords
protocol operations
Formal Syntax Definition of
The following definition uses the augmented Backus-Naur
specified in RFC 2234 [2].
ldif-file = ldif-content / ldif-
ldif-content = version-spec 1*(1*SEP ldif-attrval-record
ldif-changes = version-spec 1*(1*SEP ldif-change-record
ldif-attrval-record = dn-spec SEP 1*attrval-
ldif-change-record = dn-spec SEP *control
version-spec = "version:" FILL version-
Good Standards Track [Page 2]
RFC 2849 LDAP Data Interchange Format June 2000
version-number = 1*
; version-number MUST be "1" for
; LDIF format described in this document
dn-spec = "dn:" (FILL distinguishedName /
":" FILL base64-distinguishedName
distinguishedName = SAFE-
; a distinguished name, as defined in [3]
base64-distinguishedName = BASE64-UTF8-
; a distinguishedName which has been base64
; encoded (see note 10, below
rdn = SAFE-
; a relative distinguished name, defined
; component> in [3]
base64-rdn = BASE64-UTF8-
; an rdn which has been base64 encoded (
; note 10, below
control = "control:" FILL ldap-oid ;
0*1(1*SPACE ("true" / "false")) ;
0*1(value-spec) ;
; (See note 9, below
ldap-oid = 1*DIGIT 0*1("." 1*DIGIT
; An LDAPOID, as defined in [4]
attrval-spec = AttributeDescription value-spec
value-spec = ":" ( FILL 0*1(SAFE-STRING) /
":" FILL (BASE64-STRING) /
"<" FILL url
; See notes 7 and 8,
url = Resource Locator
as defined in [6]>
; (See Note 6, below
AttributeDescription = AttributeType [";" options
; Definition taken from [4]
AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
options = option / (option ";" options
Good Standards Track [Page 3]
RFC 2849 LDAP Data Interchange Format June 2000
option = 1*opt-
attr-type-chars = ALPHA / DIGIT / "-"
opt-char = attr-type-
changerecord = "changetype:"
(change-add / change-delete /
change-modify / change-moddn
change-add = "add" SEP 1*attrval-
change-delete = "delete"
change-moddn = ("modrdn" / "moddn")
"newrdn:" ( FILL rdn /
":" FILL base64-rdn)
"deleteoldrdn:" FILL ("0" / "1")
0*1("newsuperior:"
( FILL distinguishedName /
":" FILL base64-distinguishedName) SEP
change-modify = "modify" SEP *mod-
mod-spec = ("add:" / "delete:" / "replace:")
FILL AttributeDescription
*attrval-
"-"
SPACE = %x20
; ASCII SP,
FILL = *
SEP = (CR LF / LF
CR = %x0
; ASCII CR, carriage
LF = %x0
; ASCII LF, line
ALPHA = %x41-5A / %x61-7
; A-Z / a-
DIGIT = %x30-39
; 0-9
Good Standards Track [Page 4]
RFC 2849 LDAP Data Interchange Format June 2000
UTF8-1 = %x80-
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7
; any value <= 127 decimal except NUL, LF
; and
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
%x21-39 / %x3B / %x3D-7
; any value <= 127 except NUL, LF, CR
; SPACE, colon (":", ASCII 58 decimal
; and less-than ("<" , ASCII 60 decimal
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR
UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 /
UTF8-4 / UTF8-5 / UTF8-6
UTF8-STRING = *UTF8-
BASE64-UTF8-STRING = BASE64-
; MUST be the base64 encoding of
; UTF8-
BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
%x61-7
; +, /, 0-9, =, A-Z, and a-
; as specified in [5]
BASE64-STRING = [*(BASE64-CHAR)]
Notes on LDIF
1) For the LDIF format described in this document, the
number MUST be "1". If the version number is absent
implementations MAY choose to interpret the contents as
older LDIF file format, supported by the University
Michigan ldap-3.3 implementation [8].
Good Standards Track [Page 5]
RFC 2849 LDAP Data Interchange Format June 2000
2) Any non-empty line, including comment lines, in an LDIF
MAY be folded by inserting a line separator (SEP) and a SPACE
Folding MUST NOT occur before the first character of the line
In other words, folding a line into two lines, the first
which is empty, is not permitted. Any line that begins with
single space MUST be treated as a continuation of the
(non-empty) line. When joining folded lines, exactly one
character at the beginning of each continued line must
discarded. Implementations SHOULD NOT fold lines in the
of a multi-byte UTF-8 character
3) Any line that begins with a pound-sign ("#", ASCII 35) is
comment line, and MUST be ignored when parsing an LDIF file
4) Any dn or rdn that contains characters other than
defined as "SAFE-UTF8-CHAR", or begins with a character
than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST
base-64 encoded. Other values MAY be base-64 encoded.
value that contains characters other than those defined
"SAFE-CHAR", or begins with a character other than
defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded
Other values MAY be base-64 encoded
5) When a zero-length attribute value is to be included
in an LDIF file, it MUST be represented
AttributeDescription ":" FILL SEP. For example, "seeAlso:"
followed by a newline represents a zero-length "seeAlso
attribute value. It is also permissible for the
referred to by a URL to be of zero length
6) When a URL is specified in an attrval-spec, the
conventions apply
a) Implementations SHOULD support the file:// URL format.
contents of the referenced file are to be included
in the interpreted output of the LDIF file
b) Implementations MAY support other URL formats.
semantics associated with each supported URL will
documented in an associated Applicability Statement
7) Distinguished names, relative distinguished names,
attribute values of DirectoryString syntax MUST be valid UTF-8
strings. Implementations that read LDIF MAY interpret
in which these entities are stored in some other character
encoding, but implementations MUST NOT generate LDIF
which does not contain valid UTF-8 data
Good Standards Track [Page 6]
RFC 2849 LDAP Data Interchange Format June 2000
8) Values or distinguished names that end with SPACE SHOULD
base-64 encoded
9) When controls are included in an LDIF file,
MAY choose to ignore some or all of them. This may
necessary if the changes described in the LDIF file are
sent on an LDAPv2 connection (LDAPv2 does not
controls), or the particular controls are not supported by
remote server. If the criticality of a control is "true",
the implementation MUST either include the control, or
NOT send the operation to a remote server
10) When an attrval-spec, distinguishedName, or rdn is base64-
encoded, the encoding rules specified in [5] are used with
following exceptions: a) The requirement that base64
streams must be represented as lines of no more than 76
characters is removed. Lines in LDIF files may only be
according to the folding rules described in note 2, above. b
Base64 strings in [5] may contain characters other than
defined in BASE64-CHAR, and are ignored. LDIF does not
any extraneous characters, other than those used for
folding
Examples of LDAP Data Interchange
Example 1: An simple LDAP file with two
version: 1
dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=
objectclass:
objectclass:
objectclass:
cn: Barbara
cn: Barbara J
cn: Babs
sn:
uid:
telephonenumber: +1 408 555 1212
description: A big sailing fan
dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=
objectclass:
objectclass:
objectclass:
cn: Bjorn
sn:
telephonenumber: +1 408 555 1212
Good Standards Track [Page 7]
RFC 2849 LDAP Data Interchange Format June 2000
Example 2: A file containing an entry with a folded attribute
version: 1
dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=
objectclass:
objectclass:
objectclass:
cn:Barbara
cn:Barbara J
cn:Babs
sn:
uid:
telephonenumber:+1 408 555 1212
description:Babs is a big sailing fan, and travels extensively in
rch of perfect sailing conditions
title:Product Manager, Rod and Reel
Example 3: A file containing a base-64-encoded
version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=
objectclass:
objectclass:
objectclass:
cn: Gern
cn: Gern O
sn:
uid:
telephonenumber: +1 408 555 1212
description:: V2
IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2
VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2
b3V0IG1
Example 4: A file containing an entries with UTF-8-encoded
values, including language tags. Comments indicate the
of UTF-8-encoded attributes and distinguished names
version: 1
dn:: b3U95Za25qWt6YOoLG89
# dn:: ou=,o=
objectclass:
objectclass:
ou:: 5Za25qWt6
# ou::
ou;lang-ja:: 5Za25qWt6
# ou;lang-ja::
ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G
Good Standards Track [Page 8]
RFC 2849 LDAP Data Interchange Format June 2000
# ou;lang-ja:: representation
ou;lang-en:
description: Japanese
dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89
# dn:: uid=,ou=,o=
userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM
objectclass:
objectclass:
objectclass:
objectclass:
uid:
mail: rogasawara@airius.co.
givenname;lang-ja:: 44Ot44OJ44OL44O
# givenname;lang-ja::
sn;lang-ja:: 5bCP56yg5Y6
# sn;lang-ja::
cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn;lang-ja::
title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
# title;lang-ja::
preferredlanguage:
givenname:: 44Ot44OJ44OL44O
# givenname::
sn:: 5bCP56yg5Y6
# sn::
cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn::
title:: 5Za25qWt6YOoIOmDqOmVtw==
# title::
givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O
# givenname;lang-ja;phonetic::
representation_kana
sn;lang-ja;phonetic:: 44GK44GM44GV44KP44
# sn;lang-ja;phonetic:: representation_kana
cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
# cn;lang-ja;phonetic:: representation_kana
title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
# title;lang-ja;phonetic::
# representation_kana
givenname;lang-en:
sn;lang-en:
cn;lang-en: Rodney
title;lang-en: Sales,
Good Standards Track [Page 9]
RFC 2849 LDAP Data Interchange Format June 2000
Example 5: A file containing a reference to an external
version: 1
dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=
objectclass:
objectclass:
objectclass:
cn: Horatio
cn: Horatio N
sn:
uid:
telephonenumber: +1 408 555 1212
jpegphoto:< file:///usr/local/directory/photos/hjensen.
Example 6: A file containing a series of change records and
version: 1
# Add a new
dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=
changetype:
objectclass:
objectclass:
objectclass:
cn: Fiona
sn:
uid:
telephonenumber: +1 408 555 1212
jpegphoto:< file:///usr/local/directory/photos/fiona.
# Delete an existing
dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=
changetype:
# Modify an entry's relative distinguished
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=
changetype:
newrdn: cn=Paula
deleteoldrdn: 1
# Rename an entry and move all of its children to a new location
# the directory tree (only implemented by LDAPv3 servers).
dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=
changetype:
newrdn: ou=Product Development
deleteoldrdn: 0
newsuperior: ou=Accounting, dc=airius, dc=
Good Standards Track [Page 10]
RFC 2849 LDAP Data Interchange Format June 2000
# Modify an entry: add an additional value to the
# attribute, completely delete the description attribute,
# the telephonenumber attribute with two values, and delete a
# value from the facsimiletelephonenumber
dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=
changetype:
add:
postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
delete:
replace:
telephonenumber: +1 408 555 1234
telephonenumber: +1 408 555 5678
delete:
facsimiletelephonenumber: +1 408 555 9876
# Modify an entry: replace the postaladdress attribute with an
# set of values (which will cause the attribute to be removed),
# delete the entire description attribute. Note that the first
# always succeed, while the second will only succeed if at
# one value for the description attribute is present
dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=
changetype:
replace:
delete:
Example 7: An LDIF file containing a change record with a
version: 1
# Delete an entry. The operation will attach the LDAPv
# Tree Delete Control defined in [9]. The
# field is "true" and the controlValue field
# absent, as required by [9].
dn: ou=Product Development, dc=airius, dc=
control: 1.2.840.113556.1.4.805
changetype:
Good Standards Track [Page 11]
RFC 2849 LDAP Data Interchange Format June 2000
Security
Given typical directory applications, an LDIF file is likely
contain sensitive personal data. Appropriate measures should
taken to protect the privacy of those persons whose data is
in an LDIF file
Since ":<" directives can cause external content to be included
processing an LDIF file, one should be cautious of accepting
files from external sources. A "trojan" LDIF file could name a
with sensitive contents and cause it to be included in a
entry, which a hostile entity could read via LDAP
LDIF does not provide any method for carrying
information with an LDIF file. Users of LDIF files must take care
verify the integrity of an LDIF file received from an
source
The LDAP Interchange Format was developed as part of the
of Michigan LDAP reference implementation, and was developed by
Howes, Mark Smith, and Gordon Good. It is based in part upon
supported by the National Science Foundation under Grant No. NCR
9416667.
Members of the IETF LDAP Extensions Working group provided
helpful suggestions. In particular, Hallvard B. Furuseth of
University of Oslo made many significant contributions to
document, including a thorough review and rewrite of the BNF
[1] Howes, T. and M. Smith, "A MIME Content-Type for
Information", RFC 2425, September 1998.
[2] Crocker, D., and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[3] Wahl, M., Kille, S. and T. Howes, "A String Representation
Distinguished Names", RFC 2253, December 1997.
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Protocol (v3)", RFC 2251, July 1997.
[5] Freed, N. and N. Borenstein, "Multipurpose Internet
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
Good Standards Track [Page 12]
RFC 2849 LDAP Data Interchange Format June 2000
[6] Berners-Lee, T., Masinter, L. and M. McCahill, "
Resource Locators (URL)", RFC 1738, December 1994.
[7] Bradner, S., "Key Words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[8] The SLAPD and SLURPD Administrators Guide. University
Michigan, April 1996.
http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html
[9] M. P. Armijo, "Tree Delete Control", Work in Progress
Author's
Gordon
iPlanet e-commerce
150 Network
Mailstop USCA17-201
Santa Clara, CA 95054,
Phone: +1 408 276 4351
EMail: ggood@netscape.
Good Standards Track [Page 13]
RFC 2849 LDAP Data Interchange Format June 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Good Standards Track [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
