mirror of
https://github.com/samba-team/samba.git
synced 2024-12-23 17:34:34 +03:00
e8eee542d3
(This used to be commit d7751e3181
)
788 lines
25 KiB
Plaintext
788 lines
25 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group G. Good
|
||
Request for Comments: 2849 iPlanet e-commerce Solutions
|
||
Category: Standards Track June 2000
|
||
|
||
|
||
The LDAP Data Interchange Format (LDIF) - Technical Specification
|
||
|
||
Status of this Memo
|
||
|
||
This document specifies an Internet standards track protocol for the
|
||
Internet community, and requests discussion and suggestions for
|
||
improvements. Please refer to the current edition of the "Internet
|
||
Official Protocol Standards" (STD 1) for the standardization state
|
||
and status of this protocol. Distribution of this memo is unlimited.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||
|
||
Abstract
|
||
|
||
This document describes a file format suitable for describing
|
||
directory information or 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, or to describe a set of changes which
|
||
are to be applied to a directory.
|
||
|
||
Background and Intended Usage
|
||
|
||
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. This file can
|
||
then be imported into a directory server, regardless of the internal
|
||
database representation the target directory server uses.
|
||
|
||
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.
|
||
|
||
|
||
|
||
|
||
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 general
|
||
framework and format for conveying directory information, and is
|
||
independent of any particular directory service. The LDIF format is
|
||
a simpler format which is perhaps easier to create, and may also be
|
||
used, as noted, to describe a set of changes to be applied to a
|
||
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 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 line separators. A
|
||
record consists of a sequence of lines describing a directory entry,
|
||
or a sequence of lines describing a set of changes to a directory
|
||
entry. An LDIF 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.
|
||
|
||
Formal Syntax Definition of LDIF
|
||
|
||
The following definition uses the augmented Backus-Naur Form
|
||
specified in RFC 2234 [2].
|
||
|
||
ldif-file = ldif-content / ldif-changes
|
||
|
||
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-spec
|
||
|
||
ldif-change-record = dn-spec SEP *control changerecord
|
||
|
||
version-spec = "version:" FILL version-number
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Good Standards Track [Page 2]
|
||
|
||
RFC 2849 LDAP Data Interchange Format June 2000
|
||
|
||
|
||
version-number = 1*DIGIT
|
||
; version-number MUST be "1" for the
|
||
; LDIF format described in this document.
|
||
|
||
dn-spec = "dn:" (FILL distinguishedName /
|
||
":" FILL base64-distinguishedName)
|
||
|
||
distinguishedName = SAFE-STRING
|
||
; a distinguished name, as defined in [3]
|
||
|
||
base64-distinguishedName = BASE64-UTF8-STRING
|
||
; a distinguishedName which has been base64
|
||
; encoded (see note 10, below)
|
||
|
||
rdn = SAFE-STRING
|
||
; a relative distinguished name, defined as
|
||
; <name-component> in [3]
|
||
|
||
base64-rdn = BASE64-UTF8-STRING
|
||
; an rdn which has been base64 encoded (see
|
||
; note 10, below)
|
||
|
||
control = "control:" FILL ldap-oid ; controlType
|
||
0*1(1*SPACE ("true" / "false")) ; criticality
|
||
0*1(value-spec) ; controlValue
|
||
SEP
|
||
; (See note 9, below)
|
||
|
||
ldap-oid = 1*DIGIT 0*1("." 1*DIGIT)
|
||
; An LDAPOID, as defined in [4]
|
||
|
||
attrval-spec = AttributeDescription value-spec SEP
|
||
|
||
value-spec = ":" ( FILL 0*1(SAFE-STRING) /
|
||
":" FILL (BASE64-STRING) /
|
||
"<" FILL url)
|
||
; See notes 7 and 8, below
|
||
|
||
url = <a Uniform 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-char
|
||
|
||
attr-type-chars = ALPHA / DIGIT / "-"
|
||
|
||
opt-char = attr-type-chars
|
||
|
||
changerecord = "changetype:" FILL
|
||
(change-add / change-delete /
|
||
change-modify / change-moddn)
|
||
|
||
change-add = "add" SEP 1*attrval-spec
|
||
|
||
change-delete = "delete" SEP
|
||
|
||
change-moddn = ("modrdn" / "moddn") SEP
|
||
"newrdn:" ( FILL rdn /
|
||
":" FILL base64-rdn) SEP
|
||
"deleteoldrdn:" FILL ("0" / "1") SEP
|
||
0*1("newsuperior:"
|
||
( FILL distinguishedName /
|
||
":" FILL base64-distinguishedName) SEP)
|
||
|
||
change-modify = "modify" SEP *mod-spec
|
||
|
||
mod-spec = ("add:" / "delete:" / "replace:")
|
||
FILL AttributeDescription SEP
|
||
*attrval-spec
|
||
"-" SEP
|
||
|
||
SPACE = %x20
|
||
; ASCII SP, space
|
||
|
||
FILL = *SPACE
|
||
|
||
SEP = (CR LF / LF)
|
||
|
||
CR = %x0D
|
||
; ASCII CR, carriage return
|
||
|
||
LF = %x0A
|
||
; ASCII LF, line feed
|
||
|
||
ALPHA = %x41-5A / %x61-7A
|
||
; A-Z / a-z
|
||
|
||
DIGIT = %x30-39
|
||
; 0-9
|
||
|
||
|
||
|
||
|
||
Good Standards Track [Page 4]
|
||
|
||
RFC 2849 LDAP Data Interchange Format June 2000
|
||
|
||
|
||
UTF8-1 = %x80-BF
|
||
|
||
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-7F
|
||
; any value <= 127 decimal except NUL, LF,
|
||
; and CR
|
||
|
||
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
|
||
%x21-39 / %x3B / %x3D-7F
|
||
; 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-CHAR
|
||
|
||
BASE64-UTF8-STRING = BASE64-STRING
|
||
; MUST be the base64 encoding of a
|
||
; UTF8-STRING
|
||
|
||
BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
|
||
%x61-7A
|
||
; +, /, 0-9, =, A-Z, and a-z
|
||
; as specified in [5]
|
||
|
||
BASE64-STRING = [*(BASE64-CHAR)]
|
||
|
||
|
||
Notes on LDIF Syntax
|
||
|
||
1) For the LDIF format described in this document, the version
|
||
number MUST be "1". If the version number is absent,
|
||
implementations MAY choose to interpret the contents as an
|
||
older LDIF file format, supported by the University of
|
||
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 file
|
||
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 of
|
||
which is empty, is not permitted. Any line that begins with a
|
||
single space MUST be treated as a continuation of the previous
|
||
(non-empty) line. When joining folded lines, exactly one space
|
||
character at the beginning of each continued line must be
|
||
discarded. Implementations SHOULD NOT fold lines in the middle
|
||
of a multi-byte UTF-8 character.
|
||
|
||
3) Any line that begins with a pound-sign ("#", ASCII 35) is a
|
||
comment line, and MUST be ignored when parsing an LDIF file.
|
||
|
||
4) Any dn or rdn that contains characters other than those
|
||
defined as "SAFE-UTF8-CHAR", or begins with a character other
|
||
than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be
|
||
base-64 encoded. Other values MAY be base-64 encoded. Any
|
||
value that contains characters other than those defined as
|
||
"SAFE-CHAR", or begins with a character other than those
|
||
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 directly
|
||
in an LDIF file, it MUST be represented as
|
||
AttributeDescription ":" FILL SEP. For example, "seeAlso:"
|
||
followed by a newline represents a zero-length "seeAlso"
|
||
attribute value. It is also permissible for the value
|
||
referred to by a URL to be of zero length.
|
||
|
||
6) 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.
|
||
|
||
7) Distinguished names, relative distinguished names, and
|
||
attribute values of DirectoryString syntax MUST be valid UTF-8
|
||
strings. Implementations that read LDIF MAY interpret files
|
||
in which these entities are stored in some other character set
|
||
encoding, but implementations MUST NOT generate LDIF content
|
||
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 be
|
||
base-64 encoded.
|
||
|
||
9) When controls are included in an LDIF file, implementations
|
||
MAY choose to ignore some or all of them. This may be
|
||
necessary if the changes described in the LDIF file are being
|
||
sent on an LDAPv2 connection (LDAPv2 does not support
|
||
controls), or the particular controls are not supported by the
|
||
remote server. If the criticality of a control is "true", then
|
||
the implementation MUST either include the control, or MUST
|
||
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 the
|
||
following exceptions: a) The requirement that base64 output
|
||
streams must be represented as lines of no more than 76
|
||
characters is removed. Lines in LDIF files may only be folded
|
||
according to the folding rules described in note 2, above. b)
|
||
Base64 strings in [5] may contain characters other than those
|
||
defined in BASE64-CHAR, and are ignored. LDIF does not permit
|
||
any extraneous characters, other than those used for line
|
||
folding.
|
||
|
||
Examples of LDAP Data Interchange Format
|
||
|
||
Example 1: An simple LDAP file with two entries
|
||
|
||
version: 1
|
||
dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
|
||
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, dc=airius, dc=com
|
||
objectclass: top
|
||
objectclass: person
|
||
objectclass: organizationalPerson
|
||
cn: Bjorn Jensen
|
||
sn: Jensen
|
||
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 value
|
||
|
||
version: 1
|
||
dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
|
||
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 sea
|
||
rch of perfect sailing conditions.
|
||
title:Product Manager, Rod and Reel Division
|
||
|
||
Example 3: A file containing a base-64-encoded value
|
||
|
||
version: 1
|
||
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
|
||
objectclass: top
|
||
objectclass: person
|
||
objectclass: organizationalPerson
|
||
cn: Gern Jensen
|
||
cn: Gern O Jensen
|
||
sn: Jensen
|
||
uid: gernj
|
||
telephonenumber: +1 408 555 1212
|
||
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
|
||
IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
|
||
VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
|
||
b3V0IG1vcmUu
|
||
|
||
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.
|
||
|
||
version: 1
|
||
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
|
||
|
||
|
||
|
||
Good Standards Track [Page 8]
|
||
|
||
RFC 2849 LDAP Data Interchange Format June 2000
|
||
|
||
|
||
# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
|
||
ou;lang-en: Sales
|
||
description: Japanese office
|
||
|
||
dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
|
||
# dn:: uid=<uid>,ou=<JapaneseOU>,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:: <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::
|
||
<JapaneseGivenname_in_phonetic_representation_kana>
|
||
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
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Good Standards Track [Page 9]
|
||
|
||
RFC 2849 LDAP Data Interchange Format June 2000
|
||
|
||
|
||
Example 5: A file containing a reference to an external file
|
||
|
||
version: 1
|
||
dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
|
||
objectclass: top
|
||
objectclass: person
|
||
objectclass: organizationalPerson
|
||
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: A file containing a series of change records and comments
|
||
|
||
version: 1
|
||
# Add a new entry
|
||
dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
|
||
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, dc=airius, dc=com
|
||
changetype: delete
|
||
|
||
# Modify an entry's relative distinguished name
|
||
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
|
||
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, dc=airius, dc=com
|
||
changetype: modrdn
|
||
newrdn: ou=Product Development Accountants
|
||
deleteoldrdn: 0
|
||
newsuperior: ou=Accounting, dc=airius, dc=com
|
||
|
||
|
||
|
||
|
||
Good Standards Track [Page 10]
|
||
|
||
RFC 2849 LDAP Data Interchange Format June 2000
|
||
|
||
|
||
# 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, dc=airius, dc=com
|
||
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
|
||
-
|
||
|
||
# Modify an entry: replace the postaladdress attribute with an empty
|
||
# set of values (which will cause the attribute to be removed), and
|
||
# delete the entire description attribute. Note that the first will
|
||
# always succeed, while the second will only succeed if at least
|
||
# one value for the description attribute is present.
|
||
dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
|
||
changetype: modify
|
||
replace: postaladdress
|
||
-
|
||
delete: description
|
||
-
|
||
|
||
Example 7: An LDIF file containing a change record with a control
|
||
version: 1
|
||
# Delete an entry. The operation will attach the LDAPv3
|
||
# Tree Delete Control defined in [9]. The criticality
|
||
# field is "true" and the controlValue field is
|
||
# absent, as required by [9].
|
||
dn: ou=Product Development, dc=airius, dc=com
|
||
control: 1.2.840.113556.1.4.805 true
|
||
changetype: delete
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Good Standards Track [Page 11]
|
||
|
||
RFC 2849 LDAP Data Interchange Format June 2000
|
||
|
||
|
||
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 external content 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.
|
||
|
||
LDIF does not provide any method for carrying authentication
|
||
information with an LDIF file. Users of LDIF files must take care to
|
||
verify the integrity of an LDIF file received from an external
|
||
source.
|
||
|
||
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.
|
||
|
||
Members of the IETF LDAP Extensions Working group provided many
|
||
helpful suggestions. In particular, Hallvard B. Furuseth of the
|
||
University of Oslo made many significant contributions to this
|
||
document, including a thorough review and rewrite of the BNF.
|
||
|
||
References
|
||
|
||
[1] Howes, T. and M. Smith, "A MIME Content-Type for Directory
|
||
Information", RFC 2425, September 1998.
|
||
|
||
[2] Crocker, D., and P. Overell, "Augmented BNF for Syntax
|
||
Specifications: ABNF", RFC 2234, November 1997.
|
||
|
||
[3] Wahl, M., Kille, S. and T. Howes, "A String Representation of
|
||
Distinguished Names", RFC 2253, December 1997.
|
||
|
||
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
|
||
Protocol (v3)", RFC 2251, July 1997.
|
||
|
||
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
||
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, "Uniform
|
||
Resource Locators (URL)", RFC 1738, December 1994.
|
||
|
||
[7] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
|
||
Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[8] The SLAPD and SLURPD Administrators Guide. University of
|
||
Michigan, April 1996. <URL:
|
||
http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
|
||
|
||
[9] M. P. Armijo, "Tree Delete Control", Work in Progress.
|
||
|
||
Author's Address
|
||
|
||
Gordon Good
|
||
iPlanet e-commerce Solutions
|
||
150 Network Circle
|
||
Mailstop USCA17-201
|
||
Santa Clara, CA 95054, USA
|
||
|
||
Phone: +1 408 276 4351
|
||
EMail: ggood@netscape.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Good Standards Track [Page 13]
|
||
|
||
RFC 2849 LDAP Data Interchange Format June 2000
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2000). All Rights Reserved.
|
||
|
||
This document and translations of it may be copied and furnished to
|
||
others, and derivative works that comment on or otherwise explain it
|
||
or assist in its implementation may be prepared, copied, published
|
||
and distributed, in whole or in part, without restriction of any
|
||
kind, provided that the above copyright notice and this paragraph are
|
||
included on all such copies and derivative works. However, this
|
||
document itself may not be modified in any way, such as by removing
|
||
the copyright notice or references to the Internet Society or other
|
||
Internet organizations, except as needed for the purpose of
|
||
developing Internet standards in which case the procedures for
|
||
copyrights defined in the Internet Standards process must be
|
||
followed, or as required to translate it into languages other than
|
||
English.
|
||
|
||
The limited permissions granted above are perpetual and will not be
|
||
revoked by the Internet Society or its successors or assigns.
|
||
|
||
This document and the information contained herein is provided on an
|
||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Good Standards Track [Page 14]
|
||
|