Extended LDAP Data Interchange Format (LDIFext) CEN/ISSS/WS-DIR INTERNET-DRAFT Editor: Erik Andersen Fischer & Lorenz A/S 8 June, 1998 The Extended LDAP Data Interchange Format (LDIFext) Technical Specification Filename: draft-andersen-isss-ws-dir-ldifext-00.txt Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This Internet Draft expires 13 December, 1998. Abstract This document describes a file format known as Extended LDAP Data Interchange Format (LDIFext) that builds on the LDAP Data Interchange Format (LDIF). LDIFext is backward compatible with LDIF. Based on the LDIFext specification it is possible to build either a basic LDIF file or an LDIFext file. LDIFext is in particular applicable in situation where several participating systems are masters of pieces of information about the same object and where the participating systems do not necessarily use the same name space. LDIFext also allows for more efficient bulk transfer. ISSS/WS-DIR June 8, 1998 [Page 1] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 Background and Intended Usage The LDIF format was originally developed and used in the University of Michigan LDAP implementation. The first use of LDIF was in describing directory entries. Later, the format was expanded to allow representation of changes to directory entries. LDIFext further extends the LDAP capabilities by providing means for more efficient transfer of large amount of data in a heterogeneous, multi-master environment. There are a number of situations where a common interchange format is desirable. For example, one might wish to export a copy of the contents of a directory server to a file, move that file to a different machine, and import the contents into a second directory server. Additionally, by using a well-defined interchange format, development of data import tools from legacy systems is facilitated. A fairly simple set of tools written in awk or perl can, for example, convert a database of personnel information into an LDIF file, which can then be imported into a directory server, regardless of the internal database representation the target directory server uses. The LDIFext is a multi-master synchronization format. In contrast to basic LDIF, it does not assume that a single system is the master of all the information about a given object, but that different systems maintain their own part of this information. The purpose of LDIFext is to allow such systems to synchronize with each other resulting in entries that potentially have both master and shadowing information. In contrast to basic LDIF, LDIFext does not assume that participating systems share a common name space. It can be used to synchronize systems having different naming structures. The LDIFext specification allows an implementation to operate in either LDIF mode, where files are generated according to the specifications given in [10]; or in LDIFext mode utilizing the added capabilities of LDIFext. While the LDIFext is primarily developed with synchronization of LDAP/X.500 servers in mind, it can also be used for synchronization among directories and/or databases of different technologies. Although the LDIFext specification relates to LDAP/X.500 concepts, the way such concepts have been applied should make it easy to map them to other types of directories, e.g. to private mail directories, and to databases. ISSS/WS-DIR June 8, 1998 [Page 2] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 Relationship to the application/directory MIME content-type: The application/directory MIME content-type [1] is a general framework and format for conveying directory information, and is independent of any particular directory service. It is preferred, in most cases, to LDIF/LDIFext, for conveying directory information. The LDIF/LDIFext format is a simpler format which is perhaps easier to create, and also may be used, as noted, to describe a set of changes to be applied to a directory. The key words "MUST", "MAY", and "SHOULD" used in this document are to be interpreted as described in [7]. Definition of the Extended LDAP Data Interchange Format The LDIF/LDIFext format is used to convey directory information, or a description of a set of changes made to directory entries. An LDIF/LDIFext file consists of a series of records separated by at least two line separators. A record consists of a sequence of lines separated by a single line separator. A record describes a directory entry or a set of changes to a single directory entry. An LDIF/LDIFext file specifies a set of directory entries, or a set of changes to be applied to directory entries, but not both. There is a one-to-one correlation between LDAP operations that modify the directory (add, delete, modify, and modrdn), and the types of changerecords described below ("add", "delete", "modify", and "modrdn" or "moddn"). This correspondence is intentional, and permits a straightforward translation from LDIF changerecords to protocol operations. ISSS/WS-DIR June 8, 1998 [Page 3] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 Formal Syntax Definition of LDIF The following definition uses the augmented Backus-Naur Form specified in RFC 822 [2]. ldif-file = ldif-content / ldif-changes ldif-content = ["total" 1*SEP] heading ldif-attrval-record *(1*SEP ldif-attrval-record) ldif-changes = ["incremental" 1*SEP] heading ldif-change-record *(1*SEP ldif-change-record) heading = 0,1*(version-spec 1*SEP) ["agreement-id:" *SPACE agreement-id 1*SEP] [charset: *SPACE charset-name 1*SEP] agreement-id = 1*safe-initval charset-name = a character set name, as registered with IANA [9] ldif-attrval-record = dn-spec SEP 1*(attrval-spec SEP) ["key" SEP 1*(attrval-spec SEP)] ldif-change-record = dn-spec SEP 1*(changerecord SEP) ["key" SEP 1*(attrval-spec SEP)] version-spec = "version:" *SPACE version-number version-number = 1*DIGIT ; version-number MUST be "1" for the ; LDIFext format described in this ; document if operating in LDIF mode. dn-spec = ("dn:" *SPACE dn) / ("dn::" *SPACE base64-dn) / ("dn:" *SPACE 1*DIGIT rdn *(("," / ";") *SPACE rdn)) / ("dn::" *SPACE 1*DIGIT base64-rdn *(("," / ";") *SPACE base64-rdn )) / ("s:" [*SPACE dn]) / ("s::" *SPACE base64-dn) dn = base64-dn = rdn = base64-rdn = attrval-spec = attribute-description ((":") / (":" *SPACE value *(*SPACE "\" *SPACE value)) / ("::" *SPACE base64-value *(*SPACE "\" *SPACE base64-value)) / (":<" *SPACE url*(*SPACE "\" *SPACE url))) url = ; (See Note 6, below) ISSS/WS-DIR June 8, 1998 [Page 4] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 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 = Notes on LDIFext Syntax 1) All fields in the in the above Backus-Naur notation that are mandatory are mandatory in both LDIF and LDIFext mode. Some of the optional fields in the notation are mandatory in LDIF mode, while other such fields are mandatory in LDIFext mode 2) LDIFext mode is signalled by including the agreement-id specification. If agreement-id is not included, LDIF mode MUST be used. If the agreement-id is included, LDIFext mode MUST be used. 3) ldif-content records and ldif-changes records cannot be included ISSS/WS-DIR June 8, 1998 [Page 5] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 in the same LDIF/LDIFext file. In LDIFext mode, a file MUST have the "total" or the "incremental" specification, as appropriate, in the heading section. In LDIF mode, such a specification MUST NOT be included. 4) In LDIF mode an ldif-content record is assumed to represent a complete entry at the sender side to be copied as a complete entry into the recipient system. In LDIFext mode this assumption is relaxed. An ldif-content record may only represent part of an entry at the sender's side. It may only contain the information relevant for the recipient system. Also at the recipient system, there may already be a corresponding entry representing the same object. The ldif-content record may then be merged with such an existing record. 5) In situations where a recipient system merges ldif-content records, possibly from several systems, with own information, it MUST tag each piece of information with agreement id. In an X.500 environment, tagging can be done using the contexts feature. 6) The version number is optional. If absent, version 0 is assumed. This corresponds to either using LDIF mode according to the version of LDIF supported by the University of Michigan ldap-3.3 reference implementation [8]; or to using LDIFext mode according to the specification in this document. For use of LDIF mode as specified in this document, the version number MUST be "1". 7) Any line in an LDIF/LDIFext file MAY be wrapped by inserting a line separator (SEP) and a SPACE. Any line that begins with a single space MUST be treated as a continuation of the previous line. The LDIFext specification does not put any restriction on the line length. 8) Any line which begins with a pound-sign ("#", ASCII 35) is a comment line, and MUST be ignored when parsing an LDIF/LDIFext file. 9) In LDIF mode the UTF-8 character set MUST be used and the charset-name in the heading specification MUST NOT be included. In LDIFext mode the UTF-8 character set SHOULD be used. However, in closed communities as part an agreement, other named character sets can be specified to be used for all attribute values in attributes and RDNs. As an example, ISO_8859-1:1987 could be specified to be used within many European countries. This will allow special national characters to be encoded in a single octet, which could be of significance when millions of records are to be transferred. 10) Any dn or value which contains characters other than those defined as "safe," or begins with a character other than those defined as "safe-initval", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. ISSS/WS-DIR June 8, 1998 [Page 6] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 11) It is possible in the dn-spec field to use either the "dn:" or the "s:" specification. The "s:" specification MUST NOT be used in LDIF mode. In LDIF mode, the "dn:" specification MUST include a complete distinguished name. In LDIFext mode it is possible to use a truncated form where some implied RDNs are not included. 12) The "dn:" specification SHOULD only be used in LDIFext mode if the complete distinguished name is understood by both parties to denote the same object. As an example, the name of a reasonable seized company is assumed to be unique within a certain geographical area. This specification MUST be used in a directory environment if the record refers to an entry that has subordinate entries. 13) An abbreviated form of distinguished name MAY be used in LDIFext in addition to the truncated form. This abbreviated form MUST NOT be used unless the preceding record has a "dn:" specification. The first item in the abbreviated specification is a level indication telling how large a part of the distinguished name of the preceding record that is inherited. This item MUST include the defaulted part of the distinguished name. As an example, if the country name is implied, the country name component is still counted. The remaining items are one or more RDNs that when prefixed the inherited part comprise a complete distinguished name. 14) The "s:" specification can be used if it is not possible to establish distinguished names that are globally recognized. It MUST NOT be used in LDIF mode. In a directory environment it SHOULD include the distinguished name of the superior entry. This field can then only be used for leaf entries, e.g. residential persons. When this field is present, it is assumed that the recipient from other included information, e.g. name, telephone number, postal address, etc., can determine the entity of a possible corresponding local entry. If an existing entry is not found, the receiver can generate an RDN based on local algorithms to produce a complete distinguished name for its own use. 15) In a non-directory environment, the "s:" specification MAY be empty. It is outside the scope of this specification how a directory system handles an LDIFext file from a non-directory system having an empty "s:" specification. In a mixed environment with both directory systems and non-directory systems a non-system SHOULD generate a valid "s:" specification. 16) If there is no "s:" or "dn:" specification, an "s:" specification field is implied having the same value as in the previous record. The absence of both the "dn:" and the "s:" specification is only allowed if the previous record had an explicit or implicit "s:" specification. ISSS/WS-DIR June 8, 1998 [Page 7] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 17) In LDIF mode, the attrval-spec MUST NOT hold several attribute values. In LDIFext mode, the attrval-spec MAY hold several attribute values separated by back-slashes ("\"). In LDIFext mode, any back-slash within an attribute value MUST be replace by a double back-slash. 18) To represent a zero-length attribute value, use an attrval-spec of "attribute-description:". For example, "seeAlso:" represents a zero-length "seeAlso" attribute value. 19) When a URL is specified in an attrval-spec, the following conventions apply: a) Implementations SHOULD support the file:// URL format. The contents of the referenced file are to be included verbatim in the interpreted output of the LDIF file. b) Implementations MAY support other URL formats. The semantics associated with each supported URL will be documented in an associated Applicability Statement. 20) While it is permissible for character values larger than 126 to be contained in an attribute value, implementations SHOULD base-64 encode any value which contains such characters when generating an LDIF/LDIFext file. However, implementations MAY leave the values unencoded. This relaxation is designed to allow editing of LDIF/LDIFext files containing, for example, Latin-1 content, with existing tools. 21) In LDIFext mode, some of the information in a record is owned by the sender, i.e. the sender is master for that information. This information is located just after the "dn:" or the "s:" specification, and it may be the only information in a record. Additional information (see below) may be supplied in a record to allow the recipient to uniquely identify a corresponding local entry, if any. 22) The optional "key" specification starts a block of information, which is not to be considered master information owned by the sender. Such information is intended for identifying a possible already existing entry at the recipient. As an example, a mobile operator may supply the fixed telephone number in a record, although the fixed telephone is subscribed from another operator. If there is information in these blocks that is currently not present at the recipient, it a local option for the recipient whether to store it or dispose of it in any other way. The "key" specification MUST NOT be used in LDIF mode. 23) In the change-add field the "changetype:" specification is optional. However, it MUST be present in LDIF mode. ISSS/WS-DIR June 8, 1998 [Page 8] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 24) When doing total update in LDIFext mode: a) All information related to the agreement SHOULD be purged and replaced by the information in the current transfer. This does not necessarily mean that current entries are completely deleted during the first part of this process, as there may be local information or information from other agreements within those entries. b) Information following the "key" specification is only intended for entry identification. Such information SHOULD be included if the "s:" specification is used. c) If the object class attribute is not included for a record, the value(s) is the same as for the previous record. 25) When doing incremental update in LDIFext mode: a) Only information owned by the sender can be changed. Additional information may be transmitted to allow identification of the entries to be changed. If the "dn:" specification is used, only the distinguished name SHOULD be supplied in addition to change or delete specifications to ensure compatibility with earlier versions. For records starting with an implicit or explicit "s:" specification, additional information MUST be supplied for entry identification. b) Records without any "changetype" specification are to be considered as new entries to be added. For records starting with an implicit or explicit "s:" specification, a "key" part MUST be supplied for entry identification. c) A record with "changetype" equal to "delete" only applies to the part of the entry holding information owned by the sender according to the current agreement. Records starting with an implicit or explicit "s:" specification MUST besides the delete specification have a "key" part for entry identification. d) A record with "changetype" equal to "modify" and which starts with an implicit or explicit "s:" specification MUST besides the change specifications have a "key" part for entry identification. 26) In some cases it may not be possible to denote some pieces of information belonging to anyone. As an example, object class specification, postal address, etc. may be considered general information maintained independently by each system. If such information is not consistent across systems, correlation may not be possible. Such general information should be in the "key" block. It is recommended to establish an authoritative source for such information. ISSS/WS-DIR June 8, 1998 [Page 9] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 Agreements An agreement ID MUST be in the first part of an LDIFext file. This agreement specification is used to give a unique identification of the scope of an information exchange. The concept of agreement is not relevant in LDIF mode although some implicit understanding is probably required. An agreement can include such things as: 1) What information has to be transferred and possibly kept updated by the sender. 2) The attribute types and object classes that are part of the transport including what textual representations that are going to be used. In case of high-volume exchanges, the two parties can agree on an abbreviated form of textual representation. As an example "tel" could be an abbreviated form of TelephoneNumber. Textual representations of attribute types MUST be unique within an agreement. Likewise for textual representation of object classes. 3) An understanding of what information is necessary to transfer in the "key" block to ensure the correlation process, i.e. locating an existing entry, if any, at the recipient. 4) How much of a distinguished name that needs to be transferred. As an example, the country name could be implied. 5) Maximum line length. If a file is to be displayed on a screen, it may be useful to limit the line length accordingly. For high volume bulk transfer, it saves overhead to have unlimited line length. 6) How much information that is needed for the objectClass attribute. If the object class for the entry information is, say, residentialPerson, it may not be necessary also to specify the super- classes person and top. They could be implied. Also auxiliary object classes can be implied. It MUST be completely understood by both parties what set of object classes is behind a single object class textual specification. 7) Agreement on not to use spaces where they are optional. 8) Agreement not to use any unnecessary SEPs, i.e. consider the 1*SEP specification equals to just SEP. 9) Agreement on only using LF for SEP. 10) Update frequency. Establishment of an agreement is an off-line activity not directly reflected in the protocol. ISSS/WS-DIR June 8, 1998 [Page 10] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 Differences from Version 1 of LDIF 1) It is possible in a header besides giving version information to indicate whether an LDIF file is a complete transfer of all information or whether is an updating file 2) It is possible in the header to indicate an agreement ID 3) It is possible for each record to include information that is not intended for storage by the receiver, but is aiding the recipient in identifying a particular entry. 4) It is possible to only transfer the distinguished name of the superior of an entry in case the receiver is expected to generate the complete distinguished following local algorithms. 5) Several values for a multi-valued attribute can be on the same, possibly folded line. The separator between values is a back-slash ("\") Example 1: An simple LDIF file with two entries dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US objectclass: top objectclass: person objectclass: organizationalPerson cn: Barbara Jensen cn: Barbara J Jensen cn: Babs Jensen sn: Jensen uid: bjensen telephonenumber: +1 408 555 1212 description: A big sailing fan. dn: cn=Bjorn Jensen, ou=Accounting, o=Ace Industry, c=US objectclass: top objectclass: person objectclass: organizationalPerson cn: Bjorn Jensen sn: Jensen telephonenumber: +1 408 555 1212 Example 2: An LDIF file containing an entry with a folded attribute value dn:cn=Barbara Jensen, ou=Product Development, o=Ace Industry, c=US objectclass:top ISSS/WS-DIR June 8, 1998 [Page 11] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 objectclass:person objectclass:organizationalPerson cn:Barbara Jensen cn:Barbara J Jensen cn:Babs Jensen sn:Jensen uid:bjensen telephonenumber:+1 408 555 1212 description:Babs is a big sailing fan, and travels extensively in search of perfect sailing conditions. title:Product Manager, Rod and Reel Division Example 3: An LDIF file containing a base-64-encoded value dn: cn=Gern Jensen, ou=Product Testing, o=Ace Industry, c=US objectclass: top objectclass: person objectclass: organizationalPerson cn: Gern Jensen cn: Gern O Jensen sn: Jensen uid: gernj telephonenumber: +1 408 555 1212 description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVlIGlzIGJ hc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdGVyIGluIGl0ICh hIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQgb3V0IG1vcmUu Example 4: A file containing an entries with UTF-8-encoded attribute values, including language tags. Comments indicate the contents of UTF-8-encoded attributes and distinguished names. dn:: b3U95Za25qWt6YOoLG89QWlyaXVz # dn:: ou=,o=Airius objectclass: top objectclass: organizationalUnit ou:: 5Za25qWt6YOo # ou:: ou;lang-ja:: 5Za25qWt6YOo # ou;lang-ja:: ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2 # ou;lang-ja:: ou;lang-en: Sales description: Japanese office ISSS/WS-DIR June 8, 1998 [Page 12] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz # dn:: uid=,ou=,o=Airius userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM= objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson uid: rogasawara mail: rogasawara@airius.co.jp givenname;lang-ja:: 44Ot44OJ44OL44O8 # givenname;lang-ja:: sn;lang-ja:: 5bCP56yg5Y6f # sn;lang-ja:: cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA== # cn;lang-ja:: title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw== # title;lang-ja:: preferredlanguage: ja givenname:: 44Ot44OJ44OL44O8 # givenname:: sn:: 5bCP56yg5Y6f # sn:: cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA== # cn:: title:: 5Za25qWt6YOoIOmDqOmVtw== # title:: givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8 # givenname;lang-ja;phonetic:: sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ # sn;lang-ja;phonetic:: cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA== # cn;lang-ja;phonetic:: title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg== # title;lang-ja;phonetic:: givenname;lang-en: Rodney sn;lang-en: Ogasawara cn;lang-en: Rodney Ogasawara title;lang-en: Sales, Director Example 5: An LDIF file containing a reference to an external file dn: cn=Horatio Jensen, ou=Product Testing, o=Ace Industry, c=US objectclass: top objectclass: person objectclass: organizationalPerson ISSS/WS-DIR June 8, 1998 [Page 13] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 cn: Horatio Jensen cn: Horatio N Jensen sn: Jensen uid: hjensen telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg Example 6: An LDIF file containing a series of change records and comments # Add a new entry dn: cn=Fiona Jensen, ou=Marketing, o=Ace Industry, c=US changetype: add objectclass: top objectclass: person objectclass: organizationalPerson cn: Fiona Jensen sn: Jensen uid: fiona telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/fiona.jpg # Delete an existing entry dn: cn=Robert Jensen, ou=Marketing, o=Ace Industry, c=US changetype: delete # Modify an entry's relative distinguished name dn: cn=Paul Jensen, ou=Product Development, o=Ace Industry, c=US changetype: modrdn newrdn: cn=Paula Jensen deleteoldrdn: 1 # Rename an entry and move all of its children to a new location in # the directory tree (only implemented by LDAPv3 servers). dn: ou=PD Accountants, ou=Product Development, o=Ace Industry, c=US changetype: modrdn newrdn: ou=Product Development Accountants deleteoldrdn: 0 newsuperior: ou=Accounting, o=Ace Industry, c=US # Modify an entry: add an additional value to the postaladdress attribute, # completely delete the description attribute, replace the telephonenumber # attribute with two values, and delete a specific value from the # facsimiletelephonenumber attribute dn: cn=Paula Jensen, ou=Product Development, o=Ace Industry, c=US changetype: modify ISSS/WS-DIR June 8, 1998 [Page 14] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 add: postaladdress postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086 - delete: description - replace: telephonenumber telephonenumber: +1 408 555 1234 telephonenumber: +1 408 555 5678 - delete: facsimiletelephonenumber facsimiletelephonenumber: +1 408 555 9876 - Example 7: A simple LDIFext file with a few records sent from a mobile telephone operator to some central information service total version 0 agreement-id: op1-to-op2, ver.1 dn:o=F&L,c=DK mobile:+4533333333\+4544444444 other tel:+4539450700 fax:+4539450777 dn:2 cn=Tom Finkelstein mobile:+4512345678 key objcl:orgPers sn:Finkdelstein gn:Tom tel:+4539450999 822:tfs@fl.dk dn:2 cn=Per Futtesen mobile:+4587654321 key sn:Futtesen gn:Per tel:+4539450998 822:tfs@fl.dk s:L=Frederiksberg C,ST=Copenhagen mobile:+4520971490 key objcl:resPers sn:Andersen ISSS/WS-DIR June 8, 1998 [Page 15] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 gn:Erik street:Paludan Mullersvej num:3 floor:2 floorentity:tv tel:+4531230490 mobile:+4587654321 key sn:Petersen gn:Peter street:Paludan Mullersvej num:114 floor:3 tel:+4523456789 Example 8: A simple LDIF file with a few update records sent from a mobile telephone operator to some central information service incremental version 0 agreement-id: op1-to-op2, ver.1 # Delete an entry. The mobile number and the name is considered # sufficient information for locating the right entry s:L=1815,ST=Copenhagen changetype:delete mobile:+4520971490 key sn:Andersen gn:Erik # Update existing entry replace: mobile:+4587654321 mobile:+4598765432 - key sn:Petersen gn:Peter # Add new entry s:L=Hellerup,ST=Copenhagen mobile:+4534567890 key objcl:resPers sn:Frederiksen ISSS/WS-DIR June 8, 1998 [Page 16] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 gn:John street:Grundtvigsvej num:245 floor:5 floorentity:tv tel:+4531230490 Security Considerations Given typical directory applications, an LDIF/LDIFext file is likely to contain sensitive personal data. Appropriate measures should be taken to protect the privacy of those persons whose data is contained in an LDIF/LDIFext file. Since ":<" directives can cause external content to be included when processing an LDIF/LDIFext file, one should be cautious of accepting LDIF/LDIFext files from external sources. A "trojan" LDIF/LDIFext file could name a file with sensitive contents and cause it to be included in a directory entry, which a hostile entity could read via LDAP. LDIF/LDIFext does not provide any method for carrying authentication information with an LDIF/LDIFext file. Users of LDIF/LDIFext files must take care to verify the integrity of an LDIF file received from an external source. Acknowledgements The extensions to LDAP Data Interchange Format presented in this document has been considered too extensive to reflect a new version of LDIF. As suggested by the LDIF editor, Gordon Good, Netscape Communications Corp., the extensions are issued as a separate Internet Draft to be progressed in parallel with the basic LDIF specifications. This document has benefited greatly from the work done on LDIF and has re-used considerable amount of the text. References [1] Howes, T., Smith, M., "A MIME Content-Type for Directory Infor- mation", INTERNET-DRAFT draft-ietf-asid-mime-direct-06.txt, Netscape Communications Corp., [2] Crocker, D.H., "Standard for the Format of ARPA Internet Text Messages", RFC 822, University of Delaware, August 1982, ISSS/WS-DIR June 8, 1998 [Page 17] INTERNET-DRAFT Extended LDAP Data Interchange Format 9 June 1998 [3] Kille, S., "A String Representation of Distinguished Names", RFC 1779, ISODE Consortium, March 1995, [4] Wahl, M., Howes, T., Kille, S., "Lightweight Directory Access Protocol (v3)", RFC 2251, Critical Angle, Inc., ISODE Consor- tium, Netscape Communications Corp., July, 1997, [5] Borenstein, N., Freed, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", section 5.2, "Base64 Content-Transfer-Encoding", RFC 1521, Bellcore, Innosoft, December 1993, [6] T. Berners-Lee, L. Masinter, M. McCahill, "Uniform Resource Locators (URL)", CERN, Xerox Corporation, University of Min- nesota, Request for Comment (RFC) 1738, December 1994, [7] S. Bradner, "Key Words for use in RFCs to Indicate Requirement Levels", Harvard University, RFC 2119, March 1997, [8] The SLAPD and SLURPD Administrators Guide. University of Michi- gan, April 1996. [9] Internet Assigned Numbers Authority, "CHARACTER SETS", [10] Good, G, " The LDAP Data Interchange Format (LDIF) - Technical Specification", INTERNET-DRAFT draft-good-ldap-ldif-00.txt, Netscape Communications Corp., Author's Address Erik Andersen Fischer & Lorenz A/S Tuborgvej 10 DK-2900 Hellerup Denmark Phone: +45 20 97 14 90 EMail: era@fl.dk This Internet Draft expires 13 December, 1998. ISSS/WS-DIR June 8, 1998 [Page 18]