RFC2849 日本語訳

Network Working Group                                             G. Good
Request for Comments: 2849                   iPlanet e-commerce Solutions
Category: Standards Track                                       June 2000

コメントを求めるワーキンググループのG.の良い要求をネットワークでつないでください: 2849 iPlanet電子商取引ソリューションCategory: 標準化過程2000年6月

   The LDAP Data Interchange Format (LDIF) - Technical Specification

LDAPデータ置き換え形式(LDIF)--技術的な仕様

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

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 Data Interchange FormatのためのLDIFとして知られているファイル形式はLDAPベースのディレクトリサーバの間のディレクトリ情報をインポートして、エクスポートするか、またはディレクトリに適用されることになっている1セットの変化について説明するのにおいて通常使用されています。

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かパールに書かれたかなり簡単なセットのツールは人員情報に関するデータベースを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の最初の使用がありました。 その後、形式は、ディレクトリエントリーへの変化の表現を許容するために広げられました。

Good                        Standards Track                     [Page 1]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[1ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

   Relationship to the application/directory MIME content-type:

アプリケーション/ディレクトリ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.  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 content type[1]は、ディレクトリ情報を伝えるための一般的なフレームワークと形式であり、どんな特定のディレクトリサービスからも独立しています。 LDIF形式は、より簡単な恐らくより作成しやすい形式であり、また、使用されるかもしれません、ディレクトリに適用されるために1セットの変化について説明するために注意されるように。

   The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
   used in this document are to be interpreted as described in [7].

そして、キーワード“MUST"、「必須NOT」、「5月」“SHOULD"、「本書では使用されたNOTは[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形式は、ディレクトリ情報、またはディレクトリエントリーにされた1セットの変更の記述を伝えるのに使用されます。 LDIFファイルはラインセパレータによって切り離された一連の記録から成ります。 記録はディレクトリエントリについて説明する系列の系列、または1セットの変化をディレクトリエントリに説明する系列の系列から成ります。 LDIFファイルは、ディレクトリエントリーに適用されるために1セットのディレクトリエントリー、または1セットの変化を指定しますが、ともに指定するというわけではありません。

   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.

ディレクトリ(加えて、削除して、変更して、modrdnする)を変更するLDAP操作と、以下(「加える」か、「削除する」か、「変更し」て、"modrdnする"である、または"moddnする"である)で説明されたchangerecordsのタイプの間には、1〜1つの相関関係があります。 この通信は、意図的であり、LDIF changerecordsからの簡単な翻訳が操作について議定書の中で述べることを許可します。

Formal Syntax Definition of LDIF

LDIFの正式な構文定義

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

以下の定義はRFC2234[2]で指定された増大しているBN記法を使用します。

ldif-file                = ldif-content / ldif-changes

ldif ldif-ファイル=ldif-内容/変化

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

ldif-内容はバージョン仕様1*と等しいです。(1*9月のldif-attrval-記録)

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

ldif-変化はバージョン仕様1*と等しいです。(1*9月のldif-改訂記録)

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

ldif-attrval-記録は9月1日dn-仕様*attrval-仕様と等しいです。

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

ldif-改訂記録はdn-仕様9月*コントロールchangerecordと等しいです。

version-spec             = "version:" FILL version-number

バージョン仕様=、「バージョン:」 FILLバージョン番号

Good                        Standards Track                     [Page 2]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[2ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

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

バージョン番号は1*DIGITと等しいです。 バージョン番号がそうであるに違いない、「1インチ、」、。 本書では説明されたLDIF形式。

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

dn-仕様=は「以下をdnします」。 「(」 : 」 distinguishedName/中詰めbase64-distinguishedNameをいっぱいにしています)

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

distinguishedNameは安全なストリングと等しいです。 中で定義されるとしての分類名[3]

base64-distinguishedName = BASE64-UTF8-STRING
                           ; a distinguishedName which has been base64
                           ; encoded (see note 10, below)

base64-distinguishedNameはBASE64-UTF8-ストリングと等しいです。 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)

コントロール=は「以下を制御します」。 FILL ldap-oid。 controlType0*1(1*スペース(「本当」の、または、「誤った」))。 臨界0*1(値仕様)。 controlValue9月。 (以下で注意9を見ます)

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

ldap-oidが1*DIGIT0*1と等しい、(「. 」 1*ケタ、)、。 中で定義されるとしてのLDAPOID[4]

attrval-spec             = AttributeDescription value-spec SEP

AttributeDescription値仕様attrval-仕様=9月

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

「値仕様=」:、」 「(」 : 」 中詰め(BASE64-ストリング)/"<"中詰めFILL0*1(SAFE-STRING)/url) ; 以下で注意7と8を見てください。

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

urlは[6] >で定義されるように<a Uniform Resource Locatorと等しいです。 (以下のNote6を見ます)

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

AttributeDescriptionがAttributeTypeと等しい、[「」、;、オプション]、。 取られた定義[4]

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

AttributeTypeはldap-oid/と等しいです。(アルファ*(attrタイプ雑用))

options                  = option / (option ";" options)

オプションはオプション/と等しいです。「(オプション、」、;、」、オプション)

Good                        Standards Track                     [Page 3]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[3ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

option                   = 1*opt-char

*が選ぶオプション=1、-焦げてください。

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

attrタイプ雑用はアルファー/ DIGIT /「-」と等しいです。

opt-char                 = attr-type-chars

炭を選んでいる=attrタイプ雑用

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

changerecord=は「以下をchangetypeします」。 中詰め(/変化-moddnを変化で加えるか、変化で削除する、または変化で変更します)

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

= 「加えてください」という9月1日*attrval-仕様を変化で加えてください。

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します」。 「(」 : 」 FILL rdn/中詰めbase64-rdn) 9月は「以下をdeleteoldrdnします」。 中詰め、(「0インチ/、「1インチ) 9月の0*1」「(「以下をnewsuperiorする」、(」 : 」 distinguishedName/中詰めbase64-distinguishedNameをいっぱいにしています)9月)

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

「変更=」9月の*モッズ仕様を変化で変更してください。

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

モッズ風の仕様の=(「加えてください」という/が「以下を削除する」という/は「以下を取り替える」)FILL AttributeDescription9月*attrval-仕様「-」9月

SPACE                    = %x20
                           ; ASCII SP, space

スペース=%x20。 ASCII SP、スペース

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

アルファー=%x41-5A/%x61-7A。 a A-Z/z

DIGIT                    = %x30-39
                           ; 0-9

ケタ=%x30-39。 0-9

Good                        Standards Track                     [Page 4]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[4ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

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-EF 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

安全な炭=%のx01-09/%のx0B-0C/%のx0E-7F。 どんな値の<もNUL以外の127小数、LFと等しいです。 そして、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)

安全なイニット炭は%x01-09/%x0B-0とC/%x0E-1F/%x21-39/%x3B/%x3D-7F等しいです。 どんな値の<もNUL以外の127、LF、CRと等しいです。 SPACE、コロン、(「:」、ASCII58小数)、。 そして、 より少なさ、-("<"、ASCII60小数)

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

安全なストリング=[安全なイニット炭*安全な炭]

UTF8-CHAR                = SAFE-CHAR / UTF8-2 / UTF8-3 /
                           UTF8-4 / UTF8-5 / UTF8-6

UTF8-炭は安全な炭/UTF8-2/UTF8-3/UTF8-4/UTF8-5/UTF8-6と等しいです。

UTF8-STRING              = *UTF8-CHAR

UTF8-ストリング=*UTF8-炭

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

BASE64-UTF8-ストリングはBASE64-ストリングと等しいです。 aのbase64コード化でなければなりません。 UTF8-ストリング

BASE64-CHAR              = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
                           %x61-7A
                           ; +, /, 0-9, =, A-Z, and a-z
                           ; as specified in [5]

BASE64-炭=%x2B/%x2F/%x30-39/%x3D/%x41-5A/%x61-7A。 +、/、0-9、A-Zの、そして、1zの=。 指定されたコネとして[5]

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

BASE64-ストリング=[*(BASE64-炭)]

   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ファイル形式としてコンテンツを解釈するのを選ぶかもしれません。

Good                        Standards Track                     [Page 5]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[5ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

      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ファイルでラインセパレータ(9月)とSPACEを挿入することによって、折り重ねられるかもしれません。 折り重なりは系列の最初のキャラクタの前に起こってはいけません。 言い換えれば、系列を2つの系列に折り重ねるのは受入れられません。その第1は空です。 前の(非空)の系列の継続としてシングルスペースで始まるどんな系列も扱わなければなりません。 折り重ねられた系列を接合するとき、まさにそれぞれの前の行の始めの1つの間隔文字を捨てなければなりません。 実装SHOULD NOTはマルチバイト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) ポンド記号(「#」、ASCII35)で始まるどんな系列も、注釈行であり、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) 「安全なUTF8炭」と定義されたものを除いて、キャラクタを含んでいるか、または「安全なイニットUTF8炭」と定義されたものを除いて、キャラクタと共に始まるどんな上であることのdnやrdnもコード化されたベース-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ファイルに含まれることであるときに、AttributeDescriptionとしてそれを表さなければならない」:、」 9月をいっぱいにしてください。 例えば、「seeAlso:」 続かれて、ニューラインはゼロ・レングス"seeAlso"属性値を表します。 また、URLによって言及された値において、ゼロ・レングスがあるのも、許されています。

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

6) URLがattrval-仕様で指定されるとき、以下のコンベンションは適用されます:

         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) 実装SHOULDは、ファイル://URLが形式であるとサポートします。 参照をつけられたファイルの中身はLDIFの解釈された出力に逐語的に含まれているのが. b)をファイルするということです。 実装は、他のURLが形式であるとサポートするかもしれません。 それぞれのサポートしているURLに関連している意味論は関連Applicability Statementに記録されるでしょう。

      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 MAYを読む実装がこれらの実体がある他の文字集合コード化で保存されるファイルを解釈しますが、実装は、LDIFが有効なUTF-8データを含まない内容であると生成してはいけません。

Good                        Standards Track                     [Page 6]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[6ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

      8)  Values or distinguished names that end with SPACE SHOULD be
          base-64 encoded.

8) ベース-64がコード化されていたならそれがSPACE SHOULDと共に終わらせる値か分類名。

      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-仕様、distinguishedName、またはrdnがコード化されたbase64であるときに、[5]で指定された符号化規則は以下の例外と共に使用されます: a) 76未満のキャラクタの系列としてbase64出力ストリームを表さなければならないという要件は取り除かれます。 注意2で説明された折り尺によると、LDIFファイルの線は. 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.

