The introductory draft.

Seems to work, but no formal testing (not even on examples from RFC)
were done.

1 files changed, 787 insertions, 0 deletions

diff --git a/rfc2849.txt b/rfc2849.txt
new file mode 100644
index 0000000..2bf6455
--- /dev/null
+++ b/rfc2849.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                             G. Good
+Request for Comments: 2849                   iPlanet e-commerce Solutions
+Category: Standards Track                                       June 2000
+
+
+   The LDAP Data Interchange Format (LDIF) - Technical Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document describes a file format suitable for describing
+   directory information or modifications made to directory information.
+   The file format, known as LDIF, for LDAP Data Interchange Format, is
+   typically used to import and export directory information between
+   LDAP-based directory servers, or to describe a set of changes which
+   are to be applied to a directory.
+
+Background and Intended Usage
+
+   There are a number of situations where a common interchange format is
+   desirable.  For example, one might wish to export a copy of the
+   contents of a directory server to a file, move that file to a
+   different machine, and import the contents into a second directory
+   server.
+
+   Additionally, by using a well-defined interchange format, development
+   of data import tools from legacy systems is facilitated.  A fairly
+   simple set of tools written in awk or perl can, for example, convert
+   a database of personnel information into an LDIF file. This file can
+   then be imported into a directory server, regardless of the internal
+   database representation the target directory server uses.
+
+   The LDIF format was originally developed and used in the University
+   of Michigan LDAP implementation.  The first use of LDIF was in
+   describing directory entries.  Later, the format was expanded to
+   allow representation of changes to directory entries.
+
+
+
+
+Good                        Standards Track                     [Page 1]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+   Relationship to the application/directory MIME content-type:
+
+   The application/directory MIME content-type [1] is a general
+   framework and format for conveying directory information, and is
+   independent of any particular directory service.  The LDIF format is
+   a simpler format which is perhaps easier to create, and may also be
+   used, as noted, to describe a set of changes to be applied to a
+   directory.
+
+   The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
+   used in this document are to be interpreted as described in [7].
+
+Definition of the LDAP Data Interchange Format
+
+   The LDIF format is used to convey directory information, or a
+   description of a set of changes made to directory entries.  An LDIF
+   file consists of a series of records separated by line separators.  A
+   record consists of a sequence of lines describing a directory entry,
+   or a sequence of lines describing a set of changes to a directory
+   entry.  An LDIF file specifies a set of directory entries, or a set
+   of changes to be applied to directory entries, but not both.
+
+   There is a one-to-one correlation between LDAP operations that modify
+   the directory (add, delete, modify, and modrdn), and the types of
+   changerecords described below ("add", "delete", "modify", and
+   "modrdn" or "moddn").  This correspondence is intentional, and
+   permits a straightforward translation from LDIF changerecords to
+   protocol operations.
+
+Formal Syntax Definition of LDIF
+
+   The following definition uses the augmented Backus-Naur Form
+   specified in RFC 2234 [2].
+
+ldif-file                = ldif-content / ldif-changes
+
+ldif-content             = version-spec 1*(1*SEP ldif-attrval-record)
+
+ldif-changes             = version-spec 1*(1*SEP ldif-change-record)
+
+ldif-attrval-record      = dn-spec SEP 1*attrval-spec
+
+ldif-change-record       = dn-spec SEP *control changerecord
+
+version-spec             = "version:" FILL version-number
+
+
+
+
+
+
+Good                        Standards Track                     [Page 2]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+version-number           = 1*DIGIT
+                           ; version-number MUST be "1" for the
+                           ; LDIF format described in this document.
+
+dn-spec                  = "dn:" (FILL distinguishedName /
+                                  ":" FILL base64-distinguishedName)
+
+distinguishedName        = SAFE-STRING
+                           ; a distinguished name, as defined in [3]
+
+base64-distinguishedName = BASE64-UTF8-STRING
+                           ; a distinguishedName which has been base64
+                           ; encoded (see note 10, below)
+
+rdn                      = SAFE-STRING
+                           ; a relative distinguished name, defined as
+                           ; <name-component> in [3]
+
+base64-rdn               = BASE64-UTF8-STRING
+                           ; an rdn which has been base64 encoded (see
+                           ; note 10, below)
+
+control                  = "control:" FILL ldap-oid        ; controlType
+                           0*1(1*SPACE ("true" / "false")) ; criticality
+                           0*1(value-spec)                ; controlValue
+                           SEP
+                           ; (See note 9, below)
+
+ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
+                           ; An LDAPOID, as defined in [4]
+
+attrval-spec             = AttributeDescription value-spec SEP
+
+value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
+                                ":" FILL (BASE64-STRING) /
+                                "<" FILL url)
+                           ; See notes 7 and 8, below
+
+url                      = <a Uniform Resource Locator,
+                            as defined in [6]>
+                                   ; (See Note 6, below)
+
+AttributeDescription     = AttributeType [";" options]
+                           ; Definition taken from [4]
+
+AttributeType            = ldap-oid / (ALPHA *(attr-type-chars))
+
+options                  = option / (option ";" options)
+
+
+
+Good                        Standards Track                     [Page 3]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+option                   = 1*opt-char
+
+attr-type-chars          = ALPHA / DIGIT / "-"
+
+opt-char                 = attr-type-chars
+
+changerecord             = "changetype:" FILL
+                           (change-add / change-delete /
+                            change-modify / change-moddn)
+
+change-add               = "add"                SEP 1*attrval-spec
+
+change-delete            = "delete"             SEP
+
+change-moddn             = ("modrdn" / "moddn") SEP
+                            "newrdn:" (    FILL rdn /
+                                       ":" FILL base64-rdn) SEP
+                            "deleteoldrdn:" FILL ("0" / "1")  SEP
+                            0*1("newsuperior:"
+                            (    FILL distinguishedName /
+                             ":" FILL base64-distinguishedName) SEP)
+
+change-modify            = "modify"             SEP *mod-spec
+
+mod-spec                 = ("add:" / "delete:" / "replace:")
+                           FILL AttributeDescription SEP
+                           *attrval-spec
+                           "-" SEP
+
+SPACE                    = %x20
+                           ; ASCII SP, space
+
+FILL                     = *SPACE
+
+SEP                      = (CR LF / LF)
+
+CR                       = %x0D
+                           ; ASCII CR, carriage return
+
+LF                       = %x0A
+                           ; ASCII LF, line feed
+
+ALPHA                    = %x41-5A / %x61-7A
+                           ; A-Z / a-z
+
+DIGIT                    = %x30-39
+                           ; 0-9
+
+
+
+
+Good                        Standards Track                     [Page 4]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+UTF8-1                   = %x80-BF
+
+UTF8-2                   = %xC0-DF UTF8-1
+
+UTF8-3                   = %xE0-EF 2UTF8-1
+
+UTF8-4                   = %xF0-F7 3UTF8-1
+
+UTF8-5                   = %xF8-FB 4UTF8-1
+
+UTF8-6                   = %xFC-FD 5UTF8-1
+
+SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
+                           ; any value <= 127 decimal except NUL, LF,
+                           ; and CR
+
+SAFE-INIT-CHAR           = %x01-09 / %x0B-0C / %x0E-1F /
+                           %x21-39 / %x3B / %x3D-7F
+                           ; any value <= 127 except NUL, LF, CR,
+                           ; SPACE, colon (":", ASCII 58 decimal)
+                           ; and less-than ("<" , ASCII 60 decimal)
+
+SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]
+
+UTF8-CHAR                = SAFE-CHAR / UTF8-2 / UTF8-3 /
+                           UTF8-4 / UTF8-5 / UTF8-6
+
+UTF8-STRING              = *UTF8-CHAR
+
+BASE64-UTF8-STRING       = BASE64-STRING
+                           ; MUST be the base64 encoding of a
+                           ; UTF8-STRING
+
+BASE64-CHAR              = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
+                           %x61-7A
+                           ; +, /, 0-9, =, A-Z, and a-z
+                           ; as specified in [5]
+
+BASE64-STRING            = [*(BASE64-CHAR)]
+
+
+   Notes on LDIF Syntax
+
+      1)  For the LDIF format described in this document, the version
+          number MUST be "1". If the version number is absent,
+          implementations MAY choose to interpret the contents as an
+          older LDIF file format, supported by the University of
+          Michigan ldap-3.3 implementation [8].
+
+
+
+Good                        Standards Track                     [Page 5]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+      2)  Any non-empty line, including comment lines, in an LDIF file
+          MAY be folded by inserting a line separator (SEP) and a SPACE.
+          Folding MUST NOT occur before the first character of the line.
+          In other words, folding a line into two lines, the first of
+          which is empty, is not permitted. Any line that begins with a
+          single space MUST be treated as a continuation of the previous
+          (non-empty) line. When joining folded lines, exactly one space
+          character at the beginning of each continued line must be
+          discarded. Implementations SHOULD NOT fold lines in the middle
+          of a multi-byte UTF-8 character.
+
+      3)  Any line that begins with a pound-sign ("#", ASCII 35) is a
+          comment line, and MUST be ignored when parsing an LDIF file.
+
+      4)  Any dn or rdn that contains characters other than those
+          defined as "SAFE-UTF8-CHAR", or begins with a character other
+          than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be
+          base-64 encoded.  Other values MAY be base-64 encoded.  Any
+          value that contains characters other than those defined as
+          "SAFE-CHAR", or begins with a character other than those
+          defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
+          Other values MAY be base-64 encoded.
+
+      5)  When a zero-length attribute value is to be included directly
+          in an LDIF file, it MUST be represented as
+          AttributeDescription ":" FILL SEP.  For example, "seeAlso:"
+          followed by a newline represents a zero-length "seeAlso"
+          attribute value.  It is also permissible for the value
+          referred to by a URL to be of zero length.
+
+      6) When a URL is specified in an attrval-spec, the following
+          conventions apply:
+
+         a) Implementations SHOULD support the file:// URL format.  The
+            contents of the referenced file are to be included verbatim
+            in the interpreted output of the LDIF file.
+         b) Implementations MAY support other URL formats.  The
+            semantics associated with each supported URL will be
+            documented in an associated Applicability Statement.
+
+      7)  Distinguished names, relative distinguished names, and
+          attribute values of DirectoryString syntax MUST be valid UTF-8
+          strings.  Implementations that read LDIF MAY interpret files
+          in which these entities are stored in some other character set
+          encoding, but implementations MUST NOT generate LDIF content
+          which does not contain valid UTF-8 data.
+
+
+
+
+
+Good                        Standards Track                     [Page 6]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+      8)  Values or distinguished names that end with SPACE SHOULD be
+          base-64 encoded.
+
+      9)  When controls are included in an LDIF file, implementations
+          MAY choose to ignore some or all of them. This may be
+          necessary if the changes described in the LDIF file are being
+          sent on an LDAPv2 connection (LDAPv2 does not support
+          controls), or the particular controls are not supported by the
+          remote server. If the criticality of a control is "true", then
+          the implementation MUST either include the control, or MUST
+          NOT send the operation to a remote server.
+
+      10) When an attrval-spec, distinguishedName, or rdn is base64-
+          encoded, the encoding rules specified in [5] are used with the
+          following exceptions:  a) The requirement that base64 output
+          streams must be represented as lines of no more than 76
+          characters is removed. Lines in LDIF files may only be folded
+          according to the folding rules described in note 2, above.  b)
+          Base64 strings in [5] may contain characters other than those
+          defined in BASE64-CHAR, and are ignored. LDIF does not permit
+          any extraneous characters, other than those used for line
+          folding.
+
+Examples of LDAP Data Interchange Format
+
+Example 1: An simple LDAP file with two entries
+
+version: 1
+dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Barbara Jensen
+cn: Barbara J Jensen
+cn: Babs Jensen
+sn: Jensen
+uid: bjensen
+telephonenumber: +1 408 555 1212
+description: A big sailing fan.
+
+dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Bjorn Jensen
+sn: Jensen
+telephonenumber: +1 408 555 1212
+
+
+
+
+Good                        Standards Track                     [Page 7]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+Example 2: A file containing an entry with a folded attribute value
+
+version: 1
+dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
+objectclass:top
+objectclass:person
+objectclass:organizationalPerson
+cn:Barbara Jensen
+cn:Barbara J Jensen
+cn:Babs Jensen
+sn:Jensen
+uid:bjensen
+telephonenumber:+1 408 555 1212
+description:Babs is a big sailing fan, and travels extensively in sea
+ rch of perfect sailing conditions.
+title:Product Manager, Rod and Reel Division
+
+Example 3: A file containing a base-64-encoded value
+
+version: 1
+dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Gern Jensen
+cn: Gern O Jensen
+sn: Jensen
+uid: gernj
+telephonenumber: +1 408 555 1212
+description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
+IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
+VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
+b3V0IG1vcmUu
+
+Example 4: A file containing an entries with UTF-8-encoded attribute
+values, including language tags.  Comments indicate the contents
+of UTF-8-encoded attributes and distinguished names.
+
+version: 1
+dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
+# dn:: ou=<JapaneseOU>,o=Airius
+objectclass: top
+objectclass: organizationalUnit
+ou:: 5Za25qWt6YOo
+# ou:: <JapaneseOU>
+ou;lang-ja:: 5Za25qWt6YOo
+# ou;lang-ja:: <JapaneseOU>
+ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
+
+
+
+Good                        Standards Track                     [Page 8]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
+ou;lang-en: Sales
+description: Japanese office
+
+dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
+# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
+userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+objectclass: inetOrgPerson
+uid: rogasawara
+mail: rogasawara@airius.co.jp
+givenname;lang-ja:: 44Ot44OJ44OL44O8
+# givenname;lang-ja:: <JapaneseGivenname>
+sn;lang-ja:: 5bCP56yg5Y6f
+# sn;lang-ja:: <JapaneseSn>
+cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
+# cn;lang-ja:: <JapaneseCn>
+title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
+# title;lang-ja:: <JapaneseTitle>
+preferredlanguage: ja
+givenname:: 44Ot44OJ44OL44O8
+# givenname:: <JapaneseGivenname>
+sn:: 5bCP56yg5Y6f
+# sn:: <JapaneseSn>
+cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
+# cn:: <JapaneseCn>
+title:: 5Za25qWt6YOoIOmDqOmVtw==
+# title:: <JapaneseTitle>
+givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
+# givenname;lang-ja;phonetic::
+<JapaneseGivenname_in_phonetic_representation_kana>
+sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
+# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
+cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
+# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
+title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
+# title;lang-ja;phonetic::
+# <JapaneseTitle_in_phonetic_representation_kana>
+givenname;lang-en: Rodney
+sn;lang-en: Ogasawara
+cn;lang-en: Rodney Ogasawara
+title;lang-en: Sales, Director
+
+
+
+
+
+
+
+Good                        Standards Track                     [Page 9]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+Example 5: A file containing a reference to an external file
+
+version: 1
+dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Horatio Jensen
+
+cn: Horatio N Jensen
+sn: Jensen
+uid: hjensen
+telephonenumber: +1 408 555 1212
+jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
+
+Example 6: A file containing a series of change records and comments
+
+version: 1
+# Add a new entry
+dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
+changetype: add
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Fiona Jensen
+sn: Jensen
+uid: fiona
+telephonenumber: +1 408 555 1212
+jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
+
+# Delete an existing entry
+dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
+changetype: delete
+
+# Modify an entry's relative distinguished name
+dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
+changetype: modrdn
+newrdn: cn=Paula Jensen
+deleteoldrdn: 1
+
+# Rename an entry and move all of its children to a new location in
+# the directory tree (only implemented by LDAPv3 servers).
+dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
+changetype: modrdn
+newrdn: ou=Product Development Accountants
+deleteoldrdn: 0
+newsuperior: ou=Accounting, dc=airius, dc=com
+
+
+
+
+Good                        Standards Track                    [Page 10]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+# Modify an entry: add an additional value to the postaladdress
+# attribute, completely delete the description attribute, replace
+# the telephonenumber attribute with two values, and delete a specific
+# value from the facsimiletelephonenumber attribute
+dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
+changetype: modify
+add: postaladdress
+postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
+-
+
+delete: description
+-
+replace: telephonenumber
+telephonenumber: +1 408 555 1234
+telephonenumber: +1 408 555 5678
+-
+delete: facsimiletelephonenumber
+facsimiletelephonenumber: +1 408 555 9876
+-
+
+# Modify an entry: replace the postaladdress attribute with an empty
+# set of values (which will cause the attribute to be removed), and
+# delete the entire description attribute. Note that the first will
+# always succeed, while the second will only succeed if at least
+# one value for the description attribute is present.
+dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
+changetype: modify
+replace: postaladdress
+-
+delete: description
+-
+
+Example 7: An LDIF file containing a change record with a control
+version: 1
+# Delete an entry. The operation will attach the LDAPv3
+# Tree Delete Control defined in [9]. The criticality
+# field is "true" and the controlValue field is
+# absent, as required by [9].
+dn: ou=Product Development, dc=airius, dc=com
+control: 1.2.840.113556.1.4.805 true
+changetype: delete
+
+
+
+
+
+
+
+
+
+
+Good                        Standards Track                    [Page 11]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+Security Considerations
+
+   Given typical directory applications, an LDIF file is likely to
+   contain sensitive personal data.  Appropriate measures should be
+   taken to protect the privacy of those persons whose data is contained
+   in an LDIF file.
+
+   Since ":<" directives can cause external content to be included when
+   processing an LDIF file, one should be cautious of accepting LDIF
+   files from external sources.  A "trojan" LDIF file could name a file
+   with sensitive contents and cause it to be included in a directory
+   entry, which a hostile entity could read via LDAP.
+
+   LDIF does not provide any method for carrying authentication
+   information with an LDIF file.  Users of LDIF files must take care to
+   verify the integrity of an LDIF file received from an external
+   source.
+
+Acknowledgments
+
+   The LDAP Interchange Format was developed as part of the University
+   of Michigan LDAP reference implementation, and was developed by Tim
+   Howes, Mark Smith, and Gordon Good.  It is based in part upon work
+   supported by the National Science Foundation under Grant No.  NCR-
+   9416667.
+
+   Members of the IETF LDAP Extensions Working group provided many
+   helpful suggestions. In particular, Hallvard B. Furuseth of the
+   University of Oslo made many significant contributions to this
+   document, including a thorough review and rewrite of the BNF.
+
+References
+
+   [1]  Howes, T. and M. Smith, "A MIME Content-Type for Directory
+        Information", RFC 2425, September 1998.
+
+   [2]  Crocker, D., and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [3]  Wahl, M., Kille, S. and T. Howes, "A String Representation of
+        Distinguished Names", RFC 2253, December 1997.
+
+   [4]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+        Protocol (v3)", RFC 2251, July 1997.
+
+   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part One: Format of Internet Message Bodies",
+        RFC 2045, November 1996.
+
+
+
+Good                        Standards Track                    [Page 12]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+   [6]  Berners-Lee,  T., Masinter, L. and M. McCahill, "Uniform
+        Resource Locators (URL)", RFC 1738, December 1994.
+
+   [7]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [8]  The SLAPD and SLURPD Administrators Guide.  University of
+        Michigan, April 1996.  <URL:
+        http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
+
+   [9]  M. P. Armijo, "Tree Delete Control", Work in Progress.
+
+Author's Address
+
+   Gordon Good
+   iPlanet e-commerce Solutions
+   150 Network Circle
+   Mailstop USCA17-201
+   Santa Clara, CA 95054, USA
+
+   Phone: +1 408 276 4351
+   EMail:  ggood@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Good                        Standards Track                    [Page 13]
+
+RFC 2849              LDAP Data Interchange Format             June 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Good                        Standards Track                    [Page 14]
+