idnits 2.17.1 draft-good-ldap-ldif-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: attrval-spec = attribute-description ((":") / (":" *SPACE value) / ("::" *SPACE base64-value) / (":<" *SPACE url)) url = ; (See Note 6, below) attribute-description = value = 1*safe-initval *safe safe = safe-initval = base64-value = -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (11 March 1998) is 9542 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 449, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 458, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 464, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-asid-mime-direct-06 ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1779 (ref. '3') (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 2251 (ref. '4') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 1521 (ref. '5') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LDAP Data Interchange Format (LDIF) Gordon Good 3 INTERNET-DRAFT Netscape Communications 4 11 March 1998 6 The LDAP Data Interchange Format (LDIF) - Technical Specification 7 Filename: draft-good-ldap-ldif-00.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ds.internic.net (US East Coast), 25 nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 26 munnari.oz.au (Pacific Rim). 28 This Internet Draft expires October 1st, 1998. 30 Abstract 32 This document describes a file format suitable for describing 33 directory information or modifications made to directory information. 34 The file format, known as LDIF, for LDAP Data Interchange Format, is 35 typically used to import and export directory information between 36 LDAP-based directory servers, or to describe a set of changes which 37 are to be applied to a directory. 39 Background and Intended Usage 41 There are a number of situations where a common interchange format is 42 desirable. For example, one might wish to export a copy of the 43 contents of a directory server to a file, move that file to a 44 different machine, and import the contents into a second directory 45 server. 47 Additionally, by using a well-defined interchange format, development 48 of data import tools from legacy systems is facilitated. A fairly 49 simple set of tools written in awk or perl can, for example, convert 50 a database of personnel information into an LDIF file, which can then 51 be imported into a directory server, regardless of the internal 52 database representation the target directory server uses. 54 The LDIF format was originally developed and used in the University 55 of Michigan LDAP implementation. The first use of LDIF was in 56 describing directory entries. Later, the format was expanded to 57 allow representation of changes to directory entries. 59 Relationship to the application/directory MIME content-type: 61 The application/directory MIME content-type [1] is a general 62 framework and format for conveying directory information, and is 63 independent of any particular directory service. It is preferred, in 64 most cases, to LDIF, for conveying directory information. The LDIF 65 format is a simpler format which is perhaps easier to create, and 66 also may be used, as noted, to describe a set of changes to be 67 applied to a directory. 69 The key words "MUST", "MAY", and "SHOULD" used in this document are 70 to be interpreted as described in [7]. 72 Definition of the LDAP Data Interchange Format 74 The LDIF format is used to convey directory information, or a 75 description of a set of changes made to directory entries. An LDIF 76 file consists of a series of records separated by line separators. A 77 record consists of a sequence of lines describing a directory entry, 78 or a sequence of lines describing a set of changes to a single 79 directory entry. An LDIF file specifies a set of directory entries, 80 or a set of changes to be applied to directory entries, but not both. 82 There is a one-to-one correlation between LDAP operations which 83 modify the directory (add, delete, modify, and modrdn), and the types 84 of changerecords described below ("add", "delete", "modify", and 85 "modrdn" or "moddn"). This correspondence is intentional, and 86 permits a straightforward translation from LDIF changerecords to 87 protocol operations. 89 Formal Syntax Definition of LDIF 91 The following definition uses the augmented Backus-Naur Form 92 specified in RFC 822 [2]. 94 ldif-file = ldif-content / ldif-changes 95 ldif-content = 0,1*(version-spec 1*SEP) 96 ldif-attrval-record *(1*SEP ldif-attrval-record) 97 ldif-changes = 0,1*(version-spec 1*SEP) 98 ldif-change-record *(1*SEP ldif-change-record) 99 ldif-attrval-record = dn-spec SEP 1*(attrval-spec SEP) 100 ldif-change-record = dn-spec SEP 1*(changerecord SEP) 102 version-spec = "version:" *SPACE version-number 103 version-number = 1*DIGIT ; version-number MUST be "1" for the 104 ; LDIF format described in this document. 106 dn-spec = ("dn:" *SPACE dn) / ("dn::" *SPACE base64-dn) 107 dn = 108 base64-dn = 110 rdn = 112 base64-rdn = 115 attrval-spec = attribute-description ((":") / (":" *SPACE value) / 116 ("::" *SPACE base64-value) / 117 (":<" *SPACE url)) 118 url = 119 ; (See Note 6, below) 120 attribute-description = 123 value = 1*safe-initval *safe 124 safe = 125 safe-initval = 128 base64-value = 130 changerecord = change-add / change-delete / change-modify / 131 change-moddn 132 change-add = "changetype:" *SPACE "add" 1*(SEP attrval-spec) 133 change-delete = "changetype:" *SPACE "delete" 134 change-moddn = "changetype:" *SPACE ("modrdn" / "moddn") SEP 135 ("newrdn:" *SPACE rdn / 136 "newrdn::" *SPACE base-64-rdn) SEP 137 "deleteoldrdn:" *SPACE ("0" / "1") 138 0,1*(SEP (("newsuperior:" *SPACE dn) / 139 ("newsuperior:: *SPACE base-64-dn))) 140 change-modify = "changetype:" *SPACE "modify" 1*(SEP mod-spec) 141 mod-spec = mod-add-spec / mod-delete-spec / mod-replace-spec 142 mod-add-spec = "add:" *SPACE attribute-description 143 1*(SEP attrval-spec) SEP "-" 144 mod-delete-spec = "delete:" *SPACE attribute-description 145 *(SEP attrval-spec) SEP "-" 146 mod-replace-spec = "replace:" *SPACE attribute-description 147 *(SEP attrval-spec) SEP "-" 148 SPACE = 149 SEP = (CR LF / LF) 150 CR = 151 LF = 152 DIGIT = 154 Notes on LDIF Syntax 156 1) The version number is optional. If absent, version 0 is assumed, 157 which corresponds to the version of LDIF supported by the University 158 of Michigan ldap-3.3 reference implementation [8]. For the LDIF 159 format described in this document, the version number MUST be "1". 161 2) Any line in an LDIF file MAY be wrapped by inserting a line 162 separator (SEP) and a SPACE. Any line which begins with a single 163 space MUST be treated as a continuation of the previous line. 165 3) Any line which begins with a pound-sign ("#", ASCII 35) is a 166 comment line, and MUST be ignored when parsing an LDIF file. 168 4) Any dn or value which contains characters other than those defined 169 as "safe," or begins with a character other than those defined as 170 "safe-initval", above, MUST be base-64 encoded. Other values MAY be 171 base-64 encoded. 173 5) To represent a zero-length attribute value, use an attrval-spec of 174 "attribute-description:". For example, "seeAlso:" represents a 175 zero-length "seeAlso" attribute value. 177 6) When a URL is specified in an attrval-spec, the following 178 conventions apply: 179 a) Implementations SHOULD support the file:// URL format. The 180 contents of the referenced file are to be included verbatim 181 in the interpreted output of the LDIF file. 182 b) Implementations MAY support other URL formats. The semantics 183 associated with each supported URL will be documented in 184 an associated Applicability Statement. 186 7) While it is permissible for character values larger than 126 to be 187 contained in an attribute value, implementations SHOULD base-64 188 encode any value which contains such characters when generating LDIF. 190 However, implementations MAY leave the values unencoded. This 191 relaxation is designed to allow editing of LDIF files containing, for 192 example, Latin-1 content, with existing tools. 194 Differences from previous versions of this document 196 Differences between draft-ietf-asid-ldif-00.txt and draft-ietf-asid- 197 ldif-01.txt 199 1) The BNF has been modified to explicitly disallow ldif content and 200 change records in the same file. In other words, a given LDIF file 201 is either a series of directory entries, or a series of 202 modifications. An LDIF file MUST NOT contain both types of records. 204 2) External references are now URLs, instead of simple filenames. 206 3) The BNF has been modified to allow base-64-encoded distinguished 207 names. 209 4) Multiple separators are now permitted between records. 211 Differences between draft-ietf-asid-ldif-01.txt and draft-ietf-asid- 212 ldif-02.txt 214 1) The BNF has been modified such that a simple attribute name 215 ("attrname") has been replaced with an "attribute-description" as 216 defined in the LDAPv3 protocol document [4]. This permits language 217 codes and other attribute options to be carried in an LDIF file. 219 2) A new option, "charset", may be used in attribute descriptions. 220 This facilitates multi-lingual character set conversion. 222 3) The definition of the "safe" and "safe-initval" productions has 223 been relaxed to allow non-ASCII characters with values greater than 224 126. This permits more natural expression of character sets such as 225 Latin-1 in LDIF files. 227 Differences between draft-ietf-asid-ldif-02.txt and draft-good-ldap- 228 ldif-03.txt 230 1) The "charset-option" and "charset-name" productions were removed 231 from the BNF, due to objections within the working group. UTF-8 is 232 the only character set which may be used in LDIF. 234 2) Examples were reworked to reflect the above change, and to include 235 an example of a non-western language represented in UTF-8. 237 Examples of LDAP Data Interchange Format 238 Example 1: An simple LDAP file with two entries 240 dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 241 objectclass: top 242 objectclass: person 243 objectclass: organizationalPerson 244 cn: Barbara Jensen 245 cn: Barbara J Jensen 246 cn: Babs Jensen 247 sn: Jensen 248 uid: bjensen 249 telephonenumber: +1 408 555 1212 250 description: A big sailing fan. 252 dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US 253 objectclass: top 254 objectclass: person 255 objectclass: organizationalPerson 256 cn: Bjorn Jensen 257 sn: Jensen 258 telephonenumber: +1 408 555 1212 260 Example 2: A file containing an entry with a folded attribute value 262 dn:cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 263 objectclass:top 264 objectclass:person 265 objectclass:organizationalPerson 266 cn:Barbara Jensen 267 cn:Barbara J Jensen 268 cn:Babs Jensen 269 sn:Jensen 270 uid:bjensen 271 telephonenumber:+1 408 555 1212 272 description:Babs is a big sailing fan, and travels extensively in search of 273 perfect sailing conditions. 274 title:Product Manager, Rod and Reel Division 276 Example 3: A file containing a base-64-encoded value 278 dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US 279 objectclass: top 280 objectclass: person 281 objectclass: organizationalPerson 282 cn: Gern Jensen 283 cn: Gern O Jensen 284 sn: Jensen 285 uid: gernj 286 telephonenumber: +1 408 555 1212 287 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ 288 hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0ICh 289 hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu 291 Example 4: A file containing an entries with UTF-8-encoded attribute 292 values, including language tags. Comments indicate the contents 293 of UTF-8-encoded attributes and distinguished names. 295 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz 296 # dn:: ou=,o=Airius 297 objectclass: top 298 objectclass: organizationalUnit 299 ou:: 5Za25qWt6YOo 300 # ou:: 301 ou;lang-ja:: 5Za25qWt6YOo 302 # ou;lang-ja:: 303 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 304 # ou;lang-ja:: 305 ou;lang-en: Sales 306 description: Japanese office 308 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz 309 # dn:: uid=,ou=,o=Airius 310 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= 311 objectclass: top 312 objectclass: person 313 objectclass: organizationalPerson 314 objectclass: inetOrgPerson 315 uid: rogasawara 316 mail: rogasawara@airius.co.jp 317 givenname;lang-ja:: 44Ot44OJ44OL44O8 318 # givenname;lang-ja:: 319 sn;lang-ja:: 5bCP56yg5Y6f 320 # sn;lang-ja:: 321 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 322 # cn;lang-ja:: 323 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw== 324 # title;lang-ja:: 325 preferredlanguage: ja 326 givenname:: 44Ot44OJ44OL44O8 327 # givenname:: 328 sn:: 5bCP56yg5Y6f 329 # sn:: 330 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 331 # cn:: 332 title:: 5Za25qWt6YOoIOmDqOmVtw== 333 # title:: 334 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 335 # givenname;lang-ja;phonetic:: 336 337 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ 338 # sn;lang-ja;phonetic:: 339 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA== 340 # cn;lang-ja;phonetic:: 341 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg== 342 # title;lang-ja;phonetic:: 343 givenname;lang-en: Rodney 344 sn;lang-en: Ogasawara 345 cn;lang-en: Rodney Ogasawara 346 title;lang-en: Sales, Director 348 Example 5: A file containing a reference to an external file 350 dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US 351 objectclass: top 352 objectclass: person 353 objectclass: organizationalPerson 354 cn: Horatio Jensen 355 cn: Horatio N Jensen 356 sn: Jensen 357 uid: hjensen 358 telephonenumber: +1 408 555 1212 359 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg 361 Example 6: A file containing a series of change records and comments 363 # Add a new entry 364 dn: cn=Fiona Jensen, ou=Marketing, o=Ace Industry, c=US 365 changetype: add 366 objectclass: top 367 objectclass: person 368 objectclass: organizationalPerson 369 cn: Fiona Jensen 370 sn: Jensen 371 uid: fiona 372 telephonenumber: +1 408 555 1212 373 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg 375 # Delete an existing entry 376 dn: cn=Robert Jensen, ou=Marketing, o=Ace Industry, c=US 377 changetype: delete 379 # Modify an entry's relative distinguished name 380 dn: cn=Paul Jensen, ou=Product Development, o=Ace Industry, c=US 381 changetype: modrdn 382 newrdn: cn=Paula Jensen 383 deleteoldrdn: 1 385 # Rename an entry and move all of its children to a new location in 386 # the directory tree (only implemented by LDAPv3 servers). 387 dn: ou=PD Accountants, ou=Product Development, o=Ace Industry, c=US 388 changetype: modrdn 389 newrdn: ou=Product Development Accountants 390 deleteoldrdn: 0 391 newsuperior: ou=Accounting, o=Ace Industry, c=US 393 # Modify an entry: add an additional value to the postaladdress attribute, 394 # completely delete the description attribute, replace the telephonenumber 395 # attribute with two values, and delete a specific value from the 396 # facsimiletelephonenumber attribute 397 dn: cn=Paula Jensen, ou=Product Development, o=Ace Industry, c=US 398 changetype: modify 399 add: postaladdress 400 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 401 - 402 delete: description 403 - 404 replace: telephonenumber 405 telephonenumber: +1 408 555 1234 406 telephonenumber: +1 408 555 5678 407 - 408 delete: facsimiletelephonenumber 409 facsimiletelephonenumber: +1 408 555 9876 410 - 412 Security Considerations 414 Given typical directory applications, an LDIF file is likely to 415 contain sensitive personal data. Appropriate measures should be 416 taken to protect the privacy of those persons whose data is contained 417 in an LDIF file. 419 Since ":<" directives can cause external content to be included when 420 processing an LDIF file, one should be cautious of accepting LDIF 421 files from external sources. A "trojan" LDIF file could name a file 422 with sensitive contents and cause it to be included in a directory 423 entry, which a hostile entity could read via LDAP. 425 LDIF does not provide any method for carrying authentication 426 information with an LDIF file. Users of LDIF files must take care to 427 verify the integrity of an LDIF file received from an external 428 source. 430 Acknowledgments 432 The LDAP Interchange Format was developed as part of the University 433 of Michigan LDAP reference implementation, and was developed by Tim 434 Howes, Mark Smith, and Gordon Good. It is based in part upon work 435 supported by the National Science Foundation under Grant No. NCR- 436 9416667. 438 References 440 [1] Howes, T., Smith, M., "A MIME Content-Type for Directory Infor- 441 mation", INTERNET-DRAFT draft-ietf-asid-mime-direct-06.txt, 442 Netscape Communications Corp., 445 [2] Crocker, D.H., "Standard for the Format of ARPA Internet Text 446 Messages", RFC 822, University of Delaware, August 1982, 447 449 [3] Kille, S., "A String Representation of Distinguished Names", RFC 450 1779, ISODE Consortium, March 1995, 451 453 [4] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access 454 Protocol (v3)", RFC 2251, Critical Angle, Inc., ISODE Consor- 455 tium, Netscape Communications Corp., July, 1997, 456 458 [5] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail 459 Extensions) Part One: Mechanisms for Specifying and Describing 460 the Format of Internet Message Bodies", section 5.2, "Base64 461 Content-Transfer-Encoding", RFC 1521, Bellcore, Innosoft, 462 December 1993, 464 [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 465 Locators (URL)", CERN, Xerox Corporation, University of Min- 466 nesota, Request for Comment (RFC) 1738, December 1994, 467 469 [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement 470 Levels", Harvard University, RFC 2119, March 1997, 471 473 [8] The SLAPD and SLURPD Administrators Guide. University of Michi- 474 gan, April 1996. 477 Author's Address 479 Gordon Good 480 Netscape Communications Corp. 481 501 E. Middlefield Rd. 482 Mailstop MV068 483 Mountain View, CA 94043, USA 484 Phone: +1 415 937-3825 485 EMail: ggood@netscape.com 487 This Internet Draft expires October 1st, 1998.