[要約] RFC 2849は、LDAPデータの交換形式であるLDIFの技術仕様を定めている。 目的は、LDAPディレクトリサービス間でデータを簡単に交換するための標準形式を提供すること。 要約：RFC 2849はLDIFの技術仕様であり、LDAPデータの交換を容易にするための標準形式を提供する。
Network Working Group G. Good
Request for Comments: 2849 iPlanet e-commerce Solutions
Category: Standards Track June 2000
The LDAP Data Interchange Format (LDIF) - Technical Specification
LDAPデータインターチェンジ形式（LDIF） - 技術仕様
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes a file format suitable for describing directory information or modifications made to directory information. The file format, known as LDIF, for LDAP Data Interchange Format, is typically used to import and export directory information between LDAP-based directory servers, or to describe a set of changes which are to be applied to a directory.
このドキュメントでは、ディレクトリ情報またはディレクトリ情報に加えられた変更を説明するのに適したファイル形式について説明します。LDAPデータインターチェンジ形式のLDIFとして知られるファイル形式は、通常、LDAPベースのディレクトリサーバー間でディレクトリ情報をインポートおよびエクスポートするため、またはディレクトリに適用される一連の変更を説明するために使用されます。
Background and Intended Usage
背景と目的の使用法
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.
一般的なインターチェンジ形式が望ましい状況がいくつかあります。たとえば、ディレクトリサーバーのコンテンツのコピーをファイルにエクスポートし、そのファイルを別のマシンに移動し、コンテンツを2番目のディレクトリサーバーにインポートする場合があります。
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. This file can then be imported into a directory server, regardless of the internal database representation the target directory server uses.
さらに、明確に定義されたインターチェンジ形式を使用することにより、レガシーシステムからのデータインポートツールの開発が促進されます。たとえば、awkまたはPerlで書かれたかなりシンプルなツールセットは、人事情報のデータベースをLDIFファイルに変換できます。このファイルは、ターゲットディレクトリサーバーが使用する内部データベース表現に関係なく、ディレクトリサーバーにインポートできます。
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.
LDIF形式は、もともとミシガン大学LDAP実装で開発および使用されました。LDIFの最初の使用は、ディレクトリエントリを説明することでした。その後、フォーマットが拡張され、ディレクトリエントリの変更の表現が可能になりました。
Relationship to the application/directory MIME content-type:
アプリケーション/ディレクトリMIMEコンテンツタイプとの関係：
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. The LDIF format is a simpler format which is perhaps easier to create, and may also be used, as noted, to describe a set of changes to be applied to a directory.
アプリケーション/ディレクトリMIMEコンテンツタイプ[1]は、ディレクトリ情報を伝えるための一般的なフレームワークおよび形式であり、特定のディレクトリサービスから独立しています。LDIF形式はよりシンプルな形式であり、おそらく作成が簡単であり、指摘するように、ディレクトリに適用される一連の変更を説明するために使用することもできます。
The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT" used in this document are to be interpreted as described in [7].
「必須」、「「必要」でなければならない」、「5月」、「は」、「すべきではない」というキーワードは、[7]で説明されているように解釈されるべきではありません。
Definition of the LDAP Data Interchange Format
LDAPデータインターチェンジ形式の定義
The LDIF format is used to convey directory information, or a description of a set of changes made to directory entries. An LDIF file consists of a series of records separated by line separators. A record consists of a sequence of lines describing a directory entry, or a sequence of lines describing a set of changes to a directory entry. An LDIF file specifies a set of directory entries, or a set of changes to be applied to directory entries, but not both.
LDIF形式は、ディレクトリ情報、またはディレクトリエントリに加えられた一連の変更の説明を伝えるために使用されます。LDIFファイルは、ラインセパレーターで区切られた一連のレコードで構成されています。レコードは、ディレクトリエントリを記述する一連の行、またはディレクトリエントリの一連の変更を記述する一連の行で構成されています。LDIFファイルは、ディレクトリエントリのセット、またはディレクトリエントリに適用される一連の変更を指定しますが、両方ではありません。
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.
ディレクトリを変更するLDAP操作（追加、削除、変更、およびmodRDN）と以下に説明するチェンジセレコルドのタイプ（ "add"、 "delete"、 "Modify"、および "modRdn）の間には1対1の相関があります。「または「moddn」）。この対応は意図的なものであり、LDIF ChangereCordsからプロトコル操作への簡単な翻訳を許可します。
Formal Syntax Definition of LDIF
LDIFの正式な構文定義
The following definition uses the augmented Backus-Naur Form specified in RFC 2234 [2].
次の定義では、RFC 2234 [2]で指定された増強されたバックナウル形式を使用しています。
ldif-file = ldif-content / ldif-changes
ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
ldif-changes = version-spec 1*(1*SEP ldif-change-record)
ldif-attrval-record = dn-spec SEP 1*attrval-spec
LDIF-ATTRVAL-RECORD = DN-SPEC SEP 1*ATTRVAL-SPEC
ldif-change-record = dn-spec SEP *control changerecord
ldif-change-record = dn-spec sep *control changerecord
version-spec = "version:" FILL version-numberversion-number = 1*DIGIT ; version-number MUST be "1" for the ; LDIF format described in this document.
version-spec = "version：" fill version-numberversion-number = 1*digit;バージョン番号は;の「1」でなければなりません。このドキュメントで説明されているLDIF形式。
dn-spec = "dn:" (FILL distinguishedName /
":" FILL base64-distinguishedName)
distinguishedName = SAFE-STRING ; a distinguished name, as defined in [3]
distinguedname = safe-string;[3]で定義されているように、著名な名前
base64-distinguishedName = BASE64-UTF8-STRING ; a distinguishedName which has been base64 ; encoded (see note 10, below)
base64-distinguishedname = base64-UTF8-string;base64であった著名な名前。エンコード（下の注10を参照）
rdn = SAFE-STRING
; a relative distinguished name, defined as
; <name-component> in [3]
base64-rdn = BASE64-UTF8-STRING ; an rdn which has been base64 encoded (see ; note 10, below)
base64-rdn = base64-utf8-string;base64エンコードされたRDN（以下の注10、以下を参照）
control = "control:" FILL ldap-oid ; controlType
0*1(1*SPACE ("true" / "false")) ; criticality
0*1(value-spec) ; controlValue
SEP
; (See note 9, below)
ldap-oid = 1*DIGIT 0*1("." 1*DIGIT)
; An LDAPOID, as defined in [4]
attrval-spec = AttributeDescription value-spec SEP
value-spec = ":" ( FILL 0*1(SAFE-STRING) /
":" FILL (BASE64-STRING) /
"<" FILL url)
; See notes 7 and 8, below
url = <a Uniform Resource Locator,
as defined in [6]>
; (See Note 6, below)
AttributeDescription = AttributeType [";" options] ; Definition taken from [4]
astributedescription = astributeType [";"オプション];[4]から取られた定義
AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
options = option / (option ";" options)
option = 1*opt-char
attr-type-chars = ALPHA / DIGIT / "-"
opt-char = attr-type-chars
changerecord = "changetype:" FILL
(change-add / change-delete /
change-modify / change-moddn)
change-add = "add" SEP 1*attrval-spec
change-add = "add" Sep 1*attrval-spec
change-delete = "delete" SEP
change-delete = "delete" 9月
change-moddn = ("modrdn" / "moddn") SEP
"newrdn:" ( FILL rdn /
":" FILL base64-rdn) SEP
"deleteoldrdn:" FILL ("0" / "1") SEP
0*1("newsuperior:"
( FILL distinguishedName /
":" FILL base64-distinguishedName) SEP)
change-modify = "modify" SEP *mod-spec
Change-Modify = "Modify" SEP *mod-spec
mod-spec = ("add:" / "delete:" / "replace:")
FILL AttributeDescription SEP
*attrval-spec
"-" SEP
SPACE = %x20
; ASCII SP, space
FILL = *SPACE
SEP = (CR LF / LF)
CR = %x0D
; ASCII CR, carriage return
LF = %x0A
; ASCII LF, line feed
ALPHA = %x41-5A / %x61-7A
; A-Z / a-z
DIGIT = %x30-39
; 0-9
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
; any value <= 127 decimal except NUL, LF,
; and CR
SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
%x21-39 / %x3B / %x3D-7F
; any value <= 127 except NUL, LF, CR,
; SPACE, colon (":", ASCII 58 decimal)
; and less-than ("<" , ASCII 60 decimal)
SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 /
UTF8-4 / UTF8-5 / UTF8-6
UTF8-STRING = *UTF8-CHAR
BASE64-UTF8-STRING = BASE64-STRING ; MUST be the base64 encoding of a ; UTF8-STRING
base64-utf8-string = base64-string;aのbase64エンコーディングでなければなりません。UTF8-STRING
BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
%x61-7A
; +, /, 0-9, =, A-Z, and a-z
; as specified in [5]
BASE64-STRING = [*(BASE64-CHAR)]
Notes on LDIF Syntax
LDIF構文に関するメモ
1) For the LDIF format described in this document, the version number MUST be "1". If the version number is absent, implementations MAY choose to interpret the contents as an older LDIF file format, supported by the University of Michigan ldap-3.3 implementation [8].
1) このドキュメントで説明されているLDIF形式の場合、バージョン番号は「1」でなければなりません。バージョン番号がない場合、実装は、ミシガン大学LDAP-3.3実装[8]によってサポートされている古いLDIFファイル形式としてコンテンツを解釈することを選択できます。
2) Any non-empty line, including comment lines, in an LDIF file MAY be folded by inserting a line separator (SEP) and a SPACE. Folding MUST NOT occur before the first character of the line. In other words, folding a line into two lines, the first of which is empty, is not permitted. Any line that begins with a single space MUST be treated as a continuation of the previous (non-empty) line. When joining folded lines, exactly one space character at the beginning of each continued line must be discarded. Implementations SHOULD NOT fold lines in the middle of a multi-byte UTF-8 character.
2) LDIFファイル内のコメント行を含む非空白の行は、ラインセパレーター（SEP）とスペースを挿入することで折り畳まれる場合があります。折りたたみは、ラインの最初の文字の前に発生してはなりません。言い換えれば、線を2本の線に折り畳むと、最初は空ですが、許可されていません。単一のスペースで始まるすべてのラインは、以前の（空の）行の継続として扱わなければなりません。折り畳まれた線を結合する場合、各継続ラインの先頭にある1つのスペース文字を破棄する必要があります。実装は、マルチバイトのUTF-8文字の中央に行を折りたためないでください。
3) Any line that begins with a pound-sign ("#", ASCII 35) is a comment line, and MUST be ignored when parsing an LDIF file.
3) ポンドシグイン（ "＃"、ascii 35）で始まるすべての行はコメント行であり、LDIFファイルを解析するときは無視する必要があります。
4) Any dn or rdn that contains characters other than those defined as "SAFE-UTF8-CHAR", or begins with a character other than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded. Any value that contains characters other than those defined as "SAFE-CHAR", or begins with a character other than those defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded. Other values MAY be base-64 encoded.
4) 「Safe-UTF8-Char」と定義された文字以外の文字を含むDNまたはRDNは、上記の「Safe-Init-UTF8-Char」と定義されている文字以外の文字から始まり、ベース64エンコードする必要があります。その他の値は、ベース64エンコードされている場合があります。「セーフチャー」と定義されている文字以外の文字を含む、または上記の「セーフインイットチャー」と定義された文字以外の文字から始まる値は、ベース64エンコードする必要があります。その他の値は、ベース64エンコードされている場合があります。
5) When a zero-length attribute value is to be included directly in an LDIF file, it MUST be represented as AttributeDescription ":" FILL SEP. For example, "seeAlso:" followed by a newline represents a zero-length "seeAlso" attribute value. It is also permissible for the value referred to by a URL to be of zero length.
5) ゼロレングス属性値をLDIFファイルに直接含める場合、それは属性と表現として表現する必要があります。たとえば、「seealso：」に続いて、新しいラインが続くと、ゼロの長さの「seealso」属性値を表します。また、URLによって言及される値が長さがゼロであることも許されます。
6) When a URL is specified in an attrval-spec, the following conventions apply:
6) Attrval-SpecでURLが指定されている場合、次の規則が適用されます。
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.
a) 実装は、ファイル：// url形式をサポートする必要があります。参照されたファイルの内容は、LDIFファイルの解釈された出力に逐語的に含まれます。b）実装は、他のURL形式をサポートする場合があります。サポートされている各URLに関連付けられたセマンティクスは、関連する適用性ステートメントに文書化されます。
7) Distinguished names, relative distinguished names, and attribute values of DirectoryString syntax MUST be valid UTF-8 strings. Implementations that read LDIF MAY interpret files in which these entities are stored in some other character set encoding, but implementations MUST NOT generate LDIF content which does not contain valid UTF-8 data.
7) DirectoryStringの構文の著名な名前、相対的な識別名、および属性値は、有効なUTF-8文字列でなければなりません。LDIFを読み取る実装は、これらのエンティティが他の文字セットエンコーディングに保存されているファイルを解釈する場合がありますが、実装は有効なUTF-8データを含まないLDIFコンテンツを生成してはなりません。
8) Values or distinguished names that end with SPACE SHOULD be base-64 encoded.
8) スペースで終わる値または識別された名前は、ベース64エンコードする必要があります。
9) When controls are included in an LDIF file, implementations MAY choose to ignore some or all of them. This may be necessary if the changes described in the LDIF file are being sent on an LDAPv2 connection (LDAPv2 does not support controls), or the particular controls are not supported by the remote server. If the criticality of a control is "true", then the implementation MUST either include the control, or MUST NOT send the operation to a remote server.
9) コントロールがLDIFファイルに含まれている場合、実装はそれらの一部またはすべてを無視することを選択できます。これは、LDIFファイルで説明されている変更がLDAPV2接続（LDAPV2がコントロールをサポートしない）で送信されている場合、または特定のコントロールがリモートサーバーによってサポートされていない場合に必要になる場合があります。コントロールの重要性が「真」の場合、実装にはコントロールを含めるか、操作をリモートサーバーに送信してはなりません。
10) When an attrval-spec, distinguishedName, or rdn is base64- encoded, the encoding rules specified in [5] are used with the following exceptions: a) The requirement that base64 output streams must be represented as lines of no more than 76 characters is removed. Lines in LDIF files may only be folded according to the folding rules described in note 2, above. b) Base64 strings in [5] may contain characters other than those defined in BASE64-CHAR, and are ignored. LDIF does not permit any extraneous characters, other than those used for line folding.
10）attrval-spec、distinguishedname、またはrdnがbase64-エンコードされている場合、[5]で指定されたエンコードルールは、次の場合に使用されます。a）base64出力ストリームを76以下の行として表す必要があるという要件文字が削除されます。LDIFファイルの行は、上記のノート2に記載されている折りたたみルールに従ってのみ折り畳まれます。b）[5]のbase64文字列には、base64-charで定義されている文字以外の文字が含まれている場合があり、無視されます。LDIFは、ラインの折りたたみに使用された文字を除き、無関係な文字を許可しません。
Examples of LDAP Data Interchange Format
LDAPデータインターチェンジ形式の例
Example 1: An simple LDAP file with two entries
例1：2つのエントリを備えた単純なLDAPファイル
version: 1 dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com 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.
バージョン：1 DN：CN = Barbara Jensen、OU =製品開発、DC = Airius、DC = com ObjectClass：Top ObjectClass：Person Objectclass：組織個人CN：Barbara Jensen CN：Barbara J Jensen CN：Babs Jensen SN：Jensen UID：BjensenenThelephonEnumber：1 408 555 1212説明：帆走ファンが大きい。
dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Bjorn Jensen
sn: Jensen
telephonenumber: +1 408 555 1212
Example 2: A file containing an entry with a folded attribute value
version: 1
dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
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:Babs is a big sailing fan, and travels extensively in sea
rch of perfect sailing conditions.
title:Product Manager, Rod and Reel Division
Example 3: A file containing a base-64-encoded value
例3：ベース64エンコード値を含むファイル
version: 1
dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: Gern Jensen
cn: Gern O Jensen
sn: Jensen
uid: gernj
telephonenumber: +1 408 555 1212
description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
b3V0IG1vcmUu
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.
例4：言語タグを含むUTF-8エンコード属性値を持つエントリを含むファイル。コメントは、UTF-8エンコードされた属性と著名な名前の内容を示しています。
version: 1
dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: ou=<JapaneseOU>,o=Airius
objectclass: top
objectclass: organizationalUnit
ou:: 5Za25qWt6YOo
# ou:: <JapaneseOU>
ou;lang-ja:: 5Za25qWt6YOo
# ou;lang-ja:: <JapaneseOU>
ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
ou;lang-en: Sales
description: Japanese office
dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
# dn:: uid=<uid>,ou=<JapaneseOU>,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:: <JapaneseGivenname>
sn;lang-ja:: 5bCP56yg5Y6f
# sn;lang-ja:: <JapaneseSn>
cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn;lang-ja:: <JapaneseCn>
title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
# title;lang-ja:: <JapaneseTitle>
preferredlanguage: ja
givenname:: 44Ot44OJ44OL44O8
# givenname:: <JapaneseGivenname>
sn:: 5bCP56yg5Y6f
# sn:: <JapaneseSn>
cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
# cn:: <JapaneseCn>
title:: 5Za25qWt6YOoIOmDqOmVtw==
# title:: <JapaneseTitle>
givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
# givenname;lang-ja;phonetic::
<JapaneseGivenname_in_phonetic_representation_kana>
sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
# title;lang-ja;phonetic::
# <JapaneseTitle_in_phonetic_representation_kana>
givenname;lang-en: Rodney
sn;lang-en: Ogasawara
cn;lang-en: Rodney Ogasawara
title;lang-en: Sales, Director
Example 5: A file containing a reference to an external file
version: 1
dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
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: A file containing a series of change records and comments
例6：一連の変更レコードとコメントを含むファイル
version: 1
# Add a new entry
dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
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, dc=airius, dc=com
changetype: delete
# Modify an entry's relative distinguished name
dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
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, dc=airius, dc=com
changetype: modrdn
newrdn: ou=Product Development Accountants
deleteoldrdn: 0
newsuperior: ou=Accounting, dc=airius, dc=com
# 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, dc=airius, dc=com
changetype: modify
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 -
削除：説明 - 交換：TelephonEnumber TelephonEnanumber：1 408 555 1234 TelephonEnumber：1 408 555 5678-削除：FafsimileteLephoneNumber facsimiletelephoneNumber：1 408 555 9876-
# Modify an entry: replace the postaladdress attribute with an empty
# set of values (which will cause the attribute to be removed), and
# delete the entire description attribute. Note that the first will
# always succeed, while the second will only succeed if at least
# one value for the description attribute is present.
dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
changetype: modify
replace: postaladdress
-
delete: description
-
Example 7: An LDIF file containing a change record with a control
version: 1
# Delete an entry. The operation will attach the LDAPv3
# Tree Delete Control defined in [9]. The criticality
# field is "true" and the controlValue field is
# absent, as required by [9].
dn: ou=Product Development, dc=airius, dc=com
control: 1.2.840.113556.1.4.805 true
changetype: delete
Security Considerations
Given typical directory applications, an LDIF 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 file.
典型的なディレクトリアプリケーションを考えると、LDIFファイルには機密性の高い個人データが含まれている可能性があります。データがLDIFファイルに含まれている人のプライバシーを保護するために、適切な対策を講じる必要があります。
Since ":<" directives can cause external content to be included when processing an LDIF file, one should be cautious of accepting LDIF files from external sources. A "trojan" LDIF 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ファイルを処理するときに外部コンテンツを含める可能性があるため、外部ソースからLDIFファイルを受け入れることに注意する必要があります。「Trojan」LDIFファイルは、敏感なコンテンツを持つファイルに名前を付けて、敵対的なエンティティがLDAPを介して読むことができるディレクトリエントリに含めることができます。
LDIF does not provide any method for carrying authentication information with an LDIF file. Users of LDIF files must take care to verify the integrity of an LDIF file received from an external source.
LDIFは、LDIFファイルで認証情報を運ぶ方法を提供しません。LDIFファイルのユーザーは、外部ソースから受信したLDIFファイルの整合性を確認するように注意する必要があります。
Acknowledgments
謝辞
The LDAP Interchange Format was developed as part of the University of Michigan LDAP reference implementation, and was developed by Tim Howes, Mark Smith, and Gordon Good. It is based in part upon work supported by the National Science Foundation under Grant No. NCR-9416667.
LDAPインターチェンジ形式は、ミシガン大学LDAPリファレンスの実装の一環として開発され、ティムハウズ、マークスミス、ゴードングッドによって開発されました。これは、グラント番号NCR-9416667の下で国立科学財団によってサポートされている作業に一部基づいています。
Members of the IETF LDAP Extensions Working group provided many helpful suggestions. In particular, Hallvard B. Furuseth of the University of Oslo made many significant contributions to this document, including a thorough review and rewrite of the BNF.
IETF LDAP Extensionsワーキンググループのメンバーは、多くの有用な提案を提供しました。特に、オスロ大学のHallvard B. Furusethは、BNFの徹底的なレビューや書き換えなど、この文書に多くの重要な貢献をしました。
References
参考文献
[1] Howes, T. and M. Smith, "A MIME Content-Type for Directory Information", RFC 2425, September 1998.
[1] Howes、T。およびM. Smith、「ディレクトリ情報用のMIMEコンテンツタイプ」、RFC 2425、1998年9月。
[2] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker、D。、およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[3] Wahl, M., Kille, S. and T. Howes, "A String Representation of Distinguished Names", RFC 2253, December 1997.
[3] Wahl、M.、Kille、S。、およびT. Howes、「著名な名前の文字列表現」、RFC 2253、1997年12月。
[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, July 1997.
[4] Wahl、M.、Howes、T。およびS. Kille、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年7月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[5] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[6] Berners-Lee、T.、Masinter、L。およびM. McCahill、「Uniform Resource Locators（URL）」、RFC 1738、1994年12月。
[7] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[8] The SLAPD and SLURPD Administrators Guide. University of
Michigan, April 1996. <URL:
http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
[9] M. P. Armijo, "Tree Delete Control", Work in Progress.
[9] M. P. Armijo、「Tree Delete Control」、進行中の作業。
Author's Address
著者の連絡先
Gordon Good iPlanet e-commerce Solutions 150 Network Circle Mailstop USCA17-201 Santa Clara, CA 95054, USA
Gordon Good IPlanet E-Commerce Solutions 150 Network Circle MailStop USCA17-201 Santa Clara、CA 95054、USA
Phone: +1 408 276 4351
EMail: ggood@netscape.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。