ldif-utf8
view proposal.txt @ 3:213f3b5dcd86
added definition and example from RFC4525.
| author | Yves dorfsman <yves@zioup.com> |
|---|---|
| date | Fri Mar 20 18:43:07 2009 -0600 (17 months ago) |
| parents | d307d875966f |
| children | 13b4014d68e1 |
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 mod-spec = "increment:" FILL AttributeDescription SEP
156 attrval-spec "-" SEP
157 ; from [RFC4525]
159 url = <a Uniform Resource Locator,
160 as defined in [RFC1738]>
161 ; (See Note 6, below)
163 AttributeDescription = AttributeType [";" options]
164 ; Definition taken from [RFC2251]
166 AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
168 options = option / (option ";" options)
170 option = 1*opt-char
172 attr-type-chars = ALPHA / DIGIT / "-"
174 opt-char = attr-type-chars
176 changerecord = "changetype:" FILL
177 (change-add / change-delete /
178 change-modify / change-moddn)
180 change-add = "add" SEP 1*attrval-spec
182 change-delete = "delete" SEP
184 change-moddn = ("modrdn" / "moddn") SEP
185 "newrdn:" ( FILL rdn /
186 ":" FILL base64-rdn) SEP
187 "deleteoldrdn:" FILL ("0" / "1") SEP
188 0*1("newsuperior:"
189 ( FILL distinguishedName /
190 ":" FILL base64-distinguishedName) SEP)
192 change-modify = "modify" SEP *mod-spec
194 mod-spec = ("add:" / "delete:" / "replace:")
195 FILL AttributeDescription SEP
196 *attrval-spec
197 "-" SEP
199 SPACE = %x20
200 ; ASCII SP, space
202 FILL = *SPACE
204 SEP = (CR LF / LF)
206 CR = %x0D
207 ; ASCII CR, carriage return
209 LF = %x0A
210 ; ASCII LF, line feed
212 ALPHA = %x41-5A / %x61-7A
213 ; A-Z / a-z
215 DIGIT = %x30-39
216 ; 0-9
218 UTF8-1 = %x00-7F
220 UTF8-tail = %x80-BF
222 UTF8-2 = %xC2-DF UTF8-tail
224 UTF8-3 = %xE0 %xA0-BF UTF8-tail /
225 %xE1-EC 2( UTF8-tail ) /
226 %xED %x80-9F UTF8-tail /
227 %xEE-EF 2( UTF8-tail )
229 UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) /
230 %xF1-F3 3( UTF8-tail ) /
231 %xF4 %x80-8F 2( UTF8-tail )
233 UTF8-CHAR = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
235 UTF8-STRING = *UTF8-CHAR
237 SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
238 ; any value <= 127 decimal except NUL, LF,
239 ; and CR
241 SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
242 %x21-39 / %x3B / %x3D-7F
243 ; any value <= 127 except NUL, LF, CR,
244 ; SPACE, colon (":", ASCII 58 decimal)
245 ; and less-than ("<" , ASCII 60 decimal)
247 SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
249 SAFE-UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
251 SAFE-INIT-UTF8-CHAR = SAFE-INIT-CHAR / UTF8-2 / UTF8-3 / UTF8-4
253 SAFE-UTF8-STRING = [SAFE-INIT-UTF8-CHAR *SAFE-UTF8-CHAR]
255 BASE64-UTF8-STRING = BASE64-STRING
256 ; MUST be the base64 encoding of a
257 ; UTF8-STRING
259 BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
260 %x61-7A
261 ; +, /, 0-9, =, A-Z, and a-z
262 ; as specified in [RFC2045]
264 BASE64-STRING = [*(BASE64-CHAR)]
267 Notes on LDIF Syntax
269 1) For the LDIF format described in this document, the version
270 number MUST be "2". If the version number is absent,
271 implementations MAY choose to interpret the contents as an
272 older LDIF file format, supported by the University of
273 Michigan ldap-3.3 implementation [UMich96].
275 2) Any non-empty line, including comment lines, in an LDIF file
276 MAY be folded by inserting a line separator (SEP) and a SPACE.
277 Folding MUST NOT occur before the first character of the line.
278 In other words, folding a line into two lines, the first of
279 which is empty, is not permitted. Any line that begins with a
280 single space MUST be treated as a continuation of the previous
281 (non-empty) line. When joining folded lines, exactly one space
282 character at the beginning of each continued line must be
283 discarded. Implementations SHOULD NOT fold lines in the middle
284 of a multi-byte UTF-8 character.
286 3) Any line that begins with a pound-sign ("#", ASCII 35) is a
287 comment line, and MUST be ignored when parsing an LDIF file.
289 4) Any dn, rdn or attrval-spec that contains characters other
290 than those defined as "SAFE-UTF8-CHAR", or begins with a
291 character other than those defined as "SAFE-INIT-UTF8-CHAR",
292 above, MUST be base-64 encoded. Other values MAY be base-64
293 encoded. Any value that contains characters other than those
294 defined as "SAFE--CHAR", or begins with a character other than
295 those defined as "SAFE-INIT--CHAR", above, MUST be base-64
296 encoded. Other values MAY be base-64 encoded.
298 5) When a zero-length attribute value is to be included directly
299 in an LDIF file, it MUST be represented as
300 AttributeDescription ":" FILL SEP. For example, "seeAlso:"
301 followed by a newline represents a zero-length "seeAlso"
302 attribute value. It is also permissible for the value
303 referred to by a URL to be of zero length.
305 6) When a URL is specified in an attrval-spec, the following
306 conventions apply:
308 a) Implementations SHOULD support the file:// URL format. The
309 contents of the referenced file are to be included verbatim
310 in the interpreted output of the LDIF file.
311 b) Implementations MAY support other URL formats. The
312 semantics associated with each supported URL will be
313 documented in an associated Applicability Statement.
315 7) Distinguished names, relative distinguished names, and
316 attribute values of DirectoryString syntax MUST be valid UTF-8
317 strings. Implementations that read LDIF MAY interpret files
318 in which these entities are stored in some other character set
319 encoding, but implementations MUST NOT generate LDIF content
320 which does not contain valid UTF-8 data.
322 8) Values or distinguished names that end with SPACE SHOULD be
323 base-64 encoded.
325 9) When controls are included in an LDIF file, implementations
326 MAY choose to ignore some or all of them. This may be
327 necessary if the changes described in the LDIF file are being
328 sent on an LDAPv2 connection (LDAPv2 does not support
329 controls), or the particular controls are not supported by the
330 remote server. If the criticality of a control is "true", then
331 the implementation MUST either include the control, or MUST
332 NOT send the operation to a remote server.
334 10) When an attrval-spec, distinguishedName, or rdn is base64-
335 encoded, the encoding rules specified in [RFC2045] are used
336 with the following exceptions: a) The requirement that base64
337 output streams must be represented as lines of no more than 76
338 characters is removed. Lines in LDIF files may only be folded
339 according to the folding rules described in note 2, above. b)
340 Base64 strings in [RFC2045] may contain characters other than
341 those defined in BASE64-CHAR, and are ignored. LDIF does not
342 permit any extraneous characters, other than those used for
343 line folding.
345 Examples of LDAP Data Interchange Format
347 Example 1: An simple LDAP file with two entries
349 version: 1
350 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
351 objectclass: top
352 objectclass: person
353 objectclass: organizationalPerson
354 cn: Barbara Jensen
355 cn: Barbara J Jensen
356 cn: Babs Jensen
357 sn: Jensen
358 uid: bjensen
359 telephonenumber: +1 408 555 1212
360 description: A big sailing fan.
362 dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
363 objectclass: top
364 objectclass: person
365 objectclass: organizationalPerson
366 cn: Bjorn Jensen
367 sn: Jensen
368 telephonenumber: +1 408 555 1212
370 Example 2: A file containing an entry with a folded attribute value
372 version: 1
373 dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
374 objectclass:top
375 objectclass:person
376 objectclass:organizationalPerson
377 cn:Barbara Jensen
378 cn:Barbara J Jensen
379 cn:Babs Jensen
380 sn:Jensen
381 uid:bjensen
382 telephonenumber:+1 408 555 1212
383 description:Babs is a big sailing fan, and travels extensively in sea
384 rch of perfect sailing conditions.
385 title:Product Manager, Rod and Reel Division
387 Example 3: A file containing a base-64-encoded value
389 version: 1
390 dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
391 objectclass: top
392 objectclass: person
393 objectclass: organizationalPerson
394 cn: Gern Jensen
395 cn: Gern O Jensen
396 sn: Jensen
397 uid: gernj
398 telephonenumber: +1 408 555 1212
399 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
400 IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
401 VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
402 b3V0IG1vcmUu
404 Example 4: A file containing an entries with UTF-8-encoded attribute
405 values, including language tags. Comments indicate the contents
406 of UTF-8-encoded attributes and distinguished names.
408 version: 1
409 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
410 # dn:: ou=<JapaneseOU>,o=Airius
411 objectclass: top
412 objectclass: organizationalUnit
413 ou:: 5Za25qWt6YOo
414 # ou:: <JapaneseOU>
415 ou;lang-ja:: 5Za25qWt6YOo
416 # ou;lang-ja:: <JapaneseOU>
417 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
419 # ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
420 ou;lang-en: Sales
421 description: Japanese office
423 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
424 # dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
425 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
426 objectclass: top
427 objectclass: person
428 objectclass: organizationalPerson
429 objectclass: inetOrgPerson
430 uid: rogasawara
431 mail: rogasawara@airius.co.jp
432 givenname;lang-ja:: 44Ot44OJ44OL44O8
433 # givenname;lang-ja:: <JapaneseGivenname>
434 sn;lang-ja:: 5bCP56yg5Y6f
435 # sn;lang-ja:: <JapaneseSn>
436 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
437 # cn;lang-ja:: <JapaneseCn>
438 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
439 # title;lang-ja:: <JapaneseTitle>
440 preferredlanguage: ja
441 givenname:: 44Ot44OJ44OL44O8
442 # givenname:: <JapaneseGivenname>
443 sn:: 5bCP56yg5Y6f
444 # sn:: <JapaneseSn>
445 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
446 # cn:: <JapaneseCn>
447 title:: 5Za25qWt6YOoIOmDqOmVtw==
448 # title:: <JapaneseTitle>
449 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
450 # givenname;lang-ja;phonetic::
451 <JapaneseGivenname_in_phonetic_representation_kana>
452 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
453 # sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
454 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
455 # cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
456 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
457 # title;lang-ja;phonetic::
458 # <JapaneseTitle_in_phonetic_representation_kana>
459 givenname;lang-en: Rodney
460 sn;lang-en: Ogasawara
461 cn;lang-en: Rodney Ogasawara
462 title;lang-en: Sales, Director
464 Example 5: A file containing a reference to an external file
466 version: 1
467 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
468 objectclass: top
469 objectclass: person
470 objectclass: organizationalPerson
471 cn: Horatio Jensen
473 cn: Horatio N Jensen
474 sn: Jensen
475 uid: hjensen
476 telephonenumber: +1 408 555 1212
477 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
479 Example 6: A file containing a series of change records and comments
481 version: 1
482 # Add a new entry
483 dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
484 changetype: add
485 objectclass: top
486 objectclass: person
487 objectclass: organizationalPerson
488 cn: Fiona Jensen
489 sn: Jensen
490 uid: fiona
491 telephonenumber: +1 408 555 1212
492 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
494 # Delete an existing entry
495 dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
496 changetype: delete
498 # Modify an entry's relative distinguished name
499 dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
500 changetype: modrdn
501 newrdn: cn=Paula Jensen
502 deleteoldrdn: 1
504 # Rename an entry and move all of its children to a new location in
505 # the directory tree (only implemented by LDAPv3 servers).
506 dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
507 changetype: modrdn
508 newrdn: ou=Product Development Accountants
509 deleteoldrdn: 0
510 newsuperior: ou=Accounting, dc=airius, dc=com
512 # Modify an entry: add an additional value to the postaladdress
513 # attribute, completely delete the description attribute, replace
514 # the telephonenumber attribute with two values, and delete a specific
515 # value from the facsimiletelephonenumber attribute
516 dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
517 changetype: modify
518 add: postaladdress
519 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
520 -
522 delete: description
523 -
524 replace: telephonenumber
525 telephonenumber: +1 408 555 1234
526 telephonenumber: +1 408 555 5678
527 -
528 delete: facsimiletelephonenumber
529 facsimiletelephonenumber: +1 408 555 9876
530 -
532 # Modify an entry: replace the postaladdress attribute with an empty
533 # set of values (which will cause the attribute to be removed), and
534 # delete the entire description attribute. Note that the first will
535 # always succeed, while the second will only succeed if at least
536 # one value for the description attribute is present.
537 dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
538 changetype: modify
539 replace: postaladdress
540 -
541 delete: description
542 -
544 Example 7: An LDIF file containing a change record with a control
545 version: 1
546 # Delete an entry. The operation will attach the LDAPv3
547 # Tree Delete Control defined in [Armijo00]. The criticality
548 # field is "true" and the controlValue field is
549 # absent, as required by [Armijo00].
550 dn: ou=Product Development, dc=airius, dc=com
551 control: 1.2.840.113556.1.4.805 true
552 changetype: delete
554 Example 8: Incrementing the uidNumber, example from [RFC4525].
555 # Increment uidNumber
556 version: 1
557 dn: cn=max-assigned uidNumber,dc=example,dc=com
558 changetype: modify
559 increment: uidNumber
560 uidNumber: 1
561 -
563 Security Considerations
565 Given typical directory applications, an LDIF file is likely to
566 contain sensitive personal data. Appropriate measures should be
567 taken to protect the privacy of those persons whose data is contained
568 in an LDIF file.
570 Since ":<" directives can cause external content to be included when
571 processing an LDIF file, one should be cautious of accepting LDIF
572 files from external sources. A "trojan" LDIF file could name a file
573 with sensitive contents and cause it to be included in a directory
574 entry, which a hostile entity could read via LDAP.
576 LDIF does not provide any method for carrying authentication
577 information with an LDIF file. Users of LDIF files must take care to
578 verify the integrity of an LDIF file received from an external
579 source.
581 Contributors
582 Gordon Good was the author of [RFC2849] which defined LDIF. Most
583 of this specification is a copy of [RFC2849], simply adding full
584 support for UTF-8 and editing according to newer RFC standards.
586 Acknowledgments
588 The LDAP Interchange Format was developed as part of the University
589 of Michigan LDAP reference implementation, and was developed by Tim
590 Howes, Mark Smith, and Gordon Good. It is based in part upon work
591 supported by the National Science Foundation under Grant No. NCR-
592 9416667.
594 Members of the IETF LDAP Extensions Working group provided many
595 helpful suggestions. In particular, Hallvard B. Furuseth of the
596 University of Oslo made many significant contributions to this
597 document, including a thorough review and rewrite of the BNF.
599 Normative References
601 [RFC2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
602 Specifications: ABNF", RFC 2234, November 1997.
604 [RFC2253] Wahl, M., Kille, S. and T. Howes, "A String
605 Representation of Distinguished Names", RFC 2253,
606 December 1997.
608 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
609 Access Protocol (v3)", RFC 2251, July 1997.
611 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
612 Extensions (MIME) Part One: Format of Internet Message
613 Bodies", RFC 2045, November 1996.
615 [RFC1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
616 Resource Locators (URL)", RFC 1738, December 1994.
618 [RFC2119] Bradner, S., "Key Words for use in RFCs to Indicate
619 Requirement Levels", BCP 14, RFC 2119, March 1997.
621 [RFC3629] Yergeau, F., "UTF-8, a transformation format
622 of ISO 10646", November 2003
624 [RFC4525] Zeilenga, K., "Lightweight Directory Access Protocol
625 Modify-Increment Extension", RFC 4525, June 2006
627 Informative References
629 [RFC2849] Good, G., "The LDAP Data Interchange Format",
630 RFC 2849, June 2000.
632 [RFC2425] Howes, T. and M. Smith, "A MIME Content-Type for Directory
633 Information", RFC 2425, September 1998.
635 [Armijo00] M. P. Armijo, "Tree Delete Control", Work in Progress.
636 August 2000.
638 [UMich96] The SLAPD and SLURPD Administrators Guide. University of
639 Michigan, April 1996. <URL:
640 http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
642 [RFC2223] Postel, J. and Reynolds, J., "Instructions to RFC
643 Authors", RFC2223, October 1997.
645 Author's Address
647 Gordon Good
648 iPlanet e-commerce Solutions
649 150 Network Circle
650 Mailstop USCA17-201
651 Santa Clara, CA 95054, USA
653 Phone: +1 408 276 4351
654 EMail: ggood@netscape.com
656 Intellectual Property
658 The IETF takes no position regarding the validity or scope of any
659 Intellectual Property Rights or other rights that might be claimed
660 to pertain to the implementation or use of the technology
661 described in this document or the extent to which any license
662 under such rights might or might not be available; nor does it
663 represent that it has made any independent effort to identify any
664 such rights. Information on the ISOC's procedures with respect to
665 rights in ISOC Documents can be found in BCP 78 and BCP 79.
667 Copies of IPR disclosures made to the IETF Secretariat and any
668 assurances of licenses to be made available, or the result of an
669 attempt made to obtain a general license or permission for the use
670 of such proprietary rights by implementers or users of this
671 specification can be obtained from the IETF on-line IPR repository
672 at http://www.ietf.org/ipr.
674 The IETF invites any interested party to bring to its attention
675 any copyrights, patents or patent applications, or other
676 proprietary rights that may cover technology that may be required
677 to implement this standard. Please address the information to the
678 IETF at ietf-ipr@ietf.org.
680 Disclaimer of Validity
682 This document and the information contained herein is provided on an
683 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
684 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
685 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
686 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
687 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
689 Copyright Statement
691 Copyright (C) The IETF Trust (2009).
693 This document is subject to the rights, licenses and restrictions
694 contained in BCP 78, and except as set forth therein, the authors
695 retain all their rights.
697 Acknowledgement
699 Funding for the RFC Editor function is currently provided by the
700 Internet Society.