The LDAP Data Interchange Format (LDIF) - Technical Specification
Extracted elements (30)
The base64 encoding used in LDIF removes RFC 2045's requirement that base64 output lines be no more than 76 characters, instead relying solely on LDIF's own line-folding rules. This avoids conflicts between two independent folding schemes.
The version-spec field was added to allow distinction between the current LDIF format and the older University of Michigan ldap-3.3 format. If absent, implementations MAY interpret the file as the older format for backward compatibility.
There is a deliberate one-to-one correspondence between LDAP operations (add, delete, modify, modrdn) and LDIF changerecord types. This permits straightforward, mechanical translation from LDIF to LDAP protocol operations without semantic interpretation.
If the version number is absent, implementations MAY choose to interpret the file as the older LDIF format supported by the University of Michigan ldap-3.3 implementation, which predates this specification.
When LDIF change records include controls but the target connection is LDAPv2 (which does not support controls), implementations MAY choose to ignore some or all controls, subject to the criticality constraint.
A zero-length attribute value MUST be represented as AttributeDescription ':' FILL SEP (e.g., 'seeAlso:' followed by a newline). It is also permissible for URL-referenced values to be zero length.
An LDIF file specifies a set of directory entries or a set of changes to be applied to directory entries, but not both. The top-level grammar is either ldif-content or ldif-changes.
Any DN or RDN containing characters outside SAFE-UTF8-CHAR, or beginning with a character outside SAFE-INIT-UTF8-CHAR, MUST be base-64 encoded. Any attribute value containing characters outside SAFE-CHAR or beginning with a character outside SAFE-INIT-CHAR MUST be base-64 encoded.
Any line beginning with a pound-sign ('#', ASCII 35) is a comment and MUST be ignored when parsing an LDIF file.
Distinguished names, relative distinguished names, and attribute values of DirectoryString syntax MUST be valid UTF-8 strings. Implementations MUST NOT generate LDIF content that does not contain valid UTF-8 data.
If the criticality of a control is 'true', the implementation MUST either include the control or MUST NOT send the operation to a remote server. Implementations MAY ignore controls that cannot be honored.
Implementations SHOULD NOT fold lines in the middle of a multi-byte UTF-8 character.
Implementations SHOULD support the file:// URL format in attrval-spec; the contents of the referenced file are to be included verbatim in the interpreted output.
Line folding MUST NOT occur before the first character of the line. Any line that begins with a single space MUST be treated as a continuation of the previous non-empty line, and exactly one leading space MUST be discarded when joining.
The version number in the version-spec line MUST be '1' for the LDIF format described in this document.
Values or distinguished names that end with SPACE SHOULD be base-64 encoded to avoid ambiguity during parsing.
An ldif-attrval-record is a dn-spec followed by one or more attrval-specs, representing a complete directory entry. An ldif-change-record is a dn-spec, optional controls, and a changerecord.
AttributeDescription consists of an AttributeType (ldap-oid or alphanumeric string) optionally followed by semicolon-separated options, supporting language tags (e.g., 'givenname;lang-ja') and other extensions.
LDIF files are likely to contain sensitive personal data; appropriate measures should be taken to protect the privacy of persons whose data is included.
LDIF provides no mechanism for carrying authentication information. Recipients of LDIF files from external sources must independently verify the integrity of the file before applying its contents.
The ':<' URL directive causes external file or resource content to be included when processing an LDIF file. A malicious LDIF file could reference sensitive local files and cause their contents to be imported into a directory entry readable via LDAP.
A change-moddn record specifies 'newrdn:' (plain or base64 RDN), 'deleteoldrdn:' ('0' or '1'), and optionally 'newsuperior:' (plain or base64 DN) for subtree moves.
A changerecord begins with 'changetype:' followed by one of: 'add', 'delete', 'modify', or 'modrdn'/'moddn'. Each maps directly to the corresponding LDAP protocol operation.
A control line has the form 'control:' FILL ldap-oid, with optional criticality ('true'/'false') and optional value-spec. It precedes the changerecord in an ldif-change-record.
A mod-spec within a change-modify record begins with 'add:'/'delete:'/'replace:' followed by an AttributeDescription, zero or more attrval-specs, and a terminating '-' line (ASCII 45) followed by SEP.
An LDIF file begins with 'version: 1' followed by one or more records separated by one or more blank lines (SEP). A line separator is either CRLF or LF.
BASE64-CHAR is restricted to '+', '/', '0'–'9', '=', 'A'–'Z', and 'a'–'z' as specified in RFC 2045. No extraneous characters (other than line-folding whitespace) are permitted in LDIF base64 strings.
SAFE-CHAR is any byte value 0x01–0x7F except NUL (0x00), LF (0x0A), and CR (0x0D). SAFE-INIT-CHAR additionally excludes SPACE (0x20), colon (0x3A), and less-than (0x3C).
The dn-spec field is 'dn:' followed either by a SAFE-STRING distinguished name or '::' followed by a base64-encoded UTF-8 distinguished name.
The value-spec field encodes an attribute value in one of three forms: ':' FILL SAFE-STRING (plain text), '::' FILL BASE64-STRING (base64-encoded), or ':<' FILL url (URL reference).