| rev |
line source |
|
yves@0
|
1
|
|
yves@0
|
2
|
|
yves@0
|
3
|
|
yves@0
|
4
|
|
yves@0
|
5
|
|
yves@0
|
6
|
|
yves@0
|
7 Network Working Group G. Good
|
|
yves@1
|
8 INTERNET-DRAFT
|
|
yves@1
|
9 Obsoletes: 2849
|
|
yves@1
|
10 Category: Standards Track
|
|
yves@0
|
11
|
|
yves@0
|
12
|
|
yves@0
|
13 The LDAP Data Interchange Format (LDIF) - Technical Specification
|
|
yves@0
|
14
|
|
yves@1
|
15
|
|
yves@0
|
16 Status of this Memo
|
|
yves@0
|
17
|
|
yves@1
|
18 By submitting this Internet-Draft, each author represents that any
|
|
yves@1
|
19 applicable patent or other IPR claims of which he or she is aware
|
|
yves@1
|
20 have been or will be disclosed, and any of which he or she becomes
|
|
yves@1
|
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
|
|
yves@0
|
22
|
|
yves@0
|
23 Abstract
|
|
yves@0
|
24
|
|
yves@0
|
25 This document describes a file format suitable for describing
|
|
yves@0
|
26 directory information or modifications made to directory information.
|
|
yves@0
|
27 The file format, known as LDIF, for LDAP Data Interchange Format, is
|
|
yves@0
|
28 typically used to import and export directory information between
|
|
yves@0
|
29 LDAP-based directory servers, or to describe a set of changes which
|
|
yves@0
|
30 are to be applied to a directory.
|
|
yves@0
|
31
|
|
yves@1
|
32 Relationship to Obsolete Specification
|
|
yves@1
|
33
|
|
yves@1
|
34 This obsoletes and replaces [RFC2849] which defined version 1
|
|
yves@1
|
35 of LDIF.
|
|
yves@1
|
36
|
|
yves@1
|
37 The paragraph "Notes on LDIF Syntax" in [RFC2849] documented the
|
|
yves@1
|
38 use of non-encoded UTF-8 inside an LDIF file, but the "Formal Syntax
|
|
yves@1
|
39 Definition of LDIF" specified either ASCII or base64 encoded UTF-8
|
|
yves@1
|
40 for distinguishedName, rdn and attrval-spec. The specification has
|
|
yves@1
|
41 been changed to allow UTF-8 strings without the use of encoding.
|
|
yves@1
|
42
|
|
yves@1
|
43 The definition of UTF-8 has been slightly modified to follow the
|
|
yves@1
|
44 definition from [RFC3629].
|
|
yves@1
|
45
|
|
yves@1
|
46 The style has been changed to conform with the newer editorial
|
|
yves@1
|
47 standards from [RFC223], specifically in quoting references.
|
|
yves@1
|
48
|
|
yves@0
|
49 Background and Intended Usage
|
|
yves@0
|
50
|
|
yves@0
|
51 There are a number of situations where a common interchange format is
|
|
yves@0
|
52 desirable. For example, one might wish to export a copy of the
|
|
yves@0
|
53 contents of a directory server to a file, move that file to a
|
|
yves@0
|
54 different machine, and import the contents into a second directory
|
|
yves@0
|
55 server.
|
|
yves@0
|
56
|
|
yves@0
|
57 Additionally, by using a well-defined interchange format, development
|
|
yves@0
|
58 of data import tools from legacy systems is facilitated. A fairly
|
|
yves@0
|
59 simple set of tools written in awk or perl can, for example, convert
|
|
yves@1
|
60 a database of personnel information into an LDIF file. This file can
|
|
yves@0
|
61 then be imported into a directory server, regardless of the internal
|
|
yves@0
|
62 database representation the target directory server uses.
|
|
yves@0
|
63
|
|
yves@0
|
64 The LDIF format was originally developed and used in the University
|
|
yves@0
|
65 of Michigan LDAP implementation. The first use of LDIF was in
|
|
yves@0
|
66 describing directory entries. Later, the format was expanded to
|
|
yves@0
|
67 allow representation of changes to directory entries.
|
|
yves@0
|
68
|
|
yves@0
|
69 Relationship to the application/directory MIME content-type:
|
|
yves@0
|
70
|
|
yves@1
|
71 The application/directory MIME content-type [RFC2425] is a general
|
|
yves@0
|
72 framework and format for conveying directory information, and is
|
|
yves@0
|
73 independent of any particular directory service. The LDIF format is
|
|
yves@0
|
74 a simpler format which is perhaps easier to create, and may also be
|
|
yves@0
|
75 used, as noted, to describe a set of changes to be applied to a
|
|
yves@0
|
76 directory.
|
|
yves@0
|
77
|
|
yves@0
|
78 The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
|
|
yves@1
|
79 used in this document are to be interpreted as described
|
|
yves@1
|
80 in [RFC2119].
|
|
yves@0
|
81
|
|
yves@0
|
82 Definition of the LDAP Data Interchange Format
|
|
yves@0
|
83
|
|
yves@0
|
84 The LDIF format is used to convey directory information, or a
|
|
yves@0
|
85 description of a set of changes made to directory entries. An LDIF
|
|
yves@0
|
86 file consists of a series of records separated by line separators. A
|
|
yves@0
|
87 record consists of a sequence of lines describing a directory entry,
|
|
yves@0
|
88 or a sequence of lines describing a set of changes to a directory
|
|
yves@0
|
89 entry. An LDIF file specifies a set of directory entries, or a set
|
|
yves@0
|
90 of changes to be applied to directory entries, but not both.
|
|
yves@0
|
91
|
|
yves@0
|
92 There is a one-to-one correlation between LDAP operations that modify
|
|
yves@0
|
93 the directory (add, delete, modify, and modrdn), and the types of
|
|
yves@0
|
94 changerecords described below ("add", "delete", "modify", and
|
|
yves@0
|
95 "modrdn" or "moddn"). This correspondence is intentional, and
|
|
yves@0
|
96 permits a straightforward translation from LDIF changerecords to
|
|
yves@0
|
97 protocol operations.
|
|
yves@0
|
98
|
|
yves@0
|
99 Formal Syntax Definition of LDIF
|
|
yves@0
|
100
|
|
yves@0
|
101 The following definition uses the augmented Backus-Naur Form
|
|
yves@1
|
102 specified in [RFC2234].
|
|
yves@0
|
103
|
|
yves@0
|
104 ldif-file = ldif-content / ldif-changes
|
|
yves@0
|
105
|
|
yves@0
|
106 ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
|
|
yves@0
|
107
|
|
yves@0
|
108 ldif-changes = version-spec 1*(1*SEP ldif-change-record)
|
|
yves@0
|
109
|
|
yves@0
|
110 ldif-attrval-record = dn-spec SEP 1*attrval-spec
|
|
yves@0
|
111
|
|
yves@0
|
112 ldif-change-record = dn-spec SEP *control changerecord
|
|
yves@0
|
113
|
|
yves@0
|
114 version-spec = "version:" FILL version-number
|
|
yves@0
|
115
|
|
yves@0
|
116 version-number = 1*DIGIT
|
|
yves@1
|
117 ; version-number MUST be "2" for the
|
|
yves@0
|
118 ; LDIF format described in this document.
|
|
yves@0
|
119
|
|
yves@0
|
120 dn-spec = "dn:" (FILL distinguishedName /
|
|
yves@0
|
121 ":" FILL base64-distinguishedName)
|
|
yves@0
|
122
|
|
yves@1
|
123 distinguishedName = SAFE-UTF8-STRING
|
|
yves@1
|
124 ; a distinguished name, as defined
|
|
yves@1
|
125 ; in [RFC2253]
|
|
yves@0
|
126
|
|
yves@0
|
127 base64-distinguishedName = BASE64-UTF8-STRING
|
|
yves@0
|
128 ; a distinguishedName which has been base64
|
|
yves@0
|
129 ; encoded (see note 10, below)
|
|
yves@0
|
130
|
|
yves@1
|
131 rdn = SAFE-UTF8-STRING
|
|
yves@0
|
132 ; a relative distinguished name, defined as
|
|
yves@1
|
133 ; <name-component> in [RFC2253]
|
|
yves@0
|
134
|
|
yves@0
|
135 base64-rdn = BASE64-UTF8-STRING
|
|
yves@0
|
136 ; an rdn which has been base64 encoded (see
|
|
yves@0
|
137 ; note 10, below)
|
|
yves@0
|
138
|
|
yves@0
|
139 control = "control:" FILL ldap-oid ; controlType
|
|
yves@0
|
140 0*1(1*SPACE ("true" / "false")) ; criticality
|
|
yves@0
|
141 0*1(value-spec) ; controlValue
|
|
yves@0
|
142 SEP
|
|
yves@0
|
143 ; (See note 9, below)
|
|
yves@0
|
144
|
|
yves@0
|
145 ldap-oid = 1*DIGIT 0*1("." 1*DIGIT)
|
|
yves@1
|
146 ; An LDAPOID, as defined in [RFC2251]
|
|
yves@0
|
147
|
|
yves@0
|
148 attrval-spec = AttributeDescription value-spec SEP
|
|
yves@0
|
149
|
|
yves@1
|
150 value-spec = ":" ( FILL 0*1(SAFE-UTF8-STRING) /
|
|
yves@0
|
151 ":" FILL (BASE64-STRING) /
|
|
yves@0
|
152 "<" FILL url)
|
|
yves@0
|
153 ; See notes 7 and 8, below
|
|
yves@0
|
154
|
|
yves@0
|
155 url = <a Uniform Resource Locator,
|
|
yves@1
|
156 as defined in [RFC1738]>
|
|
yves@0
|
157 ; (See Note 6, below)
|
|
yves@0
|
158
|
|
yves@0
|
159 AttributeDescription = AttributeType [";" options]
|
|
yves@1
|
160 ; Definition taken from [RFC2251]
|
|
yves@0
|
161
|
|
yves@0
|
162 AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
|
|
yves@0
|
163
|
|
yves@0
|
164 options = option / (option ";" options)
|
|
yves@0
|
165
|
|
yves@0
|
166 option = 1*opt-char
|
|
yves@0
|
167
|
|
yves@0
|
168 attr-type-chars = ALPHA / DIGIT / "-"
|
|
yves@0
|
169
|
|
yves@0
|
170 opt-char = attr-type-chars
|
|
yves@0
|
171
|
|
yves@0
|
172 changerecord = "changetype:" FILL
|
|
yves@0
|
173 (change-add / change-delete /
|
|
yves@0
|
174 change-modify / change-moddn)
|
|
yves@0
|
175
|
|
yves@0
|
176 change-add = "add" SEP 1*attrval-spec
|
|
yves@0
|
177
|
|
yves@0
|
178 change-delete = "delete" SEP
|
|
yves@0
|
179
|
|
yves@0
|
180 change-moddn = ("modrdn" / "moddn") SEP
|
|
yves@0
|
181 "newrdn:" ( FILL rdn /
|
|
yves@0
|
182 ":" FILL base64-rdn) SEP
|
|
yves@0
|
183 "deleteoldrdn:" FILL ("0" / "1") SEP
|
|
yves@0
|
184 0*1("newsuperior:"
|
|
yves@0
|
185 ( FILL distinguishedName /
|
|
yves@0
|
186 ":" FILL base64-distinguishedName) SEP)
|
|
yves@0
|
187
|
|
yves@0
|
188 change-modify = "modify" SEP *mod-spec
|
|
yves@0
|
189
|
|
yves@0
|
190 mod-spec = ("add:" / "delete:" / "replace:")
|
|
yves@0
|
191 FILL AttributeDescription SEP
|
|
yves@0
|
192 *attrval-spec
|
|
yves@0
|
193 "-" SEP
|
|
yves@0
|
194
|
|
yves@0
|
195 SPACE = %x20
|
|
yves@0
|
196 ; ASCII SP, space
|
|
yves@0
|
197
|
|
yves@0
|
198 FILL = *SPACE
|
|
yves@0
|
199
|
|
yves@0
|
200 SEP = (CR LF / LF)
|
|
yves@0
|
201
|
|
yves@0
|
202 CR = %x0D
|
|
yves@0
|
203 ; ASCII CR, carriage return
|
|
yves@0
|
204
|
|
yves@0
|
205 LF = %x0A
|
|
yves@0
|
206 ; ASCII LF, line feed
|
|
yves@0
|
207
|
|
yves@0
|
208 ALPHA = %x41-5A / %x61-7A
|
|
yves@0
|
209 ; A-Z / a-z
|
|
yves@0
|
210
|
|
yves@0
|
211 DIGIT = %x30-39
|
|
yves@0
|
212 ; 0-9
|
|
yves@0
|
213
|
|
yves@1
|
214 UTF8-1 = %x00-7F
|
|
yves@0
|
215
|
|
yves@1
|
216 UTF8-tail = %x80-BF
|
|
yves@0
|
217
|
|
yves@1
|
218 UTF8-2 = %xC2-DF UTF8-tail
|
|
yves@0
|
219
|
|
yves@1
|
220 UTF8-3 = %xE0 %xA0-BF UTF8-tail /
|
|
yves@1
|
221 %xE1-EC 2( UTF8-tail ) /
|
|
yves@1
|
222 %xED %x80-9F UTF8-tail /
|
|
yves@1
|
223 %xEE-EF 2( UTF8-tail )
|
|
yves@0
|
224
|
|
yves@1
|
225 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
|
|
yves@1
|
226 %xF1-F3 3( UTF8-tail ) /
|
|
yves@1
|
227 %xF4 %x80-8F 2( UTF8-tail )
|
|
yves@0
|
228
|
|
yves@1
|
229 UTF8-CHAR = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
|
|
yves@1
|
230
|
|
yves@1
|
231 UTF8-STRING = *UTF8-CHAR
|
|
yves@0
|
232
|
|
yves@0
|
233 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
|
|
yves@0
|
234 ; any value <= 127 decimal except NUL, LF,
|
|
yves@0
|
235 ; and CR
|
|
yves@0
|
236
|
|
yves@0
|
237 SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
|
|
yves@0
|
238 %x21-39 / %x3B / %x3D-7F
|
|
yves@0
|
239 ; any value <= 127 except NUL, LF, CR,
|
|
yves@0
|
240 ; SPACE, colon (":", ASCII 58 decimal)
|
|
yves@0
|
241 ; and less-than ("<" , ASCII 60 decimal)
|
|
yves@0
|
242
|
|
yves@0
|
243 SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
|
|
yves@0
|
244
|
|
yves@1
|
245 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
|
|
yves@0
|
246
|
|
yves@1
|
247 SAFE-INIT-UTF8-CHAR = SAFE-INIT-CHAR / UTF8-2 / UTF8-3 / UTF8-4
|
|
yves@1
|
248
|
|
yves@1
|
249 SAFE-UTF8-STRING = [SAFE-INIT-UTF8-CHAR *SAFE-UTF8-CHAR]
|
|
yves@0
|
250
|
|
yves@0
|
251 BASE64-UTF8-STRING = BASE64-STRING
|
|
yves@0
|
252 ; MUST be the base64 encoding of a
|
|
yves@0
|
253 ; UTF8-STRING
|
|
yves@0
|
254
|
|
yves@0
|
255 BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
|
|
yves@0
|
256 %x61-7A
|
|
yves@0
|
257 ; +, /, 0-9, =, A-Z, and a-z
|
|
yves@1
|
258 ; as specified in [RFC2045]
|
|
yves@0
|
259
|
|
yves@0
|
260 BASE64-STRING = [*(BASE64-CHAR)]
|
|
yves@0
|
261
|
|
yves@0
|
262
|
|
yves@0
|
263 Notes on LDIF Syntax
|
|
yves@0
|
264
|
|
yves@0
|
265 1) For the LDIF format described in this document, the version
|
|
yves@1
|
266 number MUST be "2". If the version number is absent,
|
|
yves@0
|
267 implementations MAY choose to interpret the contents as an
|
|
yves@0
|
268 older LDIF file format, supported by the University of
|
|
yves@1
|
269 Michigan ldap-3.3 implementation [UMich96].
|
|
yves@0
|
270
|
|
yves@0
|
271 2) Any non-empty line, including comment lines, in an LDIF file
|
|
yves@0
|
272 MAY be folded by inserting a line separator (SEP) and a SPACE.
|
|
yves@0
|
273 Folding MUST NOT occur before the first character of the line.
|
|
yves@0
|
274 In other words, folding a line into two lines, the first of
|
|
yves@1
|
275 which is empty, is not permitted. Any line that begins with a
|
|
yves@0
|
276 single space MUST be treated as a continuation of the previous
|
|
yves@1
|
277 (non-empty) line. When joining folded lines, exactly one space
|
|
yves@0
|
278 character at the beginning of each continued line must be
|
|
yves@1
|
279 discarded. Implementations SHOULD NOT fold lines in the middle
|
|
yves@0
|
280 of a multi-byte UTF-8 character.
|
|
yves@0
|
281
|
|
yves@0
|
282 3) Any line that begins with a pound-sign ("#", ASCII 35) is a
|
|
yves@0
|
283 comment line, and MUST be ignored when parsing an LDIF file.
|
|
yves@0
|
284
|
|
yves@1
|
285 4) Any dn, rdn or attrval-spec that contains characters other
|
|
yves@1
|
286 than those defined as "SAFE-UTF8-CHAR", or begins with a
|
|
yves@1
|
287 character other than those defined as "SAFE-INIT-UTF8-CHAR",
|
|
yves@1
|
288 above, MUST be base-64 encoded. Other values MAY be base-64
|
|
yves@1
|
289 encoded. Any value that contains characters other than those
|
|
yves@1
|
290 defined as "SAFE--CHAR", or begins with a character other than
|
|
yves@1
|
291 those defined as "SAFE-INIT--CHAR", above, MUST be base-64
|
|
yves@1
|
292 encoded. Other values MAY be base-64 encoded.
|
|
yves@0
|
293
|
|
yves@0
|
294 5) When a zero-length attribute value is to be included directly
|
|
yves@0
|
295 in an LDIF file, it MUST be represented as
|
|
yves@0
|
296 AttributeDescription ":" FILL SEP. For example, "seeAlso:"
|
|
yves@0
|
297 followed by a newline represents a zero-length "seeAlso"
|
|
yves@0
|
298 attribute value. It is also permissible for the value
|
|
yves@0
|
299 referred to by a URL to be of zero length.
|
|
yves@0
|
300
|
|
yves@0
|
301 6) When a URL is specified in an attrval-spec, the following
|
|
yves@0
|
302 conventions apply:
|
|
yves@0
|
303
|
|
yves@0
|
304 a) Implementations SHOULD support the file:// URL format. The
|
|
yves@0
|
305 contents of the referenced file are to be included verbatim
|
|
yves@0
|
306 in the interpreted output of the LDIF file.
|
|
yves@0
|
307 b) Implementations MAY support other URL formats. The
|
|
yves@0
|
308 semantics associated with each supported URL will be
|
|
yves@0
|
309 documented in an associated Applicability Statement.
|
|
yves@0
|
310
|
|
yves@0
|
311 7) Distinguished names, relative distinguished names, and
|
|
yves@0
|
312 attribute values of DirectoryString syntax MUST be valid UTF-8
|
|
yves@0
|
313 strings. Implementations that read LDIF MAY interpret files
|
|
yves@0
|
314 in which these entities are stored in some other character set
|
|
yves@0
|
315 encoding, but implementations MUST NOT generate LDIF content
|
|
yves@0
|
316 which does not contain valid UTF-8 data.
|
|
yves@0
|
317
|
|
yves@0
|
318 8) Values or distinguished names that end with SPACE SHOULD be
|
|
yves@0
|
319 base-64 encoded.
|
|
yves@0
|
320
|
|
yves@0
|
321 9) When controls are included in an LDIF file, implementations
|
|
yves@1
|
322 MAY choose to ignore some or all of them. This may be
|
|
yves@0
|
323 necessary if the changes described in the LDIF file are being
|
|
yves@0
|
324 sent on an LDAPv2 connection (LDAPv2 does not support
|
|
yves@0
|
325 controls), or the particular controls are not supported by the
|
|
yves@1
|
326 remote server. If the criticality of a control is "true", then
|
|
yves@0
|
327 the implementation MUST either include the control, or MUST
|
|
yves@0
|
328 NOT send the operation to a remote server.
|
|
yves@0
|
329
|
|
yves@0
|
330 10) When an attrval-spec, distinguishedName, or rdn is base64-
|
|
yves@1
|
331 encoded, the encoding rules specified in [RFC2045] are used
|
|
yves@1
|
332 with the following exceptions: a) The requirement that base64
|
|
yves@1
|
333 output streams must be represented as lines of no more than 76
|
|
yves@1
|
334 characters is removed. Lines in LDIF files may only be folded
|
|
yves@0
|
335 according to the folding rules described in note 2, above. b)
|
|
yves@1
|
336 Base64 strings in [RFC2045] may contain characters other than
|
|
yves@1
|
337 those defined in BASE64-CHAR, and are ignored. LDIF does not
|
|
yves@1
|
338 permit any extraneous characters, other than those used for
|
|
yves@1
|
339 line folding.
|
|
yves@0
|
340
|
|
yves@0
|
341 Examples of LDAP Data Interchange Format
|
|
yves@0
|
342
|
|
yves@0
|
343 Example 1: An simple LDAP file with two entries
|
|
yves@0
|
344
|
|
yves@0
|
345 version: 1
|
|
yves@0
|
346 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
|
|
yves@0
|
347 objectclass: top
|
|
yves@0
|
348 objectclass: person
|
|
yves@0
|
349 objectclass: organizationalPerson
|
|
yves@0
|
350 cn: Barbara Jensen
|
|
yves@0
|
351 cn: Barbara J Jensen
|
|
yves@0
|
352 cn: Babs Jensen
|
|
yves@0
|
353 sn: Jensen
|
|
yves@0
|
354 uid: bjensen
|
|
yves@0
|
355 telephonenumber: +1 408 555 1212
|
|
yves@0
|
356 description: A big sailing fan.
|
|
yves@0
|
357
|
|
yves@0
|
358 dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
|
|
yves@0
|
359 objectclass: top
|
|
yves@0
|
360 objectclass: person
|
|
yves@0
|
361 objectclass: organizationalPerson
|
|
yves@0
|
362 cn: Bjorn Jensen
|
|
yves@0
|
363 sn: Jensen
|
|
yves@0
|
364 telephonenumber: +1 408 555 1212
|
|
yves@0
|
365
|
|
yves@0
|
366 Example 2: A file containing an entry with a folded attribute value
|
|
yves@0
|
367
|
|
yves@0
|
368 version: 1
|
|
yves@0
|
369 dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
|
|
yves@0
|
370 objectclass:top
|
|
yves@0
|
371 objectclass:person
|
|
yves@0
|
372 objectclass:organizationalPerson
|
|
yves@0
|
373 cn:Barbara Jensen
|
|
yves@0
|
374 cn:Barbara J Jensen
|
|
yves@0
|
375 cn:Babs Jensen
|
|
yves@0
|
376 sn:Jensen
|
|
yves@0
|
377 uid:bjensen
|
|
yves@0
|
378 telephonenumber:+1 408 555 1212
|
|
yves@0
|
379 description:Babs is a big sailing fan, and travels extensively in sea
|
|
yves@0
|
380 rch of perfect sailing conditions.
|
|
yves@0
|
381 title:Product Manager, Rod and Reel Division
|
|
yves@0
|
382
|
|
yves@0
|
383 Example 3: A file containing a base-64-encoded value
|
|
yves@0
|
384
|
|
yves@0
|
385 version: 1
|
|
yves@0
|
386 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
|
|
yves@0
|
387 objectclass: top
|
|
yves@0
|
388 objectclass: person
|
|
yves@0
|
389 objectclass: organizationalPerson
|
|
yves@0
|
390 cn: Gern Jensen
|
|
yves@0
|
391 cn: Gern O Jensen
|
|
yves@0
|
392 sn: Jensen
|
|
yves@0
|
393 uid: gernj
|
|
yves@0
|
394 telephonenumber: +1 408 555 1212
|
|
yves@0
|
395 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
|
|
yves@0
|
396 IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
|
|
yves@0
|
397 VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
|
|
yves@0
|
398 b3V0IG1vcmUu
|
|
yves@0
|
399
|
|
yves@0
|
400 Example 4: A file containing an entries with UTF-8-encoded attribute
|
|
yves@0
|
401 values, including language tags. Comments indicate the contents
|
|
yves@0
|
402 of UTF-8-encoded attributes and distinguished names.
|
|
yves@0
|
403
|
|
yves@0
|
404 version: 1
|
|
yves@0
|
405 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
|
|
yves@0
|
406 # dn:: ou=<JapaneseOU>,o=Airius
|
|
yves@0
|
407 objectclass: top
|
|
yves@0
|
408 objectclass: organizationalUnit
|
|
yves@0
|
409 ou:: 5Za25qWt6YOo
|
|
yves@0
|
410 # ou:: <JapaneseOU>
|
|
yves@0
|
411 ou;lang-ja:: 5Za25qWt6YOo
|
|
yves@0
|
412 # ou;lang-ja:: <JapaneseOU>
|
|
yves@0
|
413 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
|
|
yves@0
|
414
|
|
yves@0
|
415 # ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
|
|
yves@0
|
416 ou;lang-en: Sales
|
|
yves@0
|
417 description: Japanese office
|
|
yves@0
|
418
|
|
yves@0
|
419 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
|
|
yves@0
|
420 # dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
|
|
yves@0
|
421 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
|
|
yves@0
|
422 objectclass: top
|
|
yves@0
|
423 objectclass: person
|
|
yves@0
|
424 objectclass: organizationalPerson
|
|
yves@0
|
425 objectclass: inetOrgPerson
|
|
yves@0
|
426 uid: rogasawara
|
|
yves@0
|
427 mail: rogasawara@airius.co.jp
|
|
yves@0
|
428 givenname;lang-ja:: 44Ot44OJ44OL44O8
|
|
yves@0
|
429 # givenname;lang-ja:: <JapaneseGivenname>
|
|
yves@0
|
430 sn;lang-ja:: 5bCP56yg5Y6f
|
|
yves@0
|
431 # sn;lang-ja:: <JapaneseSn>
|
|
yves@0
|
432 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
|
|
yves@0
|
433 # cn;lang-ja:: <JapaneseCn>
|
|
yves@0
|
434 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
|
|
yves@0
|
435 # title;lang-ja:: <JapaneseTitle>
|
|
yves@0
|
436 preferredlanguage: ja
|
|
yves@0
|
437 givenname:: 44Ot44OJ44OL44O8
|
|
yves@0
|
438 # givenname:: <JapaneseGivenname>
|
|
yves@0
|
439 sn:: 5bCP56yg5Y6f
|
|
yves@0
|
440 # sn:: <JapaneseSn>
|
|
yves@0
|
441 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
|
|
yves@0
|
442 # cn:: <JapaneseCn>
|
|
yves@0
|
443 title:: 5Za25qWt6YOoIOmDqOmVtw==
|
|
yves@0
|
444 # title:: <JapaneseTitle>
|
|
yves@0
|
445 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
|
|
yves@0
|
446 # givenname;lang-ja;phonetic::
|
|
yves@0
|
447 <JapaneseGivenname_in_phonetic_representation_kana>
|
|
yves@0
|
448 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
|
|
yves@0
|
449 # sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
|
|
yves@0
|
450 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
|
|
yves@0
|
451 # cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
|
|
yves@0
|
452 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
|
|
yves@0
|
453 # title;lang-ja;phonetic::
|
|
yves@0
|
454 # <JapaneseTitle_in_phonetic_representation_kana>
|
|
yves@0
|
455 givenname;lang-en: Rodney
|
|
yves@0
|
456 sn;lang-en: Ogasawara
|
|
yves@0
|
457 cn;lang-en: Rodney Ogasawara
|
|
yves@0
|
458 title;lang-en: Sales, Director
|
|
yves@0
|
459
|
|
yves@0
|
460 Example 5: A file containing a reference to an external file
|
|
yves@0
|
461
|
|
yves@0
|
462 version: 1
|
|
yves@0
|
463 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
|
|
yves@0
|
464 objectclass: top
|
|
yves@0
|
465 objectclass: person
|
|
yves@0
|
466 objectclass: organizationalPerson
|
|
yves@0
|
467 cn: Horatio Jensen
|
|
yves@0
|
468
|
|
yves@0
|
469 cn: Horatio N Jensen
|
|
yves@0
|
470 sn: Jensen
|
|
yves@0
|
471 uid: hjensen
|
|
yves@0
|
472 telephonenumber: +1 408 555 1212
|
|
yves@0
|
473 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
|
|
yves@0
|
474
|
|
yves@0
|
475 Example 6: A file containing a series of change records and comments
|
|
yves@0
|
476
|
|
yves@0
|
477 version: 1
|
|
yves@0
|
478 # Add a new entry
|
|
yves@0
|
479 dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
|
|
yves@0
|
480 changetype: add
|
|
yves@0
|
481 objectclass: top
|
|
yves@0
|
482 objectclass: person
|
|
yves@0
|
483 objectclass: organizationalPerson
|
|
yves@0
|
484 cn: Fiona Jensen
|
|
yves@0
|
485 sn: Jensen
|
|
yves@0
|
486 uid: fiona
|
|
yves@0
|
487 telephonenumber: +1 408 555 1212
|
|
yves@0
|
488 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
|
|
yves@0
|
489
|
|
yves@0
|
490 # Delete an existing entry
|
|
yves@0
|
491 dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
|
|
yves@0
|
492 changetype: delete
|
|
yves@0
|
493
|
|
yves@0
|
494 # Modify an entry's relative distinguished name
|
|
yves@0
|
495 dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
|
|
yves@0
|
496 changetype: modrdn
|
|
yves@0
|
497 newrdn: cn=Paula Jensen
|
|
yves@0
|
498 deleteoldrdn: 1
|
|
yves@0
|
499
|
|
yves@0
|
500 # Rename an entry and move all of its children to a new location in
|
|
yves@0
|
501 # the directory tree (only implemented by LDAPv3 servers).
|
|
yves@0
|
502 dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
|
|
yves@0
|
503 changetype: modrdn
|
|
yves@0
|
504 newrdn: ou=Product Development Accountants
|
|
yves@0
|
505 deleteoldrdn: 0
|
|
yves@0
|
506 newsuperior: ou=Accounting, dc=airius, dc=com
|
|
yves@0
|
507
|
|
yves@0
|
508 # Modify an entry: add an additional value to the postaladdress
|
|
yves@0
|
509 # attribute, completely delete the description attribute, replace
|
|
yves@0
|
510 # the telephonenumber attribute with two values, and delete a specific
|
|
yves@0
|
511 # value from the facsimiletelephonenumber attribute
|
|
yves@0
|
512 dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
|
|
yves@0
|
513 changetype: modify
|
|
yves@0
|
514 add: postaladdress
|
|
yves@0
|
515 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
|
|
yves@0
|
516 -
|
|
yves@0
|
517
|
|
yves@0
|
518 delete: description
|
|
yves@0
|
519 -
|
|
yves@0
|
520 replace: telephonenumber
|
|
yves@0
|
521 telephonenumber: +1 408 555 1234
|
|
yves@0
|
522 telephonenumber: +1 408 555 5678
|
|
yves@0
|
523 -
|
|
yves@0
|
524 delete: facsimiletelephonenumber
|
|
yves@0
|
525 facsimiletelephonenumber: +1 408 555 9876
|
|
yves@0
|
526 -
|
|
yves@0
|
527
|
|
yves@0
|
528 # Modify an entry: replace the postaladdress attribute with an empty
|
|
yves@0
|
529 # set of values (which will cause the attribute to be removed), and
|
|
yves@1
|
530 # delete the entire description attribute. Note that the first will
|
|
yves@0
|
531 # always succeed, while the second will only succeed if at least
|
|
yves@0
|
532 # one value for the description attribute is present.
|
|
yves@0
|
533 dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
|
|
yves@0
|
534 changetype: modify
|
|
yves@0
|
535 replace: postaladdress
|
|
yves@0
|
536 -
|
|
yves@0
|
537 delete: description
|
|
yves@0
|
538 -
|
|
yves@0
|
539
|
|
yves@0
|
540 Example 7: An LDIF file containing a change record with a control
|
|
yves@0
|
541 version: 1
|
|
yves@1
|
542 # Delete an entry. The operation will attach the LDAPv3
|
|
yves@1
|
543 # Tree Delete Control defined in [Armijo00]. The criticality
|
|
yves@0
|
544 # field is "true" and the controlValue field is
|
|
yves@1
|
545 # absent, as required by [Armijo00].
|
|
yves@0
|
546 dn: ou=Product Development, dc=airius, dc=com
|
|
yves@0
|
547 control: 1.2.840.113556.1.4.805 true
|
|
yves@0
|
548 changetype: delete
|
|
yves@0
|
549
|
|
yves@0
|
550 Security Considerations
|
|
yves@0
|
551
|
|
yves@0
|
552 Given typical directory applications, an LDIF file is likely to
|
|
yves@0
|
553 contain sensitive personal data. Appropriate measures should be
|
|
yves@0
|
554 taken to protect the privacy of those persons whose data is contained
|
|
yves@0
|
555 in an LDIF file.
|
|
yves@0
|
556
|
|
yves@0
|
557 Since ":<" directives can cause external content to be included when
|
|
yves@0
|
558 processing an LDIF file, one should be cautious of accepting LDIF
|
|
yves@0
|
559 files from external sources. A "trojan" LDIF file could name a file
|
|
yves@0
|
560 with sensitive contents and cause it to be included in a directory
|
|
yves@0
|
561 entry, which a hostile entity could read via LDAP.
|
|
yves@0
|
562
|
|
yves@0
|
563 LDIF does not provide any method for carrying authentication
|
|
yves@0
|
564 information with an LDIF file. Users of LDIF files must take care to
|
|
yves@0
|
565 verify the integrity of an LDIF file received from an external
|
|
yves@0
|
566 source.
|
|
yves@0
|
567
|
|
yves@1
|
568 Contributors
|
|
yves@1
|
569 Gordon Good was the author of [RFC2849] which defined LDIF. Most
|
|
yves@1
|
570 of this specification is a copy of [RFC2849], simply adding full
|
|
yves@1
|
571 support for UTF-8 and editing according to newer RFC standards.
|
|
yves@1
|
572
|
|
yves@0
|
573 Acknowledgments
|
|
yves@0
|
574
|
|
yves@0
|
575 The LDAP Interchange Format was developed as part of the University
|
|
yves@0
|
576 of Michigan LDAP reference implementation, and was developed by Tim
|
|
yves@0
|
577 Howes, Mark Smith, and Gordon Good. It is based in part upon work
|
|
yves@0
|
578 supported by the National Science Foundation under Grant No. NCR-
|
|
yves@0
|
579 9416667.
|
|
yves@0
|
580
|
|
yves@0
|
581 Members of the IETF LDAP Extensions Working group provided many
|
|
yves@1
|
582 helpful suggestions. In particular, Hallvard B. Furuseth of the
|
|
yves@0
|
583 University of Oslo made many significant contributions to this
|
|
yves@0
|
584 document, including a thorough review and rewrite of the BNF.
|
|
yves@0
|
585
|
|
yves@1
|
586 Normative References
|
|
yves@0
|
587
|
|
yves@1
|
588 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
|
|
yves@1
|
589 Specifications: ABNF", RFC 2234, November 1997.
|
|
yves@0
|
590
|
|
yves@1
|
591 [RFC2253] Wahl, M., Kille, S. and T. Howes, "A String
|
|
yves@1
|
592 Representation of Distinguished Names", RFC 2253,
|
|
yves@1
|
593 December 1997.
|
|
yves@0
|
594
|
|
yves@1
|
595 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
|
|
yves@1
|
596 Access Protocol (v3)", RFC 2251, July 1997.
|
|
yves@0
|
597
|
|
yves@1
|
598 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
|
|
yves@1
|
599 Extensions (MIME) Part One: Format of Internet Message
|
|
yves@1
|
600 Bodies", RFC 2045, November 1996.
|
|
yves@0
|
601
|
|
yves@1
|
602 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
|
|
yves@1
|
603 Resource Locators (URL)", RFC 1738, December 1994.
|
|
yves@0
|
604
|
|
yves@1
|
605 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
|
|
yves@1
|
606 Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|
yves@0
|
607
|
|
yves@1
|
608 [RFC3629] Yergeau, F., "UTF-8, a transformation format
|
|
yves@1
|
609 of ISO 10646", November 2003
|
|
yves@0
|
610
|
|
yves@0
|
611
|
|
yves@1
|
612
|
|
yves@1
|
613
|
|
yves@1
|
614 Informative References
|
|
yves@1
|
615
|
|
yves@1
|
616 [RFC2849] Good, G., "The LDAP Data Interchange Format",
|
|
yves@1
|
617 RFC 2849, June 2000.
|
|
yves@1
|
618
|
|
yves@1
|
619 [RFC2425] Howes, T. and M. Smith, "A MIME Content-Type for Directory
|
|
yves@1
|
620 Information", RFC 2425, September 1998.
|
|
yves@1
|
621
|
|
yves@1
|
622 [Armijo00] M. P. Armijo, "Tree Delete Control", Work in Progress.
|
|
yves@1
|
623 August 2000.
|
|
yves@1
|
624
|
|
yves@1
|
625 [UMich96] The SLAPD and SLURPD Administrators Guide. University of
|
|
yves@1
|
626 Michigan, April 1996. <URL:
|
|
yves@1
|
627 http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
|
|
yves@1
|
628
|
|
yves@1
|
629 [RFC2223] Postel, J. and Reynolds, J., "Instructions to RFC
|
|
yves@1
|
630 Authors", RFC2223, October 1997.
|
|
yves@0
|
631
|
|
yves@0
|
632 Author's Address
|
|
yves@0
|
633
|
|
yves@0
|
634 Gordon Good
|
|
yves@0
|
635 iPlanet e-commerce Solutions
|
|
yves@0
|
636 150 Network Circle
|
|
yves@0
|
637 Mailstop USCA17-201
|
|
yves@0
|
638 Santa Clara, CA 95054, USA
|
|
yves@0
|
639
|
|
yves@0
|
640 Phone: +1 408 276 4351
|
|
yves@0
|
641 EMail: ggood@netscape.com
|
|
yves@0
|
642
|
|
yves@1
|
643 Intellectual Property
|
|
yves@0
|
644
|
|
yves@1
|
645 The IETF takes no position regarding the validity or scope of any
|
|
yves@1
|
646 Intellectual Property Rights or other rights that might be claimed
|
|
yves@1
|
647 to pertain to the implementation or use of the technology
|
|
yves@1
|
648 described in this document or the extent to which any license
|
|
yves@1
|
649 under such rights might or might not be available; nor does it
|
|
yves@1
|
650 represent that it has made any independent effort to identify any
|
|
yves@1
|
651 such rights. Information on the ISOC's procedures with respect to
|
|
yves@1
|
652 rights in ISOC Documents can be found in BCP 78 and BCP 79.
|
|
yves@0
|
653
|
|
yves@1
|
654 Copies of IPR disclosures made to the IETF Secretariat and any
|
|
yves@1
|
655 assurances of licenses to be made available, or the result of an
|
|
yves@1
|
656 attempt made to obtain a general license or permission for the use
|
|
yves@1
|
657 of such proprietary rights by implementers or users of this
|
|
yves@1
|
658 specification can be obtained from the IETF on-line IPR repository
|
|
yves@1
|
659 at http://www.ietf.org/ipr.
|
|
yves@0
|
660
|
|
yves@1
|
661 The IETF invites any interested party to bring to its attention
|
|
yves@1
|
662 any copyrights, patents or patent applications, or other
|
|
yves@1
|
663 proprietary rights that may cover technology that may be required
|
|
yves@1
|
664 to implement this standard. Please address the information to the
|
|
yves@1
|
665 IETF at ietf-ipr@ietf.org.
|
|
yves@1
|
666
|
|
yves@1
|
667 Disclaimer of Validity
|
|
yves@0
|
668
|
|
yves@0
|
669 This document and the information contained herein is provided on an
|
|
yves@0
|
670 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
yves@0
|
671 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
yves@0
|
672 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
yves@0
|
673 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
yves@0
|
674 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|
yves@0
|
675
|
|
yves@1
|
676 Copyright Statement
|
|
yves@1
|
677
|
|
yves@1
|
678 Copyright (C) The IETF Trust (2009).
|
|
yves@1
|
679
|
|
yves@1
|
680 This document is subject to the rights, licenses and restrictions
|
|
yves@1
|
681 contained in BCP 78, and except as set forth therein, the authors
|
|
yves@1
|
682 retain all their rights.
|
|
yves@1
|
683
|
|
yves@0
|
684 Acknowledgement
|
|
yves@0
|
685
|
|
yves@0
|
686 Funding for the RFC Editor function is currently provided by the
|
|
yves@0
|
687 Internet Society.
|
|
yves@0
|
688
|
|
yves@0
|
689
|
|
yves@0
|
690
|
