← Back to branch summary

~zulcss/samba/server-dailies-3.4

« back to all changes in this revision

Viewing changes to source4/ldap_server/devdocs/rfc2849.txt

  • Committer: Chuck Short
  • Date: 2010-09-28 20:38:39 UTC
  • Revision ID: zulcss@ubuntu.com-20100928203839-pgjulytsi9ue63x1
Initial version

Show diffs side-by-side

added added

removed removed

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