RFC 2849 - The LDAP Data Interchange Format (LDIF) - Technical Specification 日本語訳

URL : https://tools.ietf.org/html/rfc2849
タイトル : RFC 2849 - LDAPデータ交換フォーマット（LDIF） - 技術仕様
翻訳編集 : 自動生成

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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（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.

この文書は、ディレクトリ情報に対して行われたディレクトリ情報や修正を記述するのに適したファイル形式を記述する。 LDIFとして知られているファイル形式は、LDAPデータ交換フォーマットのために、通常は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.

一般的な交換形式が望ましい状況がいくつかあります。例えば、1は、ファイルへのディレクトリ・サーバの内容のコピーをエクスポートしたいかもしれない別のマシンにそのファイルを移動し、第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].

キーワード「MUST」、「MUST NOT」、「MAY」、「SHOULD」とに記載されているように解釈されるべきである本書で使用される「べきではない」[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の）、および下記のchangerecordsのタイプの間の1対1の相関関係は、（「削除」、「追加」である「変更」、および「modrdnの"または "）" moddn。この対応は意図的なものであり、LDIFのchangerecordsからプロトコル操作に簡単な翻訳を可能にします。

Formal Syntax Definition of LDIF

LDIFの正式な構文の定義

The following definition uses the augmented Backus-Naur Form specified in RFC 2234 [2].

以下の定義は、[2] RFC 2234に指定された拡張バッカスナウア記法を使用します。

ldif-file = ldif-content / ldif-changes

LDIFファイル= LDIF-コンテンツ/ LDIF-変更

ldif-content = version-spec 1*(1*SEP ldif-attrval-record)

LDIFコンテンツ=バージョンスペック1 *（1 *のSEP LDIF-attrvalをレコード）

ldif-changes = version-spec 1*(1*SEP ldif-change-record)

LDIF-変化=バージョンスペック1 *（1 *のSEP LDIF変更レコード）

ldif-attrval-record = dn-spec SEP 1*attrval-spec

LDIF-attrvalをレコード=のDN-スペック9月1日* attrvalをスペック

ldif-change-record = dn-spec SEP *control changerecord

LDIF-changerecord = DN-スペック9月*制御changerecord

version-spec = "version:" FILL version-number version-number = 1*DIGIT ; version-number MUST be "1" for the ; LDIF format described in this document.

バージョンスペック=「バージョン：」FILLバージョン番号バージョン番号= 1 * DIGIT。バージョン番号は「1」でなければなりません。 LDIF形式は、この文書で説明します。

dn-spec = "dn:" (FILL distinguishedName / ":" FILL base64-distinguishedName)

DN-スペック= "DN："（distinguishedNameのを/ FILL "：" base64でdistinguishedNameのを埋めます）

distinguishedName = SAFE-STRING ; a distinguished name, as defined in [3]

distinguishedNameの= 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でてきたのdistinguishedName;符号化された（下記の注10を参照のこと）

rdn = SAFE-STRING ; a relative distinguished name, defined as ; <name-component> in [3]

RDN = SAFE-STRING。定義される相対識別名、。 <名前成分> [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を埋めます。 controlType 0 * 1（1つの*のSPACE（） "真" / "偽"）;臨界0 * 1（値-SPEC）。 controlValue 9月; （下記の注9を参照してください）

ldap-oid = 1*DIGIT 0*1("." 1*DIGIT) ; An LDAPOID, as defined in [4]

LDAP-OID = 1 * DIGIT 0 * 1（1 * DIGIT ""）; [4]で定義されるようLDAPOID、

attrval-spec = AttributeDescription value-spec SEP

attrvalをスペック=のAttributeDescription値スペック9月

value-spec = ":" ( FILL 0*1(SAFE-STRING) / ":" FILL (BASE64-STRING) / "<" FILL url) ; See notes 7 and 8, below

値スペック= "："（0 * 1（SAFE-STRINGを埋める）/ "：" FILL（BASE64-STRING）/ "<" URLを記入）。以下、ノート7および8を参照してください。

url = <a Uniform Resource Locator, as defined in [6]> ; (See Note 6, below)

[6]>で定義されているURL = <aユニフォームリソースLocator,。（以下、注記6を参照）

AttributeDescription = AttributeType [";" options] ; Definition taken from [4]

AttributeDescription = AttributeTypeで[ ";"オプション]; [4]から採取定義

AttributeType = ldap-oid / (ALPHA *(attr-type-chars))

AttributeTypeで= LDAP-OID /（ALPHA *（ATTR型-文字））

options = option / (option ";" options) option = 1*opt-char

オプション=オプション/; = 1 * OPT-CHAR（オプション "" オプション）オプション

attr-type-chars = ALPHA / DIGIT / "-"

ATTR型-文字= ALPHA / DIGIT / " - "

opt-char = attr-type-chars

OPT-CHAR = ATTR型、文字

changerecord = "changetype:" FILL (change-add / change-delete / change-modify / change-moddn)

changerecord =「変更タイプ：」FILL（変更・追加/変更、削除/変更・修正/変更moddn）

change-add = "add" SEP 1*attrval-spec

変更・追加= * attrvalをスペックを9月1日「追加」

change-delete = "delete" SEP

変更・削除= 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)

変更-moddn =（ "modrdnの" / "moddn"）9月 "newrdn："（/ RDNを埋める "：" base64でRDNを埋める）9月 "のdeleteoldrdn：" FILL（ "0" / "1"）* 9月1日0（ "newsuperior："（distinguishedNameのを/ FILL "：" base64でdistinguishedNameのFILL）SEP）

change-modify = "modify" SEP *mod-spec

変更・修正= 9月を「修正」* MODスペック

mod-spec = ("add:" / "delete:" / "replace:") FILL AttributeDescription SEP *attrval-spec "-" SEP

MOD-スペック=（ "追加：" / "を削除します。" / "に置き換えます。"）のAttributeDescription 9月* attrvalをスペックを満たす " - " 9月

SPACE = %x20 ; ASCII SP, space

SPACE =％のX20。 ASCIIのSP、スペース

FILL = *SPACE

FILL = * SPACE

SEP = (CR LF / LF)

9月=（CR LF / LF）

CR = %x0D ; ASCII CR, carriage return

CR =％x0D。 ASCII CR、キャリッジリターン

LF = %x0A ; ASCII LF, line feed

LF =％X0A。 ASCIIのLF、ラインフィード

ALPHA = %x41-5A / %x61-7A ; A-Z / a-z

ALPHA =％x41-5A /％x61-7A。 -Z / Z-

DIGIT = %x30-39 ; 0-9

DIGIT =％x30-39。 0-9

UTF8-1 = %x80-BF

UTF8-1 =％X80-BF

UTF8-2 = %xC0-DF UTF8-1

UTF8-2 =％XC0-DF UTF8-1

UTF8-3 = %xE0-EF 2UTF8-1

UTF8-3 =％xE0-IF 2UTF8-1

UTF8-4 = %xF0-F7 3UTF8-1

UTF8-4 =％XF0-F7 3UTF8-1

UTF8-5 = %xF8-FB 4UTF8-1

UTF8-5 =％XF8-FB 4UTF8-1

UTF8-6 = %xFC-FD 5UTF8-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-CHAR =％x01-09 /％X0B-0C /％x0E-7F。任意の値<= NUL、LF、除く127小数。そして、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-INIT-CHAR =％x01-09 /％X0B-0C /％x0E-1F /％x21-39 /％X3B /％X3D-7F。 NUL、LF、CR、以外の任意の値<= 127。 SPACE、コロン（ "："、ASCII 58進）。そして小なり（ "<"、ASCII 60進）

SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]

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

