mirror of
https://github.com/samba-team/samba.git
synced 2025-01-11 05:18:09 +03:00
Simo Sorce
Gerald (Jerry) Carter
parent
181da32361
commit
e8eee542d3
787
source4/ldap_server/devdocs/rfc2849.txt
Normal file
787
source4/ldap_server/devdocs/rfc2849.txt
Normal file
@ -0,0 +1,787 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
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]
|
||||
|
||||
Loading…
Reference in New Issue
Block a user