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