RFC4514 日本語訳

Network Working Group                                   K. Zeilenga, Ed.
Request for Comments: 4514                           OpenLDAP Foundation
Obsoletes: 2253                                                June 2006
Category: Standards Track

ワーキンググループK.Zeilenga、エドをネットワークでつないでください。コメントのために以下を要求してください。 4514年のOpenLDAP財団は以下を時代遅れにします。 2253 2006年6月のカテゴリ: 標準化過程

             Lightweight Directory Access Protocol (LDAP):
              String Representation of Distinguished Names

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP): 分類名のストリング表現

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.

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

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   The X.500 Directory uses distinguished names (DNs) as primary keys to
   entries in the directory.  This document defines the string
   representation used in the Lightweight Directory Access Protocol
   (LDAP) to transfer distinguished names.  The string representation is
   designed to give a clean representation of commonly used
   distinguished names, while being able to represent any distinguished
   name.

X.500ディレクトリは主キーとしてディレクトリで分類名(DNs)をエントリーに使用します。 このドキュメントは分類名を移すのにライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)に使用されるストリング表現を定義します。 ストリング表現は、一般的に使用された分類名の清潔な表現を与えるようにどんな分類名も表すことができる間、設計されています。

1.  Background and Intended Usage

1. バックグラウンドと意図している用法

   In X.500-based directory systems [X.500], including those accessed
   using the Lightweight Directory Access Protocol (LDAP) [RFC4510],
   distinguished names (DNs) are used to unambiguously refer to
   directory entries [X.501][RFC4512].

ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC4510]を使用することでアクセスされたものを含むX.500ベースのディレクトリシステム[X.500]では、分類名(DNs)は、明白に、ディレクトリエントリー[X.501][RFC4512]について言及するのに使用されます。

   The structure of a DN [X.501] is described in terms of ASN.1 [X.680].
   In the X.500 Directory Access Protocol [X.511] (and other ITU-defined
   directory protocols), DNs are encoded using the Basic Encoding Rules
   (BER) [X.690].  In LDAP, DNs are represented in the string form
   described in this document.

DN[X.501]の構造はASN.1[X.680]に関して説明されます。 X.500ディレクトリAccessプロトコル[X.511](そして、他のITUによって定義されたディレクトリプロトコル)では、DNsは、Basic Encoding Rules(BER)[X.690]を使用することでコード化されます。 LDAPでは、DNsは本書では説明されたストリングフォームに表されます。

   It is important to have a common format to be able to unambiguously
   represent a distinguished name.  The primary goal of this
   specification is ease of encoding and decoding.  A secondary goal is
   to have names that are human readable.  It is not expected that LDAP

明白に分類名を表すことができるように一般的な形式を持っているのは重要です。 この仕様のプライマリ目標はコード化と解読の容易さです。 セカンダリ目標は読み込み可能な状態で人間である名前を持つことです。 それがそう、そのLDAPは予想しませんでした。

Zeilenga                    Standards Track                     [Page 1]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[1ページ]: 分類名2006年6月

   implementations with a human user interface would display these
   strings directly to the user, but that they would most likely be
   performing translations (such as expressing attribute type names in
   the local national language).

たぶん、翻訳(現地雇用人言語の属性型名を表すことなどの)を実行していないなら、人間のユーザーインタフェースがある実装は直接ユーザにこれらのストリングを表示するでしょうに。

   This document defines the string representation of Distinguished
   Names used in LDAP [RFC4511][RFC4517].  Section 2 details the
   RECOMMENDED algorithm for converting a DN from its ASN.1 structured
   representation to a string.  Section 3 details how to convert a DN
   from a string to an ASN.1 structured representation.

このドキュメントはLDAP[RFC4511][RFC4517]で使用されるDistinguished Namesのストリング表現を定義します。 セクション2はASN.1の構造化された表現からストリングまでDNを変換するためのRECOMMENDEDアルゴリズムを詳しく述べます。 セクション3はストリングから構造化されたASN.1表現までDNを変換する方法を詳しく述べます。

   While other documents may define other algorithms for converting a DN
   from its ASN.1 structured representation to a string, all algorithms
   MUST produce strings that adhere to the requirements of Section 3.

他のドキュメントがASN.1の構造化された表現からストリングまでDNを変換するための他のアルゴリズムを定義しているかもしれない間、すべてのアルゴリズムがセクション3の要件を固く守るストリングを作り出さなければなりません。

   This document does not define a canonical string representation for
   DNs.  Comparison of DNs for equality is to be performed in accordance
   with the distinguishedNameMatch matching rule [RFC4517].

このドキュメントはDNsの正準なストリング表現を定義しません。 平等のためのDNsの比較はdistinguishedNameMatchの合っている規則[RFC4517]に従って実行されることです。

   This document is a integral part of the LDAP technical specification
   [RFC4510], which obsoletes the previously defined LDAP technical
   specification, RFC 3377, in its entirety.  This document obsoletes
   RFC 2253.  Changes since RFC 2253 are summarized in Appendix B.

このドキュメントはLDAP技術仕様書[RFC4510]の不可欠の部分です。(それは、以前に定義されたLDAP技術仕様書、RFC3377を全体として時代遅れにします)。 このドキュメントはRFC2253を時代遅れにします。 RFC2253以来の変化はAppendix Bにまとめられます。

   This specification assumes familiarity with X.500 [X.500] and the
   concept of Distinguished Name [X.501][RFC4512].

この仕様は、X.500への親しみがDistinguished Name[X.501][RFC4512]の[X.500]と概念であると仮定します。

1.1.  Conventions

1.1. コンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきですか?

   Character names in this document use the notation for code points and
   names from the Unicode Standard [Unicode].  For example, the letter
   "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.

キャラクター名はコード・ポイントと名前にユニコードStandard[ユニコード]から記法を本書では使用します。 例えば、手紙“a"は<U+0061>か<LATIN SMALL LETTER A>のどちらかとして表されるかもしれません。

   Note: a glossary of terms used in Unicode can be found in [Glossary].
   Information on the Unicode character encoding model can be found in
   [CharModel].

以下に注意してください。 [用語集]でユニコードで使用される用語の用語集を見つけることができます。 [CharModel]でユニコード文字符号化モデルに関する情報を見つけることができます。