UTF8-STRING = * UTF8-CHAR

BASE64-UTF8-STRING = BASE64-STRING ; MUST be the base64 encoding of a ; UTF8-STRING

BASE64-UTF8-STRING = BASE64-STRING。の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-CHAR =％X2B /％x2F /％x30-39 /％X3D /％x41-5A /％x61-7A。 +、/、0-9、=、A-Z、及び、Z。 [5]で指定されるように

BASE64-STRING = [*(BASE64-CHAR)]

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」でなければなりません。バージョン番号が存在しない場合、実装は、[8]ミシガン大学のLDAP-3.3の実装によってサポートされる、古い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つのラインにラインを折り畳み、許可されません。単一のスペースで始まる行は、（非空）前の行の継続として扱われなければなりません。折りたたまれた行を結合する場合、それぞれの継続的な行の先頭に正確に一つのスペース文字を廃棄しなければなりません。実装は、マルチバイト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」として定義されたもの以外の文字が含まれている、または「SAFE-INIT-UTF8-CHAR」として定義されたもの以外の文字で始まるDNまたはRDNは、上記、ベース64符号化されなければなりません。他の値は、ベース64符号化されてもよいです。「SAFE-CHAR」として定義されたもの以外の文字を含む、または上記、「SAFE-INIT-CHAR」として定義されたもの以外の文字で始まる値は、ベース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.

