[要約] RFC 4514は、LDAPで使用される識別名（Distinguished Name）の文字列表現に関する仕様です。このRFCの目的は、LDAPクライアントとサーバー間での識別名の一貫性を確保し、ディレクトリデータの正確な参照を可能にすることです。
Network Working Group K. Zeilenga, Ed.
Request for Comments: 4514 OpenLDAP Foundation
Obsoletes: 2253 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names
LightWeight Directory Access Protocol（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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）を使用します。このドキュメントでは、LightWeight Directory Access Protocol（LDAP）で使用される文字列表現を定義して、識別名を転送します。文字列表現は、一般的に使用される著名な名前のきれいな表現を提供するように設計されており、著名な名前を表すことができます。
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].
X.500ベースのディレクトリシステム[X.500]では、LightWeight Directory Access Protocol（LDAP）[RFC4510]を使用してアクセスしたものを含む、著名な名前（DNS）を使用して、ディレクトリエントリ[X.501] [RFC45122]。
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ディレクトリアクセスプロトコル[X.511]（およびその他のITU定義ディレクトリプロトコル）では、DNSは基本エンコードルール（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 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).
著名な名前を明確に表すことができるようにするために、共通の形式を持つことが重要です。この仕様の主な目標は、エンコードとデコードの容易さです。二次的な目標は、人間が読みやすい名前を持つことです。Humanユーザーインターフェイスを使用したLDAP実装は、これらの文字列をユーザーに直接表示することは予想されませんが、翻訳を実行する可能性が高い（現地の国語で属性タイプ名を表現するなど）。
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]で使用される著名な名前の文字列表現を定義します。セクション2では、DNをそのasn.1構造表現から文字列に変換するための推奨されるアルゴリズムを詳しく説明しています。セクション3では、dnを文字列からasn.1構造化表現に変換する方法を詳しく説明しています。
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.
他のドキュメントでは、DNをそのasn.1構造表現から文字列に変換するための他のアルゴリズムを定義する場合がありますが、すべてのアルゴリズムはセクション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技術仕様であるRFC 3377全体を廃止します。このドキュメントはRFC2253を廃止します。RFC2253以降の変更は付録Bにまとめられています。
This specification assumes familiarity with X.500 [X.500] and the concept of Distinguished Name [X.501][RFC4512].
この仕様は、x.500 [x.500]と著名な名前[x.501] [RFC4512]の概念に精通していることを想定しています。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14 [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>.
このドキュメントの文字名は、Unicode標準[Unicode]のコードポイントと名前の表記を使用します。たとえば、文字「a」は<u 0061>または<ラテンの小さな文字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].
注：Unicodeで使用される用語の用語集は、[用語集]で見つけることができます。Unicode文字エンコードモデルに関する情報は、[Charmodel]に記載されています。
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
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value 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]エンコードされたUnicode [Unicode]文字文字列表現に変換するための推奨されるアルゴリズムを定義します。他のドキュメントは、著名な名前を文字列に変換するための他のアルゴリズムを説明する場合がありますが、セクション3で定義されている文法に準拠する文字列のみがLDAP実装によって生成されるものとします。
If the RDNSequence is an empty sequence, the result is the empty or zero-length string.
RDNシーケンスが空のシーケンスである場合、結果は空またはゼロの長さの文字列になります。
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.
それ以外の場合、出力は、RDNシーケンス（セクション2.2に従って）の各relativedistishishedNameの文字列エンコーディングで構成され、シーケンスの最後の要素から始まり、最初に向かって後方に移動します。
The encodings of adjoining RelativeDistinguishedNames are separated by a comma (',' U+002C) character.
隣接する相対論的なもののエンコーディングは、コンマ（ '、' u 002c）文字によって分離されます。
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.1 relativedistinguishednameから文字列に変換する場合、出力は、任意の順序で、各属性のvalue（セクション2.3による）の文字列エンコーディングで構成されます。
Where there is a multi-valued RDN, the outputs from adjoining AttributeTypeAndValues are separated by a plus sign ('+' U+002B) character.
多値のRDNがある場合、隣接する属性の類似値からの出力は、プラス記号（ '' u 002b）文字で分離されます。
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.
AttributETypEandValueは、属性の文字列表現としてエンコードされ、その後に等しい記号（ '=' u 003d）文字が続き、その後に属性の文字列表現が続きます。属性のエンコードは、セクション2.4に記載されています。
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].
属性が短い名前（記述子）[RFC4512]を持つように定義され、その短い名前が登録されていることが知られている場合[レジストリ] [RFC4520]属性の識別として、その短い名前<descr>が使用されます。それ以外の場合、属性は、そのオブジェクト識別子の点線エンコード、<umericoiod>としてエンコードされます。<descr>および<numericoiod>は[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.
実装は、登録された短編名に関する知識を動的に更新することは期待されていません。ただし、実装は、登録された短い名前の知識を更新できるメカニズムを提供する必要があります。
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).
属性が点線の形式である場合、属性はX.500属性属性のBERエンコードの各オクテットの16進コード化された数字符号（ '＃' U 0023）文字で表されます。この形式は、属性の構文に、それを定義されたLDAP固有（[RFC4517]、セクション3.1）エンコードエンコードを持たない場合、またはLDAP固有の文字列エンコードがUTF-8エンコードユニコード文字に制限されていない場合にも使用されます。。このフォームは、可逆的な文字列表現が望まれる場合など、他のケースでも使用できます（セクション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.
それ以外の場合、属性がLDAP固有の文字列エンコードを持つ構文である場合、値は最初にUTF-8エンコードされたユニコード文字列に変換されます（例[RFC4517]、セクション3.3を参照）。そのUTF-8エンコードされたUnicode文字列には、逃げる必要がある次の文字がない場合、その文字列は値の文字列表現として使用できます。
- 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）文字。
- 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.
- null（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ヘクスの数字に置き換えられ、キャラクターのコードに単一のオクテットを形成します。あるいは、逃げるキャラクターが
' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
U+003C, U+003D, U+003E, U+005C, respectively)
it can be prefixed by a backslash ('\' U+005C).
バックスラッシュ（ '\' u 005c）でプレフィックスできます。
Examples of the escaping mechanism are shown in Section 4.
脱出メカニズムの例をセクション4に示します。
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:
著名な名前の文字列表現は、UTF-8 [RFC3629]エンコードされたUnicode [Unicode]文字に制限されています。この文字列表現の構造は、次の拡張BNF [RFC4234]文法を使用して指定されています。
distinguishedName = [ relativeDistinguishedName
*( COMMA relativeDistinguishedName ) ]
relativeDistinguishedName = attributeTypeAndValue
*( PLUS attributeTypeAndValue )
attributeTypeAndValue = attributeType EQUALS attributeValue
attributeType = descr / numericoid
attributeValue = string / 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 ) ] ]
leadchar = LUTF1 / UTFMB
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
trailchar = TUTF1 / UTFMB
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
%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
pair = ESC ( ESC / special / hexpair )
special = escaped / SPACE / SHARP / EQUALS
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
hexstring = SHARP 1*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>、<numericoiod>、<comma>、<dquote>、<equals>、<esc>、<hex>、<langle>、<null>、<plus>、<plangle>、<symi>、<space>、<sharp>、および<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.
<descr>または<numericoiod>のいずれかの各<属性型>は、属性値アサーション（AVA）の属性タイプを指します。<AttributeType>の後に<Equals>および<AttributeValue>が続きます。<AttributeValue>は<string>または<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:
<string>形式では、次のように<string>に表示される各<ペア>を置き換えることで（左から右、非回復的に）、LDAP文字列表現値を取得できます。
replace <ESC><ESC> with <ESC>; replace <ESC><special> with <special>; replace <ESC><hexpair> with the octet indicated by the <hexpair>.
<ESC> <ESC>を<ESC>に置き換えます。<sisc> <special>を<special>に置き換えます。<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.
相対的な著名な名前に対して、<plus>で区切られた1つ以上の属性値アサーションがあります。
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.
実装は、次の表にリストされている属性名の名前（記述子）を認識する必要がありますが、他の名前の文字列を認識する場合があります。
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)
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に従ってDN文字列のみを生成する必要があります。
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):
この表記は、一般的な形式の名前に便利になるように設計されています。このセクションでは、この表記法を使用して書かれた著名な名前のいくつかの例を示します。1つ目は、3つの相対的な著名な名前（RDN）を含む名前です。
UID=jsmith,DC=example,DC=net
Here is an example of a name containing three RDNs, in which the first RDN is multi-valued:
以下は、3つのRDNを含む名前の例です。最初のRDNは多値です。
OU=Sales+CN=J. Smith,DC=example,DC=net
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
The following shows the method for encoding a value that contains a carriage return character:
以下は、キャリッジリターン文字を含む値をエンコードする方法を示しています。
CN=Before\0dAfter,DC=example,DC=net
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オクテット、0x48および0x69を含むオクテット文字列のBERエンコードです。
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:
最後に、この例は、共通の値が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
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
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セキュリティの考慮事項は、[RFC4511]およびLDAP技術仕様[RFC4510]を含む他のドキュメントで説明されています。
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:
際立った名前は通常、名前が付けられたエントリに関する説明的な情報で構成されています。これは、人、組織、デバイス、またはその他の現実世界のオブジェクトです。これには、次の種類の情報の一部が頻繁に含まれます。
- 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 authentication and data security services in LDAP [RFC4513][RFC4511] should be considered.
場合によっては、そのような情報は敏感であると見なすことができます。多くの国では、特定の種類の記述情報の開示を禁止するプライバシー法が存在します（たとえば、電子メールアドレス）。したがって、サーバーの実装者は、ディレクトリ情報ツリー（DIT）構造ルールと名前フォーム[RFC4512]をサポートすることをお勧めします。管理者は、エントリの命名に機密情報を含む属性の使用を制限するために利用可能なメカニズム、アクセス制御、およびその他の管理コントロールを使用することをお勧めします。さらに、LDAP [RFC4513] [RFC4511]での認証およびデータセキュリティサービスの使用を考慮する必要があります。
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文字列の表現への属性値の変換は、常に同じBER（基本エンコードルール）またはDER（際立ったエンコードルール）フォームに戻るとは限りません。著名な名前の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>.
たとえば、1つのAVAを含む1つのRDNで構成される著名な名前。このタイプは一般的なものであり、値は文字「SAM」を使用したテレットストリングの選択肢であり、LDAPで文字列<cn = sam>として表されます。値がまだ「sam」であるが、印刷する選択肢である別の著名な名前は、同じ表現<cn = sam>を持っています。
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.
値のDER形式の再構成を必要とするアプリケーションは、識別名をLDAP形式に変換するときに、属性構文の文字列表現を使用しないでください。代わりに、セクション2.4の最初の段落に記載されているように、数字記号（ '＃' u 0023）が付けた16進形式を使用する必要があります。
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.
このドキュメントは、RFC 2253の更新、Mark Wahl、Tim Howes、Steve Killeの更新です。RFC 2253は、IETF ASIDワーキンググループの製品でした。
This document is a product of the IETF LDAPBIS Working Group.
このドキュメントは、IETF LDAPBISワーキンググループの製品です。
[REGISTRY] IANA, Object Identifier Descriptors Registry, <http://www.iana.org/assignments/ldap-parameters>.
[レジストリ] IANA、オブジェクト識別子記述子レジストリ、<http://www.iana.org/assignments/ldap-parameters>。
[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/).
[Unicode] Unicodeコンソーシアム「Unicode Standard、バージョン3.2.0」は、「Unicode Standard、バージョン3.0」（Reading、MA、Addison-Wesley、2000。ISBN0-201- 61633-5）で定義されています。「Unicode Standard Annex＃27：Unicode 3.1」（http://www.unicode.org/reports/tr27/）および「Unicode Standard Annex＃28：Unicode 3.2」（http：//www.unicode.org/Reports/TR28/）。
[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/IEC 9594- 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/IEC 8824-1：1998）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K。、ed。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、ed。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：ディレクトリ情報モデル」、RFC 4512、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513] Harrison、R.、ed。、「Lightweight Directory Access Protocol（LDAP）：認証方法とセキュリティメカニズム」、RFC 4513、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517] Legg、S.、ed。、「Lightweight Directory Access Protocol（LDAP）：構文と一致するルール」、RFC 4517、2006年6月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A.、ed。、「Lightweight Directory Access Protocol（LDAP）：ユーザーアプリケーションのスキーマ」、RFC 4519、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。、「Internet Assigned Numbers Authority（IANA）Lightweight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 4520、2006年6月。
[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] Whistler、K。and M. Davis、「Unicode Technical Report＃17、Character Encoding Model」、utr17、<http://www.unicode.org/unicode/reports/tr17/>、2000年8月。
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[用語集] Unicode Consortium、「Unicode 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]国際電気通信連合 - 通信標準化セクター、「ディレクトリ - 概念、モデル、サービスの概要」X.500（1993）（また、ISO/IEC 9594-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/IEC 9594-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]国際電気通信連合 - 通信標準化セクター、「ASN.1エンコーディングルールの仕様：基本エンコーディングルール（BER）、標準エンコードルール（CER）、および区別されたエンコードルール（DER）」、X.690（1997）（ISO/IEC 8825-1：1998）。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[RFC2849] Good、G。、「LDAPデータインターチェンジ形式（LDIF） - 技術仕様」、RFC 2849、2000年6月。
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文字列を提示するアプリケーションのガイダンスを提供します。このセクションは包括的ではありません。実装者が直面する可能性のあるすべてのプレゼンテーションの問題については議論していません。
Not all user interfaces are capable of displaying the full set of Unicode characters. Some Unicode characters are not displayable.
すべてのユーザーインターフェイスがUnicode文字の完全なセットを表示できるわけではありません。一部のユニコード文字は表示できません。
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）を使用して、ユーザーへの表示に適した文字列表現を作成することをお勧めします。たとえば、アプリケーションは、Atributevalueの文字列表現に表示されるすべての印刷不可能な文字をエスケープするディスプレイ用の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 = sam \>は、AVA（commonName（cn）値 'sam'）で構成される1つのRDNで構成されるDNの文字列表現を、周囲のテキストから区別します。lapping '<'および '>'文字は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文字列は長いです。
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
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.
Whitespaceを挿入することは、ユーザーにDN文字列の一部であり、読みやすさのためにどのWhitespaceが追加されたかは明らかではない可能性があるため、お勧めしません。
Another alternative is to use the LDAP Data Interchange Format (LDIF) [RFC2849]. For example:
もう1つの選択肢は、LDAPデータインターチェンジ形式（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
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:
次の実質的な変更がRFC 2253に対して行われました。
- 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 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.
- IESGノートを削除しました。IESGノートに対処されています。-ISO 10646-1へのすべての参照を[Unicode]に置き換えました。 - （セクション1で）このドキュメントは、標準文字列の表現を定義していないことを明確にしました。 - セクション2では、推奨されるエンコードアルゴリズムについて説明し、代替アルゴリズムが許可されていることを明確にしました。RFC 2253で説明されているいくつかのエンコードオプションは、この仕様の代替アルゴリズムとして扱われています。 - 「公開されたテーブル」に制限されるのではなく、登録済み属性タイプの短い名前がDNSの文字列表現に表示されるようにするために、修正された仕様（セクション2）。「例として」言語を削除しました。追加の名前の認識を許可するが、公開されたテーブル内のそれらの名前の認識が必要である（セクション3に）追加されたステートメントが追加されました。テーブルはセクション3に表示されます。 -LDAPV2が現在歴史的であるため、LDAPV3（RFC 2253、セクション4）もサポートするLDAPV2実装の追加要件の仕様を削除しました。 - 代替文字列表現の認識が許可されています。 - セクション2.4を更新して、すべてのキャラクターを脱出し、複数のOctet UTF-8エンコーディングが存在する場合の脱出を明確にすることを許可します。null（u 0000）文字が逃げることを示しました。Equals Sign（ '=' U 003D）文字が「\ =」として逃げられる可能性があることを示しています。-RFC4234で定義されているようにABNFを使用するようにセクション3を書き直しました。-セクション3 ABNFを更新しました。変更には、許可された属性の長さ1（例： 'l'）の短い名前（ 'l'）、より制限的な<oid>生産を属性に使用し、等しい記号（ '=' u 003d）文字の脱出を必要としませんでした。-Leading Number Sign（ '＃' U 0023）文字、スペース（ '' u 0020）を「\」として脱出することを許可し、null（u 0000）文字を脱出する必要があり、LDAPV2のみのコンストラクトを削除しました。 - 文法の要素を解析する方法について説明するセクション3を更新しました。 - 例を書き直します。 - 一般的なLDAPセキュリティに関する考慮事項を含むドキュメントへの参照を追加しました。 - プレゼンテーションの問題に関する議論が追加されました（付録A）。 - この付録を追加しました。
In addition, numerous editorial changes were made.
さらに、多数の編集上の変更が行われました。
Editor's Address
編集者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
Kurt D. Zeilenga OpenLdap Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。