ldif-utf8
view proposal.txt @ 1:d307d875966f
First cut !
| author | Yves dorfsman <yves@zioup.com> |
|---|---|
| date | Fri Mar 20 18:11:24 2009 -0600 |
| parents | b49e8e2fc0ac |
| children | 213f3b5dcd86 |
line source
7 Network Working Group G. Good
8 INTERNET-DRAFT
9 Obsoletes: 2849
10 Category: Standards Track
13 The LDAP Data Interchange Format (LDIF) - Technical Specification
16 Status of this Memo
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Abstract
25 This document describes a file format suitable for describing
26 directory information or modifications made to directory information.
27 The file format, known as LDIF, for LDAP Data Interchange Format, is
28 typically used to import and export directory information between
29 LDAP-based directory servers, or to describe a set of changes which
30 are to be applied to a directory.
32 Relationship to Obsolete Specification
34 This obsoletes and replaces [RFC2849] which defined version 1
35 of LDIF.
37 The paragraph "Notes on LDIF Syntax" in [RFC2849] documented the
38 use of non-encoded UTF-8 inside an LDIF file, but the "Formal Syntax
39 Definition of LDIF" specified either ASCII or base64 encoded UTF-8
40 for distinguishedName, rdn and attrval-spec. The specification has
41 been changed to allow UTF-8 strings without the use of encoding.
43 The definition of UTF-8 has been slightly modified to follow the
44 definition from [RFC3629].
46 The style has been changed to conform with the newer editorial
47 standards from [RFC223], specifically in quoting references.
49 Background and Intended Usage
51 There are a number of situations where a common interchange format is
52 desirable. For example, one might wish to export a copy of the
53 contents of a directory server to a file, move that file to a
54 different machine, and import the contents into a second directory
55 server.
57 Additionally, by using a well-defined interchange format, development
58 of data import tools from legacy systems is facilitated. A fairly
59 simple set of tools written in awk or perl can, for example, convert
60 a database of personnel information into an LDIF file. This file can
61 then be imported into a directory server, regardless of the internal
62 database representation the target directory server uses.
64 The LDIF format was originally developed and used in the University
65 of Michigan LDAP implementation. The first use of LDIF was in
66 describing directory entries. Later, the format was expanded to
67 allow representation of changes to directory entries.
69 Relationship to the application/directory MIME content-type:
71 The application/directory MIME content-type [RFC2425] is a general
72 framework and format for conveying directory information, and is
73 independent of any particular directory service. The LDIF format is
74 a simpler format which is perhaps easier to create, and may also be
75 used, as noted, to describe a set of changes to be applied to a
76 directory.
78 The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
79 used in this document are to be interpreted as described
80 in [RFC2119].
82 Definition of the LDAP Data Interchange Format
84 The LDIF format is used to convey directory information, or a
85 description of a set of changes made to directory entries. An LDIF
86 file consists of a series of records separated by line separators. A
87 record consists of a sequence of lines describing a directory entry,
88 or a sequence of lines describing a set of changes to a directory
89 entry. An LDIF file specifies a set of directory entries, or a set
90 of changes to be applied to directory entries, but not both.
92 There is a one-to-one correlation between LDAP operations that modify
93 the directory (add, delete, modify, and modrdn), and the types of
94 changerecords described below ("add", "delete", "modify", and
95 "modrdn" or "moddn"). This correspondence is intentional, and
96 permits a straightforward translation from LDIF changerecords to
97 protocol operations.
99 Formal Syntax Definition of LDIF
101 The following definition uses the augmented Backus-Naur Form
102 specified in [RFC2234].
104 ldif-file = ldif-content / ldif-changes
106 ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
108 ldif-changes = version-spec 1*(1*SEP ldif-change-record)
110 ldif-attrval-record = dn-spec SEP 1*attrval-spec
112 ldif-change-record = dn-spec SEP *control changerecord
114 version-spec = "version:" FILL version-number
116 version-number = 1*DIGIT
117 ; version-number MUST be "2" for the
118 ; LDIF format described in this document.
120 dn-spec = "dn:" (FILL distinguishedName /
121 ":" FILL base64-distinguishedName)
123 distinguishedName = SAFE-UTF8-STRING
124 ; a distinguished name, as defined
125 ; in [RFC2253]
127 base64-distinguishedName = BASE64-UTF8-STRING
128 ; a distinguishedName which has been base64
129 ; encoded (see note 10, below)
131 rdn = SAFE-UTF8-STRING
132 ; a relative distinguished name, defined as
133 ; <name-component> in [RFC2253]
135 base64-rdn = BASE64-UTF8-STRING
136 ; an rdn which has been base64 encoded (see
137 ; note 10, below)
139 control = "control:" FILL ldap-oid ; controlType
140 0*1(1*SPACE ("true" / "false")) ; criticality
141 0*1(value-spec) ; controlValue
142 SEP
143 ; (See note 9, below)
145 ldap-oid = 1*DIGIT 0*1("." 1*DIGIT)
146 ; An LDAPOID, as defined in [RFC2251]
148 attrval-spec = AttributeDescription value-spec SEP
150 value-spec = ":" ( FILL 0*1(SAFE-UTF8-STRING) /
151 ":" FILL (BASE64-STRING) /
152 "<" FILL url)
153 ; See notes 7 and 8, below
155 url = <a Uniform Resource Locator,
156 as defined in [RFC1738]>
157 ; (See Note 6, below)
159 AttributeDescription = AttributeType [";" options]
160 ; Definition taken from [RFC2251]
162 AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
164 options = option / (option ";" options)
166 option = 1*opt-char
168 attr-type-chars = ALPHA / DIGIT / "-"
170 opt-char = attr-type-chars
172 changerecord = "changetype:" FILL
173 (change-add / change-delete /
174 change-modify / change-moddn)
176 change-add = "add" SEP 1*attrval-spec
178 change-delete = "delete" SEP
180 change-moddn = ("modrdn" / "moddn") SEP
181 "newrdn:" ( FILL rdn /
182 ":" FILL base64-rdn) SEP
183 "deleteoldrdn:" FILL ("0" / "1") SEP
184 0*1("newsuperior:"
185 ( FILL distinguishedName /
186 ":" FILL base64-distinguishedName) SEP)
188 change-modify = "modify" SEP *mod-spec
190 mod-spec = ("add:" / "delete:" / "replace:")
191 FILL AttributeDescription SEP
192 *attrval-spec
193 "-" SEP
195 SPACE = %x20
196 ; ASCII SP, space
198 FILL = *SPACE
200 SEP = (CR LF / LF)
202 CR = %x0D
203 ; ASCII CR, carriage return
205 LF = %x0A
206 ; ASCII LF, line feed
208 ALPHA = %x41-5A / %x61-7A
209 ; A-Z / a-z
211 DIGIT = %x30-39
212 ; 0-9
214 UTF8-1 = %x00-7F
216 UTF8-tail = %x80-BF
218 UTF8-2 = %xC2-DF UTF8-tail
220 UTF8-3 = %xE0 %xA0-BF UTF8-tail /
221 %xE1-EC 2( UTF8-tail ) /
222 %xED %x80-9F UTF8-tail /
223 %xEE-EF 2( UTF8-tail )
225 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
226 %xF1-F3 3( UTF8-tail ) /
227 %xF4 %x80-8F 2( UTF8-tail )
229 UTF8-CHAR = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
231 UTF8-STRING = *UTF8-CHAR
233 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
234 ; any value <= 127 decimal except NUL, LF,
235 ; and CR
237 SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
238 %x21-39 / %x3B / %x3D-7F
239 ; any value <= 127 except NUL, LF, CR,
240 ; SPACE, colon (":", ASCII 58 decimal)
241 ; and less-than ("<" , ASCII 60 decimal)
243 SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
245 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
247 SAFE-INIT-UTF8-CHAR = SAFE-INIT-CHAR / UTF8-2 / UTF8-3 / UTF8-4
249 SAFE-UTF8-STRING = [SAFE-INIT-UTF8-CHAR *SAFE-UTF8-CHAR]
251 BASE64-UTF8-STRING = BASE64-STRING
252 ; MUST be the base64 encoding of a
253 ; UTF8-STRING
255 BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
256 %x61-7A
257 ; +, /, 0-9, =, A-Z, and a-z
258 ; as specified in [RFC2045]
260 BASE64-STRING = [*(BASE64-CHAR)]
263 Notes on LDIF Syntax
265 1) For the LDIF format described in this document, the version
266 number MUST be "2". If the version number is absent,
267 implementations MAY choose to interpret the contents as an
268 older LDIF file format, supported by the University of
269 Michigan ldap-3.3 implementation [UMich96].
271 2) Any non-empty line, including comment lines, in an LDIF file
272 MAY be folded by inserting a line separator (SEP) and a SPACE.
273 Folding MUST NOT occur before the first character of the line.
274 In other words, folding a line into two lines, the first of
275 which is empty, is not permitted. Any line that begins with a
276 single space MUST be treated as a continuation of the previous
277 (non-empty) line. When joining folded lines, exactly one space
278 character at the beginning of each continued line must be
279 discarded. Implementations SHOULD NOT fold lines in the middle
280 of a multi-byte UTF-8 character.
282 3) Any line that begins with a pound-sign ("#", ASCII 35) is a
283 comment line, and MUST be ignored when parsing an LDIF file.
285 4) Any dn, rdn or attrval-spec that contains characters other
286 than those defined as "SAFE-UTF8-CHAR", or begins with a
287 character other than those defined as "SAFE-INIT-UTF8-CHAR",
288 above, MUST be base-64 encoded. Other values MAY be base-64
289 encoded. Any value that contains characters other than those
290 defined as "SAFE--CHAR", or begins with a character other than
291 those defined as "SAFE-INIT--CHAR", above, MUST be base-64
292 encoded. Other values MAY be base-64 encoded.
294 5) When a zero-length attribute value is to be included directly
295 in an LDIF file, it MUST be represented as
296 AttributeDescription ":" FILL SEP. For example, "seeAlso:"
297 followed by a newline represents a zero-length "seeAlso"
298 attribute value. It is also permissible for the value
299 referred to by a URL to be of zero length.
301 6) When a URL is specified in an attrval-spec, the following
302 conventions apply:
304 a) Implementations SHOULD support the file:// URL format. The
305 contents of the referenced file are to be included verbatim
306 in the interpreted output of the LDIF file.
307 b) Implementations MAY support other URL formats. The
308 semantics associated with each supported URL will be
309 documented in an associated Applicability Statement.
311 7) Distinguished names, relative distinguished names, and
312 attribute values of DirectoryString syntax MUST be valid UTF-8
313 strings. Implementations that read LDIF MAY interpret files
314 in which these entities are stored in some other character set
315 encoding, but implementations MUST NOT generate LDIF content
316 which does not contain valid UTF-8 data.
318 8) Values or distinguished names that end with SPACE SHOULD be
319 base-64 encoded.
321 9) When controls are included in an LDIF file, implementations
322 MAY choose to ignore some or all of them. This may be
323 necessary if the changes described in the LDIF file are being
324 sent on an LDAPv2 connection (LDAPv2 does not support
325 controls), or the particular controls are not supported by the
326 remote server. If the criticality of a control is "true", then
327 the implementation MUST either include the control, or MUST
328 NOT send the operation to a remote server.
330 10) When an attrval-spec, distinguishedName, or rdn is base64-
331 encoded, the encoding rules specified in [RFC2045] are used
332 with the following exceptions: a) The requirement that base64
333 output streams must be represented as lines of no more than 76
334 characters is removed. Lines in LDIF files may only be folded
335 according to the folding rules described in note 2, above. b)
336 Base64 strings in [RFC2045] may contain characters other than
337 those defined in BASE64-CHAR, and are ignored. LDIF does not
338 permit any extraneous characters, other than those used for
339 line folding.
341 Examples of LDAP Data Interchange Format
343 Example 1: An simple LDAP file with two entries
345 version: 1
346 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
347 objectclass: top
348 objectclass: person
349 objectclass: organizationalPerson
350 cn: Barbara Jensen
351 cn: Barbara J Jensen
352 cn: Babs Jensen
353 sn: Jensen
354 uid: bjensen
355 telephonenumber: +1 408 555 1212
356 description: A big sailing fan.
358 dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
359 objectclass: top
360 objectclass: person
361 objectclass: organizationalPerson
362 cn: Bjorn Jensen
363 sn: Jensen
364 telephonenumber: +1 408 555 1212
366 Example 2: A file containing an entry with a folded attribute value
368 version: 1
369 dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
370 objectclass:top
371 objectclass:person
372 objectclass:organizationalPerson
373 cn:Barbara Jensen
374 cn:Barbara J Jensen
375 cn:Babs Jensen
376 sn:Jensen
377 uid:bjensen
378 telephonenumber:+1 408 555 1212
379 description:Babs is a big sailing fan, and travels extensively in sea
380 rch of perfect sailing conditions.
381 title:Product Manager, Rod and Reel Division
383 Example 3: A file containing a base-64-encoded value
385 version: 1
386 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
387 objectclass: top
388 objectclass: person
389 objectclass: organizationalPerson
390 cn: Gern Jensen
391 cn: Gern O Jensen
392 sn: Jensen
393 uid: gernj
394 telephonenumber: +1 408 555 1212
395 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
396 IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
397 VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
398 b3V0IG1vcmUu
400 Example 4: A file containing an entries with UTF-8-encoded attribute
401 values, including language tags. Comments indicate the contents
402 of UTF-8-encoded attributes and distinguished names.
404 version: 1
405 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
406 # dn:: ou=<JapaneseOU>,o=Airius
407 objectclass: top
408 objectclass: organizationalUnit
409 ou:: 5Za25qWt6YOo
410 # ou:: <JapaneseOU>
411 ou;lang-ja:: 5Za25qWt6YOo
412 # ou;lang-ja:: <JapaneseOU>
413 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
415 # ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
416 ou;lang-en: Sales
417 description: Japanese office
419 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
420 # dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
421 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
422 objectclass: top
423 objectclass: person
424 objectclass: organizationalPerson
425 objectclass: inetOrgPerson
426 uid: rogasawara
427 mail: rogasawara@airius.co.jp
428 givenname;lang-ja:: 44Ot44OJ44OL44O8
429 # givenname;lang-ja:: <JapaneseGivenname>
430 sn;lang-ja:: 5bCP56yg5Y6f
431 # sn;lang-ja:: <JapaneseSn>
432 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
433 # cn;lang-ja:: <JapaneseCn>
434 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
435 # title;lang-ja:: <JapaneseTitle>
436 preferredlanguage: ja
437 givenname:: 44Ot44OJ44OL44O8
438 # givenname:: <JapaneseGivenname>
439 sn:: 5bCP56yg5Y6f
440 # sn:: <JapaneseSn>
441 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
442 # cn:: <JapaneseCn>
443 title:: 5Za25qWt6YOoIOmDqOmVtw==
444 # title:: <JapaneseTitle>
445 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
446 # givenname;lang-ja;phonetic::
447 <JapaneseGivenname_in_phonetic_representation_kana>
448 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
449 # sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
450 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
451 # cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
452 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
453 # title;lang-ja;phonetic::
454 # <JapaneseTitle_in_phonetic_representation_kana>
455 givenname;lang-en: Rodney
456 sn;lang-en: Ogasawara
457 cn;lang-en: Rodney Ogasawara
458 title;lang-en: Sales, Director
460 Example 5: A file containing a reference to an external file
462 version: 1
463 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
464 objectclass: top
465 objectclass: person
466 objectclass: organizationalPerson
467 cn: Horatio Jensen
469 cn: Horatio N Jensen
470 sn: Jensen
471 uid: hjensen
472 telephonenumber: +1 408 555 1212
473 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
475 Example 6: A file containing a series of change records and comments
477 version: 1
478 # Add a new entry
479 dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
480 changetype: add
481 objectclass: top
482 objectclass: person
483 objectclass: organizationalPerson
484 cn: Fiona Jensen
485 sn: Jensen
486 uid: fiona
487 telephonenumber: +1 408 555 1212
488 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
490 # Delete an existing entry
491 dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
492 changetype: delete
494 # Modify an entry's relative distinguished name
495 dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
496 changetype: modrdn
497 newrdn: cn=Paula Jensen
498 deleteoldrdn: 1
500 # Rename an entry and move all of its children to a new location in
501 # the directory tree (only implemented by LDAPv3 servers).
502 dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
503 changetype: modrdn
504 newrdn: ou=Product Development Accountants
505 deleteoldrdn: 0
506 newsuperior: ou=Accounting, dc=airius, dc=com
508 # Modify an entry: add an additional value to the postaladdress
509 # attribute, completely delete the description attribute, replace
510 # the telephonenumber attribute with two values, and delete a specific
511 # value from the facsimiletelephonenumber attribute
512 dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
513 changetype: modify
514 add: postaladdress
515 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
516 -
518 delete: description
519 -
520 replace: telephonenumber
521 telephonenumber: +1 408 555 1234
522 telephonenumber: +1 408 555 5678
523 -
524 delete: facsimiletelephonenumber
525 facsimiletelephonenumber: +1 408 555 9876
526 -
528 # Modify an entry: replace the postaladdress attribute with an empty
529 # set of values (which will cause the attribute to be removed), and
530 # delete the entire description attribute. Note that the first will
531 # always succeed, while the second will only succeed if at least
532 # one value for the description attribute is present.
533 dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
534 changetype: modify
535 replace: postaladdress
536 -
537 delete: description
538 -
540 Example 7: An LDIF file containing a change record with a control
541 version: 1
542 # Delete an entry. The operation will attach the LDAPv3
543 # Tree Delete Control defined in [Armijo00]. The criticality
544 # field is "true" and the controlValue field is
545 # absent, as required by [Armijo00].
546 dn: ou=Product Development, dc=airius, dc=com
547 control: 1.2.840.113556.1.4.805 true
548 changetype: delete
550 Security Considerations
552 Given typical directory applications, an LDIF file is likely to
553 contain sensitive personal data. Appropriate measures should be
554 taken to protect the privacy of those persons whose data is contained
555 in an LDIF file.
557 Since ":<" directives can cause external content to be included when
558 processing an LDIF file, one should be cautious of accepting LDIF
559 files from external sources. A "trojan" LDIF file could name a file
560 with sensitive contents and cause it to be included in a directory
561 entry, which a hostile entity could read via LDAP.
563 LDIF does not provide any method for carrying authentication
564 information with an LDIF file. Users of LDIF files must take care to
565 verify the integrity of an LDIF file received from an external
566 source.
568 Contributors
569 Gordon Good was the author of [RFC2849] which defined LDIF. Most
570 of this specification is a copy of [RFC2849], simply adding full
571 support for UTF-8 and editing according to newer RFC standards.
573 Acknowledgments
575 The LDAP Interchange Format was developed as part of the University
576 of Michigan LDAP reference implementation, and was developed by Tim
577 Howes, Mark Smith, and Gordon Good. It is based in part upon work
578 supported by the National Science Foundation under Grant No. NCR-
579 9416667.
581 Members of the IETF LDAP Extensions Working group provided many
582 helpful suggestions. In particular, Hallvard B. Furuseth of the
583 University of Oslo made many significant contributions to this
584 document, including a thorough review and rewrite of the BNF.
586 Normative References
588 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
589 Specifications: ABNF", RFC 2234, November 1997.
591 [RFC2253] Wahl, M., Kille, S. and T. Howes, "A String
592 Representation of Distinguished Names", RFC 2253,
593 December 1997.
595 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
596 Access Protocol (v3)", RFC 2251, July 1997.
598 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
599 Extensions (MIME) Part One: Format of Internet Message
600 Bodies", RFC 2045, November 1996.
602 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
603 Resource Locators (URL)", RFC 1738, December 1994.
605 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
606 Requirement Levels", BCP 14, RFC 2119, March 1997.
608 [RFC3629] Yergeau, F., "UTF-8, a transformation format
609 of ISO 10646", November 2003
614 Informative References
616 [RFC2849] Good, G., "The LDAP Data Interchange Format",
617 RFC 2849, June 2000.
619 [RFC2425] Howes, T. and M. Smith, "A MIME Content-Type for Directory
620 Information", RFC 2425, September 1998.
622 [Armijo00] M. P. Armijo, "Tree Delete Control", Work in Progress.
623 August 2000.
625 [UMich96] The SLAPD and SLURPD Administrators Guide. University of
626 Michigan, April 1996. <URL:
627 http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
629 [RFC2223] Postel, J. and Reynolds, J., "Instructions to RFC
630 Authors", RFC2223, October 1997.
632 Author's Address
634 Gordon Good
635 iPlanet e-commerce Solutions
636 150 Network Circle
637 Mailstop USCA17-201
638 Santa Clara, CA 95054, USA
640 Phone: +1 408 276 4351
641 EMail: ggood@netscape.com
643 Intellectual Property
645 The IETF takes no position regarding the validity or scope of any
646 Intellectual Property Rights or other rights that might be claimed
647 to pertain to the implementation or use of the technology
648 described in this document or the extent to which any license
649 under such rights might or might not be available; nor does it
650 represent that it has made any independent effort to identify any
651 such rights. Information on the ISOC's procedures with respect to
652 rights in ISOC Documents can be found in BCP 78 and BCP 79.
654 Copies of IPR disclosures made to the IETF Secretariat and any
655 assurances of licenses to be made available, or the result of an
656 attempt made to obtain a general license or permission for the use
657 of such proprietary rights by implementers or users of this
658 specification can be obtained from the IETF on-line IPR repository
659 at http://www.ietf.org/ipr.
661 The IETF invites any interested party to bring to its attention
662 any copyrights, patents or patent applications, or other
663 proprietary rights that may cover technology that may be required
664 to implement this standard. Please address the information to the
665 IETF at ietf-ipr@ietf.org.
667 Disclaimer of Validity
669 This document and the information contained herein is provided on an
670 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
671 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
672 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
673 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
674 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
676 Copyright Statement
678 Copyright (C) The IETF Trust (2009).
680 This document is subject to the rights, licenses and restrictions
681 contained in BCP 78, and except as set forth therein, the authors
682 retain all their rights.
684 Acknowledgement
686 Funding for the RFC Editor function is currently provided by the
687 Internet Society.