1 2 3 4 5 6 7 Network Working Group G. Good 8 Request for Comments: 2849 iPlanet e-commerce Solutions 9 Category: Standards Track June 2000 10 11 12 The LDAP Data Interchange Format (LDIF) - Technical Specification 13 14 Status of this Memo 15 16 This document specifies an Internet standards track protocol for the 17 Internet community, and requests discussion and suggestions for 18 improvements. Please refer to the current edition of the "Internet 19 Official Protocol Standards" (STD 1) for the standardization state 20 and status of this protocol. Distribution of this memo is unlimited. 21 22 Copyright Notice 23 24 Copyright (C) The Internet Society (2000). All Rights Reserved. 25 26 Abstract 27 28 This document describes a file format suitable for describing 29 directory information or modifications made to directory information. 30 The file format, known as LDIF, for LDAP Data Interchange Format, is 31 typically used to import and export directory information between 32 LDAP-based directory servers, or to describe a set of changes which 33 are to be applied to a directory. 34 35 Background and Intended Usage 36 37 There are a number of situations where a common interchange format is 38 desirable. For example, one might wish to export a copy of the 39 contents of a directory server to a file, move that file to a 40 different machine, and import the contents into a second directory 41 server. 42 43 Additionally, by using a well-defined interchange format, development 44 of data import tools from legacy systems is facilitated. A fairly 45 simple set of tools written in awk or perl can, for example, convert 46 a database of personnel information into an LDIF file. This file can 47 then be imported into a directory server, regardless of the internal 48 database representation the target directory server uses. 49 50 The LDIF format was originally developed and used in the University 51 of Michigan LDAP implementation. The first use of LDIF was in 52 describing directory entries. Later, the format was expanded to 53 allow representation of changes to directory entries. 54 55 56 57 58 Good Standards Track [Page 1] 59 61 RFC 2849 LDAP Data Interchange Format June 2000 62 63 64 Relationship to the application/directory MIME content-type: 65 66 The application/directory MIME content-type [1] is a general 67 framework and format for conveying directory information, and is 68 independent of any particular directory service. The LDIF format is 69 a simpler format which is perhaps easier to create, and may also be 70 used, as noted, to describe a set of changes to be applied to a 71 directory. 72 73 The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT" 74 used in this document are to be interpreted as described in [7]. 75 76 Definition of the LDAP Data Interchange Format 77 78 The LDIF format is used to convey directory information, or a 79 description of a set of changes made to directory entries. An LDIF 80 file consists of a series of records separated by line separators. A 81 record consists of a sequence of lines describing a directory entry, 82 or a sequence of lines describing a set of changes to a directory 83 entry. An LDIF file specifies a set of directory entries, or a set 84 of changes to be applied to directory entries, but not both. 85 86 There is a one-to-one correlation between LDAP operations that modify 87 the directory (add, delete, modify, and modrdn), and the types of 88 changerecords described below ("add", "delete", "modify", and 89 "modrdn" or "moddn"). This correspondence is intentional, and 90 permits a straightforward translation from LDIF changerecords to 91 protocol operations. 92 93 Formal Syntax Definition of LDIF 94 95 The following definition uses the augmented Backus-Naur Form 96 specified in RFC 2234 [2]. 97 98 ldif-file = ldif-content / ldif-changes 99 100 ldif-content = version-spec 1*(1*SEP ldif-attrval-record) 101 102 ldif-changes = version-spec 1*(1*SEP ldif-change-record) 103 104 ldif-attrval-record = dn-spec SEP 1*attrval-spec 105 106 ldif-change-record = dn-spec SEP *control changerecord 107 108 version-spec = "version:" FILL version-number 109 110 111 112 113 114 115 Good Standards Track [Page 2] 116 118 RFC 2849 LDAP Data Interchange Format June 2000 119 120 121 version-number = 1*DIGIT 122 ; version-number MUST be "1" for the 123 ; LDIF format described in this document. 124 125 dn-spec = "dn:" (FILL distinguishedName / 126 ":" FILL base64-distinguishedName) 127 128 distinguishedName = SAFE-STRING 129 ; a distinguished name, as defined in [3] 130 131 base64-distinguishedName = BASE64-UTF8-STRING 132 ; a distinguishedName which has been base64 133 ; encoded (see note 10, below) 134 135 rdn = SAFE-STRING 136 ; a relative distinguished name, defined as 137 ; <name-component> in [3] 138 139 base64-rdn = BASE64-UTF8-STRING 140 ; an rdn which has been base64 encoded (see 141 ; note 10, below) 142 143 control = "control:" FILL ldap-oid ; controlType 144 0*1(1*SPACE ("true" / "false")) ; criticality 145 0*1(value-spec) ; controlValue 146 SEP 147 ; (See note 9, below) 148 149 ldap-oid = 1*DIGIT 0*1("." 1*DIGIT) 150 ; An LDAPOID, as defined in [4] 151 152 attrval-spec = AttributeDescription value-spec SEP 153 154 value-spec = ":" ( FILL 0*1(SAFE-STRING) / 155 ":" FILL (BASE64-STRING) / 156 "<" FILL url) 157 ; See notes 7 and 8, below 158 159 url = <a Uniform Resource Locator, 160 as defined in [6]> 161 ; (See Note 6, below) 162 163 AttributeDescription = AttributeType [";" options] 164 ; Definition taken from [4] 165 166 AttributeType = ldap-oid / (ALPHA *(attr-type-chars)) 167 168 options = option / (option ";" options) 169 170 171 172 Good Standards Track [Page 3] 173 175 RFC 2849 LDAP Data Interchange Format June 2000 176 177 178 option = 1*opt-char 179 180 attr-type-chars = ALPHA / DIGIT / "-" 181 182 opt-char = attr-type-chars 183 184 changerecord = "changetype:" FILL 185 (change-add / change-delete / 186 change-modify / change-moddn) 187 188 change-add = "add" SEP 1*attrval-spec 189 190 change-delete = "delete" SEP 191 192 change-moddn = ("modrdn" / "moddn") SEP 193 "newrdn:" ( FILL rdn / 194 ":" FILL base64-rdn) SEP 195 "deleteoldrdn:" FILL ("0" / "1") SEP 196 0*1("newsuperior:" 197 ( FILL distinguishedName / 198 ":" FILL base64-distinguishedName) SEP) 199 200 change-modify = "modify" SEP *mod-spec 201 202 mod-spec = ("add:" / "delete:" / "replace:") 203 FILL AttributeDescription SEP 204 *attrval-spec 205 "-" SEP 206 207 SPACE = %x20 208 ; ASCII SP, space 209 210 FILL = *SPACE 211 212 SEP = (CR LF / LF) 213 214 CR = %x0D 215 ; ASCII CR, carriage return 216 217 LF = %x0A 218 ; ASCII LF, line feed 219 220 ALPHA = %x41-5A / %x61-7A 221 ; A-Z / a-z 222 223 DIGIT = %x30-39 224 ; 0-9 225 226 227 228 229 Good Standards Track [Page 4] 230 232 RFC 2849 LDAP Data Interchange Format June 2000 233 234 235 UTF8-1 = %x80-BF 236 237 UTF8-2 = %xC0-DF UTF8-1 238 239 UTF8-3 = %xE0-EF 2UTF8-1 240 241 UTF8-4 = %xF0-F7 3UTF8-1 242 243 UTF8-5 = %xF8-FB 4UTF8-1 244 245 UTF8-6 = %xFC-FD 5UTF8-1 246 247 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F 248 ; any value <= 127 decimal except NUL, LF, 249 ; and CR 250 251 SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F / 252 %x21-39 / %x3B / %x3D-7F 253 ; any value <= 127 except NUL, LF, CR, 254 ; SPACE, colon (":", ASCII 58 decimal) 255 ; and less-than ("<" , ASCII 60 decimal) 256 257 SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR] 258 259 UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / 260 UTF8-4 / UTF8-5 / UTF8-6 261 262 UTF8-STRING = *UTF8-CHAR 263 264 BASE64-UTF8-STRING = BASE64-STRING 265 ; MUST be the base64 encoding of a 266 ; UTF8-STRING 267 268 BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A / 269 %x61-7A 270 ; +, /, 0-9, =, A-Z, and a-z 271 ; as specified in [5] 272 273 BASE64-STRING = [*(BASE64-CHAR)] 274 275 276 Notes on LDIF Syntax 277 278 1) For the LDIF format described in this document, the version 279 number MUST be "1". If the version number is absent, 280 implementations MAY choose to interpret the contents as an 281 older LDIF file format, supported by the University of 282 Michigan ldap-3.3 implementation [8]. 283 284 285 286 Good Standards Track [Page 5] 287 289 RFC 2849 LDAP Data Interchange Format June 2000 290 291 292 2) Any non-empty line, including comment lines, in an LDIF file 293 MAY be folded by inserting a line separator (SEP) and a SPACE. 294 Folding MUST NOT occur before the first character of the line. 295 In other words, folding a line into two lines, the first of 296 which is empty, is not permitted. Any line that begins with a 297 single space MUST be treated as a continuation of the previous 298 (non-empty) line. When joining folded lines, exactly one space 299 character at the beginning of each continued line must be 300 discarded. Implementations SHOULD NOT fold lines in the middle 301 of a multi-byte UTF-8 character. 302 303 3) Any line that begins with a pound-sign ("#", ASCII 35) is a 304 comment line, and MUST be ignored when parsing an LDIF file. 305 306 4) Any dn or rdn that contains characters other than those 307 defined as "SAFE-UTF8-CHAR", or begins with a character other 308 than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be 309 base-64 encoded. Other values MAY be base-64 encoded. Any 310 value that contains characters other than those defined as 311 "SAFE-CHAR", or begins with a character other than those 312 defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. 313 Other values MAY be base-64 encoded. 314 315 5) When a zero-length attribute value is to be included directly 316 in an LDIF file, it MUST be represented as 317 AttributeDescription ":" FILL SEP. For example, "seeAlso:" 318 followed by a newline represents a zero-length "seeAlso" 319 attribute value. It is also permissible for the value 320 referred to by a URL to be of zero length. 321 322 6) When a URL is specified in an attrval-spec, the following 323 conventions apply: 324 325 a) Implementations SHOULD support the file:// URL format. The 326 contents of the referenced file are to be included verbatim 327 in the interpreted output of the LDIF file. 328 b) Implementations MAY support other URL formats. The 329 semantics associated with each supported URL will be 330 documented in an associated Applicability Statement. 331 332 7) Distinguished names, relative distinguished names, and 333 attribute values of DirectoryString syntax MUST be valid UTF-8 334 strings. Implementations that read LDIF MAY interpret files 335 in which these entities are stored in some other character set 336 encoding, but implementations MUST NOT generate LDIF content 337 which does not contain valid UTF-8 data. 338 339 340 341 342 343 Good Standards Track [Page 6] 344 346 RFC 2849 LDAP Data Interchange Format June 2000 347 348 349 8) Values or distinguished names that end with SPACE SHOULD be 350 base-64 encoded. 351 352 9) When controls are included in an LDIF file, implementations 353 MAY choose to ignore some or all of them. This may be 354 necessary if the changes described in the LDIF file are being 355 sent on an LDAPv2 connection (LDAPv2 does not support 356 controls), or the particular controls are not supported by the 357 remote server. If the criticality of a control is "true", then 358 the implementation MUST either include the control, or MUST 359 NOT send the operation to a remote server. 360 361 10) When an attrval-spec, distinguishedName, or rdn is base64- 362 encoded, the encoding rules specified in [5] are used with the 363 following exceptions: a) The requirement that base64 output 364 streams must be represented as lines of no more than 76 365 characters is removed. Lines in LDIF files may only be folded 366 according to the folding rules described in note 2, above. b) 367 Base64 strings in [5] may contain characters other than those 368 defined in BASE64-CHAR, and are ignored. LDIF does not permit 369 any extraneous characters, other than those used for line 370 folding. 371 372 Examples of LDAP Data Interchange Format 373 374 Example 1: An simple LDAP file with two entries 375 376 version: 1 377 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com 378 objectclass: top 379 objectclass: person 380 objectclass: organizationalPerson 381 cn: Barbara Jensen 382 cn: Barbara J Jensen 383 cn: Babs Jensen 384 sn: Jensen 385 uid: bjensen 386 telephonenumber: +1 408 555 1212 387 description: A big sailing fan. 388 389 dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com 390 objectclass: top 391 objectclass: person 392 objectclass: organizationalPerson 393 cn: Bjorn Jensen 394 sn: Jensen 395 telephonenumber: +1 408 555 1212 396 397 398 399 400 Good Standards Track [Page 7] 401 403 RFC 2849 LDAP Data Interchange Format June 2000 404 405 406 Example 2: A file containing an entry with a folded attribute value 407 408 version: 1 409 dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com 410 objectclass:top 411 objectclass:person 412 objectclass:organizationalPerson 413 cn:Barbara Jensen 414 cn:Barbara J Jensen 415 cn:Babs Jensen 416 sn:Jensen 417 uid:bjensen 418 telephonenumber:+1 408 555 1212 419 description:Babs is a big sailing fan, and travels extensively in sea 420 rch of perfect sailing conditions. 421 title:Product Manager, Rod and Reel Division 422 423 Example 3: A file containing a base-64-encoded value 424 425 version: 1 426 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com 427 objectclass: top 428 objectclass: person 429 objectclass: organizationalPerson 430 cn: Gern Jensen 431 cn: Gern O Jensen 432 sn: Jensen 433 uid: gernj 434 telephonenumber: +1 408 555 1212 435 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl 436 IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG 437 VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg 438 b3V0IG1vcmUu 439 440 Example 4: A file containing an entries with UTF-8-encoded attribute 441 values, including language tags. Comments indicate the contents 442 of UTF-8-encoded attributes and distinguished names. 443 444 version: 1 445 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz 446 # dn:: ou=<JapaneseOU>,o=Airius 447 objectclass: top 448 objectclass: organizationalUnit 449 ou:: 5Za25qWt6YOo 450 # ou:: <JapaneseOU> 451 ou;lang-ja:: 5Za25qWt6YOo 452 # ou;lang-ja:: <JapaneseOU> 453 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 454 455 456 457 Good Standards Track [Page 8] 458 460 RFC 2849 LDAP Data Interchange Format June 2000 461 462 463 # ou;lang-ja:: <JapaneseOU_in_phonetic_representation> 464 ou;lang-en: Sales 465 description: Japanese office 466 467 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz 468 # dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius 469 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= 470 objectclass: top 471 objectclass: person 472 objectclass: organizationalPerson 473 objectclass: inetOrgPerson 474 uid: rogasawara 475 mail: rogasawara (a] airius.co.jp 476 givenname;lang-ja:: 44Ot44OJ44OL44O8 477 # givenname;lang-ja:: <JapaneseGivenname> 478 sn;lang-ja:: 5bCP56yg5Y6f 479 # sn;lang-ja:: <JapaneseSn> 480 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 481 # cn;lang-ja:: <JapaneseCn> 482 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw== 483 # title;lang-ja:: <JapaneseTitle> 484 preferredlanguage: ja 485 givenname:: 44Ot44OJ44OL44O8 486 # givenname:: <JapaneseGivenname> 487 sn:: 5bCP56yg5Y6f 488 # sn:: <JapaneseSn> 489 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 490 # cn:: <JapaneseCn> 491 title:: 5Za25qWt6YOoIOmDqOmVtw== 492 # title:: <JapaneseTitle> 493 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 494 # givenname;lang-ja;phonetic:: 495 <JapaneseGivenname_in_phonetic_representation_kana> 496 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ 497 # sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana> 498 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA== 499 # cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana> 500 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg== 501 # title;lang-ja;phonetic:: 502 # <JapaneseTitle_in_phonetic_representation_kana> 503 givenname;lang-en: Rodney 504 sn;lang-en: Ogasawara 505 cn;lang-en: Rodney Ogasawara 506 title;lang-en: Sales, Director 507 508 509 510 511 512 513 514 Good Standards Track [Page 9] 515 517 RFC 2849 LDAP Data Interchange Format June 2000 518 519 520 Example 5: A file containing a reference to an external file 521 522 version: 1 523 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com 524 objectclass: top 525 objectclass: person 526 objectclass: organizationalPerson 527 cn: Horatio Jensen 528 529 cn: Horatio N Jensen 530 sn: Jensen 531 uid: hjensen 532 telephonenumber: +1 408 555 1212 533 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg 534 535 Example 6: A file containing a series of change records and comments 536 537 version: 1 538 # Add a new entry 539 dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com 540 changetype: add 541 objectclass: top 542 objectclass: person 543 objectclass: organizationalPerson 544 cn: Fiona Jensen 545 sn: Jensen 546 uid: fiona 547 telephonenumber: +1 408 555 1212 548 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg 549 550 # Delete an existing entry 551 dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com 552 changetype: delete 553 554 # Modify an entry's relative distinguished name 555 dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com 556 changetype: modrdn 557 newrdn: cn=Paula Jensen 558 deleteoldrdn: 1 559 560 # Rename an entry and move all of its children to a new location in 561 # the directory tree (only implemented by LDAPv3 servers). 562 dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com 563 changetype: modrdn 564 newrdn: ou=Product Development Accountants 565 deleteoldrdn: 0 566 newsuperior: ou=Accounting, dc=airius, dc=com 567 568 569 570 571 Good Standards Track [Page 10] 572 574 RFC 2849 LDAP Data Interchange Format June 2000 575 576 577 # Modify an entry: add an additional value to the postaladdress 578 # attribute, completely delete the description attribute, replace 579 # the telephonenumber attribute with two values, and delete a specific 580 # value from the facsimiletelephonenumber attribute 581 dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com 582 changetype: modify 583 add: postaladdress 584 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 585 - 586 587 delete: description 588 - 589 replace: telephonenumber 590 telephonenumber: +1 408 555 1234 591 telephonenumber: +1 408 555 5678 592 - 593 delete: facsimiletelephonenumber 594 facsimiletelephonenumber: +1 408 555 9876 595 - 596 597 # Modify an entry: replace the postaladdress attribute with an empty 598 # set of values (which will cause the attribute to be removed), and 599 # delete the entire description attribute. Note that the first will 600 # always succeed, while the second will only succeed if at least 601 # one value for the description attribute is present. 602 dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com 603 changetype: modify 604 replace: postaladdress 605 - 606 delete: description 607 - 608 609 Example 7: An LDIF file containing a change record with a control 610 version: 1 611 # Delete an entry. The operation will attach the LDAPv3 612 # Tree Delete Control defined in [9]. The criticality 613 # field is "true" and the controlValue field is 614 # absent, as required by [9]. 615 dn: ou=Product Development, dc=airius, dc=com 616 control: 1.2.840.113556.1.4.805 true 617 changetype: delete 618 619 620 621 622 623 624 625 626 627 628 Good Standards Track [Page 11] 629 631 RFC 2849 LDAP Data Interchange Format June 2000 632 633 634 Security Considerations 635 636 Given typical directory applications, an LDIF file is likely to 637 contain sensitive personal data. Appropriate measures should be 638 taken to protect the privacy of those persons whose data is contained 639 in an LDIF file. 640 641 Since ":<" directives can cause external content to be included when 642 processing an LDIF file, one should be cautious of accepting LDIF 643 files from external sources. A "trojan" LDIF file could name a file 644 with sensitive contents and cause it to be included in a directory 645 entry, which a hostile entity could read via LDAP. 646 647 LDIF does not provide any method for carrying authentication 648 information with an LDIF file. Users of LDIF files must take care to 649 verify the integrity of an LDIF file received from an external 650 source. 651 652 Acknowledgments 653 654 The LDAP Interchange Format was developed as part of the University 655 of Michigan LDAP reference implementation, and was developed by Tim 656 Howes, Mark Smith, and Gordon Good. It is based in part upon work 657 supported by the National Science Foundation under Grant No. NCR- 658 9416667. 659 660 Members of the IETF LDAP Extensions Working group provided many 661 helpful suggestions. In particular, Hallvard B. Furuseth of the 662 University of Oslo made many significant contributions to this 663 document, including a thorough review and rewrite of the BNF. 664 665 References 666 667 [1] Howes, T. and M. Smith, "A MIME Content-Type for Directory 668 Information", RFC 2425, September 1998. 669 670 [2] Crocker, D., and P. Overell, "Augmented BNF for Syntax 671 Specifications: ABNF", RFC 2234, November 1997. 672 673 [3] Wahl, M., Kille, S. and T. Howes, "A String Representation of 674 Distinguished Names", RFC 2253, December 1997. 675 676 [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access 677 Protocol (v3)", RFC 2251, July 1997. 678 679 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 680 Extensions (MIME) Part One: Format of Internet Message Bodies", 681 RFC 2045, November 1996. 682 683 684 685 Good Standards Track [Page 12] 686 688 RFC 2849 LDAP Data Interchange Format June 2000 689 690 691 [6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform 692 Resource Locators (URL)", RFC 1738, December 1994. 693 694 [7] Bradner, S., "Key Words for use in RFCs to Indicate Requirement 695 Levels", BCP 14, RFC 2119, March 1997. 696 697 [8] The SLAPD and SLURPD Administrators Guide. University of 698 Michigan, April 1996. <URL: 699 http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html> 700 701 [9] M. P. Armijo, "Tree Delete Control", Work in Progress. 702 703 Author's Address 704 705 Gordon Good 706 iPlanet e-commerce Solutions 707 150 Network Circle 708 Mailstop USCA17-201 709 Santa Clara, CA 95054, USA 710 711 Phone: +1 408 276 4351 712 EMail: ggood (a] netscape.com 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 Good Standards Track [Page 13] 743 745 RFC 2849 LDAP Data Interchange Format June 2000 746 747 748 Full Copyright Statement 749 750 Copyright (C) The Internet Society (2000). All Rights Reserved. 751 752 This document and translations of it may be copied and furnished to 753 others, and derivative works that comment on or otherwise explain it 754 or assist in its implementation may be prepared, copied, published 755 and distributed, in whole or in part, without restriction of any 756 kind, provided that the above copyright notice and this paragraph are 757 included on all such copies and derivative works. However, this 758 document itself may not be modified in any way, such as by removing 759 the copyright notice or references to the Internet Society or other 760 Internet organizations, except as needed for the purpose of 761 developing Internet standards in which case the procedures for 762 copyrights defined in the Internet Standards process must be 763 followed, or as required to translate it into languages other than 764 English. 765 766 The limited permissions granted above are perpetual and will not be 767 revoked by the Internet Society or its successors or assigns. 768 769 This document and the information contained herein is provided on an 770 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 771 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 772 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 773 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 774 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 775 776 Acknowledgement 777 778 Funding for the RFC Editor function is currently provided by the 779 Internet Society. 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 Good Standards Track [Page 14] 800 802
Indexes created Tue Sep 15 00:24:42 UTC 2026