Zeilenga                    Standards Track                     [Page 2]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[2ページ]: 分類名2006年6月

2.  Converting DistinguishedName from ASN.1 to a String

2. ASN.1からストリングまでDistinguishedNameを変換します。

   X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished
   name.  The following is a variant provided for discussion purposes.

X.501[X.501]は分類名のASN.1[X.680]構造を定義します。 ↓これは議論目的に提供された異形です。

      DistinguishedName ::= RDNSequence

DistinguishedName:、:= RDNSequence

      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RDNSequence:、:= RelativeDistinguishedNameの系列

      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
          AttributeTypeAndValue

RelativeDistinguishedName:、:= AttributeTypeAndValueのサイズ(1..MAX)を設定してください。

      AttributeTypeAndValue ::= SEQUENCE {
          type  AttributeType,
          value AttributeValue }

AttributeTypeAndValue:、:= 系列AttributeType、値のAttributeValueをタイプしてください。

   This section defines the RECOMMENDED algorithm for converting a
   distinguished name from an ASN.1-structured representation to a UTF-8
   [RFC3629] encoded Unicode [Unicode] character string representation.
   Other documents may describe other algorithms for converting a
   distinguished name to a string, but only strings that conform to the
   grammar defined in Section 3 SHALL be produced by LDAP
   implementations.

このセクションはASN.1によって構造化された表現からUTF-8[RFC3629]のコード化されたユニコード[ユニコード]文字列表現まで分類名を変換するためのRECOMMENDEDアルゴリズムを定義します。 他のドキュメントは分類名をストリングに変換するための他のアルゴリズムを説明するかもしれませんが、文法に一致しているストリングだけがセクション3でSHALLを定義しました。LDAP実装で、生産されます。

2.1.  Converting the RDNSequence

2.1. RDNSequenceを変換します。

   If the RDNSequence is an empty sequence, the result is the empty or
   zero-length string.

RDNSequenceが空の系列であるなら、結果は空の、または、無長さのストリングです。

   Otherwise, the output consists of the string encodings of each
   RelativeDistinguishedName in the RDNSequence (according to Section
   2.2), starting with the last element of the sequence and moving
   backwards toward the first.

さもなければ、出力はRDNSequence(セクション2.2によると)のそれぞれのRelativeDistinguishedNameのストリングencodingsから成ります、系列の最後の原理から始まって、後方に1番目に近づいて。

   The encodings of adjoining RelativeDistinguishedNames are separated
   by a comma (',' U+002C) character.

RelativeDistinguishedNamesに隣接するencodingsがコンマによって切り離される、('、'、U+002C)キャラクタ。

2.2.  Converting RelativeDistinguishedName

2.2. RelativeDistinguishedNameを変換します。

   When converting from an ASN.1 RelativeDistinguishedName to a string,
   the output consists of the string encodings of each
   AttributeTypeAndValue (according to Section 2.3), in any order.

ASN.1RelativeDistinguishedNameからストリングまで変換するとき、出力はそれぞれのAttributeTypeAndValue(セクション2.3によると)のストリングencodingsから成ります、順不同に。

   Where there is a multi-valued RDN, the outputs from adjoining
   AttributeTypeAndValues are separated by a plus sign ('+' U+002B)
   character.

マルチ評価されたRDNがあるところに、AttributeTypeAndValuesに隣接するのからの出力はプラスサイン('+'U+002B)キャラクタによって切り離されます。

Zeilenga                    Standards Track                     [Page 3]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[3ページ]: 分類名2006年6月

2.3.  Converting AttributeTypeAndValue

2.3. AttributeTypeAndValueを変換します。

   The AttributeTypeAndValue is encoded as the string representation of
   the AttributeType, followed by an equals sign ('=' U+003D) character,
   followed by the string representation of the AttributeValue.  The
   encoding of the AttributeValue is given in Section 2.4.

AttributeValueのストリング表現で等号(U+003Dと'等しい')キャラクタによって後をつけられたAttributeTypeのストリング表現が続いて、AttributeTypeAndValueはコード化されます。 セクション2.4でAttributeValueのコード化を与えます。

   If the AttributeType is defined to have a short name (descriptor)
   [RFC4512] and that short name is known to be registered [REGISTRY]
   [RFC4520] as identifying the AttributeType, that short name, a
   <descr>, is used.  Otherwise the AttributeType is encoded as the
   dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER.
   The <descr> and <numericoid> are defined in [RFC4512].

AttributeTypeが省略名(記述子)[RFC4512]を持つために定義されて、AttributeTypeを特定するとしてその省略名が登録されるのが[REGISTRY][RFC4520]知られているなら、その省略名(<descr>)は使用されています。 さもなければ、AttributeTypeはドット付き10進法コード化、OBJECT IDENTIFIERの<numericoid>としてコード化されます。 <descr>と<numericoid>は[RFC4512]で定義されます。

   Implementations are not expected to dynamically update their
   knowledge of registered short names.  However, implementations SHOULD
   provide a mechanism to allow their knowledge of registered short
   names to be updated.

実装がダイナミックに登録された省略名に関するそれらの知識をアップデートしないと予想されます。 しかしながら、実装SHOULDは、登録された省略名に関するそれらの知識をアップデートするのを許容するためにメカニズムを提供します。

2.4.  Converting an AttributeValue from ASN.1 to a String

2.4. ASN.1からストリングまでAttributeValueを変換します。

   If the AttributeType is of the dotted-decimal form, the
   AttributeValue is represented by an number sign ('#' U+0023)
   character followed by the hexadecimal encoding of each of the octets
   of the BER encoding of the X.500 AttributeValue.  This form is also
   used when the syntax of the AttributeValue does not have an LDAP-
   specific ([RFC4517], Section 3.1) string encoding defined for it, or
   the LDAP-specific string encoding is not restricted to UTF-8-encoded
   Unicode characters.  This form may also be used in other cases, such
   as when a reversible string representation is desired (see Section
   5.2).