ゼロ長の属性値がLDIFファイルに直接含まれるべきである場合5）、それのAttributeDescriptionとして表現されなければならない「：」9月を埋めます。例えば、「seeAlsoの」改行に続くゼロ長「seeAlsoの」属性の値を表します。 URLによって参照される値はゼロ長さすることも許容されます。

6) When a URL is specified in an attrval-spec, the following conventions apply:

6）URLがattrvalを-specで指定された場合、次の規則が適用されます。

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.

// URL形式：a）の実装は、ファイルをサポートする必要があります。参照されたファイルの内容は、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.

コントロールがLDIFファイルに含まれている場合9）、実装はそれらのいくつかまたは全てを無視することを選択するかもしれません。 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をスペック、distinguishedNameの、またはRDNがbase64-符号化されるときに指定された符号化規則は、[5]以下の例外を除いて使用されている：A）出力ストリームをbase64で要件がこれ以上76以下の行として表現されなければならないに文字が削除されます。 LDIFファイル内の行は、上記の注記2に記載の折りたたみ規則に従って折り畳むことができます。 B）[5] BASE64-CHARで定義されたもの以外の文字が含まれていてもよいでのBase64ストリング、および無視されます。 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 =バーバラ・ジェンセン、OU =製品開発、DC =はAirius、dc = comのオブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをCN：バーバラ・ジェンセンCN：バーバラJジェンセンCN：バブスジェンセンSN：ジェンセンのUID：bjensenのTelephoneNumber：+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

DN：CN =ビョルン・ジェンセン、OU =会計、DC =はAirius、dc = comのオブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをCN：ビョルン・ジェンセンSN：ジェンセンのTelephoneNumber：+1 408 555 1212

Example 2: A file containing an entry with a folded attribute value

例2：折りたたまれた属性値を持つエントリを含むファイル

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

バージョン：1 DN：CN =嬉しいジェンセン、OU =製品テスト、DC =はAirius、dc = comのオブジェクトクラス：トップオブジェクトクラス：人のobjectClass：organizationalPersonをCN：同様ジェンセンCN：同様にOジェンセンSN：ジェンセンUID：gernj電話番号：+1 408 555 1212説明:: 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

バージョン：1 DN :: b3U95Za25qWt6YOoLG89QWlyaXVz＃DN :: OU = <JapaneseOU>、O =はAiriusオブジェクトクラス：トップオブジェクトクラス：のorganizationalUnit OU :: 5Za25qWt6YOo＃OU :: <JapaneseOU> OU; langの-JA :: 5Za25qWt6YOo＃OU; lang- JA :: <JapaneseOU> OU; LANG-JA;音声学:: 44GI44GE44GO44KH44GG44G2

