idnits 2.17.1 draft-andersen-isss-ws-dir-ldifext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [19], [7], [8], [9], [10], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: attribute-description = value = 1*safe-initval *safe safe = safe-initval = base64-value = changerecord = change-add / change-delete / change-modify / change-moddn change-add = ["changetype:" *SPACE "add" SEP] attrval-spec *(SEP attrval-spec) change-delete = "changetype:" *SPACE "delete" change-moddn = "changetype:" *SPACE ("modrdn" / "moddn") SEP ("newrdn:" *SPACE rdn / "newrdn::" *SPACE base-64-rdn) SEP "deleteoldrdn:" *SPACE ("0" / "1") 0,1*(SEP (("newsuperior:" *SPACE dn) / ("newsuperior:: *SPACE base-64-dn))) change-modify = "changetype:" *SPACE "modify" 1*(SEP mod-spec) mod-spec = mod-add-spec / mod-delete-spec / mod-replace-spec mod-add-spec = "add:" *(*SPACE attribute-description) 1*(SEP attrval-spec) SEP "-" mod-delete-spec = "delete:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" mod-replace-spec = "replace:" *(*SPACE attribute-description) *(SEP attrval-spec) SEP "-" SPACE = SEP = (CR LF / LF) CR = LF = DIGIT = -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '3' is defined on line 798, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 807, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 813, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-asid-mime-direct-06 ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1779 (ref. '3') (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 2251 (ref. '4') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 1521 (ref. '5') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' == Outdated reference: A later version (-05) exists of draft-good-ldap-ldif-00 Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Extended LDAP Data Interchange Format (LDIFext) CEN/ISSS/WS-DIR 3 INTERNET-DRAFT Editor: Erik Andersen 4 Fischer & Lorenz A/S 5 8 June, 1998 7 The Extended LDAP Data Interchange Format (LDIFext) 8 Technical Specification 9 Filename: draft-andersen-isss-ws-dir-ldifext-00.txt 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 ``work in progress.'' 24 To view the entire list of current Internet-Drafts, please check 25 the "1id-abstracts.txt" listing contained in the Internet-Drafts 26 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 27 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 28 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 29 (US West Coast). 31 This Internet Draft expires 13 December, 1998. 33 Abstract 35 This document describes a file format known as Extended LDAP Data 36 Interchange Format (LDIFext) that builds on the LDAP Data Interchange 37 Format (LDIF). LDIFext is backward compatible with LDIF. Based on the 38 LDIFext specification it is possible to build either a basic LDIF 39 file or an LDIFext file. LDIFext is in particular applicable in 40 situation where several participating systems are masters of pieces 41 of information about the same object and where the participating 42 systems do not necessarily use the same name space. LDIFext also 43 allows for more efficient bulk transfer. 45 Background and Intended Usage 47 The LDIF format was originally developed and used in the University 48 of Michigan LDAP implementation. The first use of LDIF was in 49 describing directory entries. Later, the format was expanded to 50 allow representation of changes to directory entries. LDIFext further 51 extends the LDAP capabilities by providing means for more efficient 52 transfer of large amount of data in a heterogeneous, multi-master 53 environment. 55 There are a number of situations where a common interchange format is 56 desirable. For example, one might wish to export a copy of the 57 contents of a directory server to a file, move that file to a 58 different machine, and import the contents into a second directory 59 server. 61 Additionally, by using a well-defined interchange format, development 62 of data import tools from legacy systems is facilitated. A fairly 63 simple set of tools written in awk or perl can, for example, convert 64 a database of personnel information into an LDIF file, which can then 65 be imported into a directory server, regardless of the internal 66 database representation the target directory server uses. 68 The LDIFext is a multi-master synchronization format. In contrast to 69 basic LDIF, it does not assume that a single system is the master of 70 all the information about a given object, but that different systems 71 maintain their own part of this information. The purpose of LDIFext 72 is to allow such systems to synchronize with each other resulting in 73 entries that potentially have both master and shadowing information. 75 In contrast to basic LDIF, LDIFext does not assume that participating 76 systems share a common name space. It can be used to synchronize 77 systems having different naming structures. 79 The LDIFext specification allows an implementation to operate in 80 either LDIF mode, where files are generated according to the 81 specifications given in [10]; or in LDIFext mode utilizing the added 82 capabilities of LDIFext. 84 While the LDIFext is primarily developed with synchronization of 85 LDAP/X.500 servers in mind, it can also be used for synchronization 86 among directories and/or databases of different technologies. 88 Although the LDIFext specification relates to LDAP/X.500 concepts, 89 the way such concepts have been applied should make it easy to map 90 them to other types of directories, e.g. to private mail directories, 91 and to databases. 93 Relationship to the application/directory MIME content-type: 95 The application/directory MIME content-type [1] is a general 96 framework and format for conveying directory information, and is 97 independent of any particular directory service. It is preferred, in 98 most cases, to LDIF/LDIFext, for conveying directory information. 99 The LDIF/LDIFext format is a simpler format which is perhaps easier 100 to create, and also may be used, as noted, to describe a set of 101 changes to be applied to a directory. 103 The key words "MUST", "MAY", and "SHOULD" used in this document are 104 to be interpreted as described in [7]. 106 Definition of the Extended LDAP Data Interchange Format 108 The LDIF/LDIFext format is used to convey directory information, or a 109 description of a set of changes made to directory entries. An 110 LDIF/LDIFext file consists of a series of records separated by at 111 least two line separators. A record consists of a sequence of lines 112 separated by a single line separator. A record describes a directory 113 entry or a set of changes to a single directory entry. An 114 LDIF/LDIFext file specifies a set of directory entries, or a set of 115 changes to be applied to directory entries, but not both. 117 There is a one-to-one correlation between LDAP operations that modify 118 the directory (add, delete, modify, and modrdn), and the types of 119 changerecords described below ("add", "delete", "modify", and 120 "modrdn" or "moddn"). This correspondence is intentional, and 121 permits a straightforward translation from LDIF changerecords to 122 protocol operations. 124 Formal Syntax Definition of LDIF 126 The following definition uses the augmented Backus-Naur Form 127 specified in RFC 822 [2]. 129 ldif-file = ldif-content / ldif-changes 130 ldif-content = ["total" 1*SEP] heading ldif-attrval-record 131 *(1*SEP ldif-attrval-record) 132 ldif-changes = ["incremental" 1*SEP] heading 133 ldif-change-record 134 *(1*SEP ldif-change-record) 135 heading = 0,1*(version-spec 1*SEP) 136 ["agreement-id:" *SPACE agreement-id 1*SEP] 137 [charset: *SPACE charset-name 1*SEP] 138 agreement-id = 1*safe-initval 139 charset-name = a character set name, as registered 140 with IANA [9] 141 ldif-attrval-record = dn-spec SEP 1*(attrval-spec SEP) 142 ["key" SEP 1*(attrval-spec SEP)] 143 ldif-change-record = dn-spec SEP 1*(changerecord SEP) 144 ["key" SEP 1*(attrval-spec SEP)] 146 version-spec = "version:" *SPACE version-number 147 version-number = 1*DIGIT ; version-number MUST be "1" for the 148 ; LDIFext format described in this 149 ; document if operating in LDIF mode. 151 dn-spec = ("dn:" *SPACE dn) / 152 ("dn::" *SPACE base64-dn) / 153 ("dn:" *SPACE 1*DIGIT rdn 154 *(("," / ";") *SPACE rdn)) / 155 ("dn::" *SPACE 1*DIGIT base64-rdn 156 *(("," / ";") *SPACE base64-rdn )) / 157 ("s:" [*SPACE dn]) / ("s::" *SPACE base64-dn) 158 dn = 160 base64-dn = 162 rdn = 164 base64-rdn = 167 attrval-spec = attribute-description ((":") / 168 (":" *SPACE value *(*SPACE "\" *SPACE value)) / 169 ("::" *SPACE base64-value 170 *(*SPACE "\" *SPACE base64-value)) / 171 (":<" *SPACE url*(*SPACE "\" *SPACE url))) 172 url = ; (See Note 6, below) 175 attribute-description = 178 value = 1*safe-initval *safe 179 safe = 180 safe-initval = 183 base64-value = 185 changerecord = change-add / change-delete / change-modify / 186 change-moddn 187 change-add = ["changetype:" *SPACE "add" SEP] attrval-spec 188 *(SEP attrval-spec) 189 change-delete = "changetype:" *SPACE "delete" 190 change-moddn = "changetype:" *SPACE ("modrdn" / "moddn") SEP 191 ("newrdn:" *SPACE rdn / 192 "newrdn::" *SPACE base-64-rdn) SEP 193 "deleteoldrdn:" *SPACE ("0" / "1") 194 0,1*(SEP (("newsuperior:" *SPACE dn) / 195 ("newsuperior:: *SPACE base-64-dn))) 196 change-modify = "changetype:" *SPACE "modify" 1*(SEP mod-spec) 197 mod-spec = mod-add-spec / mod-delete-spec / 198 mod-replace-spec 199 mod-add-spec = "add:" *(*SPACE attribute-description) 200 1*(SEP attrval-spec) SEP "-" 201 mod-delete-spec = "delete:" *(*SPACE attribute-description) 202 *(SEP attrval-spec) SEP "-" 203 mod-replace-spec = "replace:" *(*SPACE attribute-description) 204 *(SEP attrval-spec) SEP "-" 205 SPACE = 206 SEP = (CR LF / LF) 207 CR = 208 LF = 209 DIGIT = 211 Notes on LDIFext Syntax 213 1) All fields in the in the above Backus-Naur notation that are 214 mandatory are mandatory in both LDIF and LDIFext mode. Some of the 215 optional fields in the notation are mandatory in LDIF mode, while 216 other such fields are mandatory in LDIFext mode 218 2) LDIFext mode is signalled by including the agreement-id 219 specification. If agreement-id is not included, LDIF mode MUST be 220 used. If the agreement-id is included, LDIFext mode MUST be used. 222 3) ldif-content records and ldif-changes records cannot be included 223 in the same LDIF/LDIFext file. In LDIFext mode, a file MUST have the 224 "total" or the "incremental" specification, as appropriate, in the 225 heading section. In LDIF mode, such a specification MUST NOT be 226 included. 228 4) In LDIF mode an ldif-content record is assumed to represent a 229 complete entry at the sender side to be copied as a complete entry 230 into the recipient system. In LDIFext mode this assumption is 231 relaxed. An ldif-content record may only represent part of an entry 232 at the sender's side. It may only contain the information relevant 233 for the recipient system. Also at the recipient system, there may 234 already be a corresponding entry representing the same object. The 235 ldif-content record may then be merged with such an existing record. 237 5) In situations where a recipient system merges ldif-content 238 records, possibly from several systems, with own information, it MUST 239 tag each piece of information with agreement id. In an X.500 240 environment, tagging can be done using the contexts feature. 242 6) The version number is optional. If absent, version 0 is assumed. 243 This corresponds to either using LDIF mode according to the version 244 of LDIF supported by the University of Michigan ldap-3.3 reference 245 implementation [8]; or to using LDIFext mode according to the 246 specification in this document. For use of LDIF mode as specified in 247 this document, the version number MUST be "1". 249 7) Any line in an LDIF/LDIFext file MAY be wrapped by inserting a 250 line separator (SEP) and a SPACE. Any line that begins with a 251 single space MUST be treated as a continuation of the previous line. 252 The LDIFext specification does not put any restriction on the line 253 length. 255 8) Any line which begins with a pound-sign ("#", ASCII 35) is a 256 comment line, and MUST be ignored when parsing an LDIF/LDIFext file. 258 9) In LDIF mode the UTF-8 character set MUST be used and the 259 charset-name in the heading specification MUST NOT be included. In 260 LDIFext mode the UTF-8 character set SHOULD be used. However, in 261 closed communities as part an agreement, other named character sets 262 can be specified to be used for all attribute values in attributes 263 and RDNs. As an example, ISO_8859-1:1987 could be specified to be 264 used within many European countries. This will allow special national 265 characters to be encoded in a single octet, which could be of 266 significance when millions of records are to be transferred. 268 10) Any dn or value which contains characters other than those 269 defined as "safe," or begins with a character other than those 270 defined as "safe-initval", above, MUST be base-64 encoded. Other 271 values MAY be base-64 encoded. 273 11) It is possible in the dn-spec field to use either the "dn:" or 274 the "s:" specification. The "s:" specification MUST NOT be used in 275 LDIF mode. In LDIF mode, the "dn:" specification MUST include a 276 complete distinguished name. In LDIFext mode it is possible to use a 277 truncated form where some implied RDNs are not included. 279 12) The "dn:" specification SHOULD only be used in LDIFext mode if 280 the complete distinguished name is understood by both parties to 281 denote the same object. As an example, the name of a reasonable 282 seized company is assumed to be unique within a certain geographical 283 area. This specification MUST be used in a directory environment if 284 the record refers to an entry that has subordinate entries. 286 13) An abbreviated form of distinguished name MAY be used in LDIFext 287 in addition to the truncated form. This abbreviated form MUST NOT be 288 used unless the preceding record has a "dn:" specification. The first 289 item in the abbreviated specification is a level indication telling 290 how large a part of the distinguished name of the preceding record 291 that is inherited. This item MUST include the defaulted part of the 292 distinguished name. As an example, if the country name is implied, 293 the country name component is still counted. The remaining items are 294 one or more RDNs that when prefixed the inherited part comprise a 295 complete distinguished name. 297 14) The "s:" specification can be used if it is not possible to 298 establish distinguished names that are globally recognized. It MUST 299 NOT be used in LDIF mode. In a directory environment it SHOULD 300 include the distinguished name of the superior entry. This field can 301 then only be used for leaf entries, e.g. residential persons. When 302 this field is present, it is assumed that the recipient from other 303 included information, e.g. name, telephone number, postal address, 304 etc., can determine the entity of a possible corresponding local 305 entry. If an existing entry is not found, the receiver can generate 306 an RDN based on local algorithms to produce a complete distinguished 307 name for its own use. 309 15) In a non-directory environment, the "s:" specification MAY be 310 empty. It is outside the scope of this specification how a directory 311 system handles an LDIFext file from a non-directory system having an 312 empty "s:" specification. In a mixed environment with both directory 313 systems and non-directory systems a non-system SHOULD generate a 314 valid "s:" specification. 316 16) If there is no "s:" or "dn:" specification, an "s:" specification 317 field is implied having the same value as in the previous record. The 318 absence of both the "dn:" and the "s:" specification is only allowed 319 if the previous record had an explicit or implicit "s:" 320 specification. 322 17) In LDIF mode, the attrval-spec MUST NOT hold several attribute 323 values. In LDIFext mode, the attrval-spec MAY hold several attribute 324 values separated by back-slashes ("\"). In LDIFext mode, any 325 back-slash within an attribute value MUST be replace by a double 326 back-slash. 328 18) To represent a zero-length attribute value, use an attrval-spec 329 of "attribute-description:". For example, "seeAlso:" represents a 330 zero-length "seeAlso" attribute value. 332 19) When a URL is specified in an attrval-spec, the following 333 conventions apply: 334 a) Implementations SHOULD support the file:// URL format. The 335 contents of the referenced file are to be included verbatim 336 in the interpreted output of the LDIF file. 337 b) Implementations MAY support other URL formats. The semantics 338 associated with each supported URL will be documented in 339 an associated Applicability Statement. 341 20) While it is permissible for character values larger than 126 to 342 be contained in an attribute value, implementations SHOULD base-64 343 encode any value which contains such characters when generating an 344 LDIF/LDIFext file. However, implementations MAY leave the values 345 unencoded. This relaxation is designed to allow editing of 346 LDIF/LDIFext files containing, for example, Latin-1 content, with 347 existing tools. 349 21) In LDIFext mode, some of the information in a record is owned by 350 the sender, i.e. the sender is master for that information. This 351 information is located just after the "dn:" or the "s:" 352 specification, and it may be the only information in a record. 353 Additional information (see below) may be supplied in a record to 354 allow the recipient to uniquely identify a corresponding local entry, 355 if any. 357 22) The optional "key" specification starts a block of information, 358 which is not to be considered master information owned by the sender. 359 Such information is intended for identifying a possible already 360 existing entry at the recipient. As an example, a mobile operator may 361 supply the fixed telephone number in a record, although the fixed 362 telephone is subscribed from another operator. If there is 363 information in these blocks that is currently not present at the 364 recipient, it a local option for the recipient whether to store it or 365 dispose of it in any other way. The "key" specification MUST NOT be 366 used in LDIF mode. 368 23) In the change-add field the "changetype:" specification is 369 optional. However, it MUST be present in LDIF mode. 371 24) When doing total update in LDIFext mode: 373 a) All information related to the agreement SHOULD be purged and 374 replaced by the information in the current transfer. This does not 375 necessarily mean that current entries are completely deleted 376 during the first part of this process, as there may be local 377 information or information from other agreements within those 378 entries. 380 b) Information following the "key" specification is only intended 381 for entry identification. Such information SHOULD be included if 382 the "s:" specification is used. 384 c) If the object class attribute is not included for a record, the 385 value(s) is the same as for the previous record. 387 25) When doing incremental update in LDIFext mode: 389 a) Only information owned by the sender can be changed. Additional 390 information may be transmitted to allow identification of the 391 entries to be changed. If the "dn:" specification is used, only 392 the distinguished name SHOULD be supplied in addition to change or 393 delete specifications to ensure compatibility with earlier 394 versions. For records starting with an implicit or explicit "s:" 395 specification, additional information MUST be supplied for entry 396 identification. 398 b) Records without any "changetype" specification are to be 399 considered as new entries to be added. For records starting with 400 an implicit or explicit "s:" specification, a "key" part MUST be 401 supplied for entry identification. 403 c) A record with "changetype" equal to "delete" only applies to 404 the part of the entry holding information owned by the sender 405 according to the current agreement. Records starting with an 406 implicit or explicit "s:" specification MUST besides the delete 407 specification have a "key" part for entry identification. 409 d) A record with "changetype" equal to "modify" and which starts 410 with an implicit or explicit "s:" specification MUST besides the 411 change specifications have a "key" part for entry identification. 413 26) In some cases it may not be possible to denote some pieces of 414 information belonging to anyone. As an example, object class 415 specification, postal address, etc. may be considered general 416 information maintained independently by each system. If such 417 information is not consistent across systems, correlation may not be 418 possible. Such general information should be in the "key" block. It 419 is recommended to establish an authoritative source for such 420 information. 422 Agreements 424 An agreement ID MUST be in the first part of an LDIFext file. This 425 agreement specification is used to give a unique identification of 426 the scope of an information exchange. The concept of agreement is not 427 relevant in LDIF mode although some implicit understanding is 428 probably required. An agreement can include such things as: 430 1) What information has to be transferred and possibly kept updated 431 by the sender. 433 2) The attribute types and object classes that are part of the 434 transport including what textual representations that are going to be 435 used. In case of high-volume exchanges, the two parties can agree on 436 an abbreviated form of textual representation. As an example "tel" 437 could be an abbreviated form of TelephoneNumber. Textual 438 representations of attribute types MUST be unique within an 439 agreement. Likewise for textual representation of object classes. 441 3) An understanding of what information is necessary to transfer in 442 the "key" block to ensure the correlation process, i.e. locating an 443 existing entry, if any, at the recipient. 445 4) How much of a distinguished name that needs to be transferred. As 446 an example, the country name could be implied. 448 5) Maximum line length. If a file is to be displayed on a screen, it 449 may be useful to limit the line length accordingly. For high volume 450 bulk transfer, it saves overhead to have unlimited line length. 452 6) How much information that is needed for the objectClass attribute. 453 If the object class for the entry information is, say, 454 residentialPerson, it may not be necessary also to specify the super- 455 classes person and top. They could be implied. Also auxiliary object 456 classes can be implied. It MUST be completely understood by both 457 parties what set of object classes is behind a single object class 458 textual specification. 460 7) Agreement on not to use spaces where they are optional. 462 8) Agreement not to use any unnecessary SEPs, i.e. consider the 1*SEP 463 specification equals to just SEP. 465 9) Agreement on only using LF for SEP. 467 10) Update frequency. 469 Establishment of an agreement is an off-line activity not directly 470 reflected in the protocol. 472 Differences from Version 1 of LDIF 474 1) It is possible in a header besides giving version information to 475 indicate whether an LDIF file is a complete transfer of all 476 information or whether is an updating file 478 2) It is possible in the header to indicate an agreement ID 480 3) It is possible for each record to include information that is not 481 intended for storage by the receiver, but is aiding the recipient in 482 identifying a particular entry. 484 4) It is possible to only transfer the distinguished name of the 485 superior of an entry in case the receiver is expected to generate the 486 complete distinguished following local algorithms. 488 5) Several values for a multi-valued attribute can be on the same, 489 possibly folded line. The separator between values is a back-slash 490 ("\") 492 Example 1: An simple LDIF file with two entries 494 dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 495 objectclass: top 496 objectclass: person 497 objectclass: organizationalPerson 498 cn: Barbara Jensen 499 cn: Barbara J Jensen 500 cn: Babs Jensen 501 sn: Jensen 502 uid: bjensen 503 telephonenumber: +1 408 555 1212 504 description: A big sailing fan. 506 dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US 507 objectclass: top 508 objectclass: person 509 objectclass: organizationalPerson 510 cn: Bjorn Jensen 511 sn: Jensen 512 telephonenumber: +1 408 555 1212 514 Example 2: An LDIF file containing an entry with a folded attribute 515 value 517 dn:cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US 518 objectclass:top 519 objectclass:person 520 objectclass:organizationalPerson 521 cn:Barbara Jensen 522 cn:Barbara J Jensen 523 cn:Babs Jensen 524 sn:Jensen 525 uid:bjensen 526 telephonenumber:+1 408 555 1212 527 description:Babs is a big sailing fan, and travels extensively in 528 search of perfect sailing conditions. 529 title:Product Manager, Rod and Reel Division 531 Example 3: An LDIF file containing a base-64-encoded value 533 dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US 534 objectclass: top 535 objectclass: person 536 objectclass: organizationalPerson 537 cn: Gern Jensen 538 cn: Gern O Jensen 539 sn: Jensen 540 uid: gernj 541 telephonenumber: +1 408 555 1212 542 description:: 543 V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ 545 hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0ICh 546 hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu 548 Example 4: A file containing an entries with UTF-8-encoded attribute 549 values, including language tags. Comments indicate the contents 550 of UTF-8-encoded attributes and distinguished names. 552 dn:: b3U95Za25qWt6YOoLG89QWlyaXVz 553 # dn:: ou=,o=Airius 554 objectclass: top 555 objectclass: organizationalUnit 556 ou:: 5Za25qWt6YOo 557 # ou:: 558 ou;lang-ja:: 5Za25qWt6YOo 559 # ou;lang-ja:: 560 ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 561 # ou;lang-ja:: 562 ou;lang-en: Sales 563 description: Japanese office 564 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz 565 # dn:: uid=,ou=,o=Airius 566 userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= 567 objectclass: top 568 objectclass: person 569 objectclass: organizationalPerson 570 objectclass: inetOrgPerson 571 uid: rogasawara 572 mail: rogasawara@airius.co.jp 573 givenname;lang-ja:: 44Ot44OJ44OL44O8 574 # givenname;lang-ja:: 575 sn;lang-ja:: 5bCP56yg5Y6f 576 # sn;lang-ja:: 577 cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 578 # cn;lang-ja:: 579 title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw== 580 # title;lang-ja:: 581 preferredlanguage: ja 582 givenname:: 44Ot44OJ44OL44O8 583 # givenname:: 584 sn:: 5bCP56yg5Y6f 585 # sn:: 586 cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA== 587 # cn:: 588 title:: 5Za25qWt6YOoIOmDqOmVtw== 589 # title:: 590 givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 591 # givenname;lang-ja;phonetic:: 592 593 sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ 594 # sn;lang-ja;phonetic:: 595 cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA== 596 # cn;lang-ja;phonetic:: 597 title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg== 598 # title;lang-ja;phonetic:: 599 givenname;lang-en: Rodney 600 sn;lang-en: Ogasawara 601 cn;lang-en: Rodney Ogasawara 602 title;lang-en: Sales, Director 604 Example 5: An LDIF file containing a reference to an external file 606 dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US 607 objectclass: top 608 objectclass: person 609 objectclass: organizationalPerson 610 cn: Horatio Jensen 611 cn: Horatio N Jensen 612 sn: Jensen 613 uid: hjensen 614 telephonenumber: +1 408 555 1212 615 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg 617 Example 6: An LDIF file containing a series of change records and 618 comments 620 # Add a new entry 621 dn: cn=Fiona Jensen, ou=Marketing, o=Ace Industry, c=US 622 changetype: add 623 objectclass: top 624 objectclass: person 625 objectclass: organizationalPerson 626 cn: Fiona Jensen 627 sn: Jensen 628 uid: fiona 629 telephonenumber: +1 408 555 1212 630 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg 632 # Delete an existing entry 633 dn: cn=Robert Jensen, ou=Marketing, o=Ace Industry, c=US 634 changetype: delete 636 # Modify an entry's relative distinguished name 637 dn: cn=Paul Jensen, ou=Product Development, o=Ace Industry, c=US 638 changetype: modrdn 639 newrdn: cn=Paula Jensen 640 deleteoldrdn: 1 642 # Rename an entry and move all of its children to a new location in 643 # the directory tree (only implemented by LDAPv3 servers). 644 dn: ou=PD Accountants, ou=Product Development, o=Ace Industry, c=US 645 changetype: modrdn 646 newrdn: ou=Product Development Accountants 647 deleteoldrdn: 0 648 newsuperior: ou=Accounting, o=Ace Industry, c=US 650 # Modify an entry: add an additional value to the postaladdress attribute, 651 # completely delete the description attribute, replace the telephonenumber 652 # attribute with two values, and delete a specific value from the 653 # facsimiletelephonenumber attribute 654 dn: cn=Paula Jensen, ou=Product Development, o=Ace Industry, c=US 655 changetype: modify 656 add: postaladdress 657 postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 658 - 659 delete: description 660 - 661 replace: telephonenumber 662 telephonenumber: +1 408 555 1234 663 telephonenumber: +1 408 555 5678 664 - 665 delete: facsimiletelephonenumber 666 facsimiletelephonenumber: +1 408 555 9876 667 - 669 Example 7: A simple LDIFext file with a few records sent from a mobile 670 telephone operator to some central information service 672 total 673 version 0 674 agreement-id: op1-to-op2, ver.1 676 dn:o=F&L,c=DK 677 mobile:+4533333333\+4544444444 678 other 679 tel:+4539450700 680 fax:+4539450777 682 dn:2 cn=Tom Finkelstein 683 mobile:+4512345678 684 key 685 objcl:orgPers 686 sn:Finkdelstein 687 gn:Tom 688 tel:+4539450999 689 822:tfs@fl.dk 691 dn:2 cn=Per Futtesen 692 mobile:+4587654321 693 key 694 sn:Futtesen 695 gn:Per 696 tel:+4539450998 697 822:tfs@fl.dk 699 s:L=Frederiksberg C,ST=Copenhagen 700 mobile:+4520971490 701 key 702 objcl:resPers 703 sn:Andersen 704 gn:Erik 705 street:Paludan Mullersvej 706 num:3 707 floor:2 708 floorentity:tv 709 tel:+4531230490 711 mobile:+4587654321 712 key 713 sn:Petersen 714 gn:Peter 715 street:Paludan Mullersvej 716 num:114 717 floor:3 718 tel:+4523456789 720 Example 8: A simple LDIF file with a few update records sent from a 721 mobile telephone operator to some central information service 723 incremental 724 version 0 725 agreement-id: op1-to-op2, ver.1 727 # Delete an entry. The mobile number and the name is considered 728 # sufficient information for locating the right entry 729 s:L=1815,ST=Copenhagen 730 changetype:delete 731 mobile:+4520971490 732 key 733 sn:Andersen 734 gn:Erik 736 # Update existing entry 737 replace: 738 mobile:+4587654321 739 mobile:+4598765432 740 - 741 key 742 sn:Petersen 743 gn:Peter 745 # Add new entry 746 s:L=Hellerup,ST=Copenhagen 747 mobile:+4534567890 748 key 749 objcl:resPers 750 sn:Frederiksen 751 gn:John 752 street:Grundtvigsvej 753 num:245 754 floor:5 755 floorentity:tv 756 tel:+4531230490 758 Security Considerations 760 Given typical directory applications, an LDIF/LDIFext file is likely 761 to contain sensitive personal data. Appropriate measures should be 762 taken to protect the privacy of those persons whose data is contained 763 in an LDIF/LDIFext file. 765 Since ":<" directives can cause external content to be included when 766 processing an LDIF/LDIFext file, one should be cautious of accepting 767 LDIF/LDIFext files from external sources. A "trojan" LDIF/LDIFext 768 file could name a file with sensitive contents and cause it to be 769 included in a directory entry, which a hostile entity could read via 770 LDAP. 772 LDIF/LDIFext does not provide any method for carrying authentication 773 information with an LDIF/LDIFext file. Users of LDIF/LDIFext files 774 must take care to verify the integrity of an LDIF file received from 775 an external source. 777 Acknowledgements 779 The extensions to LDAP Data Interchange Format presented in this 780 document has been considered too extensive to reflect a new version 781 of LDIF. As suggested by the LDIF editor, Gordon Good, Netscape 782 Communications Corp., the extensions are issued as a separate 783 Internet Draft to be progressed in parallel with the basic LDIF 784 specifications. This document has benefited greatly from the work 785 done on LDIF and has re-used considerable amount of the text. 787 References 789 [1] Howes, T., Smith, M., "A MIME Content-Type for Directory Infor- 790 mation", INTERNET-DRAFT draft-ietf-asid-mime-direct-06.txt, 791 Netscape Communications Corp., 794 [2] Crocker, D.H., "Standard for the Format of ARPA Internet Text 795 Messages", RFC 822, University of Delaware, August 1982, 796 798 [3] Kille, S., "A String Representation of Distinguished Names", RFC 799 1779, ISODE Consortium, March 1995, 800 802 [4] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access 803 Protocol (v3)", RFC 2251, Critical Angle, Inc., ISODE Consor- 804 tium, Netscape Communications Corp., July, 1997, 805 807 [5] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail 808 Extensions) Part One: Mechanisms for Specifying and Describing 809 the Format of Internet Message Bodies", section 5.2, "Base64 810 Content-Transfer-Encoding", RFC 1521, Bellcore, Innosoft, 811 December 1993, 813 [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource 814 Locators (URL)", CERN, Xerox Corporation, University of Min- 815 nesota, Request for Comment (RFC) 1738, December 1994, 816 818 [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement 819 Levels", Harvard University, RFC 2119, March 1997, 820 822 [8] The SLAPD and SLURPD Administrators Guide. University of Michi- 823 gan, April 1996. 826 [9] Internet Assigned Numbers Authority, "CHARACTER SETS", 827 829 [10] Good, G, " The LDAP Data Interchange Format (LDIF) - Technical 830 Specification", INTERNET-DRAFT draft-good-ldap-ldif-00.txt, 831 Netscape Communications Corp., 834 Author's Address 836 Erik Andersen 837 Fischer & Lorenz A/S 838 Tuborgvej 10 839 DK-2900 Hellerup 840 Denmark 841 Phone: +45 20 97 14 90 842 EMail: era@fl.dk 844 This Internet Draft expires 13 December, 1998.