source: branches/samba-3.5.x/source4/ldap_server/devdocs/rfc2849.txt

Last change on this file was 414, checked in by Herwig Bauernfeind, 15 years ago

Samba 3.5.0: Initial import
File size: 25.4 KB
Line 
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
60
61RFC 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
76Definition 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
93Formal Syntax Definition of LDIF
94
95 The following definition uses the augmented Backus-Naur Form
96 specified in RFC 2234 [2].
97
98ldif-file = ldif-content / ldif-changes
99
100ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
101
102ldif-changes = version-spec 1*(1*SEP ldif-change-record)
103
104ldif-attrval-record = dn-spec SEP 1*attrval-spec
105
106ldif-change-record = dn-spec SEP *control changerecord
107
108version-spec = "version:" FILL version-number
109
110
111
112
113
114
115Good Standards Track [Page 2]
116
117
118RFC 2849 LDAP Data Interchange Format June 2000
119
120
121version-number = 1*DIGIT
122 ; version-number MUST be "1" for the
123 ; LDIF format described in this document.
124
125dn-spec = "dn:" (FILL distinguishedName /
126 ":" FILL base64-distinguishedName)
127
128distinguishedName = SAFE-STRING
129 ; a distinguished name, as defined in [3]
130
131base64-distinguishedName = BASE64-UTF8-STRING
132 ; a distinguishedName which has been base64
133 ; encoded (see note 10, below)
134
135rdn = SAFE-STRING
136 ; a relative distinguished name, defined as
137 ; <name-component> in [3]
138
139base64-rdn = BASE64-UTF8-STRING
140 ; an rdn which has been base64 encoded (see
141 ; note 10, below)
142
143control = "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
149ldap-oid = 1*DIGIT 0*1("." 1*DIGIT)
150 ; An LDAPOID, as defined in [4]
151
152attrval-spec = AttributeDescription value-spec SEP
153
154value-spec = ":" ( FILL 0*1(SAFE-STRING) /
155 ":" FILL (BASE64-STRING) /
156 "<" FILL url)
157 ; See notes 7 and 8, below
158
159url = <a Uniform Resource Locator,
160 as defined in [6]>
161 ; (See Note 6, below)
162
163AttributeDescription = AttributeType [";" options]
164 ; Definition taken from [4]
165
166AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
167
168options = option / (option ";" options)
169
170
171
172Good Standards Track [Page 3]
173
174
175RFC 2849 LDAP Data Interchange Format June 2000
176
177
178option = 1*opt-char
179
180attr-type-chars = ALPHA / DIGIT / "-"
181
182opt-char = attr-type-chars
183
184changerecord = "changetype:" FILL
185 (change-add / change-delete /
186 change-modify / change-moddn)
187
188change-add = "add" SEP 1*attrval-spec
189
190change-delete = "delete" SEP
191
192change-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
200change-modify = "modify" SEP *mod-spec
201
202mod-spec = ("add:" / "delete:" / "replace:")
203 FILL AttributeDescription SEP
204 *attrval-spec
205 "-" SEP
206
207SPACE = %x20
208 ; ASCII SP, space
209
210FILL = *SPACE
211
212SEP = (CR LF / LF)
213
214CR = %x0D
215 ; ASCII CR, carriage return
216
217LF = %x0A
218 ; ASCII LF, line feed
219
220ALPHA = %x41-5A / %x61-7A
221 ; A-Z / a-z
222
223DIGIT = %x30-39
224 ; 0-9
225
226
227
228
229Good Standards Track [Page 4]
230
231
232RFC 2849 LDAP Data Interchange Format June 2000
233
234
235UTF8-1 = %x80-BF
236
237UTF8-2 = %xC0-DF UTF8-1
238
239UTF8-3 = %xE0-EF 2UTF8-1
240
241UTF8-4 = %xF0-F7 3UTF8-1
242
243UTF8-5 = %xF8-FB 4UTF8-1
244
245UTF8-6 = %xFC-FD 5UTF8-1
246
247SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
248 ; any value <= 127 decimal except NUL, LF,
249 ; and CR
250
251SAFE-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
257SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
258
259UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 /
260 UTF8-4 / UTF8-5 / UTF8-6
261
262UTF8-STRING = *UTF8-CHAR
263
264BASE64-UTF8-STRING = BASE64-STRING
265 ; MUST be the base64 encoding of a
266 ; UTF8-STRING
267
268BASE64-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
273BASE64-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
286Good Standards Track [Page 5]
287
288
289RFC 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
343Good Standards Track [Page 6]
344
345
346RFC 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
372Examples of LDAP Data Interchange Format
373
374Example 1: An simple LDAP file with two entries
375
376version: 1
377dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
378objectclass: top
379objectclass: person
380objectclass: organizationalPerson
381cn: Barbara Jensen
382cn: Barbara J Jensen
383cn: Babs Jensen
384sn: Jensen
385uid: bjensen
386telephonenumber: +1 408 555 1212
387description: A big sailing fan.
388
389dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
390objectclass: top
391objectclass: person
392objectclass: organizationalPerson
393cn: Bjorn Jensen
394sn: Jensen
395telephonenumber: +1 408 555 1212
396
397
398
399
400Good Standards Track [Page 7]
401
402
403RFC 2849 LDAP Data Interchange Format June 2000
404
405
406Example 2: A file containing an entry with a folded attribute value
407
408version: 1
409dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
410objectclass:top
411objectclass:person
412objectclass:organizationalPerson
413cn:Barbara Jensen
414cn:Barbara J Jensen
415cn:Babs Jensen
416sn:Jensen
417uid:bjensen
418telephonenumber:+1 408 555 1212
419description:Babs is a big sailing fan, and travels extensively in sea
420 rch of perfect sailing conditions.
421title:Product Manager, Rod and Reel Division
422
423Example 3: A file containing a base-64-encoded value
424
425version: 1
426dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
427objectclass: top
428objectclass: person
429objectclass: organizationalPerson
430cn: Gern Jensen
431cn: Gern O Jensen
432sn: Jensen
433uid: gernj
434telephonenumber: +1 408 555 1212
435description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
436IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
437VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
438b3V0IG1vcmUu
439
440Example 4: A file containing an entries with UTF-8-encoded attribute
441values, including language tags. Comments indicate the contents
442of UTF-8-encoded attributes and distinguished names.
443
444version: 1
445dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
446# dn:: ou=<JapaneseOU>,o=Airius
447objectclass: top
448objectclass: organizationalUnit
449ou:: 5Za25qWt6YOo
450# ou:: <JapaneseOU>
451ou;lang-ja:: 5Za25qWt6YOo
452# ou;lang-ja:: <JapaneseOU>
453ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
454
455
456
457Good Standards Track [Page 8]
458
459
460RFC 2849 LDAP Data Interchange Format June 2000
461
462
463# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
464ou;lang-en: Sales
465description: Japanese office
466
467dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
468# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
469userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
470objectclass: top
471objectclass: person
472objectclass: organizationalPerson
473objectclass: inetOrgPerson
474uid: rogasawara
475mail: rogasawara@airius.co.jp
476givenname;lang-ja:: 44Ot44OJ44OL44O8
477# givenname;lang-ja:: <JapaneseGivenname>
478sn;lang-ja:: 5bCP56yg5Y6f
479# sn;lang-ja:: <JapaneseSn>
480cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
481# cn;lang-ja:: <JapaneseCn>
482title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
483# title;lang-ja:: <JapaneseTitle>
484preferredlanguage: ja
485givenname:: 44Ot44OJ44OL44O8
486# givenname:: <JapaneseGivenname>
487sn:: 5bCP56yg5Y6f
488# sn:: <JapaneseSn>
489cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
490# cn:: <JapaneseCn>
491title:: 5Za25qWt6YOoIOmDqOmVtw==
492# title:: <JapaneseTitle>
493givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
494# givenname;lang-ja;phonetic::
495<JapaneseGivenname_in_phonetic_representation_kana>
496sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
497# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
498cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
499# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
500title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
501# title;lang-ja;phonetic::
502# <JapaneseTitle_in_phonetic_representation_kana>
503givenname;lang-en: Rodney
504sn;lang-en: Ogasawara
505cn;lang-en: Rodney Ogasawara
506title;lang-en: Sales, Director
507
508
509
510
511
512
513
514Good Standards Track [Page 9]
515
516
517RFC 2849 LDAP Data Interchange Format June 2000
518
519
520Example 5: A file containing a reference to an external file
521
522version: 1
523dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
524objectclass: top
525objectclass: person
526objectclass: organizationalPerson
527cn: Horatio Jensen
528
529cn: Horatio N Jensen
530sn: Jensen
531uid: hjensen
532telephonenumber: +1 408 555 1212
533jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
534
535Example 6: A file containing a series of change records and comments
536
537version: 1
538# Add a new entry
539dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
540changetype: add
541objectclass: top
542objectclass: person
543objectclass: organizationalPerson
544cn: Fiona Jensen
545sn: Jensen
546uid: fiona
547telephonenumber: +1 408 555 1212
548jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
549
550# Delete an existing entry
551dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
552changetype: delete
553
554# Modify an entry's relative distinguished name
555dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
556changetype: modrdn
557newrdn: cn=Paula Jensen
558deleteoldrdn: 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).
562dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
563changetype: modrdn
564newrdn: ou=Product Development Accountants
565deleteoldrdn: 0
566newsuperior: ou=Accounting, dc=airius, dc=com
567
568
569
570
571Good Standards Track [Page 10]
572
573
574RFC 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
581dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
582changetype: modify
583add: postaladdress
584postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
585-
586
587delete: description
588-
589replace: telephonenumber
590telephonenumber: +1 408 555 1234
591telephonenumber: +1 408 555 5678
592-
593delete: facsimiletelephonenumber
594facsimiletelephonenumber: +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.
602dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
603changetype: modify
604replace: postaladdress
605-
606delete: description
607-
608
609Example 7: An LDIF file containing a change record with a control
610version: 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].
615dn: ou=Product Development, dc=airius, dc=com
616control: 1.2.840.113556.1.4.805 true
617changetype: delete
618
619
620
621
622
623
624
625
626
627
628Good Standards Track [Page 11]
629
630
631RFC 2849 LDAP Data Interchange Format June 2000
632
633
634Security 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
652Acknowledgments
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
665References
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
685Good Standards Track [Page 12]
686
687
688RFC 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
703Author'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@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
742Good Standards Track [Page 13]
743
744
745RFC 2849 LDAP Data Interchange Format June 2000
746
747
748Full 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
776Acknowledgement
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
799Good Standards Track [Page 14]
800
801
Note: See TracBrowser for help on using the repository browser.