AttributeTypeがドット付き10進法フォームのものであるなら、AttributeValueはそれぞれのX.500 AttributeValueのBERコード化の八重奏の16進コード化があとに続いたナンバー記号('#'U+0023)キャラクタによって表されます。 また、AttributeValueの構文にコード化がそれのために定義したLDAPの特定([RFC4517]、セクション3.1)のストリングがないと、このフォームが使用されるか、またはLDAP特有のストリングコード化はコード化されたUTF8ユニコード文字に制限されません。 また、このフォームは他の場合に使用されるかもしれません、リバーシブルのストリング表現が望まれている(セクション5.2を見てください)時のように。

   Otherwise, if the AttributeValue is of a syntax that has a LDAP-
   specific string encoding, the value is converted first to a UTF-8-
   encoded Unicode string according to its syntax specification (see
   [RFC4517], Section 3.3, for examples).  If that UTF-8-encoded Unicode
   string does not have any of the following characters that need
   escaping, then that string can be used as the string representation
   of the value.

さもなければ、AttributeValueがLDAPの特定のストリングがそれでコード化する構文のものであるなら、値は構文仕様通りに最初に、UTF-8でコード化されたユニコードストリングに変換されます([RFC4517]を見てください、セクション3.3、例のために)。 そのコード化されたUTF8ユニコードストリングに逃げる必要がある以下のキャラクタのいずれもないなら、価値のストリング表現としてそのストリングを使用できます。

      - a space (' ' U+0020) or number sign ('#' U+0023) occurring at
        the beginning of the string;

- スペース(''U+0020)か数がストリングの始めに起こりながら、('#'U+0023)に署名します;、'

      - a space (' ' U+0020) character occurring at the end of the
        string;

- ストリングの端に起こる宇宙(''U+0020)キャラクタ;、'

Zeilenga                    Standards Track                     [Page 4]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[4ページ]: 分類名2006年6月

      - one of the characters '"', '+', ',', ';', '<', '>',  or '\'
        (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C,
        respectively);

- 'キャラクタ'「''、+'のひとり'、'';'、'<''か、>、''\'(それぞれU+0022、U+002B、U+002C、U+003B、U+003C、U+003E、またはU+005C)」。

      - the null (U+0000) character.

- ヌル(U+0000)のキャラクタ。

   Other characters may be escaped.

他のキャラクタ逃げられるかもしれません。

   Each octet of the character to be escaped is replaced by a backslash
   and two hex digits, which form a single octet in the code of the
   character.  Alternatively, if and only if the character to be escaped
   is one of

逃げられるべきキャラクタの各八重奏をバックスラッシュと2十六進法ケタに取り替えます。(ケタはキャラクタのコードにおけるただ一つの八重奏を形成します)。 代わりに、逃げられるべきキャラクタは1歳にすぎません。

      ' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
      (U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
       U+003C, U+003D, U+003E, U+005C, respectively)

