diff options
Diffstat (limited to 'source4')
| -rw-r--r-- | source4/ldap_server/devdocs/rfc2849.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/source4/ldap_server/devdocs/rfc2849.txt b/source4/ldap_server/devdocs/rfc2849.txt new file mode 100644 index 0000000000..2bf645500a --- /dev/null +++ b/source4/ldap_server/devdocs/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] + |