1.1 --- a/proposal.txt	Tue Mar 10 19:49:43 2009 -0600
     1.2 +++ b/proposal.txt	Fri Mar 20 18:11:24 2009 -0600
     1.3 @@ -5,23 +5,20 @@
     1.4  
     1.5  
     1.6  Network Working Group                                             G. Good
     1.7 -Request for Comments: 2849                   iPlanet e-commerce Solutions
     1.8 -Category: Standards Track                                       June 2000
     1.9 +INTERNET-DRAFT
    1.10 +Obsoletes: 2849
    1.11 +Category: Standards Track
    1.12  
    1.13  
    1.14     The LDAP Data Interchange Format (LDIF) - Technical Specification
    1.15  
    1.16 +
    1.17  Status of this Memo
    1.18  
    1.19 -   This document specifies an Internet standards track protocol for the
    1.20 -   Internet community, and requests discussion and suggestions for
    1.21 -   improvements.  Please refer to the current edition of the "Internet
    1.22 -   Official Protocol Standards" (STD 1) for the standardization state
    1.23 -   and status of this protocol.  Distribution of this memo is unlimited.
    1.24 -
    1.25 -Copyright Notice
    1.26 -
    1.27 -   Copyright (C) The Internet Society (2000).  All Rights Reserved.
    1.28 +   By submitting this Internet-Draft, each author represents that any
    1.29 +   applicable patent or other IPR claims of which he or she is aware
    1.30 +   have been or will be disclosed, and any of which he or she becomes
    1.31 +   aware will be disclosed, in accordance with Section 6 of BCP 79.
    1.32  
    1.33  Abstract
    1.34  
    1.35 @@ -32,6 +29,23 @@
    1.36     LDAP-based directory servers, or to describe a set of changes which
    1.37     are to be applied to a directory.
    1.38  
    1.39 +Relationship to Obsolete Specification
    1.40 +
    1.41 +   This obsoletes and replaces [RFC2849] which defined version 1
    1.42 +   of LDIF.
    1.43 +
    1.44 +   The paragraph "Notes on LDIF Syntax" in [RFC2849] documented the
    1.45 +   use of non-encoded UTF-8 inside an LDIF file, but the "Formal Syntax
    1.46 +   Definition of LDIF" specified either ASCII or base64 encoded UTF-8
    1.47 +   for distinguishedName, rdn and attrval-spec.  The specification has
    1.48 +   been changed to allow UTF-8 strings without the use of encoding.
    1.49 +
    1.50 +   The definition of UTF-8 has been slightly modified to follow the
    1.51 +   definition from [RFC3629].
    1.52 +
    1.53 +   The style has been changed to conform with the newer editorial
    1.54 +   standards from [RFC223], specifically in quoting references.
    1.55 +
    1.56  Background and Intended Usage
    1.57  
    1.58     There are a number of situations where a common interchange format is
    1.59 @@ -43,7 +57,7 @@
    1.60     Additionally, by using a well-defined interchange format, development
    1.61     of data import tools from legacy systems is facilitated.  A fairly
    1.62     simple set of tools written in awk or perl can, for example, convert
    1.63 -   a database of personnel information into an LDIF file. This file can
    1.64 +   a database of personnel information into an LDIF file.  This file can
    1.65     then be imported into a directory server, regardless of the internal
    1.66     database representation the target directory server uses.
    1.67  
    1.68 @@ -54,7 +68,7 @@
    1.69  
    1.70     Relationship to the application/directory MIME content-type:
    1.71  
    1.72 -   The application/directory MIME content-type [1] is a general
    1.73 +   The application/directory MIME content-type [RFC2425] is a general
    1.74     framework and format for conveying directory information, and is
    1.75     independent of any particular directory service.  The LDIF format is
    1.76     a simpler format which is perhaps easier to create, and may also be
    1.77 @@ -62,7 +76,8 @@
    1.78     directory.
    1.79  
    1.80     The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
    1.81 -   used in this document are to be interpreted as described in [7].
    1.82 +   used in this document are to be interpreted as described
    1.83 +   in [RFC2119].
    1.84  
    1.85  Definition of the LDAP Data Interchange Format
    1.86  
    1.87 @@ -84,7 +99,7 @@
    1.88  Formal Syntax Definition of LDIF
    1.89  
    1.90     The following definition uses the augmented Backus-Naur Form
    1.91 -   specified in RFC 2234 [2].
    1.92 +   specified in [RFC2234].
    1.93  
    1.94  ldif-file                = ldif-content / ldif-changes
    1.95  
    1.96 @@ -99,22 +114,23 @@
    1.97  version-spec             = "version:" FILL version-number
    1.98  
    1.99  version-number           = 1*DIGIT
   1.100 -                           ; version-number MUST be "1" for the
   1.101 +                           ; version-number MUST be "2" for the
   1.102                             ; LDIF format described in this document.
   1.103  
   1.104  dn-spec                  = "dn:" (FILL distinguishedName /
   1.105                                    ":" FILL base64-distinguishedName)
   1.106  
   1.107 -distinguishedName        = SAFE-STRING
   1.108 -                           ; a distinguished name, as defined in [3]
   1.109 +distinguishedName        = SAFE-UTF8-STRING
   1.110 +                           ; a distinguished name, as defined
   1.111 +                           ; in [RFC2253]
   1.112  
   1.113  base64-distinguishedName = BASE64-UTF8-STRING
   1.114                             ; a distinguishedName which has been base64
   1.115                             ; encoded (see note 10, below)
   1.116  
   1.117 -rdn                      = SAFE-STRING
   1.118 +rdn                      = SAFE-UTF8-STRING
   1.119                             ; a relative distinguished name, defined as
   1.120 -                           ; <name-component> in [3]
   1.121 +                           ; <name-component> in [RFC2253]
   1.122  
   1.123  base64-rdn               = BASE64-UTF8-STRING
   1.124                             ; an rdn which has been base64 encoded (see
   1.125 @@ -127,21 +143,21 @@
   1.126                             ; (See note 9, below)
   1.127  
   1.128  ldap-oid                 = 1*DIGIT 0*1("." 1*DIGIT)
   1.129 -                           ; An LDAPOID, as defined in [4]
   1.130 +                           ; An LDAPOID, as defined in [RFC2251]
   1.131  
   1.132  attrval-spec             = AttributeDescription value-spec SEP
   1.133  
   1.134 -value-spec               = ":" (    FILL 0*1(SAFE-STRING) /
   1.135 +value-spec               = ":" (    FILL 0*1(SAFE-UTF8-STRING) /
   1.136                                  ":" FILL (BASE64-STRING) /
   1.137                                  "<" FILL url)
   1.138                             ; See notes 7 and 8, below
   1.139  
   1.140  url                      = <a Uniform Resource Locator,
   1.141 -                            as defined in [6]>
   1.142 +                            as defined in [RFC1738]>
   1.143                                     ; (See Note 6, below)
   1.144  
   1.145  AttributeDescription     = AttributeType [";" options]
   1.146 -                           ; Definition taken from [4]
   1.147 +                           ; Definition taken from [RFC2251]
   1.148  
   1.149  AttributeType            = ldap-oid / (ALPHA *(attr-type-chars))
   1.150  
   1.151 @@ -195,17 +211,24 @@
   1.152  DIGIT                    = %x30-39
   1.153                             ; 0-9
   1.154  
   1.155 -UTF8-1                   = %x80-BF
   1.156 +UTF8-1                   = %x00-7F
   1.157  
   1.158 -UTF8-2                   = %xC0-DF UTF8-1
   1.159 +UTF8-tail                = %x80-BF
   1.160  
   1.161 -UTF8-3                   = %xE0-EF 2UTF8-1
   1.162 +UTF8-2                   = %xC2-DF UTF8-tail
   1.163  
   1.164 -UTF8-4                   = %xF0-F7 3UTF8-1
   1.165 +UTF8-3                   = %xE0 %xA0-BF UTF8-tail /
   1.166 +                           %xE1-EC 2( UTF8-tail ) /
   1.167 +                           %xED %x80-9F UTF8-tail /
   1.168 +                           %xEE-EF 2( UTF8-tail )
   1.169  
   1.170 -UTF8-5                   = %xF8-FB 4UTF8-1
   1.171 +UTF8-4                   = %xF0 %x90-BF 2( UTF8-tail ) /
   1.172 +                           %xF1-F3 3( UTF8-tail ) /
   1.173 +                           %xF4 %x80-8F 2( UTF8-tail )
   1.174  
   1.175 -UTF8-6                   = %xFC-FD 5UTF8-1
   1.176 +UTF8-CHAR                = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
   1.177 +
   1.178 +UTF8-STRING              = *UTF8-CHAR
   1.179  
   1.180  SAFE-CHAR                = %x01-09 / %x0B-0C / %x0E-7F
   1.181                             ; any value <= 127 decimal except NUL, LF,
   1.182 @@ -219,10 +242,11 @@
   1.183  
   1.184  SAFE-STRING              = [SAFE-INIT-CHAR *SAFE-CHAR]
   1.185  
   1.186 -UTF8-CHAR                = SAFE-CHAR / UTF8-2 / UTF8-3 /
   1.187 -                           UTF8-4 / UTF8-5 / UTF8-6
   1.188 +SAFE-UTF8-CHAR           = SAFE-CHAR / UTF8-2 / UTF8-3 / UTF8-4
   1.189  
   1.190 -UTF8-STRING              = *UTF8-CHAR
   1.191 +SAFE-INIT-UTF8-CHAR      = SAFE-INIT-CHAR / UTF8-2 / UTF8-3 / UTF8-4
   1.192 +
   1.193 +SAFE-UTF8-STRING         = [SAFE-INIT-UTF8-CHAR *SAFE-UTF8-CHAR]
   1.194  
   1.195  BASE64-UTF8-STRING       = BASE64-STRING
   1.196                             ; MUST be the base64 encoding of a
   1.197 @@ -231,7 +255,7 @@
   1.198  BASE64-CHAR              = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
   1.199                             %x61-7A
   1.200                             ; +, /, 0-9, =, A-Z, and a-z
   1.201 -                           ; as specified in [5]
   1.202 +                           ; as specified in [RFC2045]
   1.203  
   1.204  BASE64-STRING            = [*(BASE64-CHAR)]
   1.205  
   1.206 @@ -239,33 +263,33 @@
   1.207     Notes on LDIF Syntax
   1.208  
   1.209        1)  For the LDIF format described in this document, the version
   1.210 -          number MUST be "1". If the version number is absent,
   1.211 +          number MUST be "2".  If the version number is absent,
   1.212            implementations MAY choose to interpret the contents as an
   1.213            older LDIF file format, supported by the University of
   1.214 -          Michigan ldap-3.3 implementation [8].
   1.215 +          Michigan ldap-3.3 implementation [UMich96].
   1.216  
   1.217        2)  Any non-empty line, including comment lines, in an LDIF file
   1.218            MAY be folded by inserting a line separator (SEP) and a SPACE.
   1.219            Folding MUST NOT occur before the first character of the line.
   1.220            In other words, folding a line into two lines, the first of
   1.221 -          which is empty, is not permitted. Any line that begins with a
   1.222 +          which is empty, is not permitted.  Any line that begins with a
   1.223            single space MUST be treated as a continuation of the previous
   1.224 -          (non-empty) line. When joining folded lines, exactly one space
   1.225 +          (non-empty) line.  When joining folded lines, exactly one space
   1.226            character at the beginning of each continued line must be
   1.227 -          discarded. Implementations SHOULD NOT fold lines in the middle
   1.228 +          discarded.  Implementations SHOULD NOT fold lines in the middle
   1.229            of a multi-byte UTF-8 character.
   1.230  
   1.231        3)  Any line that begins with a pound-sign ("#", ASCII 35) is a
   1.232            comment line, and MUST be ignored when parsing an LDIF file.
   1.233  
   1.234 -      4)  Any dn or rdn that contains characters other than those
   1.235 -          defined as "SAFE-UTF8-CHAR", or begins with a character other
   1.236 -          than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be
   1.237 -          base-64 encoded.  Other values MAY be base-64 encoded.  Any
   1.238 -          value that contains characters other than those defined as
   1.239 -          "SAFE-CHAR", or begins with a character other than those
   1.240 -          defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
   1.241 -          Other values MAY be base-64 encoded.
   1.242 +      4)  Any dn, rdn or attrval-spec that contains characters other
   1.243 +          than those defined as "SAFE-UTF8-CHAR", or begins with a
   1.244 +          character other than those defined as "SAFE-INIT-UTF8-CHAR",
   1.245 +          above, MUST be base-64 encoded.  Other values MAY be base-64
   1.246 +          encoded.  Any value that contains characters other than those
   1.247 +          defined as "SAFE--CHAR", or begins with a character other than
   1.248 +          those defined as "SAFE-INIT--CHAR", above, MUST be base-64
   1.249 +          encoded.  Other values MAY be base-64 encoded.
   1.250  
   1.251        5)  When a zero-length attribute value is to be included directly
   1.252            in an LDIF file, it MUST be represented as
   1.253 @@ -295,24 +319,24 @@
   1.254            base-64 encoded.
   1.255  
   1.256        9)  When controls are included in an LDIF file, implementations
   1.257 -          MAY choose to ignore some or all of them. This may be
   1.258 +          MAY choose to ignore some or all of them.  This may be
   1.259            necessary if the changes described in the LDIF file are being
   1.260            sent on an LDAPv2 connection (LDAPv2 does not support
   1.261            controls), or the particular controls are not supported by the
   1.262 -          remote server. If the criticality of a control is "true", then
   1.263 +          remote server.  If the criticality of a control is "true", then
   1.264            the implementation MUST either include the control, or MUST
   1.265            NOT send the operation to a remote server.
   1.266  
   1.267        10) When an attrval-spec, distinguishedName, or rdn is base64-
   1.268 -          encoded, the encoding rules specified in [5] are used with the
   1.269 -          following exceptions:  a) The requirement that base64 output
   1.270 -          streams must be represented as lines of no more than 76
   1.271 -          characters is removed. Lines in LDIF files may only be folded
   1.272 +          encoded, the encoding rules specified in [RFC2045] are used
   1.273 +          with the following exceptions:  a) The requirement that base64
   1.274 +          output streams must be represented as lines of no more than 76
   1.275 +          characters is removed.  Lines in LDIF files may only be folded
   1.276            according to the folding rules described in note 2, above.  b)
   1.277 -          Base64 strings in [5] may contain characters other than those
   1.278 -          defined in BASE64-CHAR, and are ignored. LDIF does not permit
   1.279 -          any extraneous characters, other than those used for line
   1.280 -          folding.
   1.281 +          Base64 strings in [RFC2045] may contain characters other than
   1.282 +          those defined in BASE64-CHAR, and are ignored.  LDIF does not
   1.283 +          permit any extraneous characters, other than those used for
   1.284 +          line folding.
   1.285  
   1.286  Examples of LDAP Data Interchange Format
   1.287  
   1.288 @@ -503,7 +527,7 @@
   1.289  
   1.290  # Modify an entry: replace the postaladdress attribute with an empty
   1.291  # set of values (which will cause the attribute to be removed), and
   1.292 -# delete the entire description attribute. Note that the first will
   1.293 +# delete the entire description attribute.  Note that the first will
   1.294  # always succeed, while the second will only succeed if at least
   1.295  # one value for the description attribute is present.
   1.296  dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
   1.297 @@ -515,10 +539,10 @@
   1.298  
   1.299  Example 7: An LDIF file containing a change record with a control
   1.300  version: 1
   1.301 -# Delete an entry. The operation will attach the LDAPv3
   1.302 -# Tree Delete Control defined in [9]. The criticality
   1.303 +# Delete an entry.  The operation will attach the LDAPv3
   1.304 +# Tree Delete Control defined in [Armijo00].  The criticality
   1.305  # field is "true" and the controlValue field is
   1.306 -# absent, as required by [9].
   1.307 +# absent, as required by [Armijo00].
   1.308  dn: ou=Product Development, dc=airius, dc=com
   1.309  control: 1.2.840.113556.1.4.805 true
   1.310  changetype: delete
   1.311 @@ -541,6 +565,11 @@
   1.312     verify the integrity of an LDIF file received from an external
   1.313     source.
   1.314  
   1.315 +Contributors
   1.316 +   Gordon Good was the author of [RFC2849] which defined LDIF. Most
   1.317 +   of this specification is a copy of [RFC2849], simply adding full
   1.318 +   support for UTF-8 and editing according to newer RFC standards.
   1.319 +
   1.320  Acknowledgments
   1.321  
   1.322     The LDAP Interchange Format was developed as part of the University
   1.323 @@ -550,39 +579,55 @@
   1.324     9416667.
   1.325  
   1.326     Members of the IETF LDAP Extensions Working group provided many
   1.327 -   helpful suggestions. In particular, Hallvard B. Furuseth of the
   1.328 +   helpful suggestions.  In particular, Hallvard B. Furuseth of the
   1.329     University of Oslo made many significant contributions to this
   1.330     document, including a thorough review and rewrite of the BNF.
   1.331  
   1.332 -References
   1.333 +Normative References
   1.334  
   1.335 -   [1]  Howes, T. and M. Smith, "A MIME Content-Type for Directory
   1.336 -        Information", RFC 2425, September 1998.
   1.337 +   [RFC2234]   Crocker, D., and P. Overell, "Augmented BNF for Syntax
   1.338 +               Specifications: ABNF", RFC 2234, November 1997.
   1.339  
   1.340 -   [2]  Crocker, D., and P. Overell, "Augmented BNF for Syntax
   1.341 -        Specifications: ABNF", RFC 2234, November 1997.
   1.342 +   [RFC2253]   Wahl, M., Kille, S. and T. Howes, "A String
   1.343 +               Representation of Distinguished Names", RFC 2253,
   1.344 +               December 1997.
   1.345  
   1.346 -   [3]  Wahl, M., Kille, S. and T. Howes, "A String Representation of
   1.347 -        Distinguished Names", RFC 2253, December 1997.
   1.348 +   [RFC2251]   Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
   1.349 +               Access Protocol (v3)", RFC 2251, July 1997.
   1.350  
   1.351 -   [4]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
   1.352 -        Protocol (v3)", RFC 2251, July 1997.
   1.353 +   [RFC2045]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
   1.354 +               Extensions (MIME) Part One: Format of Internet Message
   1.355 +               Bodies", RFC 2045, November 1996.
   1.356  
   1.357 -   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
   1.358 -        Extensions (MIME) Part One: Format of Internet Message Bodies",
   1.359 -        RFC 2045, November 1996.
   1.360 +   [RFC1738]   Berners-Lee,  T., Masinter, L. and M. McCahill, "Uniform
   1.361 +               Resource Locators (URL)", RFC 1738, December 1994.
   1.362  
   1.363 -   [6]  Berners-Lee,  T., Masinter, L. and M. McCahill, "Uniform
   1.364 -        Resource Locators (URL)", RFC 1738, December 1994.
   1.365 +   [RFC2119]   Bradner, S., "Key Words for use in RFCs to Indicate
   1.366 +               Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.367  
   1.368 -   [7]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
   1.369 -        Levels", BCP 14, RFC 2119, March 1997.
   1.370 +   [RFC3629]   Yergeau, F., "UTF-8, a transformation format
   1.371 +               of ISO 10646", November 2003
   1.372  
   1.373 -   [8]  The SLAPD and SLURPD Administrators Guide.  University of
   1.374 -        Michigan, April 1996.  <URL:
   1.375 -        http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
   1.376  
   1.377 -   [9]  M. P. Armijo, "Tree Delete Control", Work in Progress.
   1.378 +
   1.379 +
   1.380 +Informative References
   1.381 +
   1.382 +   [RFC2849]   Good, G., "The LDAP Data Interchange Format",
   1.383 +               RFC 2849, June 2000.
   1.384 +
   1.385 +   [RFC2425]   Howes, T. and M. Smith, "A MIME Content-Type for Directory
   1.386 +               Information", RFC 2425, September 1998.
   1.387 +
   1.388 +   [Armijo00]  M. P. Armijo, "Tree Delete Control", Work in Progress.
   1.389 +               August 2000.
   1.390 +
   1.391 +   [UMich96]   The SLAPD and SLURPD Administrators Guide.  University of
   1.392 +               Michigan, April 1996.  <URL:
   1.393 +           http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
   1.394 +
   1.395 +   [RFC2223]   Postel, J. and Reynolds, J., "Instructions to RFC
   1.396 +               Authors", RFC2223, October 1997.
   1.397  
   1.398  Author's Address
   1.399  
   1.400 @@ -595,26 +640,31 @@
   1.401     Phone: +1 408 276 4351
   1.402     EMail:  ggood@netscape.com
   1.403  
   1.404 -Full Copyright Statement
   1.405 +Intellectual Property
   1.406  
   1.407 -   Copyright (C) The Internet Society (2000).  All Rights Reserved.
   1.408 +   The IETF takes no position regarding the validity or scope of any
   1.409 +   Intellectual Property Rights or other rights that might be claimed
   1.410 +   to pertain to the implementation or use of the technology
   1.411 +   described in this document or the extent to which any license
   1.412 +   under such rights might or might not be available; nor does it
   1.413 +   represent that it has made any independent effort to identify any
   1.414 +   such rights.  Information on the ISOC's procedures with respect to
   1.415 +   rights in ISOC Documents can be found in BCP 78 and BCP 79.
   1.416  
   1.417 -   This document and translations of it may be copied and furnished to
   1.418 -   others, and derivative works that comment on or otherwise explain it
   1.419 -   or assist in its implementation may be prepared, copied, published
   1.420 -   and distributed, in whole or in part, without restriction of any
   1.421 -   kind, provided that the above copyright notice and this paragraph are
   1.422 -   included on all such copies and derivative works.  However, this
   1.423 -   document itself may not be modified in any way, such as by removing
   1.424 -   the copyright notice or references to the Internet Society or other
   1.425 -   Internet organizations, except as needed for the purpose of
   1.426 -   developing Internet standards in which case the procedures for
   1.427 -   copyrights defined in the Internet Standards process must be
   1.428 -   followed, or as required to translate it into languages other than
   1.429 -   English.
   1.430 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.431 +   assurances of licenses to be made available, or the result of an
   1.432 +   attempt made to obtain a general license or permission for the use
   1.433 +   of such proprietary rights by implementers or users of this
   1.434 +   specification can be obtained from the IETF on-line IPR repository
   1.435 +   at http://www.ietf.org/ipr.
   1.436  
   1.437 -   The limited permissions granted above are perpetual and will not be
   1.438 -   revoked by the Internet Society or its successors or assigns.
   1.439 +   The IETF invites any interested party to bring to its attention
   1.440 +   any copyrights, patents or patent applications, or other
   1.441 +   proprietary rights that may cover technology that may be required
   1.442 +   to implement this standard.  Please address the information to the
   1.443 +   IETF at ietf-ipr@ietf.org.
   1.444 +
   1.445 +Disclaimer of Validity
   1.446  
   1.447     This document and the information contained herein is provided on an
   1.448     "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   1.449 @@ -623,6 +673,14 @@
   1.450     HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   1.451     MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.452  
   1.453 +Copyright Statement
   1.454 +
   1.455 +   Copyright (C) The IETF Trust (2009).
   1.456 +
   1.457 +   This document is subject to the rights, licenses and restrictions
   1.458 +   contained in BCP 78, and except as set forth therein, the authors
   1.459 +   retain all their rights.
   1.460 +
   1.461  Acknowledgement
   1.462  
   1.463     Funding for the RFC Editor function is currently provided by the