# ou;lang-ja:: <JapaneseOU_in_phonetic_representation> ou;lang-en: Sales description: Japanese office

＃OU; LANG-JA :: <JapaneseOU_in_phonetic_representation> OU; LANG-EN：販売の説明：日本のオフィス

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

DN :: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz位のDN :: UID = <uid>、OU = <JapaneseOU>、O =はAiriusのにuserPassword：{SHA} O3HSv1MusyL4kTjP + HKI5uxuNoM =オブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをオブジェクトクラス：inetOrgPersonのUID：rogasawaraメール：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>タイトル; LANG-JA :: 5Za25qWt6YOoIOmDqOmVtw ==＃タイトル; LANG-JA :: <JapaneseTitle>は、preferredlanguage：JA givennameの:: 44Ot44OJ44OL44O8＃givennameの:: < JapaneseGivenname> SN :: 5bCP56yg5Y6f＃SN :: <JapaneseSn> CN :: 5bCP56yg5Y6fIOODreODieODi + ODVA ==＃CN :: <JapaneseCn>タイトル:: 5Za25qWt6YOoIOmDqOmVtw ==＃タイトル:: <JapaneseTitle>のgivenname; LANG-JA;発音:: 44KN44Gp44Gr44O8＃のgivenname; LANG-JA;発音:: <JapaneseGivenname_in_phonetic_representation_kana> SN; LANG-JA;発音:: 44GK44GM44GV44KP44KJ＃のSN; LANG-JA;電話チック:: <JapaneseSn_in_phonetic_representation_kana> CN; LANG-JA;発音:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq + ODVA ==＃CN; LANG-JA;発音:: <JapaneseCn_in_phonetic_representation_kana>タイトル; LANG-JA;発音:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh + OBhg ==＃タイトル。 LANG-JA;発音::＃<JapaneseTitle_in_phonetic_representation_kana>のgivenname; LANGエン：ロドニーSN; LANGエン：小笠原CN; LANGエン：ロドニー小笠原タイトル; LANGエン：セールスディレクター

Example 5: A file containing a reference to an external file

実施例5：外部ファイルへの参照を含むファイル

version: 1 dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com objectclass: top objectclass: person objectclass: organizationalPerson cn: Horatio Jensen

バージョン：1 DN：CN =ホレイショ・ジェンセン、OU =製品テスト、DC =はAirius、dc = comのオブジェクトクラス：トップオブジェクトクラス：人物オブジェクトクラス：organizationalPersonをCN：ホレイショ・ジェンセン

cn: Horatio N Jensen sn: Jensen uid: hjensen telephonenumber: +1 408 555 1212 jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg

CN：ホレイショNジェンセンSN：ジェンセンのUID：hjensenのTelephoneNumber：<ファイル：///usr/local/directory/photos/hjensen.jpgをjpegPhoto +1 408 555 1212

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

バージョン：CN =フィオナ・ジェンセン、OU =マーケティング、DC =はAirius、dc = comのの変更タイプ：1つの＃は、新しいエントリのDNを追加オブジェクトクラス追加：トップオブジェクトクラス：人のオブジェクトクラスを：organizationalPersonをCN：フィオナジェンセンSN：ジェンセンのUID：フィオナののTelephoneNumber： +1 408 555 1212をjpegPhoto：<ファイル：///usr/local/directory/photos/fiona.jpg

# Delete an existing entry dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com changetype: delete

CN =ロバート・ジェンセン、OU =マーケティング、DC =はAirius、dc = comのの変更タイプ：削除＃既存のエントリのDNを削除します。

# 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

＃エントリの相対識別名DN変更します。cn =ポール・ジェンセンが、OU =製品開発、DC =はAirius、dc = comの変更タイプ：modrdnのnewrdn：CN =ポーラジェンセンの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

