idnits 2.17.1 draft-good-ldap-ldif-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 15 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], [9], [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 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 (19 October 1999) is 8954 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: '6' is defined on line 718, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2245 (ref. '1') (Obsoleted by RFC 4505) ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2253 (ref. '3') (Obsoleted by RFC 4510, RFC 4514) ** 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' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 13 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 LDAP Data Interchange Format (LDIF) Gordon Good 2 INTERNET-DRAFT Netscape Communications 3 Status: Standards-Track 19 October 1999 5 The LDAP Data Interchange Format (LDIF) - Technical Specification 6 Filename: draft-good-ldap-ldif-05.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 To view the list Internet-Draft Shadow Directories, see 25 http://www.ietf.org/shadow.html. 27 This Internet Draft expires 19 April, 2000. 29 Abstract 31 This document describes a file format suitable for describing 32 directory information or modifications made to directory information. 33 The file format, known as LDIF, for LDAP Data Interchange Format, is 34 typically used to import and export directory information between 35 LDAP-based directory servers, or to describe a set of changes which 36 are to be applied to a directory. 38 Background and Intended Usage 40 There are a number of situations where a common interchange format is 41 desirable. For example, one might wish to export a copy of the 42 contents of a directory server to a file, move that file to a 43 different machine, and import the contents into a second directory 44 server. 46 Additionally, by using a well-defined interchange format, development 47 of data import tools from legacy systems is facilitated. A fairly 48 simple set of tools written in awk or perl can, for example, convert 49 a database of personnel information into an LDIF file. This file can 50 then be imported into a directory server, regardless of the internal 51 database representation the target directory server uses. 53 The LDIF format was originally developed and used in the University 54 of Michigan LDAP implementation. The first use of LDIF was in 55 describing directory entries. Later, the format was expanded to 56 allow representation of changes to directory entries. 58 Relationship to the application/directory MIME content-type: 60 The application/directory MIME content-type [1] is a general 61 framework and format for conveying directory information, and is 62 independent of any particular directory service. The LDIF format is 63 a simpler format which is perhaps easier to create, and may also be 64 used, as noted, to describe a set of changes to be applied to a 65 directory. 67 The key words "MUST", "MAY", and "SHOULD" used in this document are 68 to be interpreted as described in [7]. 70 Definition of the LDAP Data Interchange Format 72 The LDIF format is used to convey directory information, or a 73 description of a set of changes made to directory entries. An LDIF 74 file consists of a series of records separated by line separators. A 75 record consists of a sequence of lines describing a directory entry, 76 or a sequence of lines describing a set of changes to a directory 77 entry. An LDIF file specifies a set of directory entries, or a set 78 of changes to be applied to directory entries, but not both. 80 There is a one-to-one correlation between LDAP operations that modify 81 the directory (add, delete, modify, and modrdn), and the types of 82 changerecords described below ("add", "delete", "modify", and 83 "modrdn" or "moddn"). This correspondence is intentional, and 84 permits a straightforward translation from LDIF changerecords to 85 protocol operations. 87 Formal Syntax Definition of LDIF 89 The following definition uses the augmented Backus-Naur Form 90 specified in RFC 2234 [2]. 92 ldif-file = ldif-content / ldif-changes 93 ldif-content = version-spec 1*(1*SEP ldif-attrval-record) 95 ldif-changes = version-spec 1*(1*SEP ldif-change-record) 97 ldif-attrval-record = dn-spec SEP 1*attrval-spec 99 ldif-change-record = dn-spec SEP *control changerecord 101 version-spec = "version:" FILL version-number 103 version-number = 1*DIGIT 104 ; version-number MUST be "1" for the 105 ; LDIF format described in this document. 107 dn-spec = "dn:" (FILL distinguishedName / 108 ":" FILL base64-distinguishedName) 110 distinguishedName = SAFE-UTF8-STRING 111 ; a distinguished name, as defined in [3] 113 base64-distinguishedName = BASE64-UTF8-STRING 114 ; a distinguishedName which has been base64 115 ; encoded (see note 10, below) 117 rdn = SAFE-UTF8-STRING 118 ; a relative distinguished name, defined as 119 ; in [3] 121 base64-rdn = BASE64-UTF8-STRING 122 ; an rdn which has been base64 encoded (see 123 ; note 10, below) 125 control = "control:" FILL ldap-oid ; controlType 126 0*1(1*SPACE ("true" / "false")) ; criticality 127 0*1(value-spec) ; controlValue 128 SEP 129 ; (See note 9, below) 131 ldap-oid = 1*DIGIT 0*1("." 1*DIGIT) 132 ; An LDAPOID, as defined in [4] 134 attrval-spec = AttributeDescription value-spec SEP 136 value-spec = ":" ( FILL 0*1(SAFE-STRING) / 137 ":" FILL (BASE64-STRING) / 138 "<" FILL url) 139 ; See notes 7 and 8, below 141 url = 142 ; (See Note 6, below) 144 AttributeDescription = AttributeType [";" options] 145 ; Definition taken from [4] 147 AttributeType = ldap-oid / (ALPHA *(attr-type-chars)) 149 options = option / (option ";" options) 151 option = 1*opt-char 153 attr-type-chars = ALPHA / DIGIT / "-" 155 opt-char = attr-type-chars 157 changerecord = "changetype:" FILL 158 (change-add / change-delete / 159 change-modify / change-moddn) 161 change-add = "add" SEP 1*attrval-spec 163 change-delete = "delete" SEP 165 change-moddn = ("modrdn" / "moddn") SEP 166 "newrdn:" ( FILL rdn / 167 ":" FILL base64-rdn) SEP 168 "deleteoldrdn:" FILL ("0" / "1") SEP 169 0*1("newsuperior:" 170 ( FILL distinguishedName / 171 ":" FILL base64-distinguishedName) SEP) 173 change-modify = "modify" SEP *mod-spec 175 mod-spec = ("add:" / "delete:" / "replace:") 176 FILL AttributeDescription SEP 177 *attrval-spec 178 "-" SEP 180 SPACE = %x20 181 ; ASCII SP, space 183 FILL = *SPACE 185 SEP = (CR LF / LF) 187 CR = %x0D 188 ; ASCII CR, carriage return 190 LF = %x0A 191 ; ASCII LF, line feed 193 ALPHA = %x41-5A / %x61-7A 194 ; A-Z / a-z 196 DIGIT = %x30-39 197 ; 0-9 199 UTF8-1 = %x80-BF 201 UTF8-2 = %xC0-DF UTF8-1 203 UTF8-3 = %xE0-EF 2UTF8-1 205 UTF8-4 = %xF0-F7 3UTF8-1 207 UTF8-5 = %xF8-FB 4UTF8-1 209 UTF8-6 = %xFC-FD 5UTF8-1 211 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F 212 ; any value <= 127 decimal except NUL, LF, and CR 214 SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / 215 %x21-39 / %x3B / %x3D-7F 216 ; any value <= 127 except NUL, LF, CR, 217 ; SPACE, colon (":", ASCII 58 decimal) 218 ; and less-than ("<" , ASCII 60 decimal) 220 SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR] 222 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / 223 UTF8-4 / UTF8-5 / UTF8-6 225 SAFE-INIT-UTF8-CHAR = SAFE-INIT-CHAR / UTF8-2 / UTF8-3 / 226 UTF8-4 / UTF8-5 / UTF8-6 228 SAFE-UTF8-STRING = [SAFE-INIT-UTF8-CHAR *SAFE-UTF8-CHAR] 230 BASE64-UTF8-STRING = BASE64-STRING 231 ; MUST be the base64 encoding of a valid 232 ; string of UTF-8 characters 234 BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / %x61-7A 235 ; +, /, 0-9, =, A-Z, and a-z 236 ; as specified in [5] 238 BASE64-STRING = [*(BASE64-CHAR)] 240 Notes on LDIF Syntax 242 1) For the LDIF format described in this document, the version number 243 MUST be "1". If the version number is absent, implementations MAY 244 choose to interpret the contents as an older LDIF file format, 245 supported by the University of Michigan ldap-3.3 implementation [8]. 247 2) Any non-empty line, including comment lines, in an LDIF file MAY 248 be folded by inserting a line separator (SEP) and a SPACE. Folding 249 MUST NOT occur before the first character of the line. In other 250 words, folding a line into two lines, the first of which is empty, is 251 not permitted. Any line that begins with a single space MUST be 252 treated as a continuation of the previous (non-empty) line. When 253 joining folded lines, exactly one space character at the beginning of 254 each continued line must be discarded. Implementations SHOULD NOT 255 fold lines in the middle of a multi-byte UTF-8 character. 257 3) Any line that begins with a pound-sign ("#", ASCII 35) is a 258 comment line, and MUST be ignored when parsing an LDIF file. 260 4) Any dn or rdn that contains characters other than those defined as 261 "SAFE-UTF8-CHAR", or begins with a character other than those defined 262 as "SAFE-INIT-UTF8-CHAR", above, MUST be base-64 encoded. Other 263 values MAY be base-64 encoded. Any value that contains characters 264 other than those defined as "SAFE-CHAR", or begins with a character 265 other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 266 encoded. Other values MAY be base-64 encoded. 268 5) When a zero-length attribute value is to be included directly in 269 an LDIF file, it MUST be represented as AttributeDescription ":" FILL 270 SEP. For example, "seeAlso:" followed by a newline represents a 271 zero-length "seeAlso" attribute value. It is also permissible for 272 the value referred to by a URL to be of zero length. 274 6) When a URL is specified in an attrval-spec, the following 275 conventions apply: 276 a) Implementations SHOULD support the file:// URL format. The 277 contents of the referenced file are to be included verbatim 278 in the interpreted output of the LDIF file. 279 b) Implementations MAY support other URL formats. The semantics 280 associated with each supported URL will be documented in 281 an associated Applicability Statement. 283 7) Distinguished names, relative distinguished names, and attribute 284 values of DirectoryString syntax MUST be valid UTF-8 strings. 286 Implementations that read LDIF MAY interpret files in which these 287 entities are stored in some other character set encoding, but 288 implementations MUST NOT generate LDIF content which does not contain 289 valid UTF-8 data. 291 8) Values or distinguished names that end with SPACE SHOULD be base- 292 64 encoded. 294 9) When controls are included in an LDIF file, implementations MAY 295 choose to ignore some or all of them. This may be necessary if the 296 changes described in the LDIF file are being sent on an LDAPv2 297 connection (LDAPv2 does not support controls), or the particular 298 controls are not supported by the remote server. If the criticality 299 of a control is "true", then the implementation MUST either include 300 the control, or MUST NOT send the operation to a remote server. 302 10) When an attrval-spec, distinguishedName, or rdn is base64- 303 encoded, the encoding rules specified in [5] are used with the 304 following exceptions: a) The requirement that base64 output streams 305 must be represented as lines of no more than 76 characters is 306 removed. Lines in LDIF files may only be folded according to the 307 folding rules described in note 2, above. b) Base64 strings in [5] 308 may contain characters other than those defined in BASE64-CHAR, and 309 are ignored. LDIF does not permit any extraneous characters, other 310 than those used for line folding. 312 Examples of LDAP Data Interchange Format 314 Example 1: An simple LDAP file with two entries 316 version: 1 317 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com 318 objectclass: top 319 objectclass: person 320 objectclass: organizationalPerson 321 cn: Barbara Jensen 322 cn: Barbara J Jensen 323 cn: Babs Jensen 324 sn: Jensen 325 uid: bjensen 326 telephonenumber: +1 408 555 1212 327 description: A big sailing fan. 329 dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com 330 objectclass: top 331 objectclass: person 332 objectclass: organizationalPerson 333 cn: Bjorn Jensen 334 sn: Jensen 335 telephonenumber: +1 408 555 1212 337 Example 2: A file containing an entry with a folded attribute value 339 version: 1 340 dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com 341 objectclass:top 342 objectclass:person 343 objectclass:organizationalPerson 344 cn:Barbara Jensen 345 cn:Barbara J Jensen 346 cn:Babs Jensen 347 sn:Jensen 348 uid:bjensen 349 telephonenumber:+1 408 555 1212 350 description:Babs is a big sailing fan, and travels extensively in sea 351 rch of perfect sailing conditions. 352 title:Product Manager, Rod and Reel Division 354 Example 3: A file containing a base-64-encoded value 356 version: 1 357 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com 358 objectclass: top 359 objectclass: person 360 objectclass: organizationalPerson 361 cn: Gern Jensen 362 cn: Gern O Jensen 363 sn: Jensen 364 uid: gernj 365 telephonenumber: +1 408 555 1212 366 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ 367 hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0ICh 368 hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu 370 Example 4: A file containing an entries with UTF-8-encoded attribute 371 values, including language tags. Comments indicate the contents 372 of UTF-8-encoded attributes and distinguished names. 374 version: 1 375 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz 376 # dn:: ou=,o=Airius 377 objectclass: top 378 objectclass: organizationalUnit 379 ou:: 5Za25qWt6YOo 380 # ou:: 381 ou;lang-ja:: 5Za25qWt6YOo 382 # ou;lang-ja:: 383 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 384 # ou;lang-ja:: 385 ou;lang-en: Sales 386 description: Japanese office 388 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz 389 # dn:: uid=,ou=,o=Airius 390 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= 391 objectclass: top 392 objectclass: person 393 objectclass: organizationalPerson 394 objectclass: inetOrgPerson 395 uid: rogasawara 396 mail: rogasawara@airius.co.jp 397 givenname;lang-ja:: 44Ot44OJ44OL44O8 398 # givenname;lang-ja:: 399 sn;lang-ja:: 5bCP56yg5Y6f 400 # sn;lang-ja:: 401 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 402 # cn;lang-ja:: 403 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw== 404 # title;lang-ja:: 405 preferredlanguage: ja 406 givenname:: 44Ot44OJ44OL44O8 407 # givenname:: 408 sn:: 5bCP56yg5Y6f 409 # sn:: 410 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 411 # cn:: 412 title:: 5Za25qWt6YOoIOmDqOmVtw== 413 # title:: 414 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 415 # givenname;lang-ja;phonetic:: 416 417 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ 418 # sn;lang-ja;phonetic:: 419 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA== 420 # cn;lang-ja;phonetic:: 421 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg== 422 # title;lang-ja;phonetic:: 423 givenname;lang-en: Rodney 424 sn;lang-en: Ogasawara 425 cn;lang-en: Rodney Ogasawara 426 title;lang-en: Sales, Director 428 Example 5: A file containing a reference to an external file 429 version: 1 430 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com 431 objectclass: top 432 objectclass: person 433 objectclass: organizationalPerson 434 cn: Horatio Jensen 435 cn: Horatio N Jensen 436 sn: Jensen 437 uid: hjensen 438 telephonenumber: +1 408 555 1212 439 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg 441 Example 6: A file containing a series of change records and comments 443 version: 1 444 # Add a new entry 445 dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com 446 changetype: add 447 objectclass: top 448 objectclass: person 449 objectclass: organizationalPerson 450 cn: Fiona Jensen 451 sn: Jensen 452 uid: fiona 453 telephonenumber: +1 408 555 1212 454 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg 456 # Delete an existing entry 457 dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com 458 changetype: delete 460 # Modify an entry's relative distinguished name 461 dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com 462 changetype: modrdn 463 newrdn: cn=Paula Jensen 464 deleteoldrdn: 1 466 # Rename an entry and move all of its children to a new location in 467 # the directory tree (only implemented by LDAPv3 servers). 468 dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com 469 changetype: modrdn 470 newrdn: ou=Product Development Accountants 471 deleteoldrdn: 0 472 newsuperior: ou=Accounting, dc=airius, dc=com 474 # Modify an entry: add an additional value to the postaladdress attribute, 475 # completely delete the description attribute, replace the telephonenumber 476 # attribute with two values, and delete a specific value from the 477 # facsimiletelephonenumber attribute 478 dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com 479 changetype: modify 480 add: postaladdress 481 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 482 - 483 delete: description 484 - 485 replace: telephonenumber 486 telephonenumber: +1 408 555 1234 487 telephonenumber: +1 408 555 5678 488 - 489 delete: facsimiletelephonenumber 490 facsimiletelephonenumber: +1 408 555 9876 491 - 493 # Modify an entry: replace the postaladdress attribute with an empty 494 # set of values (which will cause the attribute to be removed), and 495 # delete the entire description attribute. Note that the first will 496 # always succeed, while the second will only succeed if at least 497 # one value for the description attribute is present. 498 dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com 499 changetype: modify 500 replace: postaladdress 501 - 502 delete: description 503 - 505 Example 7: An LDIF file containing a change record with a control 506 version: 1 507 # Delete an entry. The operation will attach the LDAPv3 508 # Tree Delete Control defined in [9]. The criticality 509 # field is "true" and the controlValue field is 510 # absent, as required by [9]. 511 dn: ou=Product Development, dc=airius, dc=com 512 control: 1.2.840.113556.1.4.805 true 513 changetype: delete 515 Security Considerations 517 Given typical directory applications, an LDIF file is likely to 518 contain sensitive personal data. Appropriate measures should be 519 taken to protect the privacy of those persons whose data is contained 520 in an LDIF file. 522 Since ":<" directives can cause external content to be included when 523 processing an LDIF file, one should be cautious of accepting LDIF 524 files from external sources. A "trojan" LDIF file could name a file 525 with sensitive contents and cause it to be included in a directory 526 entry, which a hostile entity could read via LDAP. 528 LDIF does not provide any method for carrying authentication 529 information with an LDIF file. Users of LDIF files must take care to 530 verify the integrity of an LDIF file received from an external 531 source. 533 Appendix A: Differences from previous versions of this document 535 This section summarizes the differences between previous revisions of 536 this draft, as an aid to document reviewers. This section will be 537 deleted prior to publication as an RFC. 539 Differences between draft-ietf-asid-ldif-00.txt and draft-ietf-asid- 540 ldif-01.txt 542 1) The BNF has been modified to explicitly disallow ldif content and 543 change records in the same file. In other words, a given LDIF file 544 is either a series of directory entries, or a series of 545 modifications. An LDIF file MUST NOT contain both types of records. 547 2) External references are now URLs, instead of simple filenames. 549 3) The BNF has been modified to allow base-64-encoded distinguished 550 names. 552 4) Multiple separators are now permitted between records. 554 Differences between draft-ietf-asid-ldif-01.txt and draft-ietf-asid- 555 ldif-02.txt 557 1) The BNF has been modified such that a simple attribute name 558 ("attrname") has been replaced with an "attribute-description" as 559 defined in the LDAPv3 protocol document [4]. This permits language 560 codes and other attribute options to be carried in an LDIF file. 562 2) A new option, "charset", may be used in attribute descriptions. 563 This facilitates multi-lingual character set conversion. 565 3) The definition of the "safe" and "safe-initval" productions has 566 been relaxed to allow non-ASCII characters with values greater than 567 126. This permits more natural expression of character sets such as 568 Latin-1 in LDIF files. 570 Differences between draft-ietf-asid-ldif-02.txt and draft-good-ldap- 571 ldif-00.txt 572 1) The "charset-option" and "charset-name" productions were removed 573 from the BNF, due to objections within the working group. UTF-8 is 574 the only character set that may be used in LDIF. 576 2) Examples were reworked to reflect the above change, and to include 577 an example of a non-western language represented in UTF-8. 579 Differences between draft-ietf-good-ldif-00.txt and draft-good-ldap- 580 ldif-01.txt 582 1) Added version identifiers to the examples - they were missing. 584 2) Clarified that LDIF files must use UTF-8. 586 Differences between draft-good-ldap-ldif-01.txt and draft-good-ldap- 587 ldif-02.txt 589 1) Added a recommendation that values ending in SPACE should be 590 base-64 encoded. 592 2) Clarified the procedure for joining folded lines. 594 3) Updated header to reflect new IETF I-D guidelines. 596 Differences between draft-good-ldap-ldif-02.txt and draft-good-ldap- 597 ldif-03.txt 599 1) Fixed reference from RFC 1779 to RFC 2253. 601 2) Version string is now required. 603 3) Comment lines may be folded (this is now explicitly mentioned in 604 note 2). 606 4) Moved this section (differences between draft versions) to an 607 appendix. 609 5) Updated examples to use "dc=airius, dc=com" instead of "o=Ace 610 Industry, c=US" 612 6) Cleaned up references section. 614 Differences between draft-good-ldap-ldif-03.txt and draft-good-ldap- 615 ldif-04.txt 617 1) The grammar now requires that an LDIF file end with one or more 618 SEP sequences (newlines). This was inadvertently prohibited in 619 earlier revisions of the grammar. 621 2) Several minor spelling and typographical errors were fixed. 623 3) Reworked the grammar to make it more readable. Hallvard Furuseth 624 (University of Oslo) provided the new BNF. 626 4) Excluded NUL from "safe" production. 628 5) Changed "0,1*xxx" "0*1xxx" in compliance with RFC822. 630 6) Fixed a glitch in the grammar that allowed multiple changetypes 631 within a single LDIF change record. The intent is that only one 632 changetype per change record is permitted. 634 7) Fixed a mistake in example 2 (folded attribute value). 636 8) The BNF now explicitly requires that zero-length attribute values 637 be encoded as attribute-description ":" FILL SEP. 639 9) Factored "changetype: FILL" out of the productions for change-add, 640 change-delete, change-moddn, and change-modify. 642 10) RFC 2251 permits an LDAP modify operation with no modifications, 643 and also permits an attribute with no values. Although it's unclear 644 what the purpose of these constructs might be, I altered the BNF to 645 allow these to be described in LDIF. 647 11) The BNF may now carry LDAP v3 controls in ldif-change-records. 648 The "value-spec" production was factored out to allow it to be used 649 in the definition of a control. 651 12) Clarified the rules for line-folding to prohibit a line from 652 being folded into two lines, the first of which is empty. This 653 guarantees that the sequence SEP SEP terminates an LDIF record, and 654 allows, for example, "perl -n00" to be used to read an entire LDIF 655 record into the $_ variable. 657 Differences between draft-good-ldap-ldif-04.txt and draft-good-ldap- 658 ldif-05.txt 660 1) The grammar has been rewritten to use the RFC2234 ABNF, replacing 661 the RFC822 ABNF. 663 2) The grammar makes fewer uses of . 665 3) DNs, RDNs, and attribute values with DirectoryString are now 666 explicitly called out as UTF-8 strings. 668 4) An error in the BNF for "control" was fixed. 670 5) An additional ldif-change-record was added to example 6. 672 6) Since RFC 1521 defines base-64 encoding with different folding 673 rules, and permits illegal characters (which should be ignored), an 674 explanatory note has been added. This note explains that lines must 675 be folded according to LDIF rules, not RFC 1521 rules, and that 676 extraneous characters are not permitted. 678 7) DNs, values, and rdns containing octets > 127 must be base-64 679 encoded. 681 Acknowledgments 683 The LDAP Interchange Format was developed as part of the University 684 of Michigan LDAP reference implementation, and was developed by Tim 685 Howes, Mark Smith, and Gordon Good. It is based in part upon work 686 supported by the National Science Foundation under Grant No. NCR- 687 9416667. 689 Members of the IETF LDAP Extensions Working group provided many 690 helpful suggestions. In particular, Hallvard B. Furuseth of the 691 University of Oslo made many significant contributions to this 692 document, including a thorough review and rewrite of the BNF. 694 References 696 [1] Howes, T., Smith, M., "A MIME Content-Type for Directory Infor- 697 mation", RFC 2425, September 1998, 698 700 [2] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifica- 701 tions: ABNF" , RFC 2234, November 1997, 702 704 [3] Wahl, M., Kille, S., Howes, T., "A String Representation of Dis- 705 tinguished Names", RFC 2253, 706 708 [4] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access 709 Protocol (v3)", RFC 2251, July, 1997, 710 712 [5] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail 713 Extensions) Part One: Mechanisms for Specifying and Describing 714 the Format of Internet Message Bodies", section 5.2, "Base64 715 Content-Transfer-Encoding", RFC 1521, December 1993, 716 718 [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 719 Locators (URL)", RFC 1738, December 1994, 720 722 [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement 723 Levels", Harvard University, RFC 2119, March 1997, 724 726 [8] The SLAPD and SLURPD Administrators Guide. University of Michi- 727 gan, April 1996. 730 [9] M. P. Armijo, "Tree Delete Control", Microsoft Corporation, 731 INTERNET-DRAFT June 1999, 734 Author's Address 736 Gordon Good 737 Netscape Communications Corp. 738 501 E. Middlefield Rd. 739 Mailstop MV068 740 Mountain View, CA 94043, USA 741 Phone: +1 650 937-3825 742 EMail: ggood@netscape.com 744 This Internet Draft expires 19 April, 2000.