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