＃（のみのLDAPv3サーバによって実装）ディレクトリツリーをエントリの名前を変更し、＃で新しい場所にその子のすべてを移動します。 DN：OU = PD会計士、OU =製品開発、DC =はAirius、dc = comの変更タイプ：modrdnのnewrdn：OU =製品開発会計士のdeleteoldrdn：0 newsuperior：OU =会計、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 -

二つの値で位にtelephoneNumber属性を置き換え、完全に説明属性を削除し、のPostalAddress＃属性に付加価値を追加し、facsimiletelephonenumber属性DNから特定の＃値を削除します：＃エントリを変更CN =ポーラ・ジェンセン、OU =製品開発、DC =はAirius、dc = comのの変更タイプ：アドオンを変更：のPostalAddressのPostalAddress：123 Anystreet $カリフォルニア州サニーベール$ 94086 -

delete: description - replace: telephonenumber telephonenumber: +1 408 555 1234 telephonenumber: +1 408 555 5678 - delete: facsimiletelephonenumber facsimiletelephonenumber: +1 408 555 9876 -

説明を - 置き換えます：削除のTelephoneNumberのTelephoneNumberを：+1 408 555 1234のTelephoneNumber：+1 408 555 5678 - 削除：facsimiletelephonenumberの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 -

＃エントリを変更します（属性が削除されます）値の空＃セットでのPostalAddressの属性を交換し、＃全体description属性を削除します。 description属性について少なくとも＃つの値が存在する場合には、第2にのみ成功しますが、最初の意志＃が常に成功することに注意してください。 DN：CN =イングリッド・ジェンセン、OU =製品サポート、DC =はAirius、dc = comのの変更タイプ：置き換える修正：のPostalAddress - 削除：説明 -

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

例7：コントロールバージョンで変更レコードを含むLDIFファイル：1つの＃は、エントリを削除します。操作は、LDAPv3の＃ツリー[9]で定義されたコントロールを削除して添付します。臨界＃フィールドが「真」である、[9]によって必要とcontrolValueフィールドは、＃1は存在しません。 DN：OU =製品開発、DC =はAirius、dc = comの制御：1.2.840.113556.1.4.805真の変更タイプ：削除

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ファイルを受け入れるの注意が必要です。「トロイの木馬」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機能拡張ワーキンググループのメンバーは、多くの役立つ情報を提供しました。特に、オスロ大学のHallvard B. FurusethはBNFの徹底的な見直しとリライトを含め、この文書に多くの重要な貢献をし、作られました。

References

リファレンス

[1] Howes, T. and M. Smith, "A MIME Content-Type for Directory Information", RFC 2425, September 1998.

[1]ハウズ、T.およびM.スミス、 "ディレクトリ情報のMIMEのContent-Type"、RFC 2425、1998年9月。

[2] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[2]クロッカー、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]ワール、M.、Kille、S.とT.ハウズ、 "識別名の文字列表現"、RFC 2253、1997年12月。

[4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, July 1997.

[4]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。

[6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.

[6]バーナーズ=リー、T.、Masinter、LとM. McCahill、 "ユニフォームリソースロケータ（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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[8] The SLAPD and SLURPD Administrators Guide. University of Michigan, April 1996. <URL: http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>

[8] SLAPDとSLURPD管理者ガイド。ミシガン大学、1996年4月<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を、 "ツリーコントロールの削除"、進行中の作業。

Author's Address

著者のアドレス

Gordon Good iPlanet e-commerce Solutions 150 Network Circle Mailstop USCA17-201 Santa Clara, CA 95054, USA

ゴードン・グッドiPlanetのeコマース・ソリューション150ネットワークサークルメールストップUSCA17-201サンタクララ、CA 95054、USA

Phone: +1 408 276 4351 EMail: ggood@netscape.com

電話：+1 408 276 4351 Eメール：ggood@netscape.com

Full Copyright Statement

完全な著作権声明

著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。