'、'、'、「''#、''+'''、'、'、;、<、'''='、'>'、または'\'」(U+0020、U+0022、U+0023、U+002B、U+002Cと、U+003B、U+003Cと、U+003D、U+003E、U+005Cと、それぞれ)

   it can be prefixed by a backslash ('\' U+005C).

バックスラッシュ(U+005'\'のC)でそれを前に置くことができます。

   Examples of the escaping mechanism are shown in Section 4.

エスケープメカニズムに関する例はセクション4に示されます。

3.  Parsing a String Back to a Distinguished Name

3. 分類名にストリングを分析して戻します。

   The string representation of Distinguished Names is restricted to
   UTF-8 [RFC3629] encoded Unicode [Unicode] characters.  The structure
   of this string representation is specified using the following
   Augmented BNF [RFC4234] grammar:

Distinguished Namesのストリング表現はUTF-8[RFC3629]のコード化されたユニコード[ユニコード]キャラクタに制限されます。 このストリング表現の構造は以下のAugmented BNF[RFC4234]文法を使用することで指定されます:

      distinguishedName = [ relativeDistinguishedName
          *( COMMA relativeDistinguishedName ) ]
      relativeDistinguishedName = attributeTypeAndValue
          *( PLUS attributeTypeAndValue )
      attributeTypeAndValue = attributeType EQUALS attributeValue
      attributeType = descr / numericoid
      attributeValue = string / hexstring

distinguishedName=[relativeDistinguishedName*(COMMA relativeDistinguishedName)]relativeDistinguishedName=attributeTypeAndValue*(PLUS attributeTypeAndValue)attributeTypeAndValue=attributeType EQUALS attributeValue attributeType=descr / numericoid attributeValueはストリング/hexstringと等しいです。

      ; The following characters are to be escaped when they appear
      ; in the value to be encoded: ESC, one of <escaped>, leading
      ; SHARP or SPACE, trailing SPACE, and NULL.
      string =   [ ( leadchar / pair ) [ *( stringchar / pair )
         ( trailchar / pair ) ] ]

; 彼らが現れるとき、以下のキャラクタ逃げられることになっています。 コード化されるべき値で: ESC、<の1つは>、先導から逃げました。 NULLシャープかSPACEと、引きずっているSPACEと、ストリング=[(leadchar/組)[*(stringchar/組)(trailchar/組)]]

      leadchar = LUTF1 / UTFMB
      LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
         %x3D / %x3F-5B / %x5D-7F

leadcharはLUTF1 / UTFMB LUTF1と= x21/%x24-2A/%x2D-3A/%x3D/%x3F-5B/%x5D-7%x01 1F/%F等しいです。

      trailchar  = TUTF1 / UTFMB
      TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /

trailchar=TUTF1 / UTFMB TUTF1は%x01-1F/%x21/%x23-2A/%x2D-3A/と等しいです。

Zeilenga                    Standards Track                     [Page 5]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[5ページ]: 分類名2006年6月

         %x3D / %x3F-5B / %x5D-7F

%x3D/%x3F-5B/%x5D-7F

      stringchar = SUTF1 / UTFMB
      SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
         %x3D / %x3F-5B / %x5D-7F

stringcharはSUTF1 / UTFMB SUTF1と= %x01-21/%x23-2A/%x2D-3A/%x3D/%x3F-5B/%x5D-7F等しいです。

      pair = ESC ( ESC / special / hexpair )
      special = escaped / SPACE / SHARP / EQUALS
      escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
      hexstring = SHARP 1*hexpair
      hexpair = HEX HEX

組=ESC(ESC/特別番組/hexpair)スペシャル=はシャープ1/ SPACE /シャープ/EQUALS逃げられた=DQUOTE/PLUS/COMMA/SEMI/LANGLE/RANGLE hexstring=*hexpair hexpair=HEX HEXから逃げました。

   where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>,
   <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>,
   <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].

創作の<descr>、<numericoid>、<COMMA>、<DQUOTE>、<EQUALS>、<ESC>、<HEX>、<LANGLE>、<NULL>、<PLUS>、<RANGLE>、<SEMI>、<SPACE>、<シャープ>、および<UTFMB>が[RFC4512]で定義されるところ。

   Each <attributeType>, either a <descr> or a <numericoid>, refers to
   an attribute type of an attribute value assertion (AVA).  The
   <attributeType> is followed by an <EQUALS> and an <attributeValue>.
   The <attributeValue> is either in <string> or <hexstring> form.

それぞれの<attributeType>(<descr>か<numericoid>のどちらか)は属性値主張(AVA)の属性タイプに言及します。 <attributeType>は<EQUALS>と<attributeValue>によって続かれています。 <attributeValue>が<ストリング>か>フォームをhexstringする<にあります。

   If in <string> form, a LDAP string representation asserted value can
   be obtained by replacing (left to right, non-recursively) each <pair>
   appearing in the <string> as follows:

LDAPストリング表現が、<ストリング>フォームで<ストリング>で以下の通りに見えるそれぞれの<組>を取り替えることによって(非再帰的な右への左)値を得ることができると断言したなら:

      replace <ESC><ESC> with <ESC>;
      replace <ESC><special> with <special>;
      replace <ESC><hexpair> with the octet indicated by the <hexpair>.

<ESC><ESC>を<ESC>に取り替えてください。 <のESCの>の<の特別な>を<の特別な>に取り替えてください。 <ESC><hexpair>を<hexpair>によって示された八重奏に取り替えてください。

   If in <hexstring> form, a BER representation can be obtained from
   converting each <hexpair> of the <hexstring> to the octet indicated
   by the <hexpair>.

>フォームをhexstringする<で>をhexstringする<のそれぞれの<hexpair>を変換するのから<hexpair>によって示された八重奏までBER表現を得ることができるなら。

   There is one or more attribute value assertions, separated by <PLUS>,
   for a relative distinguished name.

1つがあるか、または以上は相対的な分類名のために<PLUS>によって切り離された値の主張を結果と考えます。

   There is zero or more relative distinguished names, separated by
   <COMMA>, for a distinguished name.

<COMMA>によって切り離されたゼロか、より相対的な分類名が分類名のためにあります。

   Implementations MUST recognize AttributeType name strings
   (descriptors) listed in the following table, but MAY recognize other
   name strings.

実装は、以下のテーブルに記載されたAttributeType名前ストリング(記述子)を認識しなければなりませんが、他の名前ストリングを認識するかもしれません。

Zeilenga                    Standards Track                     [Page 6]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[6ページ]: 分類名2006年6月

      String  X.500 AttributeType
      ------  --------------------------------------------
      CN      commonName (2.5.4.3)
      L       localityName (2.5.4.7)
      ST      stateOrProvinceName (2.5.4.8)
      O       organizationName (2.5.4.10)
      OU      organizationalUnitName (2.5.4.11)
      C       countryName (2.5.4.6)
      STREET  streetAddress (2.5.4.9)
      DC      domainComponent (0.9.2342.19200300.100.1.25)
      UID     userId (0.9.2342.19200300.100.1.1)

ストリングX.500 AttributeType------ -------------------------------------------- CN commonName、(2.5、.4、.3)L localityName、(2.5、.4、.7)第stateOrProvinceName、(2.5.4.8)o organizationName、(2.5、.4、.10)OU organizationalUnitName、(2.5、.4の.11)CのcountryName、(2.5.4.6)通りのstreetAddress、(2.5.4.9)DC domainComponent、(0.9.2342.19200300.100.1.25)UIDユーザID(0.9.2342.19200300.100.1.1)

   These attribute types are described in [RFC4519].

これらの属性タイプは[RFC4519]で説明されます。

   Implementations MAY recognize other DN string representations.
   However, as there is no requirement that alternative DN string
   representations be recognized (and, if so, how), implementations
   SHOULD only generate DN strings in accordance with Section 2 of this
   document.

実装は他のDNストリング表現を認識するかもしれません。 そして、しかしながら、代替のDNが表現を結ぶという要件が全くないように認識されてください、(そうだとすれば、どのように、)、このドキュメントのセクション2によると、実装SHOULDはDNにストリングを生成するだけであるか。

4.  Examples

4. 例

   This notation is designed to be convenient for common forms of name.
   This section gives a few examples of distinguished names written
   using this notation.  First is a name containing three relative
   distinguished names (RDNs):

この記法は、一般的なフォームの名前に近くなるように設計されています。 このセクションはこの記法を使用することで書かれた分類名に関するいくつかの例を出します。 まず最初に、3つの相対的な分類名(RDNs)を含む名前があります:

      UID=jsmith,DC=example,DC=net

UID=jsmith、DCは例と等しく、DCはネットと等しいです。

   Here is an example of a name containing three RDNs, in which the
   first RDN is multi-valued:

ここに、最初のRDNがマルチ評価されている3RDNsを含んでいて、名前に関する例があります:

      OU=Sales+CN=J.  Smith,DC=example,DC=net

OUは販売+CN=Jと等しいです。 スミス(DC)=例、DC=ネット

   This example shows the method of escaping of a special characters
   appearing in a common name:

この例は一般名における、特殊文字排臨のエスケープのメソッドを示しています:

      CN=James \"Jim\" Smith\, III,DC=example,DC=net

III、CNはジェームス\「ジム\」スミス\と等しく、DCは例と等しく、DCはネットと等しいです。

   The following shows the method for encoding a value that contains a
   carriage return character:

以下は復帰文字を含む値をコード化するためのメソッドを示しています:

      CN=Before%%BODY%%dAfter,DC=example,DC=net

%%BODY%%dAfter、DCの前のCN=は例と等しく、DCはネットと等しいです。

   In this RDN example, the type in the RDN is unrecognized, and the
   value is the BER encoding of an OCTET STRING containing two octets,
   0x48 and 0x69.

このRDNの例では、RDNのタイプは認識されていません、そして、値は2つの八重奏、0×48、および0×69を含むOCTET STRINGのBERコード化です。

Zeilenga                    Standards Track                     [Page 7]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[7ページ]: 分類名2006年6月

      1.3.6.1.4.1.1466.0=#04024869

1.3.6.1.4.1.1466.0=#04024869

   Finally, this example shows an RDN whose commonName value consists of
   5 letters:

最終的に、この例は、だれのcommonName値が5個の手紙から成るかをRDNに示します:

      Unicode Character                Code       UTF-8   Escaped
      -------------------------------  ------     ------  --------
      LATIN CAPITAL LETTER L           U+004C     0x4C    L
      LATIN SMALL LETTER U             U+0075     0x75    u
      LATIN SMALL LETTER C WITH CARON  U+010D     0xC48D  \C4\8D
      LATIN SMALL LETTER I             U+0069     0x69    i
      LATIN SMALL LETTER C WITH ACUTE  U+0107     0xC487  \C4\87

ユニコードキャラクターコードUTF-8は逃げました。------------------------------- ------ ------ -------- LATIN CAPITAL LETTER L U+004C0x4C L LATIN SMALL LETTER U U+0075 0×75u LATIN SMALL LETTER C WITH CARON U+010D 0xC48D\C4円の8D LATIN SMALL LETTER I U+0069 0x69i LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487\C4円87

   This could be encoded in printable ASCII [ASCII] (useful for
   debugging purposes) as:

以下として印刷可能なASCII[ASCII](デバッグ目的の役に立つ)でこれをコード化できました。

      CN=Lu\C4\8Di\C4\87

CNはLu\C4\8Di\C4と87円等しいです。

5.  Security Considerations

5. セキュリティ問題

   The following security considerations are specific to the handling of
   distinguished names.  LDAP security considerations are discussed in
   [RFC4511] and other documents comprising the LDAP Technical
   Specification [RFC4510].

以下のセキュリティ問題は分類名の取り扱いに特定です。 LDAP仕様書[RFC4510]を包括する[RFC4511]と他のドキュメントでLDAPセキュリティ問題について議論します。

5.1.  Disclosure

5.1. 公開

   Distinguished Names typically consist of descriptive information
   about the entries they name, which can be people, organizations,
   devices, or other real-world objects.  This frequently includes some
   of the following kinds of information:

顕著なNamesは彼らが命名するエントリーの描写的である情報から通常成ります。(人々、組織、デバイス、またはエントリーは他の本当の世界オブジェクトであるかもしれません)。 これは頻繁に情報の以下の数種類を含んでいます:

      - the common name of the object (i.e., a person's full name)
      - an email or TCP/IP address
      - its physical location (country, locality, city, street address)
      - organizational attributes (such as department name or
        affiliation)

- オブジェクト(すなわち、人のフルネーム)の一般名--メールかTCP/IPアドレス--物理的な位置(国、場所、都市、住所)--組織的な属性(部の名か提携などの)

   In some cases, such information can be considered sensitive.  In many
   countries, privacy laws exist that prohibit disclosure of certain
   kinds of descriptive information (e.g., email addresses).  Hence,
   server implementers are encouraged to support Directory Information
   Tree (DIT) structural rules and name forms [RFC4512], as these
   provide a mechanism for administrators to select appropriate naming
   attributes for entries.  Administrators are encouraged to use
   mechanisms, access controls, and other administrative controls that
   may be available to restrict use of attributes containing sensitive
   information in naming of entries.   Additionally, use of

いくつかの場合、敏感であるとそのような情報を考えることができます。 多くの国では、ある種類の描写的である情報(例えば、Eメールアドレス)の公開を禁止するプライバシー法が存在しています。 したがって、サーバimplementersが、ディレクトリ情報がTree(DIT)の構造的な規則と名前フォーム[RFC4512]であるとサポートするよう奨励されます、管理者が適切な命名属性をエントリーに選択するようにこれらがメカニズムを提供するとき。 管理者がエントリーの命名における機密情報を含む属性の使用を制限するために利用可能であるかもしれないメカニズム、アクセス制御、および他の運営管理コントロールを使用するよう奨励されます。 さらに、使用

Zeilenga                    Standards Track                     [Page 8]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[8ページ]: 分類名2006年6月

   authentication and data security services in LDAP [RFC4513][RFC4511]
   should be considered.

LDAP[RFC4513][RFC4511]での認証とデータ機密保護サービスは考えられるべきです。

5.2.  Use of Distinguished Names in Security Applications

5.2. セキュリティアプリケーションにおける分類名の使用

   The transformations of an AttributeValue value from its X.501 form to
   an LDAP string representation are not always reversible back to the
   same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules)
   form.  An example of a situation that requires the DER form of a
   distinguished name is the verification of an X.509 certificate.

X.501フォームからLDAPストリング表現までのAttributeValue価値の変換はいつも同じBER(基本的なEncoding Rules)かDER(Encoding Rulesを区別する)フォームにリバーシブルであって戻るというわけではありません。 分類名のDERフォームを必要とする状況に関する例はX.509証明書の検証です。

   For example, a distinguished name consisting of one RDN with one AVA,
   in which the type is commonName and the value is of the TeletexString
   choice with the letters 'Sam', would be represented in LDAP as the
   string <CN=Sam>.  Another distinguished name in which the value is
   still 'Sam', but is of the PrintableString choice, would have the
   same representation <CN=Sam>.

例えば、ストリング<CNがサム>と等しいときに、1AVAと共に1RDNから成る分類名はLDAPに表されるでしょう。そこでは、タイプがcommonNameであり、値は'サム'という手紙によるTeletexString選択のものです。 値がそれでも、'サム'ですが、PrintableString選択のものである別の分類名、同じ表現<CNにサム>と等しくさせるでしょう。

   Applications that require the reconstruction of the DER form of the
   value SHOULD NOT use the string representation of attribute syntaxes
   when converting a distinguished name to the LDAP format.  Instead,
   they SHOULD use the hexadecimal form prefixed by the number sign ('#'
   U+0023) as described in the first paragraph of Section 2.4.

LDAP形式に分類名を変換するとき、値のSHOULD NOTのDER形式の再構成を必要とするアプリケーションが属性構文のストリング表現を使用します。 代わりにそれら、SHOULDはナンバー記号('#'U+0023)によってセクション2.4の第一節で説明されるように前に置かれた16進フォームを使用します。

6.  Acknowledgements

6. 承認

   This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and
   Steve Kille.  RFC 2253 was a product of the IETF ASID Working Group.

このドキュメントはマーク・ウォール、ティム・ハウズ、およびスティーブKilleによるRFC2253への最新版です。 RFC2253はIETF ASID作業部会の製品でした。

   This document is a product of the IETF LDAPBIS Working Group.

このドキュメントはIETF LDAPBIS作業部会の製品です。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [REGISTRY]    IANA, Object Identifier Descriptors Registry,
                 <http://www.iana.org/assignments/ldap-parameters>.

[登録]IANA、オブジェクト識別子記述子登録、<ldap http://www.iana.org/課題/パラメタ>。

   [Unicode]     The Unicode Consortium, "The Unicode Standard, Version
                 3.2.0" is defined by "The Unicode Standard, Version
                 3.0" (Reading, MA, Addison-Wesley, 2000.  ISBN 0-201-
                 61633-5), as amended by the "Unicode Standard Annex
                 #27: Unicode 3.1"
                 (http://www.unicode.org/reports/tr27/) and by the
                 "Unicode Standard Annex #28: Unicode 3.2"
                 (http://www.unicode.org/reports/tr28/).

[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201- 61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 ユニコード3.2インチ( http://www.unicode.org/reports/tr28/ )。

Zeilenga                    Standards Track                     [Page 9]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[9ページ]: 分類名2006年6月

   [X.501]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "The
                 Directory -- Models," X.501(1993) (also ISO/IEC 9594-
                 2:1994).

[X.501]国際電気通信連合--電気通信標準化セクター、「ディレクトリ--、モデル、」、X.501(1993)(ISO/IEC9594- 2も: 1994)。

   [X.680]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "Abstract
                 Syntax Notation One (ASN.1) - Specification of Basic
                 Notation", X.680(1997) (also ISO/IEC 8824-1:1998).

[X.680]国際電気通信連合--電気通信標準化セクター、「構文記法1(ASN.1)を抜き取ってください--基本的な記法の仕様」、X.680(1997)(ISO/IEC8824-1も: 1998)。

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

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC3629]     Yergeau, F., "UTF-8, a transformation format of ISO
                 10646", STD 63, RFC 3629, November 2003.

[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日

   [RFC4234]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
                 Specifications: ABNF", RFC 4234, October 2005.

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

   [RFC4510]     Zeilenga, K., Ed., "Lightweight Directory Access
                 Protocol (LDAP): Technical Specification Road Map", RFC
                 4510, June 2006.

[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。

   [RFC4511]     Sermersheim, J., Ed., "Lightweight Directory Access
                 Protocol (LDAP): The Protocol", RFC 4511, June 2006.

[RFC4511] Sermersheim、J.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「プロトコル」、RFC4511、2006年6月。

   [RFC4512]     Zeilenga, K., "Lightweight Directory Access Protocol
                 (LDAP): Directory Information Models", RFC 4512, June
                 2006.

[RFC4512] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「ディレクトリ情報モデル」、RFC4512、2006年6月。

   [RFC4513]     Harrison, R., Ed., "Lightweight Directory Access
                 Protocol (LDAP): Authentication Methods and Security
                 Mechanisms", RFC 4513, June 2006.

[RFC4513] ハリソン、R.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日

   [RFC4517]     Legg, S., Ed., "Lightweight Directory Access Protocol
                 (LDAP): Syntaxes and Matching Rules", RFC 4517, June
                 2006.

[RFC4517] Legg、S.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「構文とマッチングは統治する」RFC4517、2006年6月。

   [RFC4519]     Sciberras, A., Ed., "Lightweight Directory Access
                 Protocol (LDAP): Schema for User Applications", RFC
                 4519, June 2006.

[RFC4519] Sciberras、A.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「ユーザアプリケーションのための図式」、RFC4519、2006年6月。

   [RFC4520]     Zeilenga, K., "Internet Assigned Numbers Authority
                 (IANA) Considerations for the Lightweight Directory
                 Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.

[RFC4520]Zeilenga、K.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC4520、2006年6月。

Zeilenga                    Standards Track                    [Page 10]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[10ページ]: 分類名2006年6月

7.2.  Informative References

7.2. 有益な参照

   [ASCII]       Coded Character Set--7-bit American Standard Code for
                 Information Interchange, ANSI X3.4-1986.

[ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。

   [CharModel]   Whistler, K. and M. Davis, "Unicode Technical Report
                 #17, Character Encoding Model", UTR17,
                 <http://www.unicode.org/unicode/reports/tr17/>, August
                 2000.

[CharModel] ウィスラーとK.とM.デイヴィス、「ユニコード技術報告書#17、文字符号化モデル」、UTR17、<は://www.unicode.org/unicode/reports/tr17/>をhttpして、8月は2000です。

   [Glossary]    The Unicode Consortium, "Unicode Glossary",
                 <http://www.unicode.org/glossary/>.

[用語集] ユニコード共同体、「ユニコード用語集」、<http://www.unicode.org/glossary/>。

   [X.500]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "The
                 Directory -- Overview of concepts, models and
                 services," X.500(1993) (also ISO/IEC 9594-1:1994).

[X.500]国際電気通信連合--電気通信Standardization Sector、「ディレクトリ--、概念の、そして、モデルの、そして、サービスの概要、」、X.500(1993)(ISO/IEC9594-1も: 1994)。

   [X.511]       International Telecommunication Union -
                 Telecommunication Standardization Sector, "The
                 Directory: Abstract Service Definition", X.511(1993)
                 (also ISO/IEC 9594-3:1993).

[X.511]国際電気通信連合--電気通信標準化セクター、「ディレクトリ:」 「抽象的なサービス定義」、X.511(1993)(ISO/IEC9594-3も: 1993)。

   [X.690]       International Telecommunication Union -
                 Telecommunication Standardization Sector,
                 "Specification of ASN.1 encoding rules: Basic Encoding
                 Rules (BER), Canonical Encoding Rules (CER), and
                 Distinguished Encoding Rules (DER)", X.690(1997) (also
                 ISO/IEC 8825-1:1998).

[X.690]国際電気通信連合--電気通信Standardization Sector、「ASN.1コード化の仕様は統治します」。 「規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)をコード化する基礎」、X.690(1997)(ISO/IEC8825-1も: 1998)。

   [RFC2849]     Good, G., "The LDAP Data Interchange Format (LDIF) -
                 Technical Specification", RFC 2849, June 2000.

[RFC2849] いいぞ、G.、「LDAPデータは形式(LDIF)を交換します--技術的な仕様」、RFC2849、6月2000日

Zeilenga                    Standards Track                    [Page 11]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[11ページ]: 分類名2006年6月

Appendix A.  Presentation Issues

付録A.プレゼンテーション問題

   This appendix is provided for informational purposes only; it is not
   a normative part of this specification.

この付録を情報の目的だけに提供します。 それはこの仕様の標準の部分ではありません。

   The string representation described in this document is not intended
   to be presented to humans without translation.  However, at times it
   may be desirable to present non-translated DN strings to users.  This
   section discusses presentation issues associated with non-translated
   DN strings.  Issues with presentation of translated DN strings are
   not discussed in this appendix.  Transcoding issues are also not
   discussed in this appendix.

本書では説明されたストリング表現によって翻訳なしで人間に提示されることを意図しません。 しかしながら、時には、非翻訳されたDNストリングをユーザに贈るのは望ましいかもしれません。 このセクションは非翻訳されたDNストリングに関連しているプレゼンテーション問題について論じます。 この付録で翻訳されたDNストリングのプレゼンテーションの問題について議論しません。 また、この付録でコード変換問題について議論しません。

   This appendix provides guidance for applications presenting DN
   strings to users.  This section is not comprehensive; it does not
   discuss all presentation issues that implementers may face.

この付録はストリングをDNに贈るアプリケーションのための指導をユーザに提供します。 このセクションは包括的ではありません。 それはimplementersが直面するかもしれないすべてのプレゼンテーション問題について議論しません。

   Not all user interfaces are capable of displaying the full set of
   Unicode characters.  Some Unicode characters are not displayable.

すべてのユーザインタフェースがどんなユニコード文字のフルセットを表示できるというわけではありません。 「ディスプレイ-可能」でないユニコード文字もいます。

   It is recommended that human interfaces use the optional hex pair
   escaping mechanism (Section 2.3) to produce a string representation
   suitable for display to the user.  For example, an application can
   generate a DN string for display that escapes all non-printable
   characters appearing in the AttributeValue's string representation
   (as demonstrated in the final example of Section 4).

ヒューマンインターフェースがユーザにとって、表示に適したストリング表現を作成するのに、任意の十六進法組エスケープメカニズム(セクション2.3)を使用するのは、お勧めです。 例えば、アプリケーションはAttributeValueのストリング表現に現れるすべての非印刷可能なキャラクタから逃げる表示のためにDNストリングを発生させることができます(セクション4の最終的な例に示されるように)。

   When a DN string is displayed in free-form text, it is often
   necessary to distinguish the DN string from surrounding text.  While
   this is often done with whitespace (as demonstrated in Section 4), it
   is noted that DN strings may end with whitespace.  Careful readers of
   Section 3 will note that the characters '<' (U+003C) and '>' (U+003E)
   may only appear in the DN string if escaped.  These characters are
   intended to be used in free-form text to distinguish a DN string from
   surrounding text.  For example, <CN=Sam\ > distinguishes the string
   representation of the DN composed of one RDN consisting of the AVA
   (the commonName (CN) value 'Sam ') from the surrounding text.  It
   should be noted to the user that the wrapping '<' and '>' characters
   are not part of the DN string.

自由形式テキストにDNストリングを表示するとき、周囲のテキストとDNストリングを区別するのがしばしば必要です。 しばしば空白でこれをしますが(セクション4に示されるように)、DNストリングが空白で終わるかもしれないことに注意します。 セクション3の慎重な読者は、逃げられる場合にだけキャラクタの'<'(U+003C)と'>'(U+003E)がDNストリングに現れるかもしれないことに注意するでしょう。 周囲のテキストとDNストリングを区別するのに自由形式テキストでこれらのキャラクタが使用されることを意図します。 例えば、サム<CN=\>は周囲のテキストからAVA(commonName(CN)価値の'サム')から成る1RDNで構成されたDNのストリング表現を区別します。 ラッピング'<'と'>'キャラクタがDNストリングの一部でないことにユーザに注意されるべきです。

   DN strings can be quite long.  It is often desirable to line-wrap
   overly long DN strings in presentations.  Line wrapping should be
   done by inserting whitespace after the RDN separator character or, if
   necessary, after the AVA separator character.  It should be noted to
   the user that the inserted whitespace is not part of the DN string
   and is to be removed before use in LDAP.  For example, the following
   DN string is long:

DNストリングはかなり長い場合があります。 それはしばしばひどく長いDNがプレゼンテーションで結ぶ線包装に望ましいです。 RDN分離符キャラクタの後か必要ならAVA分離符キャラクタの後に空白を挿入することによって、線ラッピングをするべきです。 挿入された空白がDNストリングの一部でなく、LDAPにおける使用の前に取り除かれることになっていることにユーザに注意されるべきです。 例えば、以下のDNストリングは長いです:

Zeilenga                    Standards Track                    [Page 12]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[12ページ]: 分類名2006年6月

         CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
         O=OpenLDAP Foundation,ST=California,C=US

=第カリフォルニア、CNはカートD.Zeilengaと等しく、OUは工学と等しく、Lはアカスギ岸、O=OpenLDAP財団と等しく、Cは米国と等しいです。

   So it has been line-wrapped for readability.  The extra whitespace is
   to be removed before the DN string is used in LDAP.

それで、それは読み易さのために線によって包装されています。 DNストリングがLDAPで使用される前に余分な空白は取り除かれることになっています。

   Inserting whitespace is not advised because it may not be obvious to
   the user which whitespace is part of the DN string and which
   whitespace was added for readability.

それの空白がDNストリングの一部とどの空白が読み易さのために加えられたかということであるユーザには、それが明白でないかもしれないので、空白を挿入するのはアドバイスされません。

   Another alternative is to use the LDAP Data Interchange Format (LDIF)
   [RFC2849].  For example:

別の代替手段はLDAP Data Interchange Format(LDIF)[RFC2849]を使用することです。 例えば:

         # This entry has a long DN...
         dn: CN=Kurt D.  Zeilenga,OU=Engineering,L=Redwood Shores,
          O=OpenLDAP Foundation,ST=California,C=US
         CN: Kurt D.  Zeilenga
         SN: Zeilenga
         objectClass: person

# このエントリーには、長いDN…dnがあります: =C=カリフォルニア(米国)第CN、CNはカートD.Zeilengaと等しく、OUは工学と等しく、Lはアカスギ岸、O=OpenLDAP財団と等しいです: カートD.Zeilenga SN: Zeilenga objectClass: 人

Appendix B.  Changes Made since RFC 2253

付録B.変化は以来、RFCを2253にしました。

   This appendix is provided for informational purposes only, it is not
   a normative part of this specification.

この付録はそれが情報の目的だけのための、この仕様の標準の部分でないかどうかということです。

   The following substantive changes were made to RFC 2253:

以下の実質的な変更をRFC2253にしました:

      - Removed IESG Note.  The IESG Note has been addressed.
      - Replaced all references to ISO 10646-1 with [Unicode].
      - Clarified (in Section 1) that this document does not define a
        canonical string representation.
      - Clarified that Section 2 describes the RECOMMENDED encoding
        algorithm and that alternative algorithms are allowed.  Some
        encoding options described in RFC 2253 are now treated as
        alternative algorithms in this specification.
      - Revised specification (in Section 2) to allow short names of any
        registered attribute type to appear in string representations of
        DNs instead of being restricted to a "published table".  Removed
        "as an example" language.  Added statement (in Section 3)
        allowing recognition of additional names but require recognition
        of those names in the published table.  The table now appears in
        Section 3.
      - Removed specification of additional requirements for LDAPv2
        implementations which also support LDAPv3 (RFC 2253, Section 4)
        as LDAPv2 is now Historic.
      - Allowed recognition of alternative string representations.
      - Updated Section 2.4 to allow hex pair escaping of all characters
        and clarified escaping for when multiple octet UTF-8 encodings

- IESG注意を取り除きました。 IESG Noteは記述されました。 - ISO10646-1のすべての参照を[ユニコード]に取り替えました。 - はっきりさせられて(セクション1で)、それは正準なストリング表現を定義しませんこれが、ドキュメントである。 - アルゴリズムをコード化するRECOMMENDEDが説明して、代替のアルゴリズムが許容されているそのセクション2をはっきりさせました。 RFC2253で説明されたいくつかのコード化オプションが現在、この仕様で代替のアルゴリズムとして扱われます。 - いずれの省略名を許容する訂正明細書(セクション2における)は、「発行されたテーブル」に制限されることの代わりにDNsのストリング表現に現れるように属性タイプを示しました。 「例」言語を取り除きました。 発行されたテーブルでのそれらの名前の認識を必要とするのを除いて、追加することの認識が命名する加えられた声明(セクション3における)許容。 テーブルは今、セクション3に現れます。 - 現在、また、LDAPv2としてLDAPv3(RFC2253、セクション4)を支持するLDAPv2実現のための追加要件の取り除かれた仕様はHistoricです。 - 代替のストリング表現の認識を許しました。 - アップデートされたセクション2.4 複数の八重奏UTF-8 encodingsであるときに、すべてのキャラクタに逃げる十六進法組とはっきりさせられたエスケープを許すために

Zeilenga                    Standards Track                    [Page 13]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[13ページ]: 分類名2006年6月

        are present.  Indicated that null (U+0000) character is to be
        escaped.  Indicated that equals sign ('=' U+003D) character may
        be escaped as '\='.
      - Rewrote Section 3 to use ABNF as defined in RFC 4234.
      - Updated the Section 3 ABNF.  Changes include:
        + allowed AttributeType short names of length 1 (e.g., 'L'),
        + used more restrictive <oid> production in AttributeTypes,
        + did not require escaping of equals sign ('=' U+003D)
          characters,
        + did not require escaping of non-leading number sign ('#'
          U+0023) characters,
        + allowed space (' ' U+0020) to be escaped as '\ ',
        + required hex escaping of null (U+0000) characters, and
        + removed LDAPv2-only constructs.
      - Updated Section 3 to describe how to parse elements of the
        grammar.
      - Rewrote examples.
      - Added reference to documentations containing general LDAP
        security considerations.
      - Added discussion of presentation issues (Appendix A).
      - Added this appendix.

プレゼント。 ヌル(U+0000)のキャラクタ逃げられることになっているのを示しました。 '等号(U+003Dと'等しい')キャラクタ'\=として逃げられるかもしれないのを示します'だった。 - RFC4234で定義されるようにABNFを使用するためにセクション3を書き直しました。 - セクション3ABNFをアップデートしました。 変化は: + 長さ1(例えば、'L')の許容AttributeType省略名、+ AttributeTypesでの中古の、より制限している<oid>生産、+が等号(U+003Dと'等しい')キャラクタに逃げるのを必要としないで、+が、非主なナンバー記号('#'U+0023)キャラクタに逃げるのを必要としないで、+が+ '\'として逃げられるべき(''U+0020)、ヌル(U+0000)のキャラクタの必要な十六進法エスケープをスペースに許して、+ 取り外されたLDAPv2だけに構造物を許容した、' - その方法を説明するアップデートされたセクション3は文法の原理を分析します。. --例を書き直しました。 - 一般的なLDAPセキュリティ問題を含む文書化の参照を加えました。 - プレゼンテーションの加えられた議論は(付録A)を発行します。 - この付録を加えました。

   In addition, numerous editorial changes were made.

さらに、多数の編集の変更は行われました。

Editor's Address

エディタのアドレス

   Kurt D.  Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Zeilenga                    Standards Track                    [Page 14]

RFC 4514               LDAP: Distinguished Names               June 2006

Zeilenga規格はRFC4514LDAPを追跡します[14ページ]: 分類名2006年6月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Zeilenga                    Standards Track                    [Page 15]

Zeilenga標準化過程[15ページ]