1
2
3
4
5
6
7Network Working Group                                             G. Good
8Request for Comments: 2849                   iPlanet e-commerce Solutions
9Category: Standards Track                                       June 2000
10
11
12   The LDAP Data Interchange Format (LDIF) - Technical Specification
13
14Status 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
22Copyright Notice
23
24   Copyright (C) The Internet Society (2000).  All Rights Reserved.
25
26Abstract
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
35Background 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
58Good                        Standards Track                     [Page 1]
59
60RFC 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
75Definition 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
92Formal Syntax Definition of LDIF
93
94   The following definition uses the augmented Backus-Naur Form
95   specified in RFC 2234 [2].
96
97ldif-file                = ldif-content / ldif-changes
98
99ldif-content             = version-spec 1*(1*SEP ldif-attrval-record)
100
101ldif-changes             = version-spec 1*(1*SEP ldif-change-record)
102
103ldif-attrval-record      = dn-spec SEP 1*attrval-spec
104
105ldif-change-record       = dn-spec SEP *control changerecord
106
107version-spec             = "version:" FILL version-number
108
109
110
111
112
113
114Good                        Standards Track                     [Page 2]
115
116RFC 2849              LDAP Data Interchange Format             June 2000
117
118
119version-number           = 1*DIGIT
120                           ; version-number MUST be "1" for the
121                           ; LDIF format described in this document.
122
123dn-spec                  = "dn:" (FILL distinguishedName /
124                                  ":" FILL base64-distinguishedName)
125
126distinguishedName        = SAFE-STRING
127                           ; a distinguished name, as defined in [3]
128
129base64-distinguishedName = BASE64-UTF8-STRING
130                           ; a distinguishedName which has been base64
131                           ; encoded (see note 10, below)
132
133rdn                      = SAFE-STRING
134                           ; a relative distinguished name, defined as
135                           ; <name-component> in [3]
136
137base64-rdn               = BASE64-UTF8-STRING
138                           ; an rdn which has been base64 encoded (see
139                           ; note 10, below)
140
141control                  = "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
147ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
148                           ; An LDAPOID, as defined in [4]
149
150attrval-spec             = AttributeDescription value-spec SEP
151
152value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
153                                ":" FILL (BASE64-STRING) /
154                                "<" FILL url)
155                           ; See notes 7 and 8, below
156
157url                      = <a Uniform Resource Locator,
158                            as defined in [6]>
159                                   ; (See Note 6, below)
160
161AttributeDescription     = AttributeType [";" options]
162                           ; Definition taken from [4]
163
164AttributeType            = ldap-oid / (ALPHA *(attr-type-chars))
165
166options                  = option / (option ";" options)
167
168
169
170Good                        Standards Track                     [Page 3]
171
172RFC 2849              LDAP Data Interchange Format             June 2000
173
174
175option                   = 1*opt-char
176
177attr-type-chars          = ALPHA / DIGIT / "-"
178
179opt-char                 = attr-type-chars
180
181changerecord             = "changetype:" FILL
182                           (change-add / change-delete /
183                            change-modify / change-moddn)
184
185change-add               = "add"                SEP 1*attrval-spec
186
187change-delete            = "delete"             SEP
188
189change-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
197change-modify            = "modify"             SEP *mod-spec
198
199mod-spec                 = ("add:" / "delete:" / "replace:")
200                           FILL AttributeDescription SEP
201                           *attrval-spec
202                           "-" SEP
203
204SPACE                    = %x20
205                           ; ASCII SP, space
206
207FILL                     = *SPACE
208
209SEP                      = (CR LF / LF)
210
211CR                       = %x0D
212                           ; ASCII CR, carriage return
213
214LF                       = %x0A
215                           ; ASCII LF, line feed
216
217ALPHA                    = %x41-5A / %x61-7A
218                           ; A-Z / a-z
219
220DIGIT                    = %x30-39
221                           ; 0-9
222
223
224
225
226Good                        Standards Track                     [Page 4]
227
228RFC 2849              LDAP Data Interchange Format             June 2000
229
230
231UTF8-1                   = %x80-BF
232
233UTF8-2                   = %xC0-DF UTF8-1
234
235UTF8-3                   = %xE0-EF 2UTF8-1
236
237UTF8-4                   = %xF0-F7 3UTF8-1
238
239UTF8-5                   = %xF8-FB 4UTF8-1
240
241UTF8-6                   = %xFC-FD 5UTF8-1
242
243SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
244                           ; any value <= 127 decimal except NUL, LF,
245                           ; and CR
246
247SAFE-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
253SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]
254
255UTF8-CHAR                = SAFE-CHAR / UTF8-2 / UTF8-3 /
256                           UTF8-4 / UTF8-5 / UTF8-6
257
258UTF8-STRING              = *UTF8-CHAR
259
260BASE64-UTF8-STRING       = BASE64-STRING
261                           ; MUST be the base64 encoding of a
262                           ; UTF8-STRING
263
264BASE64-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
269BASE64-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
282Good                        Standards Track                     [Page 5]
283
284RFC 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
338Good                        Standards Track                     [Page 6]
339
340RFC 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
366Examples of LDAP Data Interchange Format
367
368Example 1: An simple LDAP file with two entries
369
370version: 1
371dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
372objectclass: top
373objectclass: person
374objectclass: organizationalPerson
375cn: Barbara Jensen
376cn: Barbara J Jensen
377cn: Babs Jensen
378sn: Jensen
379uid: bjensen
380telephonenumber: +1 408 555 1212
381description: A big sailing fan.
382
383dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
384objectclass: top
385objectclass: person
386objectclass: organizationalPerson
387cn: Bjorn Jensen
388sn: Jensen
389telephonenumber: +1 408 555 1212
390
391
392
393
394Good                        Standards Track                     [Page 7]
395
396RFC 2849              LDAP Data Interchange Format             June 2000
397
398
399Example 2: A file containing an entry with a folded attribute value
400
401version: 1
402dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
403objectclass:top
404objectclass:person
405objectclass:organizationalPerson
406cn:Barbara Jensen
407cn:Barbara J Jensen
408cn:Babs Jensen
409sn:Jensen
410uid:bjensen
411telephonenumber:+1 408 555 1212
412description:Babs is a big sailing fan, and travels extensively in sea
413 rch of perfect sailing conditions.
414title:Product Manager, Rod and Reel Division
415
416Example 3: A file containing a base-64-encoded value
417
418version: 1
419dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
420objectclass: top
421objectclass: person
422objectclass: organizationalPerson
423cn: Gern Jensen
424cn: Gern O Jensen
425sn: Jensen
426uid: gernj
427telephonenumber: +1 408 555 1212
428description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
429IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
430VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
431b3V0IG1vcmUu
432
433Example 4: A file containing an entries with UTF-8-encoded attribute
434values, including language tags.  Comments indicate the contents
435of UTF-8-encoded attributes and distinguished names.
436
437version: 1
438dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
439# dn:: ou=<JapaneseOU>,o=Airius
440objectclass: top
441objectclass: organizationalUnit
442ou:: 5Za25qWt6YOo
443# ou:: <JapaneseOU>
444ou;lang-ja:: 5Za25qWt6YOo
445# ou;lang-ja:: <JapaneseOU>
446ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
447
448
449
450Good                        Standards Track                     [Page 8]
451
452RFC 2849              LDAP Data Interchange Format             June 2000
453
454
455# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
456ou;lang-en: Sales
457description: Japanese office
458
459dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
460# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
461userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
462objectclass: top
463objectclass: person
464objectclass: organizationalPerson
465objectclass: inetOrgPerson
466uid: rogasawara
467mail: rogasawara@airius.co.jp
468givenname;lang-ja:: 44Ot44OJ44OL44O8
469# givenname;lang-ja:: <JapaneseGivenname>
470sn;lang-ja:: 5bCP56yg5Y6f
471# sn;lang-ja:: <JapaneseSn>
472cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
473# cn;lang-ja:: <JapaneseCn>
474title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
475# title;lang-ja:: <JapaneseTitle>
476preferredlanguage: ja
477givenname:: 44Ot44OJ44OL44O8
478# givenname:: <JapaneseGivenname>
479sn:: 5bCP56yg5Y6f
480# sn:: <JapaneseSn>
481cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
482# cn:: <JapaneseCn>
483title:: 5Za25qWt6YOoIOmDqOmVtw==
484# title:: <JapaneseTitle>
485givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
486# givenname;lang-ja;phonetic::
487<JapaneseGivenname_in_phonetic_representation_kana>
488sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
489# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
490cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
491# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
492title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
493# title;lang-ja;phonetic::
494# <JapaneseTitle_in_phonetic_representation_kana>
495givenname;lang-en: Rodney
496sn;lang-en: Ogasawara
497cn;lang-en: Rodney Ogasawara
498title;lang-en: Sales, Director
499
500
501
502
503
504
505
506Good                        Standards Track                     [Page 9]
507
508RFC 2849              LDAP Data Interchange Format             June 2000
509
510
511Example 5: A file containing a reference to an external file
512
513version: 1
514dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
515objectclass: top
516objectclass: person
517objectclass: organizationalPerson
518cn: Horatio Jensen
519
520cn: Horatio N Jensen
521sn: Jensen
522uid: hjensen
523telephonenumber: +1 408 555 1212
524jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
525
526Example 6: A file containing a series of change records and comments
527
528version: 1
529# Add a new entry
530dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
531changetype: add
532objectclass: top
533objectclass: person
534objectclass: organizationalPerson
535cn: Fiona Jensen
536sn: Jensen
537uid: fiona
538telephonenumber: +1 408 555 1212
539jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
540
541# Delete an existing entry
542dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
543changetype: delete
544
545# Modify an entry's relative distinguished name
546dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
547changetype: modrdn
548newrdn: cn=Paula Jensen
549deleteoldrdn: 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).
553dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
554changetype: modrdn
555newrdn: ou=Product Development Accountants
556deleteoldrdn: 0
557newsuperior: ou=Accounting, dc=airius, dc=com
558
559
560
561
562Good                        Standards Track                    [Page 10]
563
564RFC 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
571dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
572changetype: modify
573add: postaladdress
574postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
575-
576
577delete: description
578-
579replace: telephonenumber
580telephonenumber: +1 408 555 1234
581telephonenumber: +1 408 555 5678
582-
583delete: facsimiletelephonenumber
584facsimiletelephonenumber: +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.
592dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
593changetype: modify
594replace: postaladdress
595-
596delete: description
597-
598
599Example 7: An LDIF file containing a change record with a control
600version: 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].
605dn: ou=Product Development, dc=airius, dc=com
606control: 1.2.840.113556.1.4.805 true
607changetype: delete
608
609
610
611
612
613
614
615
616
617
618Good                        Standards Track                    [Page 11]
619
620RFC 2849              LDAP Data Interchange Format             June 2000
621
622
623Security 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
641Acknowledgments
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
654References
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
674Good                        Standards Track                    [Page 12]
675
676RFC 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
691Author'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
730Good                        Standards Track                    [Page 13]
731
732RFC 2849              LDAP Data Interchange Format             June 2000
733
734
735Full 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
763Acknowledgement
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
786Good                        Standards Track                    [Page 14]
787
788