バージョン: 1dn: cnはバーバラ・ジェンセンと等しく、ouは製品Development、dc=airius、dc=com objectclassと等しいです: 最高objectclass: 人のobjectclass: organizationalPerson cn: バーバラジェンセンcn: バーバラJジェンセンcn: バブスジェンセンsn: ジェンセンuid: bjensen telephonenumber: +1 1212年の408 555記述: 航行大ファン。

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 objectclassと等しいです: 最高objectclass: 人のobjectclass: organizationalPerson cn: ビヨンジェンセンsn: ジェンセンtelephonenumber: +1 408 555 1212

Good                        Standards Track                     [Page 7]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[7ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

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

バージョン: ジェンセンsn: ジェンセンuid: 1dn: cnはバーバラ・ジェンセンと等しいです、製品ou=Development、dc=airius、dc=com objectclass: 最高objectclass: 人のobjectclass:organizationalPerson cn:バーバラジェンセンcn: バーバラJジェンセンcn: バブスbjensen telephonenumber: +1 1212年の408 555記述: バブスは航行大ファンであり、完全な航行状態 タイトルの海のrchを手広く移動します: 製品マネージャ、Rod、およびReel事業部

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

バージョン: 1dn: cn=Gernジェンセン、ouは製品Testing、dc=airius、dc=com objectclassと等しいです: 最高objectclass: 人のobjectclass: organizationalPerson cn: Gernジェンセンcn: Gern Oジェンセンsn: ジェンセンuid: gernj telephonenumber: +1 1212年の408 555記述:、: 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: 言語タグを含むコード化されたUTF8属性値があるエントリーを含むファイル。 コメントはコード化されたUTF8属性と分類名のコンテンツを示します。

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 objectclassと等しいです: 最高objectclass: organizationalUnit ou:、: 5Za25qWt6YOo#は以下をouします: <JapaneseOU>ou;、lang-ja:、: 5Za25qWt6YOo#ou;、lang-ja:、: <JapaneseOU>ou; lang-ja; 音声の:、: 44GI44GE44GO44KH44GG44G2

Good                        Standards Track                     [Page 8]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[8ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

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

# ou;、lang-ja:、: _音声の_表示>ouにおける<JapaneseOU_; langアン: 販売記述: 日本のオフィス

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= objectclass: 最高objectclass: 人のobjectclass: organizationalPerson objectclass: 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; 音声の:、: _音声の_表現_仮名>snの<JapaneseGivenname_; lang-ja; 音声の:、: 44GK44GM44GV44KP44KJ#sn; lang-ja; 音声の:、: _音声の_表現_仮名>cnの<JapaneseSn_; lang-ja; 音声の:、: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA=#cn; lang-ja; 音声の:、: _音声の_表現_仮名>タイトルの<JapaneseCn_; lang-ja; 音声の:、: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg=#タイトル; lang-ja; 音声の:、: # _音声の_表現_仮名>givennameの<JapaneseTitle_; langアン: ロドニーsn; langアン: 小笠原cn; langアン: ロドニー小笠原タイトル; langアン: 販売、ディレクター

Good                        Standards Track                     [Page 9]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[9ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

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

バージョン: 1dn: cnはホレイショー・ジェンセンと等しく、ouは製品Testing、dc=airius、dc=com objectclassと等しいです: 最高objectclass: 人のobjectclass: 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: +1 1212がjpegphotoする408 555:<ファイル:///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

バージョン: 1 #新しいエントリーdnを加えてください: cnはフィオナ・ジェンセンと等しく、ouはマーケティング、dc=airius、dc=com changetypeと等しいです: objectclassを加えてください: 最高objectclass: 人のobjectclass: organizationalPerson cn: フィオナジェンセンsn: ジェンセンuid: fiona telephonenumber: +1 1212がjpegphotoする408 555:<ファイル:///usr/local/directory/photos/fiona.jpg

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

# 既存のエントリーdnを削除してください: cnはロバート・ジェンセンと等しく、ouはマーケティング、dc=airius、dc=com changetypeと等しいです: 削除します。

# 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は製品Development、dc=airius、dc=com changetypeと等しいです: 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 Accountants、ouは製品Development、dc=airius、dc=com changetypeと等しいです: modrdn newrdn: ouは製品Development Accountants deleteoldrdnと等しいです: 0newsuperior: ouは会計、dc=airius、dc=comと等しいです。

Good                        Standards Track                    [Page 10]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[10ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

# 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
-

# エントリーを変更してください: postaladdress#属性に加算値を加えてください、そして、記述属性を完全に削除してください、そして、telephonenumberが結果と考える#、を2つの値に取り替えてください、そして、facsimiletelephonenumber属性dnから特定の#値を削除してください: cnはポーラ・ジェンセンと等しく、ouは製品Development、dc=airius、dc=com changetypeと等しいです: 変更、加えます: postaladdress postaladdress: サニーベル、123Anystreetドルのカリフォルニア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、1234telephonenumber: +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属性を空の#値(属性を取り除かせる)に取り替えてください、そして、全体の記述属性を削除してください。 1番目が#いつもそうするというメモは成功します、2番目が記述属性のための少なくとも#1値が. dnを寄贈することである場合にだけ成功するでしょうが: cnはイングリッド・イァンセンと等しく、ouは製品Support、dc=airius、dc=com changetypeと等しいです: 変更、取り替えます: 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 #エントリーを削除してください。 操作は[9]で定義されたLDAPv3#Tree Delete Controlを取り付けるでしょう。 臨界#分野は「本当です」、そして、controlValue分野は必要に応じて#欠けています。[9]でdn: ouは製品Development、dc=airius、dc=comコントロールと等しいです: 1.2.840.113556.1.4.805 本当のchangetype: 削除します。

Good                        Standards Track                    [Page 11]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[11ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

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 Interchange Formatはミシガン大学LDAP参照実装の一部として開発されて、ティム・ハウズ、マーク・スミス、およびゴードンGoodによって開発されました。 それはグラントNo.の下で国立科学財団によってサポートされた仕事に一部基づいています。 NCR9416667。

   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 Workingグループのメンバーは多くの役立つ提案を提供しました。 オスロ大学の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コンテントタイプ」、RFC2425、1998年9月。

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

[2] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

   [3]  Wahl, M., Kille, S. and T. Howes, "A String Representation of
        Distinguished Names", RFC 2253, December 1997.

[3] ウォールとM.とKilleとS.とT.ハウズ、「分類名のストリング表現」、RFC2253、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)」、RFC2251 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)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、1996年11月。

Good                        Standards Track                    [Page 12]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[12ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

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

[6] バーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。

   [7]  Bradner, S., "Key Words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のための主要なワーズ」、BCP14、RFC2119、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>

[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

Network Circle Mailstop USCA17-201サンタクララ、ゴードンGood iPlanet電子商取引Solutions150カリフォルニア 95054、米国

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

以下に電話をしてください。 +1 4351年の408 276メール: ggood@netscape.com

Good                        Standards Track                    [Page 13]

RFC 2849              LDAP Data Interchange Format             June 2000

良い標準化過程[13ページ]RFC2849LDAPデータは形式2000年6月に交換されます。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

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

Good                        Standards Track                    [Page 14]

良い標準化過程[14ページ]