Network Working Group S. Legg, Ed.
Request for Comments: 4517 eB2Bcom
Obsoletes: 2252, 2256 June 2006
Updates: 3698
Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules
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).
著作権（C）インターネット協会（2006）。
Abstract
抽象
Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory, whose values may be transferred in the LDAP protocol, has a defined syntax that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories.
その値はLDAPプロトコルで転送することができるLDAP（Lightweight Directory Access Protocol）ディレクトリに格納された各属性は、その値の構造およびフォーマットを制約定義された構文を有します。構文の値について比較セマンティクスは、構文定義の一部ではなく、代わりに別々に定義されたマッチングルールを介して提供されます。マッチングルールも定義された構文を持っている引数、アサーション値を指定します。このドキュメントでは、LDAPディレクトリの属性を定義する際に使用するための構文と一致ルールの基本セットを定義します。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions .....................................................4
3. Syntaxes ........................................................4
3.1. General Considerations .....................................5
3.2. Common Definitions .........................................5
3.3. Syntax Definitions .........................................6
3.3.1. Attribute Type Description ..........................6
3.3.2. Bit String ..........................................6
3.3.3. Boolean .............................................7
3.3.4. Country String ......................................7
3.3.5. Delivery Method .....................................8
3.3.6. Directory String ....................................8
3.3.7. DIT Content Rule Description ........................9
3.3.8. DIT Structure Rule Description .....................10
3.3.9. DN .................................................10
3.3.10. Enhanced Guide ....................................11
3.3.11. Facsimile Telephone Number ........................12
3.3.12. Fax ...............................................12
3.3.13. Generalized Time ..................................13
3.3.14. Guide .............................................14
3.3.15. IA5 String ........................................15
3.3.16. Integer ...........................................15
3.3.17. JPEG ..............................................15
3.3.18. LDAP Syntax Description ...........................16
3.3.19. Matching Rule Description .........................16
3.3.20. Matching Rule Use Description .....................17
3.3.21. Name and Optional UID .............................17
3.3.22. Name Form Description .............................18
3.3.23. Numeric String ....................................18
3.3.24. Object Class Description ..........................18
3.3.25. Octet String ......................................19
3.3.26. OID ...............................................19
3.3.27. Other Mailbox .....................................20
3.3.28. Postal Address ....................................20
3.3.29. Printable String ..................................21
3.3.30. Substring Assertion ...............................22
3.3.31. Telephone Number ..................................23
3.3.32. Teletex Terminal Identifier .......................23
3.3.33. Telex Number ......................................24
3.3.34. UTC Time ..........................................24
4. Matching Rules .................................................25
4.1. General Considerations ....................................25
4.2. Matching Rule Definitions .................................27
4.2.1. bitStringMatch .....................................27
4.2.2. booleanMatch .......................................28
4.2.3. caseExactIA5Match ..................................28
4.2.4. caseExactMatch .....................................29
4.2.5. caseExactOrderingMatch .............................29
4.2.6. caseExactSubstringsMatch ...........................30
4.2.7. caseIgnoreIA5Match .................................30
4.2.8. caseIgnoreIA5SubstringsMatch .......................31
4.2.9. caseIgnoreListMatch ................................31
4.2.10. caseIgnoreListSubstringsMatch .....................32
4.2.11. caseIgnoreMatch ...................................33
4.2.12. caseIgnoreOrderingMatch ...........................33
4.2.13. caseIgnoreSubstringsMatch .........................34
4.2.14. directoryStringFirstComponentMatch ................34
4.2.15. distinguishedNameMatch ............................35
4.2.16. generalizedTimeMatch ..............................36
4.2.17. generalizedTimeOrderingMatch ......................36
4.2.18. integerFirstComponentMatch ........................36
4.2.19. integerMatch ......................................37
4.2.20. integerOrderingMatch ..............................37
4.2.21. keywordMatch ......................................38
4.2.22. numericStringMatch ................................38
4.2.23. numericStringOrderingMatch ........................39
4.2.24. numericStringSubstringsMatch ......................39
4.2.25. objectIdentifierFirstComponentMatch ...............40
4.2.26. objectIdentifierMatch .............................40
4.2.27. octetStringMatch ..................................41
4.2.28. octetStringOrderingMatch ..........................41
4.2.29. telephoneNumberMatch ..............................42
4.2.30. telephoneNumberSubstringsMatch ....................42
4.2.31. uniqueMemberMatch .................................43
4.2.32. wordMatch .........................................44
5. Security Considerations ........................................44
6. Acknowledgements ...............................................44
7. IANA Considerations ............................................45
8. References .....................................................46
8.1. Normative References ......................................46
8.2. Informative References ....................................48
Appendix A. Summary of Syntax Object Identifiers ..................49
Appendix B. Changes from RFC 2252 .................................49
Each attribute stored in a Lightweight Directory Access Protocol (LDAP) directory [RFC4510], whose values may be transferred in the LDAP protocol [RFC4511], has a defined syntax (i.e., data type) that constrains the structure and format of its values. The comparison semantics for values of a syntax are not part of the syntax definition but are instead provided through separately defined matching rules. Matching rules specify an argument, an assertion value, which also has a defined syntax. This document defines a base set of syntaxes and matching rules for use in defining attributes for LDAP directories.
その値はLDAPプロトコル[RFC4511]に転送することができるLDAP（Lightweight Directory Access Protocol）ディレクトリ[RFC4510]に格納された各属性は、その値の構造およびフォーマットを制約定義された構文（すなわち、データ型）を有しています。構文の値について比較セマンティクスは、構文定義の一部ではなく、代わりに別々に定義されたマッチングルールを介して提供されます。マッチングルールも定義された構文を持っている引数、アサーション値を指定します。このドキュメントでは、LDAPディレクトリの属性を定義する際に使用するための構文と一致ルールの基本セットを定義します。
Readers are advised to familiarize themselves with the Directory Information Models [RFC4512] before reading the rest of this document. Section 3 provides definitions for the base set of LDAP syntaxes. Section 4 provides definitions for the base set of matching rules for LDAP.
読者は、この文書の残りの部分を読む前に、ディレクトリ情報モデル[RFC4512]に慣れることをお勧めします。第3節では、LDAP構文の基本セットの定義を提供します。セクション4は、LDAPのマッチングルールの基本セットの定義を提供します。
This document is an integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety.
この文書は、その全体が、先に定義されたLDAP技術仕様、RFC 3377を時代遅れLDAP技術仕様書[RFC4510]の不可欠な部分です。
Sections 4, 5, and 7 of RFC 2252 are obsoleted by [RFC4512]. The remainder of RFC 2252 is obsoleted by this document. Sections 6 and 8 of RFC 2256 are obsoleted by this document. The remainder of RFC 2256 is obsoleted by [RFC4519] and [RFC4512]. All but Section 2.11 of RFC 3698 is obsoleted by this document.
セクション4、5、及びRFC 2252の7は、[RFC4512]によって廃止されています。 RFC 2252の残りの部分は、この文書により廃止されます。 RFC 2256のセクション6と8は、本文書によって廃止されています。 RFC 2256の残りは[RFC4519]及び[RFC4512]によって廃止されます。 RFC 3698のセクション2.11が、すべては、この文書により廃止されます。
A number of schema elements that were included in the previous revision of the LDAP technical specification are not included in this revision of LDAP. Public Key Infrastructure schema elements are now specified in [RFC4523]. Unless reintroduced in future technical specifications, the remainder are to be considered Historic.
LDAP技術仕様書の以前のリビジョンに含まれていたスキーマ要素の数は、LDAPのこの改正には含まれていません。公開鍵インフラストラクチャのスキーマ要素は現在、[RFC4523]で指定されています。将来の技術仕様に再導入されていない限り、残りは歴史的考慮されるべきです。
The changes with respect to RFC 2252 are described in Appendix B of this document.
RFC 2252に対する変更は、この文書の付録Bに記載されています。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119 [RFC2119]に記載されているように解釈されるべきです。
Syntax definitions are written according to the <SyntaxDescription> ABNF [RFC4234] rule specified in [RFC4512], and matching rule definitions are written according to the <MatchingRuleDescription> ABNF rule specified in [RFC4512], except that the syntax and matching rule definitions provided in this document are line-wrapped for readability. When such definitions are transferred as attribute values in the LDAP protocol (e.g., as values of the ldapSyntaxes and matchingRules attributes [RFC4512], respectively), then those values would not contain line breaks.
構文定義は[RFC4512]で指定された<SyntaxDescription> ABNF [RFC4234]のルールに従って書き込まれ、マッチングルールの定義は、構文とマッチングルール定義を提供したことを除いて、[RFC4512]で指定された<MatchingRuleDescription> ABNF規則に従って書かれていますこのドキュメントでは、読みやすくするために、ライン包まれています。そのような定義が（それぞれ、ldapSyntaxesの値として、例えば及びmatchingRulesは[RFC4512]を属性）LDAPプロトコルで属性値として転送されると、その後、それらの値は、改行が含まれていないであろう。
Syntax definitions constrain the structure of attribute values stored in an LDAP directory, and determine the representation of attribute and assertion values transferred in the LDAP protocol.
構文定義は、LDAPディレクトリに格納されている属性値の構造を制約、およびLDAPプロトコルで転送属性アサーション値の表現を決定します。
Syntaxes that are required for directory operation, or that are in common use, are specified in this section. Servers SHOULD recognize all the syntaxes listed in this document, but are not required to otherwise support them, and MAY recognise or support other syntaxes. However, the definition of additional arbitrary syntaxes is discouraged since it will hinder interoperability. Client and server implementations typically do not have the ability to dynamically recognize new syntaxes.
一般的に使用されている、またはそのディレクトリの操作のために必要とされる構文は、このセクションで指定されています。サーバーは、この文書に記載されているすべての構文を認識する必要がありますが、そうでない場合は、それらをサポートする必要はありません、と認識または他の構文をサポートするかもしれません。それは、相互運用性の妨げになるので、追加の任意の構文の定義が推奨されていません。クライアントとサーバーの実装は通常、動的に新しい構文を認識する能力を持っていません。
The description of each syntax specifies how attribute or assertion values conforming to the syntax are to be represented when transferred in the LDAP protocol [RFC4511]. This representation is referred to as the LDAP-specific encoding to distinguish it from other methods of encoding attribute values (e.g., the Basic Encoding Rules (BER) encoding [BER] used by X.500 [X.500] directories).
各構文の説明は、LDAPプロトコル[RFC4511]で転送する際の構文に準拠する属性またはアサーションの値が表現される方法を指定します。この表現は、（X.500 [X.500]ディレクトリによって使用される[BER]をコードする、例えば、基本符号化規則（BER））属性値を符号化する他の方法と区別するためにLDAP固有の符号化と呼ばれています。
The LDAP-specific encoding of a given attribute syntax always produces octet-aligned values. To the greatest extent possible, encoding rules for LDAP syntaxes should produce character strings that can be displayed with little or no translation by clients implementing LDAP. However, clients MUST NOT assume that the LDAP-specific encoding of a value of an unrecognized syntax is a human-readable character string. There are a few cases (e.g., the JPEG syntax) when it is not reasonable to produce a human-readable representation.
指定された属性構文のLDAP固有のエンコーディングは常にオクテット整列値を生成します。可能な限り、LDAP構文のための符号化規則は、LDAPを実装するクライアントがほとんど、あるいはまったく翻訳して表示することができる文字列を生成する必要があります。ただし、クライアントが認識されない構文の値のLDAP固有のエンコードは、人間が読み取り可能な文字列であると仮定してはいけません。人間が読める表現を生成するのが妥当でない場合、いくつかのケース（例えば、JPEG構文）があります。
Each LDAP syntax is uniquely identified with an object identifier [ASN.1] represented in the dotted-decimal format (short descriptive names are not defined for syntaxes). These object identifiers are not intended to be displayed to users. The object identifiers for the syntaxes defined in this document are summarized in Appendix A.
各LDAP構文を一意ドット付き10進形式で表されるオブジェクト識別子[ASN.1]で識別される（短い記述名は、シンタックスのために定義されていません）。これらのオブジェクト識別子がユーザーに表示されるように意図されていません。この文書で定義された構文のオブジェクト識別子は、付録Aに要約されています
A suggested minimum upper bound on the number of characters in an attribute value with a string-based syntax, or the number of octets in a value for all other syntaxes, MAY be indicated by appending the bound inside of curly braces following the syntax's OBJECT IDENTIFIER in an attribute type definition (see the <noidlen> rule in [RFC4512]). Such a bound is not considered part of the syntax identifier.
提案最小アッパーは、文字列ベースの構文と属性値の文字数にバインドされ、または他のすべての構文の値のオクテットの数は、構文のオブジェクト識別子以下の中括弧の内側に束縛追加することによって示すことができます属性タイプ定義の（[RFC4512]で<noidlen>ルールを参照）。このようなバウンドは、構文識別子の一部とはみなされません。
For example, "1.3.6.1.4.1.1466.115.121.1.15{64}" in an attribute definition suggests that the directory server will allow a value of the attribute to be up to 64 characters long, although it may allow longer character strings. Note that a single character of the Directory String syntax can be encoded in more than one octet, since UTF-8 [RFC3629] is a variable-length encoding. Therefore, a 64- character string may be more than 64 octets in length.
例えば、「1.3.6.1.4.1.1466.115.121.1.15 {64}」属性の定義では、ディレクトリ・サーバは、それが長い文字列を許すかもしれないが、属性の値は、最大64文字の長できるようになりますことを示唆しています。 UTF-8 [RFC3629]は可変長符号であるので、ディレクトリ文字列構文の単一文字は、複数のオクテットで符号化することができることに留意されたいです。そのため、64文字の文字列の長さは64以上のオクテットかもしれません。
The following ABNF rules are used in a number of the syntax definitions in Section 3.3.
以下のABNF規則は3.3節の構文定義の数に使用されています。
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PLUS / COMMA / HYPHEN / DOT / EQUALS /
PrintableCharacter = ALPHA / DIGIT / SQUOTE / LPAREN / RPAREN / PLUS / COMMA /ハイフン/ DOT /を/ EQUALS
SLASH / COLON / QUESTION / SPACE PrintableString = 1*PrintableCharacter IA5String = *(%x00-7F) SLASH = %x2F ; forward slash ("/") COLON = %x3A ; colon (":") QUESTION = %x3F ; question mark ("?")
SLASH / COLON / QUESTION / SPACEはPrintableString = 1 * PrintableCharacter IA5String = *（％x00-7F）=％x2Fスラッシュ。スラッシュ（ "/"）COLON =％のX3A。コロン（ "："）QUESTION =％のからx3F。疑問符（ "？"）
The <ALPHA>, <DIGIT>, <SQUOTE>, <LPAREN>, <RPAREN>, <PLUS>, <COMMA>, <HYPHEN>, <DOT>, <EQUALS>, and <SPACE> rules are defined in [RFC4512].
<ALPHA>、<DIGIT>、<SQUOTE>、<LPAREN>、<RPAREN>、<PLUS>、<COMMA>、<ハイフン>、<DOT>、<EQUALS>、および<SPACE>ルールは、[で定義されていますRFC4512]。
A value of the Attribute Type Description syntax is the definition of an attribute type. The LDAP-specific encoding of a value of this syntax is defined by the <AttributeTypeDescription> rule in [RFC4512].
属性型説明構文の値は、属性タイプの定義です。この構文の値のLDAP固有の符号化は[RFC4512]で<AttributeTypeDescription>ルールによって定義されます。
For example, the following definition of the createTimestamp attribute type from [RFC4512] is also a value of the Attribute Type Description syntax. (Note: Line breaks have been added for readability; they are not part of the value when transferred in protocol.)
例えば、[RFC4512]からcreateTimestamp属性タイプの以下の定義はまた、属性型説明構文の値です。 （注：改行は読みやすくするために追加されました。彼らはプロトコルで転送される値の一部ではありません。）
( 2.5.18.1 NAME 'createTimestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )
（2.5.18.1 NAME 'createTimestamp' 平等generalizedTimeMatchはgeneralizedTimeOrderingMatch SYNTAXオーダー1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation）
The LDAP definition for the Attribute Type Description syntax is:
属性タイプ説明構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' )
（1.3.6.1.4.1.1466.115.121.1.3 DESC '属性タイプ説明'）
This syntax corresponds to the AttributeTypeDescription ASN.1 type from [X.501].
この構文は、[X.501]からAttributeTypeDescriptionのASN.1型に対応します。
A value of the Bit String syntax is a sequence of binary digits. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
ビット列の構文の値は、バイナリ数字の列です。この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
BitString = SQUOTE *binary-digit SQUOTE "B" binary-digit = "0" / "1"
ビット文字列= SQUOTE *バイナリ桁SQUOTE "B" バイナリ桁= "0" / "1"
The <SQUOTE> rule is defined in [RFC4512].
<SQUOTE>ルールは、[RFC4512]で定義されています。
Example: '0101111101'B
例：「0101111101'B
The LDAP definition for the Bit String syntax is:
ビット列の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' )
（1.3.6.1.4.1.1466.115.121.1.6 DESC 'ビット文字列'）
This syntax corresponds to the BIT STRING ASN.1 type from [ASN.1].
この構文は、[ASN.1]からビット列ASN.1型に対応します。
A value of the Boolean syntax is one of the Boolean values, true or false. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
ブール構文の値がtrueまたはfalseのブール値のいずれか、です。この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
Boolean = "TRUE" / "FALSE"
ブール= "TRUE" / "FALSE"
The LDAP definition for the Boolean syntax is:
ブール構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )
（1.3.6.1.4.1.1466.115.121.1.7 DESC 'ブール'）
This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].
この構文は、[ASN.1]からBOOLEAN ASN.1型に対応します。
A value of the Country String syntax is one of the two-character codes from ISO 3166 [ISO3166] for representing a country. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
国別の文字列の構文の値は、国を表すためのISO 3166 [ISO3166]から2文字コードのいずれかです。この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
CountryString = 2(PrintableCharacter)
CountryString = 2（PrintableCharacter）
The <PrintableCharacter> rule is defined in Section 3.2.
<PrintableCharacter>ルールは、3.2節で定義されています。
Examples:
例：
US AU
米国AU
The LDAP definition for the Country String syntax is:
国別の文字列構文のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' )
（1.3.6.1.4.1.1466.115.121.1.11 DESC 'カントリー文字列'）
This syntax corresponds to the following ASN.1 type from [X.520]:
この構文は、[X.520]から以下のASN.1タイプに対応しています。
PrintableString (SIZE (2)) -- ISO 3166 codes only
PrintableString（SIZE（2）） - ISO 3166コードのみ
A value of the Delivery Method syntax is a sequence of items that indicate, in preference order, the service(s) by which an entity is willing and/or capable of receiving messages. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
配送方法構文の値は、優先順に、エンティティが喜んで、および/またはメッセージを受信することが可能であることによって、サービス（単数または複数）を示すアイテムのシーケンスです。この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
DeliveryMethod = pdm *( WSP DOLLAR WSP pdm )
deliveryMethod（配信方法）= PDM *（WSP DOLLAR WSPのPDM）
pdm = "any" / "mhs" / "physical" / "telex" / "teletex" / "g3fax" / "g4fax" / "ia5" / "videotex" / "telephone"
PDM = "任意の" / "MHS" / "物理的" / "テレックス" / "テレテックス" / "G3FAX" / "G4FAX" / "IA5" / "ビデオテックス" / "電話"
The <WSP> and <DOLLAR> rules are defined in [RFC4512].
<WSP>と<ドル>ルールは、[RFC4512]で定義されています。
Example: telephone $ videotex
例：電話$のビデオテックス
The LDAP definition for the Delivery Method syntax is:
配信方法の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' )
（1.3.6.1.4.1.1466.115.121.1.14 DESC '配達方法'）
This syntax corresponds to the following ASN.1 type from [X.520]:
この構文は、[X.520]から以下のASN.1タイプに対応しています。
SEQUENCE OF INTEGER { any-delivery-method (0), mhs-delivery (1), physical-delivery (2), telex-delivery (3), teletex-delivery (4), g3-facsimile-delivery (5), g4-facsimile-delivery (6), ia5-terminal-delivery (7), videotex-delivery (8), telephone-delivery (9) }
INTEGER {いずれか、送達方法のシーケンス（0）、MHS-配信（1）、物理的な配信（2）、テレックス配信（3）、テレテックス配信（4）、G3ファクシミリ配信（5）、 G4ファクシミリ配信（6）、IA5末端配信（7）、ビデオテックス配信（8）、電話配信（9）}
A value of the Directory String syntax is a string of one or more arbitrary characters from the Universal Character Set (UCS) [UCS]. A zero-length character string is not permitted. The LDAP-specific encoding of a value of this syntax is the UTF-8 encoding [RFC3629] of the character string. Such encodings conform to the following ABNF:
ディレクトリ文字列構文の値は、ユニバーサル文字セット（UCS）UCS]からの1つの以上の任意の文字列です。長さゼロの文字列が許可されていません。この構文の値のLDAP固有のエンコードは、文字列のUTF-8エンコーディング[RFC3629]です。このようなエンコーディングは以下のABNFに準拠します：
DirectoryString = 1*UTF8
DirectoryString = 1 * UTF8
The <UTF8> rule is defined in [RFC4512].
<UTF8>ルールは、[RFC4512]で定義されています。
Example: This is a value of Directory String containing #!%#@.
例：！これは＃％＃@含むディレクトリ文字列の値です。
Servers and clients MUST be prepared to receive arbitrary UCS code points, including code points outside the range of printable ASCII and code points not presently assigned to any character.
サーバとクライアントは現在、任意の文字に割り当てられていない印刷可能なASCII、コードポイントの範囲外のコードポイントを含む任意のUCSコードポイントを受信する準備をしなければなりません。
Attribute type definitions using the Directory String syntax should not restrict the format of Directory String values, e.g., by requiring that the character string conforms to specific patterns described by ABNF. A new syntax should be defined in such cases.
ディレクトリ文字列構文を使用して、型定義は、文字列がABNFによって記載された特定のパターンに準拠していることを要求することにより、例えば、ディレクトリ文字列値の形式を制限してはならない属性。新しい構文は、このような場合に定義する必要があります。
The LDAP definition for the Directory String syntax is:
ディレクトリ文字列構文のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' )
（1.3.6.1.4.1.1466.115.121.1.15 DESC 'ディレクトリ文字列'）
This syntax corresponds to the DirectoryString parameterized ASN.1 type from [X.520].
この構文は、[X.520]からDirectoryStringパラメータ化ASN.1型に対応します。
The DirectoryString ASN.1 type allows a choice between the TeletexString, PrintableString, or UniversalString ASN.1 types from [ASN.1]. However, note that the chosen alternative is not indicated in the LDAP-specific encoding of a Directory String value.
DirectoryString ASN.1タイプは[ASN.1]からTeletexString、はPrintableString、又はUniversalString ASN.1タイプ間の選択を可能にします。しかし、選ばれた選択肢は、ディレクトリ文字列値のLDAP固有のエンコードに示されていないことに注意してください。
Implementations that convert Directory String values from the LDAP-specific encoding to the BER encoding used by X.500 must choose an alternative that permits the particular characters in the string and must convert the characters from the UTF-8 encoding into the character encoding of the chosen alternative. When converting Directory String values from the BER encoding to the LDAP-specific encoding, the characters must be converted from the character encoding of the chosen alternative into the UTF-8 encoding. These conversions SHOULD be done in a manner consistent with the Transcode step of the string preparation algorithms [RFC4518] for LDAP.
の文字エンコーディングにUTF-8エンコーディングからの文字を文字列に特定の文字を許可する代替手段を選択する必要がありますX.500で使用されるBERのエンコーディングにLDAP固有のエンコードからディレクトリ文字列値を変換し、変換する必要があります実装選ばれた選択肢。 LDAP固有のエンコードにBERエンコーディングからディレクトリ文字列値を変換する場合、文字がUTF-8エンコーディングに選ばれた代替の文字エンコーディングから変換する必要があります。これらの変換は、LDAPの文字列準備アルゴリズム[RFC4518]のトランスコードするステップと一致する形で行われるべきです。
A value of the DIT Content Rule Description syntax is the definition of a DIT (Directory Information Tree) content rule. The LDAP-specific encoding of a value of this syntax is defined by the <DITContentRuleDescription> rule in [RFC4512].
DITコンテンツルールの説明構文の値がDIT（ディレクトリ情報ツリー）コンテンツルールの定義です。この構文の値のLDAP固有の符号化は[RFC4512]で<DITContentRuleDescription>ルールによって定義されます。
Example: ( 2.5.6.4 DESC 'content rule for organization' NOT ( x121Address $ telexNumber ) )
例：（2.5.6.4 DESC '組織のコンテンツルール' NOT（x121Address $ telexNumber））
Note: A line break has been added for readability; it is not part of the value.
注：改行は読みやすくするために追加されました。それは価値の一部ではありません。
The LDAP definition for the DIT Content Rule Description syntax is:
DITのコンテンツルールの説明構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' )
（1.3.6.1.4.1.1466.115.121.1.16 DESC 'DITコンテンツルールの説明'）
This syntax corresponds to the DITContentRuleDescription ASN.1 type from [X.501].
この構文は、[X.501]からDITContentRuleDescription ASN.1型に対応します。
A value of the DIT Structure Rule Description syntax is the definition of a DIT structure rule. The LDAP-specific encoding of a value of this syntax is defined by the <DITStructureRuleDescription> rule in [RFC4512].
DITの構造ルールの説明構文の値は、DIT構造規則の定義です。この構文の値のLDAP固有の符号化は[RFC4512]で<DITStructureRuleDescription>ルールによって定義されます。
Example: ( 2 DESC 'organization structure rule' FORM 2.5.15.3 )
例：（2 DESC '組織構造規則' FORM 2.5.15.3）
The LDAP definition for the DIT Structure Rule Description syntax is:
DIT構造ルールの説明構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description' )
（1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT構造規則の説明'）
This syntax corresponds to the DITStructureRuleDescription ASN.1 type from [X.501].
この構文は、[X.501]からDITStructureRuleDescription ASN.1型に対応します。
A value of the DN syntax is the (purported) distinguished name (DN) of an entry [RFC4512]. The LDAP-specific encoding of a value of this syntax is defined by the <distinguishedName> rule from the string representation of distinguished names [RFC4514].
DNシンタックスの値は、エントリの（主張）識別名（DN）[RFC4512]です。この構文の値のLDAP固有の符号化は、識別名[RFC4514]の文字列表現から<distinguishedNameの>ルールによって定義されます。
Examples (from [RFC4514]): UID=jsmith,DC=example,DC=net OU=Sales+CN=J. Smith,DC=example,DC=net CN=John Smith\, III,DC=example,DC=net CN=Before\0dAfter,DC=example,DC=net 1.3.6.1.4.1.1466.0=#04024869,DC=example,DC=com CN=Lu\C4\8Di\C4\87
実施例（から[RFC4514]）：UID = JSMITH、DC =例えば、DCは=ネットOU =売上高+ CN = J。スミス、DC =例、DC =ネットCN =ジョン・スミス\、III、DC =例、DC =ネットCN = \ 0dAfter、DC =例、DC =ネット1.3.6.1.4.1.1466.0 =＃04024869前に、DC =たとえば、DC = comのCN =呂\ C4 \ 8DI \ C4 \ 87
The LDAP definition for the DN syntax is:
DN構文のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN' )
（1.3.6.1.4.1.1466.115.121.1.12 DESC 'DN'）
The DN syntax corresponds to the DistinguishedName ASN.1 type from [X.501]. Note that a BER encoded distinguished name (as used by X.500) re-encoded into the LDAP-specific encoding is not necessarily reversible to the original BER encoding since the chosen string type in any DirectoryString components of the distinguished name is not indicated in the LDAP-specific encoding of the distinguished name (see Section 3.3.6).
DNシンタックスは、[X.501]から識別名ASN.1型に対応します。識別名のいずれかDirectoryStringコンポーネントで選択された文字列型は、に示されていないので、LDAP固有の符号化に再エンコード（X.500で使用されるように）BERが識別名をコードしていることに注意することは、必ずしも元のBER符号化に可逆的ではありません識別名のLDAP固有のエンコード（第3.3.6項を参照してください）。
A value of the Enhanced Guide syntax suggests criteria, which consist of combinations of attribute types and filter operators, to be used in constructing filters to search for entries of particular object classes. The Enhanced Guide syntax improves upon the Guide syntax by allowing the recommended depth of the search to be specified.
強化されたガイド構文の値は、特定のオブジェクトクラスのエントリを検索するためのフィルタを構成するのに使用される属性タイプとフィルタ演算子の組み合わせで構成された基準を、示唆しています。強化されたガイドの構文を指定するために、検索の推奨深さを可能にすることにより、ガイド構文を改善します。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
EnhancedGuide = object-class SHARP WSP criteria WSP SHARP WSP subset object-class = WSP oid WSP subset = "baseobject" / "oneLevel" / "wholeSubtree"
EnhancedGuide =オブジェクトクラスSHARP WSP基準WSP SHARP WSPサブセットオブジェクトクラス= WSP OID WSPサブセット= "baseobject" / "ONELEVEL" / "wholeSubtree"
criteria = and-term *( BAR and-term ) and-term = term *( AMPERSAND term ) term = EXCLAIM term / attributetype DOLLAR match-type / LPAREN criteria RPAREN / true / false match-type = "EQ" / "SUBSTR" / "GE" / "LE" / "APPROX" true = "?true" false = "?false" BAR = %x7C ; vertical bar ("|") AMPERSAND = %x26 ; ampersand ("&") EXCLAIM = %x21 ; exclamation mark ("!")
基準=と期*（BARと期）および期=長期*（アンパサンド項）項=叫ぶ語/とattributeType DOLLARマッチ型/ LPAREN基準RPAREN /真/偽のマッチタイプ=「EQ」/「SUBSTR ？ "/ "GE"/ "LE"/ "APPROX" 真= "真" 偽= "偽" BAR =％のx7C。垂直バー（ "|"）アンパサンド=％のX26;アンパサンド（ "＆"）叫ぶ=％X21。エクスクラメーション・マーク （"！"）
The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and <DOLLAR> rules are defined in [RFC4512].
<SHARP>、<WSP>、<OID>、<LPAREN>、<RPAREN>、<とattributeType>、および<ドル>ルールは、[RFC4512]で定義されています。
The LDAP definition for the Enhanced Guide syntax is:
強化されたガイドの構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' )
（1.3.6.1.4.1.1466.115.121.1.21 DESC '強化ガイド'）
Example: person#(sn$EQ)#oneLevel
例：人＃（SN $ EQ）#oneLevel
The Enhanced Guide syntax corresponds to the EnhancedGuide ASN.1 type from [X.520]. The EnhancedGuide type references the Criteria ASN.1 type, also from [X.520]. The <true> rule, above, represents an empty
強化されたガイドの構文は[X.520]からEnhancedGuide ASN.1型に対応します。 EnhancedGuideタイプも[X.520]から、基準ASN.1タイプを参照します。 <真>ルール、上記では、空を表します。
"and" expression in a value of the Criteria type. The <false> rule, above, represents an empty "or" expression in a value of the Criteria type.
「と」基準型の値で表現。 <偽>ルールは、上記の条件式の値が空の「または」発現を表します。
A value of the Facsimile Telephone Number syntax is a subscriber number of a facsimile device on the public switched telephone network. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
ファクシミリ電話番号構文の値は、公共上のファクシミリ装置の加入者番号が電話網です。この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
fax-number = telephone-number *( DOLLAR fax-parameter ) telephone-number = PrintableString fax-parameter = "twoDimensional" / "fineResolution" / "unlimitedLength" / "b4Length" / "a3Width" / "b4Width" / "uncompressed"
ファックス番号=電話番号*（DOLLARファックスパラメータ）の電話番号= PrintableStringのファックスパラメータ= "二次元" / "fineResolution" / "unlimitedLength" / "b4Length" / "a3Width" / "b4Width" / "圧縮されていません"
The <telephone-number> is a string of printable characters that complies with the internationally agreed format for representing international telephone numbers [E.123]. The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
<電話番号>国際電話番号[E.123]を表現するための国際的に合意されたフォーマットに準拠して印刷可能な文字の文字列です。 <PrintableStringタイプ>規則は、セクション3.2で定義されています。 <ドル>ルールは、[RFC4512]で定義されています。
The LDAP definition for the Facsimile Telephone Number syntax is:
ファクシミリ電話番号の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
（1.3.6.1.4.1.1466.115.121.1.22 DESC 'ファクシミリ電話番号'）
The Facsimile Telephone Number syntax corresponds to the FacsimileTelephoneNumber ASN.1 type from [X.520].
ファクシミリ電話番号の構文は[X.520]からFacsimileTelephoneNumber ASN.1型に対応します。
A value of the Fax syntax is an image that is produced using the Group 3 facsimile process [FAX] to duplicate an object, such as a memo. The LDAP-specific encoding of a value of this syntax is the string of octets for a Group 3 Fax image as defined in [FAX].
ファックス構文の値は、メモなどのオブジェクトを複製するために、グループ3ファクシミリプロセス[FAX]を使用して製造された画像です。 [FAX]で定義されるように、この構文の値のLDAP固有の符号化は、グループ3ファックスイメージのオクテット列です。
The LDAP definition for the Fax syntax is:
ファックス構文のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' )
（1.3.6.1.4.1.1466.115.121.1.23 DESC 'ファックス'）
The ASN.1 type corresponding to the Fax syntax is defined as follows, assuming EXPLICIT TAGS:
EXPLICITタグを仮定すると、次のようにファックス構文に対応するASN.1型が定義されます。
Fax ::= CHOICE {
g3-facsimile [3] G3FacsimileBodyPart
}
The G3FacsimileBodyPart ASN.1 type is defined in [X.420].
G3FacsimileBodyPartのASN.1タイプは、[X.420]で定義されています。
A value of the Generalized Time syntax is a character string representing a date and time. The LDAP-specific encoding of a value of this syntax is a restriction of the format defined in [ISO8601], and is described by the following ABNF:
汎用時間構文の値は、日付と時刻を表す文字列です。この構文の値のLDAP固有の符号化は、[ISO8601]で定義されたフォーマットの制限であり、以下のABNFによって記述されます。
GeneralizedTime = century year month day hour [ minute [ second / leap-second ] ] [ fraction ] g-time-zone
GeneralizedTimeの=世紀の年月日時[分[秒/うるう秒]] [分数] G-タイムゾーン
century = 2(%x30-39) ; "00" to "99" year = 2(%x30-39) ; "00" to "99" month = ( %x30 %x31-39 ) ; "01" (January) to "09" / ( %x31 %x30-32 ) ; "10" to "12" day = ( %x30 %x31-39 ) ; "01" to "09" / ( %x31-32 %x30-39 ) ; "10" to "29" / ( %x33 %x30-31 ) ; "30" to "31" hour = ( %x30-31 %x30-39 ) / ( %x32 %x30-33 ) ; "00" to "23" minute = %x30-35 %x30-39 ; "00" to "59"
世紀= 2（％x30-39）。 "00" 〜 "99" 年= 2（％のx30-39）。 "99" 月=（％X30％x31-39）に "00"。 "01"（1月）に "09" /（％X31％x30-32）。 "12" 日=（％X30％x31-39）に "10"。 "09" から "01" /（％x31-32％x30-39）。 "10" から "29" /（％X33％x30-31）。 "30" から "31" 時間=（％x30-31％x30-39）/（％X32％x30-33）。 "00" 〜 "23" 分=％x30-35％x30-39。 "00" から "59"
second = ( %x30-35 %x30-39 ) ; "00" to "59" leap-second = ( %x36 %x30 ) ; "60"
第二=（％x30-35％x30-39）。 "00" 〜 "59" うるう秒=（％のX36の％のX30）。 "60"
fraction = ( DOT / COMMA ) 1*(%x30-39) g-time-zone = %x5A ; "Z" / g-differential g-differential = ( MINUS / PLUS ) hour [ minute ] MINUS = %x2D ; minus sign ("-")
フラクション=（DOT / COMMA）1 *（％x30-39）G-時間帯=％のX5A。 "Z" / G-G-差動差動=（マイナス/プラス）時間[分]マイナス=％x2D。マイナス記号 （"-"）
The <DOT>, <COMMA>, and <PLUS> rules are defined in [RFC4512].
<DOT>、<COMMA>、および<PLUS>ルールは、[RFC4512]で定義されています。
The above ABNF allows character strings that do not represent valid dates (in the Gregorian calendar) and/or valid times (e.g., February 31, 1994). Such character strings SHOULD be considered invalid for this syntax.
ABNF上記（グレゴリオ暦で）有効な日付および/または有効な時間（例えば、1994年2月31日）を表していない文字列を可能にします。このような文字列は、この構文については無効とみなされるべきです。
The time value represents coordinated universal time (equivalent to Greenwich Mean Time) if the "Z" form of <g-time-zone> is used; otherwise, the value represents a local time in the time zone indicated by <g-differential>. In the latter case, coordinated universal time can be calculated by subtracting the differential from the local time. The "Z" form of <g-time-zone> SHOULD be used in preference to <g-differential>.
時間値は、<G時間帯>の「Z」形が使用される場合（グリニッジ標準時に相当）協定世界時間を表します。そうでない場合、値は<G-差動>で示されるタイムゾーンのローカル時間を表します。後者の場合には、協定世界時は、ローカル時刻との差分を減算することによって算出することができます。 <G時間帯>の「Z」形は、<G-差動>に優先して使用されるべきです。
If <minute> is omitted, then <fraction> represents a fraction of an hour; otherwise, if <second> and <leap-second> are omitted, then <fraction> represents a fraction of a minute; otherwise, <fraction> represents a fraction of a second.
<分>が省略された場合、その後<画分は>時間の割合を表します。そうでなければ、もし<第二>と<うるう秒>を省略しているが、その後<分数>分の画分を表します。そうでない場合は、<画分は>第二の割合を表します。
Examples: 199412161032Z 199412160532-0500
例：199412161032Z 199412160532から0500
Both example values represent the same coordinated universal time: 10:32 AM, December 16, 1994.
どちらの例の値は、同じ協定世界時間を表す：午前10時32分AM、1994年12月16日。
The LDAP definition for the Generalized Time syntax is:
汎用時間構文のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' )
（1.3.6.1.4.1.1466.115.121.1.24 DESC '汎用時間'）
This syntax corresponds to the GeneralizedTime ASN.1 type from [ASN.1], with the constraint that local time without a differential SHALL NOT be used.
この構文は、差動ことなくローカル時間を使用してはならないという制約で、[ASN.1]からGeneralizedTimeのASN.1型に対応します。
A value of the Guide syntax suggests criteria, which consist of combinations of attribute types and filter operators, to be used in constructing filters to search for entries of particular object classes. The Guide syntax is obsolete and should not be used for defining new attribute types.
ガイド構文の値は、特定のオブジェクトクラスのエントリを検索するためのフィルタを構成するのに使用される属性タイプとフィルタ演算子の組み合わせで構成された基準を、示唆しています。ガイドの構文は廃止され、新しい属性タイプを定義するために使用すべきではありません。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
Guide = [ object-class SHARP ] criteria
= [オブジェクトクラスのシャープ]基準ガイド
The <object-class> and <criteria> rules are defined in Section 3.3.10. The <SHARP> rule is defined in [RFC4512].
<オブジェクトクラス>と<基準>ルールはセクション3.3.10で定義されています。 <SHARP>ルールは、[RFC4512]で定義されています。
The LDAP definition for the Guide syntax is:
ガイドの構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' )
（1.3.6.1.4.1.1466.115.121.1.25 DESC 'ガイド'）
The Guide syntax corresponds to the Guide ASN.1 type from [X.520].
ガイドの構文は[X.520]からガイドASN.1型に対応します。
A value of the IA5 String syntax is a string of zero, one, or more characters from International Alphabet 5 (IA5) [T.50], the international version of the ASCII character set. The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the <IA5String> rule in Section 3.2.
IA5文字列構文の値は、国際アルファベット5（IA5）[T.50]、ASCII文字セットの国際版からゼロ、1、または複数の文字の文字列です。この構文の値のLDAP固有のエンコードは、3.2節で<IA5String>ルールに準拠した文字の変換されていない文字列です。
The LDAP definition for the IA5 String syntax is:
IA5文字列構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' )
（1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5文字列'）
This syntax corresponds to the IA5String ASN.1 type from [ASN.1].
この構文は、[ASN.1]からIA5String ASN.1型に対応します。
A value of the Integer syntax is a whole number of unlimited magnitude. The LDAP-specific encoding of a value of this syntax is the optionally signed decimal digit character string representation of the number (for example, the number 1321 is represented by the character string "1321"). The encoding is defined by the following ABNF:
整数構文の値は、無制限の大きさの整数です。この構文の値のLDAP固有の符号化は、多数（例えば、数1321は、文字列「1321」で表される）の必要に応じて符号付き10進数の文字列表現です。符号化は、以下のABNFによって定義されます。
Integer = ( HYPHEN LDIGIT *DIGIT ) / number
整数=（ハイフンLDIGIT * DIGIT）/数
The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in [RFC4512].
<ハイフン>、<LDIGIT>、<DIGIT>、および<番号>ルールは、[RFC4512]で定義されています。
The LDAP definition for the Integer syntax is:
整数の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER' )
（1.3.6.1.4.1.1466.115.121.1.27 DESC 'INTEGER'）
This syntax corresponds to the INTEGER ASN.1 type from [ASN.1].
この構文は、[ASN.1]から整数ASN.1型に対応します。
A value of the JPEG syntax is an image in the JPEG File Interchange Format (JFIF), as described in [JPEG]. The LDAP-specific encoding of a value of this syntax is the sequence of octets of the JFIF encoding of the image.
[JPEG]に記載されているようにJPEG構文の値は、JPEGファイル交換フォーマット（JFIF）の画像です。この構文の値のLDAP固有の符号化は、画像のJFIF符号化のオクテットのシーケンスです。
The LDAP definition for the JPEG syntax is:
JPEGの構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' )
（1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG'）
The JPEG syntax corresponds to the following ASN.1 type:
JPEGの構文は以下のASN.1タイプに対応しています。
JPEG ::= OCTET STRING (CONSTRAINED BY
{ -- contents octets are an image in the --
-- JPEG File Interchange Format -- })
A value of the LDAP Syntax Description syntax is the description of an LDAP syntax. The LDAP-specific encoding of a value of this syntax is defined by the <SyntaxDescription> rule in [RFC4512].
LDAPシンタックスの説明シンタックスの値は、LDAP構文の説明です。この構文の値のLDAP固有の符号化は[RFC4512]で<SyntaxDescription>ルールによって定義されます。
The LDAP definition for the LDAP Syntax Description syntax is:
LDAP構文説明構文のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' )
（1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP構文説明'）
The above LDAP definition for the LDAP Syntax Description syntax is itself a legal value of the LDAP Syntax Description syntax.
LDAP構文説明構文については、上記のLDAP定義は、LDAP構文説明構文の正当な値そのものです。
The ASN.1 type corresponding to the LDAP Syntax Description syntax is defined as follows, assuming EXPLICIT TAGS:
EXPLICITタグを仮定すると、次のようにLDAP構文説明構文に対応するASN.1型が定義されます。
LDAPSyntaxDescription ::= SEQUENCE {
identifier OBJECT IDENTIFIER,
description DirectoryString { ub-schema } OPTIONAL }
The DirectoryString parameterized ASN.1 type is defined in [X.520].
DirectoryStringパラメータ化されたASN.1タイプは、[X.520]で定義されています。
The value of ub-schema (an integer) is implementation defined. A non-normative definition appears in [X.520].
UB-スキーマ（整数）の値は実装定義です。非規範的な定義は[X.520]に表示されます。
A value of the Matching Rule Description syntax is the definition of a matching rule. The LDAP-specific encoding of a value of this syntax is defined by the <MatchingRuleDescription> rule in [RFC4512].
マッチングルールの説明構文の値が一致するルールの定義です。この構文の値のLDAP固有の符号化は[RFC4512]で<MatchingRuleDescription>ルールによって定義されます。
Example: ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
例：（2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）
Note: A line break has been added for readability; it is not part of the syntax.
注：改行は読みやすくするために追加されました。それは構文の一部ではありません。
The LDAP definition for the Matching Rule Description syntax is:
マッチングルールの説明構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' )
（1.3.6.1.4.1.1466.115.121.1.30 DESC 'マッチングルール説明'）
This syntax corresponds to the MatchingRuleDescription ASN.1 type from [X.501].
この構文は、[X.501]からMatchingRuleDescription ASN.1型に対応します。
A value of the Matching Rule Use Description syntax indicates the attribute types to which a matching rule may be applied in an extensibleMatch search filter [RFC4511]. The LDAP-specific encoding of a value of this syntax is defined by the <MatchingRuleUseDescription> rule in [RFC4512].
マッチングルールの使用説明構文の値は、マッチングルールがextensibleMatch検索フィルタ[RFC4511]に適用可能な属性タイプを示しています。この構文の値のLDAP固有の符号化は[RFC4512]で<MatchingRuleUseDescription>ルールによって定義されます。
Example: ( 2.5.13.16 APPLIES ( givenName $ surname ) )
例：（2.5.13.16）は（givenName属性$姓を適用）
The LDAP definition for the Matching Rule Use Description syntax is:
一致ルールの使用説明構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' )
（1.3.6.1.4.1.1466.115.121.1.31 DESC「マッチングルールの使用説明」）
This syntax corresponds to the MatchingRuleUseDescription ASN.1 type from [X.501].
この構文は、[X.501]からMatchingRuleUseDescription ASN.1型に対応します。
A value of the Name and Optional UID syntax is the distinguished name [RFC4512] of an entity optionally accompanied by a unique identifier that serves to differentiate the entity from others with an identical distinguished name.
名前およびオプションUID構文の値は、必要に応じて同一の識別名と他のエンティティを区別するのに役立つ一意の識別子を伴うエンティティの識別名[RFC4512]です。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
NameAndOptionalUID = distinguishedName [ SHARP BitString ]
NameAndOptionalUID = distinguishedNameの[SHARPビット文字列]
The <BitString> rule is defined in Section 3.3.2. The <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule is defined in [RFC4512].
<ビット列>ルールは3.3.2項で定義されています。 <distinguishedNameの>ルールは、[RFC4514]で定義されています。 <SHARP>ルールは、[RFC4512]で定義されています。
Note that although the '#' character may occur in the string representation of a distinguished name, no additional escaping of this character is performed when a <distinguishedName> is encoded in a <NameAndOptionalUID>.
<distinguishedNameの> <NameAndOptionalUID>で符号化されたときに「＃」文字が識別名の文字列表現で起こり得るが、この文字の追加のエスケープが行われないことに留意されたいです。
Example: 1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB#'0101'B
例：1.3.6.1.4.1.1466.0 =＃04024869、O =テスト、C = GB＃ '0101'B
The LDAP definition for the Name and Optional UID syntax is:
名前とオプションのUID構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' )
（1.3.6.1.4.1.1466.115.121.1.34 DESC '名前とオプションのUID'）
This syntax corresponds to the NameAndOptionalUID ASN.1 type from [X.520].
この構文は、[X.520]からNameAndOptionalUID ASN.1型に対応します。
A value of the Name Form Description syntax is the definition of a name form, which regulates how entries may be named. The LDAP-specific encoding of a value of this syntax is defined by the <NameFormDescription> rule in [RFC4512].
名前形式説明構文の値は、エントリが命名することができる方法を規制する名前の形式の定義です。この構文の値のLDAP固有の符号化は[RFC4512]で<NameFormDescription>ルールによって定義されます。
Example: ( 2.5.15.3 NAME 'orgNameForm' OC organization MUST o )
例：（2.5.15.3 NAME 'orgNameForm' OC組織マストO）
The LDAP definition for the Name Form Description syntax is:
名前形式説明構文のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' )
（1.3.6.1.4.1.1466.115.121.1.35 DESC '名前形式説明'）
This syntax corresponds to the NameFormDescription ASN.1 type from [X.501].
この構文は、[X.501]からNameFormDescription ASN.1型に対応します。
A value of the Numeric String syntax is a sequence of one or more numerals and spaces. The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the following ABNF:
数値文字列の構文の値は、一つ以上の数字とスペースの配列です。この構文の値のLDAP固有のエンコードには、以下のABNFに準拠した文字の変換されていない文字列、次のとおりです。
NumericString = 1*(DIGIT / SPACE)
NumericString = 1 *（DIGIT /空間）
The <DIGIT> and <SPACE> rules are defined in [RFC4512].
<DIGIT>と<SPACE>ルールは、[RFC4512]で定義されています。
Example: 15 079 672 281
例：15 079 672 281
The LDAP definition for the Numeric String syntax is:
数値文字列の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' )
（1.3.6.1.4.1.1466.115.121.1.36 DESC '数値文字列'）
This syntax corresponds to the NumericString ASN.1 type from [ASN.1].
この構文は、[ASN.1]からNumericStringのASN.1型に対応します。
A value of the Object Class Description syntax is the definition of an object class. The LDAP-specific encoding of a value of this syntax is defined by the <ObjectClassDescription> rule in [RFC4512].
オブジェクトクラス説明構文の値は、オブジェクトクラスの定義です。この構文の値のLDAP固有の符号化は[RFC4512]で<ObjectClassDescription>ルールによって定義されます。
Example: ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ) )
例：（2.5.6.2 NAME MAY（searchGuide $の説明）C '国のSUPトップSTRUCTURAL MUST）
Note: A line break has been added for readability; it is not part of the syntax.
注：改行は読みやすくするために追加されました。それは構文の一部ではありません。
The LDAP definition for the Object Class Description syntax is:
オブジェクトクラス説明構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' )
（1.3.6.1.4.1.1466.115.121.1.37 DESC 'オブジェクトクラス説明'）
This syntax corresponds to the ObjectClassDescription ASN.1 type from [X.501].
この構文は、[X.501]からObjectClassDescription ASN.1型に対応します。
A value of the Octet String syntax is a sequence of zero, one, or more arbitrary octets. The LDAP-specific encoding of a value of this syntax is the unconverted sequence of octets, which conforms to the following ABNF:
オクテット文字列の構文の値は、ゼロ、1つ、またはそれ以上の任意のオクテットのシーケンスです。この構文の値のLDAP固有のエンコードには、以下のABNFに準拠した、オクテットの未変換の配列です。
OctetString = *OCTET
OCTETSTRING = * BYTE
The <OCTET> rule is defined in [RFC4512]. Values of this syntax are not generally human-readable.
<OCTET>ルールは、[RFC4512]で定義されています。この構文の値は、一般的に人間が読めるではありません。
The LDAP definition for the Octet String syntax is:
オクテット文字列の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' )
（1.3.6.1.4.1.1466.115.121.1.40 DESC 'オクテット文字列'）
This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].
この構文は、[ASN.1]からOCTET STRINGのASN.1型に対応します。
A value of the OID syntax is an object identifier: a sequence of two or more non-negative integers that uniquely identify some object or item of specification. Many of the object identifiers used in LDAP also have IANA registered names [RFC4520].
一意明細書のいくつかのオブジェクトまたはアイテムを識別する2つ以上の非負整数の配列：OID構文の値は、オブジェクト識別子です。 LDAPで使用されるオブジェクト識別子の多くは、IANAは名前[RFC4520]を登録しています。
The LDAP-specific encoding of a value of this syntax is defined by the <oid> rule in [RFC4512].
この構文の値のLDAP固有の符号化は[RFC4512]で<OID>ルールによって定義されます。
Examples: 1.2.3.4 cn
例：1.2.3.4 CN
The LDAP definition for the OID syntax is:
OID構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' )
（1.3.6.1.4.1.1466.115.121.1.38 DESC "OID"）
This syntax corresponds to the OBJECT IDENTIFIER ASN.1 type from [ASN.1].
この構文は、[ASN.1]からオブジェクト識別子ASN.1型に対応します。
A value of the Other Mailbox syntax identifies an electronic mailbox, in a particular named mail system. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
他のメールボックスの構文の値は、特定の名前のメールシステムでは、電子メールボックスを識別します。この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
OtherMailbox = mailbox-type DOLLAR mailbox mailbox-type = PrintableString mailbox = IA5String
otherMailbox =メールボックス型DOLLARのメールボックスのメールボックス型= PrintableStringのメールボックス= IA5String
The <mailbox-type> rule represents the type of mail system in which the mailbox resides (for example, "MCIMail"), and <mailbox> is the actual mailbox in the mail system described by <mailbox-type>. The <PrintableString> and <IA5String> rules are defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
<メールボックス型>ルールは、メール内のメールボックスが存在する（例えば、「MCIMail」）システム、および<メールボックス>のタイプを表す<メールボックス型>で説明メールシステムの実際のメールボックスです。 <PrintableStringの>と<IA5String>規則は、3.2節で定義されています。 <ドル>ルールは、[RFC4512]で定義されています。
The LDAP definition for the Other Mailbox syntax is:
他のメールボックスの構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' )
（1.3.6.1.4.1.1466.115.121.1.39 DESC 'その他のメールボックス'）
The ASN.1 type corresponding to the Other Mailbox syntax is defined as follows, assuming EXPLICIT TAGS:
EXPLICITタグを仮定すると、次のように他のメールボックスの構文に対応するASN.1型が定義されます。
OtherMailbox ::= SEQUENCE {
mailboxType PrintableString,
mailbox IA5String
}
A value of the Postal Address syntax is a sequence of strings of one or more arbitrary UCS characters, which form an address in a physical mail system.
住所の構文の値は、物理的なメールシステムのアドレスを形成する1つの以上の任意のUCS文字の文字列のシーケンスです。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
PostalAddress = line *( DOLLAR line ) line = 1*line-char line-char = %x00-23 / (%x5C "24") ; escaped "$" / %x25-5B / (%x5C "5C") ; escaped "\" / %x5D-7F / UTFMB
PostalAddress =行*（ドルライン）ライン= 1 *ラインチャーラインチャー=％x00-23 /（％のx5C "24"）。エスケープ "$" /％x25-5B /（％のx5C "5C"）;エスケープ "\" /％x5D-7F / UTFMB
Each character string (i.e., <line>) of a postal address value is encoded as a UTF-8 [RFC3629] string, except that "\" and "$" characters, if they occur in the string, are escaped by a "\" character followed by the two hexadecimal digit code for the character. The <DOLLAR> and <UTFMB> rules are defined in [RFC4512].
彼らは文字列で発生した場合、その「\」と「$」文字を除いて、 "でエスケープされている住所値はUTF-8 [RFC3629]の文字列としてエンコードされるの各文字列（すなわち、<ライン>） \」文字の文字の2進数桁のコードが続きます。 <ドル>と<UTFMB>ルールは、[RFC4512]で定義されています。
Many servers limit the postal address to no more than six lines of no more than thirty characters each.
多くのサーバは、せいぜい30文字ずつのせいぜい6行に住所を制限します。
Example: 1234 Main St.$Anytown, CA 12345$USA \241,000,000 Sweepstakes$PO Box 1000000$Anytown, CA 12345$USA
例：1234メインストリート$ Anytown、CA 12345 USA $ \2.41億懸賞$私書箱1000000 $ Anytown、CA 12345 USA $
The LDAP definition for the Postal Address syntax is:
住所の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' )
（1.3.6.1.4.1.1466.115.121.1.41 DESC '住所'）
This syntax corresponds to the PostalAddress ASN.1 type from [X.520]; that is
この構文は、[X.520]からのPostalAddress ASN.1型に対応します。あれは
PostalAddress ::= SEQUENCE SIZE(1..ub-postal-line) OF
DirectoryString { ub-postal-string }
The values of ub-postal-line and ub-postal-string (both integers) are implementation defined. Non-normative definitions appear in [X.520].
UB-郵便ライン及びUB-郵便列（両方とも整数）の値は実装に定義されています。非規範的な定義は[X.520]に表示されます。
A value of the Printable String syntax is a string of one or more latin alphabetic, numeric, and selected punctuation characters as specified by the <PrintableCharacter> rule in Section 3.2.
印刷可能な文字列の構文の値は、3.2節で<PrintableCharacter>ルールで指定された一つ以上の、アルファベット、数字ラテン、選択した句読点文字の文字列です。
The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the <PrintableString> rule in Section 3.2.
この構文の値のLDAP固有のエンコードは、3.2節では、<はPrintableString>ルールに準拠した文字の変換されていない文字列です。
Example: This is a PrintableString.
例：これはPrintableStringのです。
The LDAP definition for the PrintableString syntax is:
PrintableStringの構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )
（1.3.6.1.4.1.1466.115.121.1.44 DESC '印刷可能な文字列'）
This syntax corresponds to the PrintableString ASN.1 type from [ASN.1].
この構文は、[ASN.1]からはPrintableString ASN.1型に対応します。
A value of the Substring Assertion syntax is a sequence of zero, one, or more character substrings used as an argument for substring extensible matching of character string attribute values; i.e., as the matchValue of a MatchingRuleAssertion [RFC4511]. Each substring is a string of one or more arbitrary characters from the Universal Character Set (UCS) [UCS]. A zero-length substring is not permitted.
サブストリングアサーション構文の値は、1つのゼロのシーケンスで、または文字列の属性値の拡張可能なマッチングをサブストリングの引数として使用される複数の文字ストリング。即ち、MatchingRuleAssertionのmatchValue [RFC4511]として。各部分は、ユニバーサル文字セット（UCS）UCS]からの1つの以上の任意の文字列です。長さゼロのストリングが許可されていません。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
SubstringAssertion = [ initial ] any [ final ]
SubstringAssertion = [初期]任意[最終]
initial = substring any = ASTERISK *(substring ASTERISK) final = substring ASTERISK = %x2A ; asterisk ("*")
任意=アスタリスク*（サブストリングアスタリスク）最終=サブアスタリスク=％のX2Aをサブストリング初期=。アスタリスク（ "*"）
substring = 1*substring-character substring-character = %x00-29 / (%x5C "2A") ; escaped "*" / %x2B-5B / (%x5C "5C") ; escaped "\" / %x5D-7F / UTFMB
ストリング= 1 *ストリング文字サブストリング文字=％x00-29 /（％x5C "2A"）。 "*" /％X2B-5B /（％のx5C "5C"）をエスケープ。エスケープ "\" /％x5D-7F / UTFMB
Each <substring> of a Substring Assertion value is encoded as a UTF-8 [RFC3629] string, except that "\" and "*" characters, if they occur in the substring, are escaped by a "\" character followed by the two hexadecimal digit code for the character.
彼らは部分文字列で発生した場合、サブストリングのアサーション値のそれぞれの<サブ>が続く「\」文字でエスケープされている、その「\」と「*」の文字を除いて、UTF-8 [RFC3629]の文字列としてエンコードされます文字の2進数桁のコード。
The Substring Assertion syntax is used only as the syntax of assertion values in the extensible match. It is not used as an attribute syntax, or in the SubstringFilter [RFC4511].
サブストリングアサーション構文のみ拡張可能なマッチでアサーション値の構文として使用されます。これは、属性構文として、またはSubstringFilter [RFC4511]で使用されていません。
The LDAP definition for the Substring Assertion syntax is:
サブストリングアサーション構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' )
（1.3.6.1.4.1.1466.115.121.1.58 DESC 'サブストリングのアサーション'）
This syntax corresponds to the SubstringAssertion ASN.1 type from [X.520].
この構文は、[X.520]からSubstringAssertionのASN.1型に対応します。
A value of the Telephone Number syntax is a string of printable characters that complies with the internationally agreed format for representing international telephone numbers [E.123].
電話番号の構文の値は、国際電話番号[E.123]を表現するための国際的に合意されたフォーマットに準拠して印刷可能な文字の文字列です。
The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the <PrintableString> rule in Section 3.2.
この構文の値のLDAP固有のエンコードは、3.2節では、<はPrintableString>ルールに準拠した文字の変換されていない文字列です。
Examples: +1 512 315 0280 +1-512-315-0280 +61 3 9896 7830
例：+ 1-512-315-0280 +61 3 9896 7830 +1 512 315 0280
The LDAP definition for the Telephone Number syntax is:
電話番号の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
（1.3.6.1.4.1.1466.115.121.1.50 DESC '電話番号'）
The Telephone Number syntax corresponds to the following ASN.1 type from [X.520]:
電話番号の構文は[X.520]から以下のASN.1タイプに対応しています。
PrintableString (SIZE(1..ub-telephone-number))
PrintableString（SIZE（1..ub-電話番号））
The value of ub-telephone-number (an integer) is implementation defined. A non-normative definition appears in [X.520].
UB-電話番号（整数）の値は実装定義です。非規範的な定義は[X.520]に表示されます。
A value of this syntax specifies the identifier and (optionally) parameters of a teletex terminal.
この構文の値は、識別子とテレテックス端末の（任意に）パラメータを指定します。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
teletex-id = ttx-term *(DOLLAR ttx-param) ttx-term = PrintableString ; terminal identifier ttx-param = ttx-key COLON ttx-value ; parameter ttx-key = "graphic" / "control" / "misc" / "page" / "private" ttx-value = *ttx-value-octet
テレテックス-ID = TTX項*（ドルTTX-PARAM）TTX-TERM =はPrintableString。端末識別子TTX-PARAM = TTX-キー大腸TTX値。パラメータTTX-キー= "グラフィック" / "コントロール" / "その他" / "ページ" / "プライベート" TTX-値= * TTX-値オクテット
ttx-value-octet = %x00-23 / (%x5C "24") ; escaped "$" / %x25-5B / (%x5C "5C") ; escaped "\"
TTX-値オクテット=％x00-23 /（％のx5C "24"）。エスケープ "$" /％x25-5B /（％のx5C "5C"）; 「\」エスケープ
/ %x5D-FF
/％X5d-FF
The <PrintableString> and <COLON> rules are defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
<PrintableStringの>と<COLON>規則は、3.2節で定義されています。 <ドル>ルールは、[RFC4512]で定義されています。
The LDAP definition for the Teletex Terminal Identifier syntax is:
テレテックス端末識別子の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' )
（1.3.6.1.4.1.1466.115.121.1.51 DESC 'テレテックス端末識別子'）
This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type from [X.520].
この構文は、[X.520]からTeletexTerminalIdentifier ASN.1型に対応します。
A value of the Telex Number syntax specifies the telex number, country code, and answerback code of a telex terminal.
テレックス番号構文の値はテレックス番号、国コード、およびテレックス端末のアンサーバックコードを指定します。
The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
この構文の値のLDAP固有の符号化は、以下のABNFによって定義されます。
telex-number = actual-number DOLLAR country-code DOLLAR answerback actual-number = PrintableString country-code = PrintableString answerback = PrintableString
テレックス番号=実際の番号DOLLAR国コードDOLLARアンサー実数= PrintableStringの国コード= PrintableStringのアンサーバック=はPrintableString
The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
<PrintableStringタイプ>規則は、セクション3.2で定義されています。 <ドル>ルールは、[RFC4512]で定義されています。
The LDAP definition for the Telex Number syntax is:
テレックス番号の構文については、LDAPの定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
（1.3.6.1.4.1.1466.115.121.1.52 DESC 'テレックス番号'）
This syntax corresponds to the TelexNumber ASN.1 type from [X.520].
この構文は、[X.520]からTelexNumber ASN.1型に対応します。
A value of the UTC Time syntax is a character string representing a date and time to a precision of one minute or one second. The year is given as a two-digit number. The LDAP-specific encoding of a value of this syntax follows the format defined in [ASN.1] for the UTCTime type and is described by the following ABNF:
UTC時間構文の値は、1分1秒の精度に日付と時刻を表す文字列です。年が2桁の数として与えられています。この構文の値のLDAP固有の符号化は、UTC時刻タイプの[ASN.1]で定義されたフォーマットに従い、以下のABNFによって記述されます。
UTCTime = year month day hour minute [ second ] [ u-time-zone ] u-time-zone = %x5A ; "Z" / u-differential
UTC時刻=年月日時分[秒] [U-タイムゾーン] uの時間帯=％のX5A。 "Z" / U-差動
u-differential = ( MINUS / PLUS ) hour minute
U-差動=（マイナス/プラス）時間分
The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS> rules are defined in Section 3.3.13. The <PLUS> rule is defined in [RFC4512].
<年>、<月>、<日>、<時間>、<分>、<秒>、および<MINUS>規則は、セクション3.3.13で定義されています。 <PLUS>ルールは、[RFC4512]で定義されています。
The above ABNF allows character strings that do not represent valid dates (in the Gregorian calendar) and/or valid times. Such character strings SHOULD be considered invalid for this syntax.
上記のABNFは、（グレゴリオ暦で）有効な日付および/または有効な時刻を表すものではない文字列を可能にします。このような文字列は、この構文については無効とみなされるべきです。
The time value represents coordinated universal time if the "Z" form of <u-time-zone> is used; otherwise, the value represents a local time. In the latter case, if <u-differential> is provided, then coordinated universal time can be calculated by subtracting the differential from the local time. The <u-time-zone> SHOULD be present in time values, and the "Z" form of <u-time-zone> SHOULD be used in preference to <u-differential>.
時間値は、<U時間帯>の「Z」形が使用される場合、協定世界時間を表します。そうでない場合、値はローカル時間を表します。 <U-差動>が設けられている場合、後者の場合には、その後、協定世界時は、ローカル時刻との差分を減算することによって算出することができます。 <U時間帯>時間値で存在すべきであり、<U時間帯>の「Z」形は、<U-差動>に優先して使用されるべきです。
The LDAP definition for the UTC Time syntax is:
UTC時間構文のLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC Time' )
（1.3.6.1.4.1.1466.115.121.1.53 DESC 'UTC時間'）
Note: This syntax is deprecated in favor of the Generalized Time syntax.
注：この構文は汎用時間構文の賛成で廃止されました。
The UTC Time syntax corresponds to the UTCTime ASN.1 type from [ASN.1].
UTC時刻の構文は[ASN.1]からUTC時刻ASN.1型に対応します。
Matching rules are used by directory implementations to compare attribute values against assertion values when performing Search and Compare operations [RFC4511]. They are also used when comparing a purported distinguished name [RFC4512] with the name of an entry. When modifying entries, matching rules are used to identify values to be deleted and to prevent an attribute from containing two equal values.
マッチングルールは、検索を実行するときに、アサーション値に対して属性値を比較し、操作[RFC4511]を比較するために、ディレクトリの実装によって使用されています。エントリの名前を主張識別名[RFC4512]を比較するときにも使用されます。エントリを変更する場合、一致するルールが削除される値を識別し、二つの等しい値を含むから属性を防止するために使用されます。
Matching rules that are required for directory operation, or that are in common use, are specified in this section.
ディレクトリ操作のために必要とされるルールに一致する、またはその一般的に使用されている、このセクションで指定されています。
A matching rule is applied to attribute values through an AttributeValueAssertion or MatchingRuleAssertion [RFC4511]. The conditions under which an AttributeValueAssertion or MatchingRuleAssertion evaluates to Undefined are specified elsewhere [RFC4511]. If an assertion is not Undefined, then the result of the
マッチングルールはAttributeValueAssertion又はMatchingRuleAssertion [RFC4511]を介して属性値に適用されます。 AttributeValueAssertion又はMatchingRuleAssertionは未定義と評価される条件は、他の場所に[RFC4511]に指定されています。の主張が未定義でない場合、結果
assertion is the result of applying the selected matching rule. A matching rule evaluates to TRUE, and in some cases Undefined, as specified in the description of the matching rule; otherwise, it evaluates to FALSE.
アサーションは、選択されたマッチングルールを適用した結果です。マッチングルールは、マッチングルールの説明で指定されるように、TRUEと評価され、そしていくつかの場合には未定義。それ以外の場合はFALSEと評価されます。
Each assertion contains an assertion value. The definition of each matching rule specifies the syntax for the assertion value. The syntax of the assertion value is typically, but not necessarily, the same as the syntax of the attribute values to which the matching rule may be applied. Note that an AssertionValue in a SubstringFilter [RFC4511] conforms to the assertion syntax of the equality matching rule for the attribute type rather than to the assertion syntax of the substrings matching rule for the attribute type. Conceptually, the entire SubstringFilter is converted into an assertion value of the substrings matching rule prior to applying the rule.
各アサーションは、アサーション値が含まれています。各一致ルールの定義は、アサーション値の構文を指定します。アサーション値の構文は、必ずしも一致するルールが適用される属性値の構文と同じではない典型的であるが。 SubstringFilter [RFC4511]でAssertionValueの属性タイプの等価マッチング規則のアサーション構文にではなく、属性タイプのルールに一致するサブストリングのアサーション構文に準拠していることに注意してください。概念的に、全体SubstringFilterルールを適用する前に、ストリングマッチング規則のアサーション値に変換されます。
The definition of each matching rule indicates the attribute syntaxes to which the rule may be applied, by specifying conditions the corresponding ASN.1 type of a candidate attribute syntax must satisfy. These conditions are also satisfied if the corresponding ASN.1 type is a tagged or constrained derivative of the ASN.1 type explicitly mentioned in the rule description (i.e., ASN.1 tags and constraints are ignored in checking applicability), or is an alternative reference notation for the explicitly mentioned type. Each rule description lists, as examples of applicable attribute syntaxes, the complete list of the syntaxes defined in this document to which the matching rule applies. A matching rule may be applicable to additional syntaxes defined in other documents if those syntaxes satisfy the conditions on the corresponding ASN.1 type.
各マッチングルールの定義は、どのルールが、候補属性構文の対応するASN.1タイプが満たさなければならない条件を指定することにより、適用可能な属性構文を示しています。対応するASN.1タイプが明示的ルールの説明で述べたASN.1タイプのタグ付きまたは制約誘導体（すなわち、ASN.1タグと制約が適用性をチェックでは無視される）であり、または代替である場合、これらの条件も満たされています明示的に述べたタイプの参照符号。各ルールの説明のリストは、該当する属性構文の例として、構文の完全なリストは、一致するルールが適用されるには、この文書で定義されました。これらの構文は、対応するASN.1タイプに条件を満たした場合、一致するルールが他の文書で定義された追加の構文にも適用可能です。
The description of each matching rule indicates whether the rule is suitable for use as the equality matching rule (EQUALITY), ordering matching rule (ORDERING), or substrings matching rule (SUBSTR) in an attribute type definition [RFC4512].
各マッチングルールの説明は、ルールが等価一致ルール（平等）、マッチング規則（オーダー）、または属性タイプ定義[RFC4512]におけるルール（SUBSTR）と一致するサブストリングを注文としての使用に適しているかどうかを示します。
Each matching rule is uniquely identified with an object identifier. The definition of a matching rule should not subsequently be changed. If a change is desirable, then a new matching rule with a different object identifier should be defined instead.
各マッチングルールは一意のオブジェクト識別子で識別されます。マッチングルールの定義は、後で変更すべきではありません。変更が望ましい場合には、異なるオブジェクト識別子を使用して新しいマッチングルールが代わりに定義されるべきです。
Servers MAY implement the wordMatch and keywordMatch matching rules, but they SHOULD implement the other matching rules in Section 4.2. Servers MAY implement additional matching rules.
サーバーはwordMatchとキーワード一致のマッチングルールを実装するかもしれないが、彼らは、4.2節で他のマッチングルールを実装する必要があります。サーバーは、追加のマッチング規則を実施することができます。
Servers that implement the extensibleMatch filter SHOULD allow the matching rules listed in Section 4.2 to be used in the extensibleMatch filter and SHOULD allow matching rules to be used with all attribute types known to the server, where the assertion syntax of the matching rule is the same as the value syntax of the attribute.
extensibleMatchフィルタは、セクション4.2に記載されているマッチングルールがextensibleMatchフィルタに使用されることを可能にするべきであり、一致するルールがサーバに知られているすべての属性タイプで使用することができるようにする必要があり実装サーバ、マッチング規則のアサーション構文は同じです属性の値の構文として。
Servers MUST publish, in the matchingRules attribute, the definitions of matching rules referenced by values of the attributeTypes and matchingRuleUse attributes in the same subschema entry. Other unreferenced matching rules MAY be published in the matchingRules attribute.
サーバーは、一致ルールの定義はattributeTypes属性の値によって参照されるmatchingRuleUseは、同じサブスキーマエントリの属性、matchingRules属性では、公開する必要があります。その他の参照されていないマッチングルールはmatchingRules属性に公開することができます。
If the server supports the extensibleMatch filter, then the server MAY use the matchingRuleUse attribute to indicate the applicability (in an extensibleMatch filter) of selected matching rules to nominated attribute types.
サーバがextensibleMatchフィルタをサポートしている場合、サーバは指名属性タイプに選択されたマッチングルールの（extensibleMatchフィルターで）適用性を示すためれるmatchingRuleUse属性を使用するかもしれません。
Nominated character strings in assertion and attribute values are prepared according to the string preparation algorithms [RFC4518] for LDAP when evaluating the following matching rules:
アサーションに文字列をノミネートし、属性の値は、次のマッチングルールを評価するLDAPの文字列準備アルゴリズム[RFC4518]に従って製造されています。
numericStringMatch, numericStringSubstringsMatch, caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch, caseExactIA5Match, caseIgnoreIA5Match, caseIgnoreIA5SubstringsMatch, caseIgnoreListMatch, caseIgnoreListSubstringsMatch, caseIgnoreMatch, caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, directoryStringFirstComponentMatch, telephoneNumberMatch, telephoneNumberSubstringsMatch and wordMatch.
numericStringMatch、numericStringSubstringsMatch、CaseExactMatchの、caseExactOrderingMatch、caseExactSubstringsMatch、caseExactIA5Match、caseIgnoreIA5Match、caseIgnoreIA5SubstringsMatch、caseIgnoreListMatch、caseIgnoreListSubstringsMatch、caseIgnoreMatch、caseIgnoreOrderingMatch、caseIgnoreSubstringsMatch、directoryStringFirstComponentMatch、telephoneNumberMatch、telephoneNumberSubstringsMatchとwordMatch。
The Transcode, Normalize, Prohibit, and Check bidi steps are the same for each of the matching rules. However, the Map and Insignificant Character Handling steps depend on the specific rule, as detailed in the description of these matching rules in the sections that follow.
トランスコード、正規化、禁止、及び双方向手順をチェックし、一致するルールの各々に対して同じです。しかし、地図や無意味な文字の処理手順は、以下のセクションでは、これらのマッチングルールの説明で詳述するように、特定のルールに依存します。
The bitStringMatch rule compares an assertion value of the Bit String syntax to an attribute value of a syntax (e.g., the Bit String syntax) whose corresponding ASN.1 type is BIT STRING.
bitStringMatchルールは、対応するASN.1タイプはビット列である構文（例えば、ビット文字列構文）の属性値をビット文字列構文のアサーション値を比較します。
If the corresponding ASN.1 type of the attribute syntax does not have a named bit list [ASN.1] (which is the case for the Bit String syntax), then the rule evaluates to TRUE if and only if the attribute value has the same number of bits as the assertion value and the bits match on a bitwise basis.
属性構文の対応するASN.1タイプは（ビット文字列の構文の場合である）という名前のビットリスト[ASN.1]を持っていない場合、属性値がある場合のみなら、ルールがTRUEと評価しますアサーション値としてビットと同じビット数はビット単位毎に一致します。
If the corresponding ASN.1 type does have a named bit list, then bitStringMatch operates as above, except that trailing zero bits in the attribute and assertion values are treated as absent.
対応するASN.1タイプが名前付きビットリストがない場合、bitStringMatchは存在しないとして扱われる属性アサーション値のその後続ゼロのビットを除いて、上記のように動作します。
The LDAP definition for the bitStringMatch rule is:
bitStringMatchルールのLDAP定義は次のとおりです。
( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 )
（2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6）
The bitStringMatch rule is an equality matching rule.
bitStringMatchルールはルールに一致平等です。
The booleanMatch rule compares an assertion value of the Boolean syntax to an attribute value of a syntax (e.g., the Boolean syntax) whose corresponding ASN.1 type is BOOLEAN.
booleanMatchルールは、対応するASN.1タイプBOOLEANある構文（例えば、ブール構文）の属性値にブール構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the attribute value and the assertion value are both TRUE or both FALSE.
ルールがTRUEと評価された場合、属性値と主張値がTRUEまたは両方FALSEの両方である場合にのみ。
The LDAP definition for the booleanMatch rule is:
booleanMatchルールのLDAP定義は次のとおりです。
( 2.5.13.13 NAME 'booleanMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
（2.5.13.13 NAME 'booleanMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7）
The booleanMatch rule is an equality matching rule.
booleanMatchルールはルールに一致平等です。
The caseExactIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
caseExactIA5Matchルールは、対応するASN.1タイプIA5Stringである構文（例えば、IA5文字列構文）の属性値にIA5文字列構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
ルールがTRUEと評価された場合、準備属性値の文字列と準備アサーション値の文字列は、文字の同じ番号を持って、対応する文字が同じコードポイントを持っている場合にのみ。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のための属性値と主張値を調製する際に、文字が地図作製工程、およびだけ意味のない空白の扱いに折りたたまれた場合は、ステップの取り扱い無意味な文字には適用されません。
The LDAP definition for the caseExactIA5Match rule is:
caseExactIA5MatchルールのLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
The caseExactIA5Match rule is an equality matching rule.
caseExactIA5Matchルールはルールに一致平等です。
The caseExactMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of the alternative string types of DirectoryString, such as PrintableString (the other alternatives do not correspond to any syntax defined in this document).
CaseExactMatchのルールは、（例えば、ディレクトリ文字列、表示可能な文字列、国文字列、または電話番号構文）に対応するASN.1タイプはDirectoryStringまたは代替の一つで、構文の属性値にディレクトリ文字列構文の主張値を比較し、などはPrintableStringとしてDirectoryStringの文字列型、（他の選択肢は、この文書で定義された任意の構文に対応していません）。
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
ルールがTRUEと評価された場合、準備属性値の文字列と準備アサーション値の文字列は、文字の同じ番号を持って、対応する文字が同じコードポイントを持っている場合にのみ。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のための属性値と主張値を調製する際に、文字が地図作製工程、およびだけ意味のない空白の扱いに折りたたまれた場合は、ステップの取り扱い無意味な文字には適用されません。
The LDAP definition for the caseExactMatch rule is:
CaseExactMatchのルールのLDAP定義は次のとおりです。
( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（2.5.13.5 NAME 'CaseExactMatchの' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）
The caseExactMatch rule is an equality matching rule.
CaseExactMatchのルールはルールに一致平等です。
The caseExactOrderingMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
caseExactOrderingMatchルールは（例えば、ディレクトリ文字列、表示可能な文字列、国文字列、または電話番号構文）に対応するASN.1タイプはDirectoryStringまたはその代替のひとつれる構文の属性値にディレクトリ文字列構文の主張値を比較し、文字列型。
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value.
ルールは、コードポイント照合順序、準備された属性値の文字列が用意さアサーション値の文字列よりも先に表示された中で、場合に限り、TRUEと評価します。すなわち、属性値は、アサーション値「未満」です。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のための属性値と主張値を調製する際に、文字が地図作製工程、およびだけ意味のない空白の扱いに折りたたまれた場合は、ステップの取り扱い無意味な文字には適用されません。
The LDAP definition for the caseExactOrderingMatch rule is:
caseExactOrderingMatchルールのLDAP定義は次のとおりです。
( 2.5.13.6 NAME 'caseExactOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（2.5.13.6 NAME 'caseExactOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）
The caseExactOrderingMatch rule is an ordering matching rule.
caseExactOrderingMatchルールはルールに一致する順序です。
The caseExactSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
caseExactSubstringsMatchルールは（例えば、ディレクトリ文字列、表示可能な文字列、国文字列、または電話番号構文）に対応するASN.1タイプはDirectoryStringまたはその代替のひとつれる構文の属性値にサブストリングのアサーション構文の主張値を比較し、文字列型。
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
ルールがあれば、場合にのみ（1）アサーション値の一致の調製ストリング主張値のサブストリングのために準備された属性値文字列の互いに素な部分、（2）<初期>サブTRUEと評価します現在、準備された属性値の文字列の先頭にマッチし、（3）<最終>のサブストリングは、存在する場合、準備された属性値の文字列の末尾にマッチします。対応する文字が同じコードポイントを持っている場合、準備された部分文字列は、準備された属性値の文字列の部分と一致します。
In preparing the attribute value and assertion value substrings for comparison, characters are not case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のための属性値と主張値のサブストリングを調製する際に、文字が地図作製工程、およびだけ意味のない空白の扱いに折りたたまれた場合は、ステップの取り扱い無意味な文字には適用されません。
The LDAP definition for the caseExactSubstringsMatch rule is:
caseExactSubstringsMatchルールのLDAP定義は次のとおりです。
( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
（2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58）
The caseExactSubstringsMatch rule is a substrings matching rule.
caseExactSubstringsMatch規則は、ストリングマッチングルールです。
The caseIgnoreIA5Match rule compares an assertion value of the IA5 String syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
caseIgnoreIA5Matchルールは、対応するASN.1タイプIA5Stringである構文（例えば、IA5文字列構文）の属性値にIA5文字列構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
ルールがTRUEと評価された場合、準備属性値の文字列と準備アサーション値の文字列は、文字の同じ番号を持って、対応する文字が同じコードポイントを持っている場合にのみ。
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のために、属性値と主張値を調製する際に、文字が地図作製工程で折り畳まれた場合であり、唯一の意味のない空白の扱いは無意味な文字の処理ステップで適用されます。
The LDAP definition for the caseIgnoreIA5Match rule is:
caseIgnoreIA5MatchルールのLDAP定義は次のとおりです。
( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）
The caseIgnoreIA5Match rule is an equality matching rule.
caseIgnoreIA5Matchルールはルールに一致平等です。
The caseIgnoreIA5SubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the IA5 String syntax) whose corresponding ASN.1 type is IA5String.
caseIgnoreIA5SubstringsMatchルールは、対応するASN.1タイプIA5Stringある構文（例えば、IA5文字列構文）の属性値にサブストリングアサーション構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
ルールがあれば、場合にのみ（1）アサーション値の一致の調製ストリング主張値のサブストリングのために準備された属性値文字列の互いに素な部分、（2）<初期>サブTRUEと評価します現在、準備された属性値の文字列の先頭にマッチし、（3）<最終>のサブストリングは、存在する場合、準備された属性値の文字列の末尾にマッチします。対応する文字が同じコードポイントを持っている場合、準備された部分文字列は、準備された属性値の文字列の部分と一致します。
In preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のために、属性値と主張値のサブストリングを調製する際に、文字が地図作製工程で折り畳まれた場合であり、唯一の意味のない空白の扱いは無意味な文字の処理ステップで適用されます。
( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
（1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58）
The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.
caseIgnoreIA5SubstringsMatch規則は、ストリングマッチングルールです。
The caseIgnoreListMatch rule compares an assertion value that is a sequence of strings to an attribute value of a syntax (e.g., the
caseIgnoreListMatchルールは、構文（例えばの属性値文字列の配列であるアサーション値を比較します
Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type.
その対応するASN.1タイプ住所構文）はDirectoryStringのASN.1タイプのシーケンスです。
The rule evaluates to TRUE if and only if the attribute value and the assertion value have the same number of strings and corresponding strings (by position) match according to the caseIgnoreMatch matching rule.
caseIgnoreMatchマッチング規則に従って規則がTRUEと評価された属性値と主張値は、文字列と対応する文字列（位置による）の数が同じ場合にのみ一致。
In [X.520], the assertion syntax for this matching rule is defined to be:
[X.520]において、このマッチングルールのアサーション構文があると定義されます。
SEQUENCE OF DirectoryString {ub-match}
ディレクトリ列のSEQUENCE {にマッチ}
That is, it is different from the corresponding type for the Postal Address syntax. The choice of the Postal Address syntax for the assertion syntax of the caseIgnoreListMatch in LDAP should not be seen as limiting the matching rule to apply only to attributes with the Postal Address syntax.
つまり、それは郵便住所の構文については、対応するタイプとは異なります。 LDAPでcaseIgnoreListMatchのアサーション構文については、住所構文の選択は、住所の構文と属性のみに適用するマッチングルールを限定するものと考えるべきではありません。
The LDAP definition for the caseIgnoreListMatch rule is:
caseIgnoreListMatchルールのLDAP定義は次のとおりです。
( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 )
（2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41）
The caseIgnoreListMatch rule is an equality matching rule.
caseIgnoreListMatchルールはルールに一致平等です。
The caseIgnoreListSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Postal Address syntax) whose corresponding ASN.1 type is a SEQUENCE OF the DirectoryString ASN.1 type.
caseIgnoreListSubstringsMatchルールは、対応するASN.1タイプDirectoryString ASN.1タイプのシーケンスである構文（例えば、郵便アドレス構文）の属性値にサブストリングアサーション構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the assertion value matches, per the caseIgnoreSubstringsMatch rule, the character string formed by concatenating the strings of the attribute value, except that none of the <initial>, <any>, or <final> substrings of the assertion value are considered to match a substring of the concatenated string which spans more than one of the original strings of the attribute value.
ルールがTRUEと評価された場合と主張値は、caseIgnoreSubstringsMatchルール、<イニシャル>のどれを除いて、属性値の文字列を連結することによって形成された文字列、あたり、<任意の>、または<最終>のサブストリングと一致した場合にのみ、アサーション値の属性値の元の文字列の複数にまたがる連結文字列の部分文字列に一致すると考えられています。
Note that, in terms of the LDAP-specific encoding of the Postal Address syntax, the concatenated string omits the <DOLLAR> line separator and the escaping of "\" and "$" characters.
住所構文のLDAP固有のエンコードの観点から、連結した文字列は、<DOLLAR>行区切りと「\」と「$」文字のエスケープを省略し、ことに注意してください。
The LDAP definition for the caseIgnoreListSubstringsMatch rule is:
caseIgnoreListSubstringsMatchルールのLDAP定義は次のとおりです。
( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
（2.5.13.12 NAME 'caseIgnoreListSubstringsMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
SYNTAX 1.3.6.1.4.1.1466.115.121.1.58）
The caseIgnoreListSubstringsMatch rule is a substrings matching rule.
caseIgnoreListSubstringsMatch規則は、ストリングマッチングルールです。
The caseIgnoreMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
caseIgnoreMatchルールは（例えば、ディレクトリ文字列、表示可能な文字列、国文字列、または電話番号構文）に対応するASN.1タイプはDirectoryStringまたはその代替のひとつれる構文の属性値にディレクトリ文字列構文の主張値を比較し、文字列型。
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
ルールがTRUEと評価された場合、準備属性値の文字列と準備アサーション値の文字列は、文字の同じ番号を持って、対応する文字が同じコードポイントを持っている場合にのみ。
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のために、属性値と主張値を調製する際に、文字が地図作製工程で折り畳まれた場合であり、唯一の意味のない空白の扱いは無意味な文字の処理ステップで適用されます。
The LDAP definition for the caseIgnoreMatch rule is:
caseIgnoreMatchルールのLDAP定義は次のとおりです。
( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）
The caseIgnoreMatch rule is an equality matching rule.
caseIgnoreMatchルールはルールに一致平等です。
The caseIgnoreOrderingMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
caseIgnoreOrderingMatchルールは（例えば、ディレクトリ文字列、表示可能な文字列、国文字列、または電話番号構文）に対応するASN.1タイプはDirectoryStringまたはその代替のひとつれる構文の属性値にディレクトリ文字列構文の主張値を比較し、文字列型。
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value.
ルールは、コードポイント照合順序、準備された属性値の文字列が用意さアサーション値の文字列よりも先に表示された中で、場合に限り、TRUEと評価します。すなわち、属性値は、アサーション値「未満」です。
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のために、属性値と主張値を調製する際に、文字が地図作製工程で折り畳まれた場合であり、唯一の意味のない空白の扱いは無意味な文字の処理ステップで適用されます。
The LDAP definition for the caseIgnoreOrderingMatch rule is:
caseIgnoreOrderingMatchルールのLDAP定義は次のとおりです。
( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（2.5.13.3 NAME 'caseIgnoreOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）
The caseIgnoreOrderingMatch rule is an ordering matching rule.
caseIgnoreOrderingMatchルールはルールに一致する順序です。
The caseIgnoreSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Directory String, Printable String, Country String, or Telephone Number syntax) whose corresponding ASN.1 type is DirectoryString or one of its alternative string types.
caseIgnoreSubstringsMatchルールは（例えば、ディレクトリ文字列、表示可能な文字列、国文字列、または電話番号構文）に対応するASN.1タイプはDirectoryStringまたはその代替のひとつれる構文の属性値にサブストリングのアサーション構文の主張値を比較し、文字列型。
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
ルールがあれば、場合にのみ（1）アサーション値の一致の調製ストリング主張値のサブストリングのために準備された属性値文字列の互いに素な部分、（2）<初期>サブTRUEと評価します現在、準備された属性値の文字列の先頭にマッチし、（3）<最終>のサブストリングは、存在する場合、準備された属性値の文字列の末尾にマッチします。対応する文字が同じコードポイントを持っている場合、準備された部分文字列は、準備された属性値の文字列の部分と一致します。
In preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only Insignificant Space Handling is applied in the Insignificant Character Handling step.
比較のために、属性値と主張値のサブストリングを調製する際に、文字が地図作製工程で折り畳まれた場合であり、唯一の意味のない空白の扱いは無意味な文字の処理ステップで適用されます。
The LDAP definition for the caseIgnoreSubstringsMatch rule is:
caseIgnoreSubstringsMatchルールのLDAP定義は次のとおりです。
( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
（2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58）
The caseIgnoreSubstringsMatch rule is a substrings matching rule.
caseIgnoreSubstringsMatch規則は、ストリングマッチングルールです。
The directoryStringFirstComponentMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory first component of the DirectoryString ASN.1 type.
directoryStringFirstComponentMatchルールは、対応するASN.1タイプDirectoryString ASN.1タイプの必須の第一の成分を有する配列である構文の属性値ディレクトリ文字列構文のアサーション値を比較します。
Note that the assertion syntax of this matching rule differs from the attribute syntax of attributes for which this is the equality matching rule.
このマッチング規則のアサーション構文は、これが平等に一致するルールであるため、属性の属性構文は異なることに注意してください。
The rule evaluates to TRUE if and only if the assertion value matches the first component of the attribute value using the rules of caseIgnoreMatch.
ルールがTRUEと評価され、主張値がcaseIgnoreMatchの規則を使用して属性値の最初の成分と一致する場合にのみ。
The LDAP definition for the directoryStringFirstComponentMatch matching rule is:
directoryStringFirstComponentMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（2.5.13.31 NAME 'directoryStringFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）
The directoryStringFirstComponentMatch rule is an equality matching rule. When using directoryStringFirstComponentMatch to compare two attribute values (of an applicable syntax), an assertion value must first be derived from one of the attribute values. An assertion value can be derived from an attribute value by taking the first component of that attribute value.
directoryStringFirstComponentMatchルールはルールに一致平等です。 （適用可能なシンタックスの）2つの属性値を比較するdirectoryStringFirstComponentMatchを使用する場合、アサーション値は、第1の属性値の1つに由来しなければなりません。アサーションの値は、その属性値の最初の成分を取ることによって、属性値から導出することができます。
The distinguishedNameMatch rule compares an assertion value of the DN syntax to an attribute value of a syntax (e.g., the DN syntax) whose corresponding ASN.1 type is DistinguishedName.
distinguishedNameMatchルールは、対応するASN.1タイプ識別名である構文（例えば、DNシンタックス）の属性値にDNシンタックスのアサーション値を比較します。
The rule evaluates to TRUE if and only if the attribute value and the assertion value have the same number of relative distinguished names and corresponding relative distinguished names (by position) are the same. A relative distinguished name (RDN) of the assertion value is the same as an RDN of the attribute value if and only if they have the same number of attribute value assertions and each attribute value assertion (AVA) of the first RDN is the same as the AVA of the second RDN with the same attribute type. The order of the AVAs is not significant. Also note that a particular attribute type may appear in at most one AVA in an RDN. Two AVAs with the same attribute type are the same if their values are equal according to the equality matching rule of the attribute type. If one or more of the AVA comparisons evaluate to Undefined and the remaining AVA comparisons return TRUE then the distinguishedNameMatch rule evaluates to Undefined.
ルールがTRUEと評価された場合、属性値と主張値は、相対識別名の同じ数を有し、（位置して）相対識別名に対応する同じである場合にのみ。それらは、属性値アサーションの同じ数を有し、第一のRDNの各属性値アサーション（AVA）が同じである場合だけアサーション値の相対識別名（RDN）は、属性値のRDNと同じです同じ属性の型を有する第二RDNのAVA。 AVAの順序は重要ではありません。また、特定の属性タイプは、RDNに最大1つのAVAに表示される可能性があることに注意。それらの値は、属性タイプの等価マッチング規則に従って等しい場合、同じ属性タイプを有する2つのAVAは同じです。 AVAの比較の1つ以上が未定義に評価し、残りのAVAの比較がTRUEを返す場合、distinguishedNameMatchルールは未定義と評価されます。
The LDAP definition for the distinguishedNameMatch rule is:
distinguishedNameMatchルールのLDAP定義は次のとおりです。
( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 )
（2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12）
The distinguishedNameMatch rule is an equality matching rule.
distinguishedNameMatchルールはルールに一致平等です。
The generalizedTimeMatch rule compares an assertion value of the Generalized Time syntax to an attribute value of a syntax (e.g., the Generalized Time syntax) whose corresponding ASN.1 type is GeneralizedTime.
generalizedTimeMatchルールは、対応するASN.1タイプGeneralizedTimeのある構文（例えば、汎用時間構文）の属性値に一般時間構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the attribute value represents the same universal coordinated time as the assertion value. If a time is specified with the minutes or seconds absent, then the number of minutes or seconds (respectively) is assumed to be zero.
ルールがTRUEと評価された場合、属性値は、アサーション値と同じ協定世界時間を表す場合にのみ。時間が存在しない分または秒で指定されている場合は、（それぞれ）分または秒数がゼロであると仮定されます。
The LDAP definition for the generalizedTimeMatch rule is:
generalizedTimeMatchルールのLDAP定義は次のとおりです。
( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
（2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24）
The generalizedTimeMatch rule is an equality matching rule.
generalizedTimeMatchルールはルールに一致平等です。
The generalizedTimeOrderingMatch rule compares the time ordering of an assertion value of the Generalized Time syntax to an attribute value of a syntax (e.g., the Generalized Time syntax) whose corresponding ASN.1 type is GeneralizedTime.
generalizedTimeOrderingMatchルールは、対応するASN.1タイプGeneralizedTimeのある構文（例えば、汎用時間構文）の属性値に一般時間構文のアサーション値の時間順序を比較します。
The rule evaluates to TRUE if and only if the attribute value represents a universal coordinated time that is earlier than the universal coordinated time represented by the assertion value.
ルールがTRUEと評価された場合、属性値は、アサーション値によって表される協定世界時よりも前である協定世界時間を表す場合にのみ。
The LDAP definition for the generalizedTimeOrderingMatch rule is:
generalizedTimeOrderingMatchルールのLDAP定義は次のとおりです。
( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
（2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24）
The generalizedTimeOrderingMatch rule is an ordering matching rule.
generalizedTimeOrderingMatchルールはルールに一致する順序です。
The integerFirstComponentMatch rule compares an assertion value of the Integer syntax to an attribute value of a syntax (e.g., the DIT Structure Rule Description syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory first component of the INTEGER ASN.1 type.
integerFirstComponentMatchルールは、対応するASN.1タイプが整数ASN.1タイプの必須の第一の成分を有する配列である構文（例えば、DIT構造ルールの説明構文）の属性値の整数構文のアサーション値を比較します。
Note that the assertion syntax of this matching rule differs from the attribute syntax of attributes for which this is the equality matching rule.
このマッチング規則のアサーション構文は、これが平等に一致するルールであるため、属性の属性構文は異なることに注意してください。
The rule evaluates to TRUE if and only if the assertion value and the first component of the attribute value are the same integer value.
ルールがTRUEと評価された場合と主張値と属性値の最初の成分は同じ整数値である場合にのみ。
The LDAP definition for the integerFirstComponentMatch matching rule is:
integerFirstComponentMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.29 NAME 'integerFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
（2.5.13.29 NAME 'integerFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27）
The integerFirstComponentMatch rule is an equality matching rule. When using integerFirstComponentMatch to compare two attribute values (of an applicable syntax), an assertion value must first be derived from one of the attribute values. An assertion value can be derived from an attribute value by taking the first component of that attribute value.
integerFirstComponentMatchルールはルールに一致平等です。 （適用可能なシンタックスの）2つの属性値を比較するintegerFirstComponentMatchを使用する場合、アサーション値は、第1の属性値の1つに由来しなければなりません。アサーションの値は、その属性値の最初の成分を取ることによって、属性値から導出することができます。
The integerMatch rule compares an assertion value of the Integer syntax to an attribute value of a syntax (e.g., the Integer syntax) whose corresponding ASN.1 type is INTEGER.
integerMatchルールは、対応するASN.1タイプINTEGERである構文（例えば、整数構文）の属性値の整数構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the attribute value and the assertion value are the same integer value.
ルールがTRUEと評価された場合、属性値と主張値が同じ整数値である場合にのみ。
The LDAP definition for the integerMatch matching rule is:
integerMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.14 NAME 'integerMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
（2.5.13.14 NAME 'integerMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27）
The integerMatch rule is an equality matching rule.
integerMatchルールはルールに一致平等です。
The integerOrderingMatch rule compares an assertion value of the Integer syntax to an attribute value of a syntax (e.g., the Integer syntax) whose corresponding ASN.1 type is INTEGER.
integerOrderingMatchルールは、対応するASN.1タイプINTEGERである構文（例えば、整数構文）の属性値の整数構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the integer value of the attribute value is less than the integer value of the assertion value.
ルールがTRUEと評価された場合、属性値の整数値は、アサーション値の整数値未満である場合にのみ。
The LDAP definition for the integerOrderingMatch matching rule is:
integerOrderingMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.15 NAME 'integerOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
（2.5.13.15 NAME 'integerOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27）
The integerOrderingMatch rule is an ordering matching rule.
integerOrderingMatchルールはルールに一致する順序です。
The keywordMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax) whose corresponding ASN.1 type is DirectoryString.
キーワード一致ルールは、対応するASN.1タイプDirectoryStringある構文（例えば、ディレクトリ文字列構文）の属性値ディレクトリ文字列構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the assertion value character string matches any keyword in the attribute value. The identification of keywords in the attribute value and the exactness of the match are both implementation specific.
主張値文字列が属性値のいずれかのキーワードに一致する場合にだけルールがTRUEと評価されます。属性値のキーワードの識別および一致の正確さは、両方の実装固有です。
The LDAP definition for the keywordMatch rule is:
キーワード一致ルールのLDAP定義は次のとおりです。
( 2.5.13.33 NAME 'keywordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（2.5.13.33 NAME 'キーワード一致' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）
The numericStringMatch rule compares an assertion value of the Numeric String syntax to an attribute value of a syntax (e.g., the Numeric String syntax) whose corresponding ASN.1 type is NumericString.
numericStringMatchルールは、対応するASN.1タイプがNumericStringある構文（例えば、数字列構文）の属性値に数値文字列の構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
ルールがTRUEと評価された場合、準備属性値の文字列と準備アサーション値の文字列は、文字の同じ番号を持って、対応する文字が同じコードポイントを持っている場合にのみ。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only numericString Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のための属性値と主張値を調製する際に、文字が地図作製工程で折り畳ま場合ではない、とだけnumericString無意味な文字の扱いは無意味な文字の処理ステップで適用されます。
The LDAP definition for the numericStringMatch matching rule is:
numericStringMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
（2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36）
The numericStringMatch rule is an equality matching rule.
numericStringMatchルールはルールに一致平等です。
The numericStringOrderingMatch rule compares an assertion value of the Numeric String syntax to an attribute value of a syntax (e.g., the Numeric String syntax) whose corresponding ASN.1 type is NumericString.
numericStringOrderingMatchルールは、対応するASN.1タイプがNumericStringある構文（例えば、数字列構文）の属性値に数値文字列の構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if, in the code point collation order, the prepared attribute value character string appears earlier than the prepared assertion value character string; i.e., the attribute value is "less than" the assertion value.
ルールは、コードポイント照合順序、準備された属性値の文字列が用意さアサーション値の文字列よりも先に表示された中で、場合に限り、TRUEと評価します。すなわち、属性値は、アサーション値「未満」です。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only numericString Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のための属性値と主張値を調製する際に、文字が地図作製工程で折り畳ま場合ではない、とだけnumericString無意味な文字の扱いは無意味な文字の処理ステップで適用されます。
The rule is identical to the caseIgnoreOrderingMatch rule except that all space characters are skipped during comparison (case is irrelevant as the characters are numeric).
ルールは、すべての空白文字を比較（文字が数字である場合としては、無関係である）中にスキップされていることを除いcaseIgnoreOrderingMatchルールと同一です。
The LDAP definition for the numericStringOrderingMatch matching rule is:
numericStringOrderingMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.9 NAME 'numericStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 )
（2.5.13.9 NAME 'numericStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36）
The numericStringOrderingMatch rule is an ordering matching rule.
numericStringOrderingMatchルールはルールに一致する順序です。
The numericStringSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Numeric String syntax) whose corresponding ASN.1 type is NumericString.
numericStringSubstringsMatchルールは、対応するASN.1タイプがNumericStringある構文（例えば、数字列構文）の属性値にサブストリングアサーション構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
ルールがあれば、場合にのみ（1）アサーション値の一致の調製ストリング主張値のサブストリングのために準備された属性値文字列の互いに素な部分、（2）<初期>サブTRUEと評価します現在、準備された属性値の文字列の先頭にマッチし、（3）<最終>のサブストリングは、存在する場合、準備された属性値の文字列の末尾にマッチします。対応する文字が同じコードポイントを持っている場合、準備された部分文字列は、準備された属性値の文字列の部分と一致します。
In preparing the attribute value and assertion value for comparison, characters are not case folded in the Map preparation step, and only numericString Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のための属性値と主張値を調製する際に、文字が地図作製工程で折り畳ま場合ではない、とだけnumericString無意味な文字の扱いは無意味な文字の処理ステップで適用されます。
The LDAP definition for the numericStringSubstringsMatch matching rule is:
numericStringSubstringsMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
（2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58）
The numericStringSubstringsMatch rule is a substrings matching rule.
numericStringSubstringsMatch規則は、ストリングマッチングルールです。
The objectIdentifierFirstComponentMatch rule compares an assertion value of the OID syntax to an attribute value of a syntax (e.g., the Attribute Type Description, DIT Content Rule Description, LDAP Syntax Description, Matching Rule Description, Matching Rule Use Description, Name Form Description, or Object Class Description syntax) whose corresponding ASN.1 type is a SEQUENCE with a mandatory first component of the OBJECT IDENTIFIER ASN.1 type.
objectIdentifierFirstComponentMatchルールは、構文の属性値（例えば、属性タイプ説明、DITコンテンツルールの説明、LDAP構文説明、ルールの説明をマッチングルールの使用説明をマッチング、名前の形式説明、またはオブジェクトへのOIDの構文の主張値を比較し、その対応するASN.1タイプクラス説明構文）は、オブジェクト識別子ASN.1タイプの必須の第一の成分を有する配列です。
Note that the assertion syntax of this matching rule differs from the attribute syntax of attributes for which this is the equality matching rule.
このマッチング規則のアサーション構文は、これが平等に一致するルールであるため、属性の属性構文は異なることに注意してください。
The rule evaluates to TRUE if and only if the assertion value matches the first component of the attribute value using the rules of objectIdentifierMatch.
アサーション値がobjectIdentifierMatchの規則を使用して属性値の最初の成分と一致する場合にのみ場合にルールがTRUEと評価されます。
The LDAP definition for the objectIdentifierFirstComponentMatch matching rule is:
objectIdentifierFirstComponentMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
（2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38）
The objectIdentifierFirstComponentMatch rule is an equality matching rule. When using objectIdentifierFirstComponentMatch to compare two attribute values (of an applicable syntax), an assertion value must first be derived from one of the attribute values. An assertion value can be derived from an attribute value by taking the first component of that attribute value.
objectIdentifierFirstComponentMatchルールはルールに一致平等です。 （適用可能なシンタックスの）2つの属性値を比較するobjectIdentifierFirstComponentMatchを使用する場合、アサーション値は、第1の属性値の1つに由来しなければなりません。アサーションの値は、その属性値の最初の成分を取ることによって、属性値から導出することができます。
The objectIdentifierMatch rule compares an assertion value of the OID syntax to an attribute value of a syntax (e.g., the OID syntax) whose corresponding ASN.1 type is OBJECT IDENTIFIER.
objectIdentifierMatchルールは、対応するASN.1型オブジェクト識別子である構文（例えば、OID構文）の属性値にOID構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the assertion value and the attribute value represent the same object identifier; that is, the same sequence of integers, whether represented explicitly in the <numericoid> form of <oid> or implicitly in the <descr> form (see [RFC4512]).
規則がTRUEと評価された場合と主張値及び属性値が同じオブジェクト識別子を表す場合にのみ。すなわち、（[RFC4512]を参照）<OID>または暗黙的に<DESCR>形式での<numericoid>形で明示的に示されるか否か、整数の同じシーケンスです。
If an LDAP client supplies an assertion value in the <descr> form and the chosen descriptor is not recognized by the server, then the objectIdentifierMatch rule evaluates to Undefined.
LDAPクライアントは、<DESCR>フォームでアサーション値を供給し、選択した記述子がサーバによって認識されない場合は、objectIdentifierMatchルールは未定義と評価されます。
The LDAP definition for the objectIdentifierMatch matching rule is:
objectIdentifierMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
（2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38）
The objectIdentifierMatch rule is an equality matching rule.
objectIdentifierMatchルールはルールに一致平等です。
The octetStringMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING ASN.1 type.
octetStringMatchルールは、対応するASN.1タイプがオクテットストリングASN.1型で構文（例えば、オクテットストリングまたはJPEG構文）の属性値にオクテット文字列構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the attribute value and the assertion value are the same length and corresponding octets (by position) are the same.
ルールがTRUEと評価された属性値と主張値（位置によって）同じ長さと対応するオクテットである場合にのみ同じです。
The LDAP definition for the octetStringMatch matching rule is:
octetStringMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
（2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40）
The octetStringMatch rule is an equality matching rule.
octetStringMatchルールはルールに一致平等です。
The octetStringOrderingMatch rule compares an assertion value of the Octet String syntax to an attribute value of a syntax (e.g., the Octet String or JPEG syntax) whose corresponding ASN.1 type is the OCTET STRING ASN.1 type.
octetStringOrderingMatchルールは、対応するASN.1タイプがオクテットストリングASN.1型で構文（例えば、オクテットストリングまたはJPEG構文）の属性値にオクテット文字列構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the attribute value appears earlier in the collation order than the assertion value. The rule compares octet strings from the first octet to the last octet, and from the most significant bit to the least significant bit within the octet. The first occurrence of a different bit determines the ordering of the strings. A zero bit precedes a one bit. If the strings contain different numbers of octets but the longer string is identical to the shorter string up to the length of the shorter string, then the shorter string precedes the longer string.
ルールがTRUEと評価された場合、属性値は、以前の主張値よりも照合順序で表示されている場合のみ。ルールは最後のオクテットに最初のオクテットからのオクテット文字列を比較し、最上位ビットからのオクテット内の最下位ビットへ。異なるビットの最初の発生は、文字列の順序を決定します。ゼロビットが1ビットに先行します。文字列はオクテットの異なる数字を含むが、より長い文字列が短い文字列の長さまで短く文字列と同一であれば、より短い文字列が長い文字列の前に。
The LDAP definition for the octetStringOrderingMatch matching rule is:
octetStringOrderingMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.18 NAME 'octetStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )
（2.5.13.18 NAME 'octetStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40）
The octetStringOrderingMatch rule is an ordering matching rule.
octetStringOrderingMatchルールはルールに一致する順序です。
The telephoneNumberMatch rule compares an assertion value of the Telephone Number syntax to an attribute value of a syntax (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is a PrintableString representing a telephone number.
telephoneNumberMatchルールはASN.1タイプに対応する電話番号を表わすはPrintableStringであるシンタクス（例えば、電話番号構文）の属性値に電話番号構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the prepared attribute value character string and the prepared assertion value character string have the same number of characters and corresponding characters have the same code point.
ルールがTRUEと評価された場合、準備属性値の文字列と準備アサーション値の文字列は、文字の同じ番号を持って、対応する文字が同じコードポイントを持っている場合にのみ。
In preparing the attribute value and assertion value for comparison, characters are case folded in the Map preparation step, and only telephoneNumber Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のために、属性値と主張値を調製する際に、文字が地図作製工程で折り畳まれた場合であり、唯一のtelephoneNumberの無意味な文字の扱いは無意味な文字の処理ステップで適用されます。
The LDAP definition for the telephoneNumberMatch matching rule is:
telephoneNumberMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )
（2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50）
The telephoneNumberMatch rule is an equality matching rule.
telephoneNumberMatchルールはルールに一致平等です。
The telephoneNumberSubstringsMatch rule compares an assertion value of the Substring Assertion syntax to an attribute value of a syntax (e.g., the Telephone Number syntax) whose corresponding ASN.1 type is a PrintableString representing a telephone number.
telephoneNumberSubstringsMatchルールは、対応するASN.1タイプは、電話番号を表わすはPrintableStringであるシンタクス（例えば、電話番号構文）の属性値にサブストリングアサーション構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if (1) the prepared substrings of the assertion value match disjoint portions of the prepared attribute value character string in the order of the substrings in the assertion value, (2) an <initial> substring, if present, matches the beginning of the prepared attribute value character string, and (3) a <final> substring, if present, matches the end of the prepared attribute value character string. A prepared substring matches a portion of the prepared attribute value character string if corresponding characters have the same code point.
ルールがあれば、場合にのみ（1）アサーション値の一致の調製ストリング主張値のサブストリングのために準備された属性値文字列の互いに素な部分、（2）<初期>サブTRUEと評価します現在、準備された属性値の文字列の先頭にマッチし、（3）<最終>のサブストリングは、存在する場合、準備された属性値の文字列の末尾にマッチします。対応する文字が同じコードポイントを持っている場合、準備された部分文字列は、準備された属性値の文字列の部分と一致します。
In preparing the attribute value and assertion value substrings for comparison, characters are case folded in the Map preparation step, and only telephoneNumber Insignificant Character Handling is applied in the Insignificant Character Handling step.
比較のために、属性値と主張値のサブストリングを調製する際に、文字が地図作製工程で折り畳まれた場合であり、唯一のtelephoneNumberの無意味な文字の扱いは無意味な文字の処理ステップで適用されます。
The LDAP definition for the telephoneNumberSubstringsMatch matching rule is:
telephoneNumberSubstringsMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 )
（2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58）
The telephoneNumberSubstringsMatch rule is a substrings matching rule.
telephoneNumberSubstringsMatch規則は、ストリングマッチングルールです。
The uniqueMemberMatch rule compares an assertion value of the Name And Optional UID syntax to an attribute value of a syntax (e.g., the Name And Optional UID syntax) whose corresponding ASN.1 type is NameAndOptionalUID.
uniqueMemberMatchルール構文（例えば、名前および任意のUID構文）は、その対応するASN.1タイプNameAndOptionalUIDでの属性値に名前およびオプションのUID構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the <distinguishedName> components of the assertion value and attribute value match according to the distinguishedNameMatch rule and either, (1) the <BitString> component is absent from both the attribute value and assertion value, or (2) the <BitString> component is present in both the attribute value and the assertion value and the <BitString> component of the assertion value matches the <BitString> component of the attribute value according to the bitStringMatch rule.
アサーション値及び属性値一致の<distinguishedNameの>構成要素のいずれかdistinguishedNameMatchルールとに応じた場合にのみ、（1）<ビット文字列>コンポーネントは、属性値と主張値、またはその両方に存在しない場合にルールがTRUEと評価します（2）<ビットストリング>要素は、属性値と主張値の両方に存在すると主張値の<ビット列>成分はbitStringMatch規則に従って属性値の<ビット列>成分と一致します。
Note that this matching rule has been altered from its description in X.520 [X.520] in order to make the matching rule commutative. Server implementors should consider using the original X.520 semantics (where the matching was less exact) for approximate matching of attributes with uniqueMemberMatch as the equality matching rule.
このマッチングルールが一致するルールが可換にするために、X.520 [X.520]にその説明から変更されていることに留意されたいです。サーバーの実装は、ルールに一致平等などuniqueMemberMatchと属性のおおよそのマッチングのために（マッチングがあまり正確だった）オリジナルのX.520セマンティクスを使用して検討すべきです。
The LDAP definition for the uniqueMemberMatch matching rule is:
uniqueMemberMatchマッチングルールのLDAP定義は次のとおりです。
( 2.5.13.23 NAME 'uniqueMemberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 )
（2.5.13.23 NAME 'uniqueMemberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.34）
The uniqueMemberMatch rule is an equality matching rule.
uniqueMemberMatchルールはルールに一致平等です。
The wordMatch rule compares an assertion value of the Directory String syntax to an attribute value of a syntax (e.g., the Directory String syntax) whose corresponding ASN.1 type is DirectoryString.
wordMatchルールは、対応するASN.1タイプDirectoryStringある構文（例えば、ディレクトリ文字列構文）の属性値ディレクトリ文字列構文のアサーション値を比較します。
The rule evaluates to TRUE if and only if the assertion value word matches, according to the semantics of caseIgnoreMatch, any word in the attribute value. The precise definition of a word is implementation specific.
ルールがTRUEと評価された場合と主張値ワードが一致した場合にのみ、caseIgnoreMatch、属性値の任意の単語の意味に応じました。単語の正確な定義は実装固有のものです。
The LDAP definition for the wordMatch rule is:
wordMatchルールのLDAP定義は次のとおりです。
( 2.5.13.32 NAME 'wordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（2.5.13.32 NAME 'wordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）
In general, the LDAP-specific encodings for syntaxes defined in this document do not define canonical encodings. That is, a transformation from an LDAP-specific encoding into some other encoding (e.g., BER) and back into the LDAP-specific encoding will not necessarily reproduce exactly the original octets of the LDAP-specific encoding. Therefore, an LDAP-specific encoding should not be used where a canonical encoding is required.
一般的には、この文書で定義された構文のためのLDAP固有のエンコーディングは、標準的なエンコーディングを定義していません。すなわち、いくつかの他の符号化（例えば、BER）にLDAP固有のエンコーディングからの変換であり、バックLDAP固有の符号化に必ずしもLDAP固有の符号化の正確元のオクテットを再現しないであろう。正規の符号化が要求されるため、LDAP固有のエンコーディングが使用されるべきではありません。
Furthermore, the LDAP-specific encodings do not necessarily enable an alternative encoding of values of the Directory String and DN syntaxes to be reconstructed; e.g., a transformation from a Distinguished Encoding Rules (DER) [BER] encoding to an LDAP-specific encoding and back to a DER encoding may not reproduce the original DER encoding. Therefore, LDAP-specific encodings should not be used where reversibility to DER is needed; e.g., for the verification of digital signatures. Instead, DER or a DER-reversible encoding should be used.
また、LDAP固有の符号化は、必ずしも再構成するディレクトリ列とDN構文の値の別のエンコーディングを有効にしません。例えば、識別符号化規則（DER）[BER] LDAP固有の符号に符号化し、バックDERエンコーディングへの変換は、元のDER符号化を再現しないことができます。 DERに対して可逆が必要とされるため、LDAP固有のエンコーディングが使用されるべきではありません。例えば、デジタル署名の検証のための。代わりに、DERまたはDER-可逆符号化が使用されるべきです。
When interpreting security-sensitive fields (in particular, fields used to grant or deny access), implementations MUST ensure that any matching rule comparisons are done on the underlying abstract value, regardless of the particular encoding used.
（具体的には、フィールドがアクセスを許可または拒否するために使用される）セキュリティに敏感なフィールドを解釈する際に、実装は、任意のマッチング規則の比較に関係なく使用される特定の符号化の基礎となる抽象値で行われていることを確認しなければなりません。
This document is primarily a revision of RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, and S. Kille. RFC 2252 was a product of the IETF ASID Working Group.
この文書は、主M.ワール、A. Coulbeck、T.ハウズ、およびS. KilleによるRFC 2252の改訂版です。 RFC 2252は、IETF ASID作業部会の製品でした。
This document is based on input from the IETF LDAPBIS working group. The author would like to thank Kathy Dally for editing the early drafts of this document, and Jim Sermersheim and Kurt Zeilenga for their significant contributions to this revision.
このドキュメントはIETF LDAPBISワーキンググループからの入力に基づいています。著者は、この改正への重要な貢献のために早期に、この文書の草稿、そしてジム・SermersheimとクルトZeilengaを編集するためのキャシー・ダリーに感謝したいと思います。
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [BCP64] as indicated by the following templates:
以下のテンプレートによって示されるようにIANA（Internet Assigned Numbers Authority）はLDAP記述子レジストリ[BCP64]を更新しました：
Subject: Request for LDAP Descriptor Registration Update Descriptor (short name): see comment Object Identifier: see comment Person & email address to contact for further information: Steven Legg <steven.legg@eb2bcom.com> Usage: see comment Specification: RFC 4517 Author/Change Controller: IESG
件名：LDAP記述子登録更新記述子（短い名前）のための要求：コメントのオブジェクト識別子を参照してください：詳細のために連絡する人とEメールアドレスをコメント：スティーブン・レッグ<steven.legg@eb2bcom.com>使用方法：参照コメント仕様：RFC 4517著者/変更コントローラ：IESG
NAME Type OID
------------------------------------------------------------------
bitStringMatch M 2.5.13.16
booleanMatch M 2.5.13.13
caseExactIA5Match M 1.3.6.1.4.1.1466.109.114.1
caseExactMatch M 2.5.13.5
caseExactOrderingMatch M 2.5.13.6
caseExactSubstringsMatch M 2.5.13.7
caseIgnoreIA5Match M 1.3.6.1.4.1.1466.109.114.2
caseIgnoreListMatch M 2.5.13.11
caseIgnoreListSubstringsMatch M 2.5.13.12
caseIgnoreMatch M 2.5.13.2
caseIgnoreOrderingMatch M 2.5.13.3
caseIgnoreSubstringsMatch M 2.5.13.4
directoryStringFirstComponentMatch M 2.5.13.31
distinguishedNameMatch M 2.5.13.1
generalizedTimeMatch M 2.5.13.27
generalizedTimeOrderingMatch M 2.5.13.28
integerFirstComponentMatch M 2.5.13.29
integerMatch M 2.5.13.14
integerOrderingMatch M 2.5.13.15
keywordMatch M 2.5.13.33
numericStringMatch M 2.5.13.8
numericStringOrderingMatch M 2.5.13.9
numericStringSubstringsMatch M 2.5.13.10
objectIdentifierFirstComponentMatch M 2.5.13.30
octetStringMatch M 2.5.13.17
octetStringOrderingMatch M 2.5.13.18
telephoneNumberMatch M 2.5.13.20 telephoneNumberSubstringsMatch M 2.5.13.21
uniqueMemberMatch M 2.5.13.23
wordMatch M 2.5.13.32
The descriptor for the object identifier 2.5.13.0 was incorrectly registered as objectIdentifiersMatch (extraneous \`s') in BCP 64. It has been changed to the following, with a reference to RFC 4517.
オブジェクト識別子2.5.13.0の記述子が誤ってそれはRFC 4517を参照して、以下に変更されたBCP 64にobjectIdentifiersMatch（外来\ 'S'）として登録されました。
NAME Type OID
------------------------------------------------------------------
objectIdentifierMatch M 2.5.13.0
Subject: Request for LDAP Descriptor Registration Descriptor (short name): caseIgnoreIA5SubstringsMatch Object Identifier: 1.3.6.1.4.1.1466.109.114.3 Person & email address to contact for further information: Steven Legg <steven.legg@eb2bcom.com> Usage: other (M) Specification: RFC 4517 Author/Change Controller: IESG
件名：LDAP記述子登録記述子（短い名前）のための要求：caseIgnoreIA5SubstringsMatchオブジェクト識別子：1.3.6.1.4.1.1466.109.114.3人＆詳細のために連絡する電子メールアドレス：スティーブン・レッグ<steven.legg@eb2bcom.com>使用方法：他の（M）仕様：RFC 4517著者/変更コントローラ：IESG
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]クロッカー、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.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：技術仕様ロードマップ"。、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル"、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ディレクトリ情報モデル"、RFC 4512、2006年6月。
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：識別名の文字列表現"。、RFC 4514、2006年6月。
[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006.
[RFC4518] Zeilenga、K.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：国際化文字列の準備"、RFC 4518、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.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（LDAP）に関する考慮事項"、BCP 64、RFC 4520、2006年6月。
[E.123] Notation for national and international telephone numbers, ITU-T Recommendation E.123, 1988.
国内および国際電話番号の[E.123]表記、ITU-T勧告E.123、1988。
[FAX] Standardization of Group 3 facsimile apparatus for document transmission - Terminal Equipment and Protocols for Telematic Services, ITU-T Recommendation T.4, 1993
[FAX]文書伝送用グループ3ファクシミリ装置の標準化 - テレマティックサービス、ITU-T勧告T. 4用の端末装置とプロトコル、1993
[T.50] International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) Information Technology - 7-Bit Coded Character Set for Information Interchange, ITU-T Recommendation T.50, 1992
[T.50]国際リファレンスアルファベット（IRA）（旧世界アルファベット番号5またはIA5）情報技術 - 情報交換、ITU-T勧告T.50、1992年7ビットの符号化文字セット
[X.420] ITU-T Recommendation X.420 (1996) | ISO/IEC 10021-7:1997, Information Technology - Message Handling Systems (MHS): Interpersonal messaging system
[X.420] ITU-T勧告X.420（1996）| ISO / IEC 10021から7：1997、情報技術 - メッセージハンドリングシステム（MHS）：対人メッセージングシステム
[X.501] ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994, Information Technology - Open Systems Interconnection - The Directory: Models
[X.501] ITU-T勧告X.501（1993）| ISO / IEC 9594から2：1994、情報技術 - 開放型システム間相互接続 - ディレクトリ：モデル
[X.520] ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994, Information Technology - Open Systems Interconnection - The Directory: Selected attribute types
[X.520] ITU-T勧告X.520（1993）| ISO / IEC 9594から6：1994、情報技術 - 開放型システム間相互接続 - ディレクトリ：選択した属性タイプ
[ASN.1] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation
[ASN.1] ITU-T勧告X.680（7月2日）| ISO / IEC 8824から1：2002、情報技術 - 抽象構文記法1（ASN.1）：基本的な表記法の仕様
[ISO3166] ISO 3166, "Codes for the representation of names of countries".
[ISO3166] ISO 3166、「国の名前の表現のためのコード」。
[ISO8601] ISO 8601:2004, "Data elements and interchange formats -- Information interchange -- Representation of dates and times".
[ISO8601] ISO 8601：2004、「データ要素と交換フォーマット - 情報交換 - 日付と時刻の表現」。
[UCS] Universal Multiple-Octet Coded Character Set (UCS) - Architecture and Basic Multilingual Plane, ISO/IEC 10646- 1: 1993 (with amendments).
[UCS]ユニバーサルマルチオクテット符号化文字セット（UCS） - アーキテクチャと基本多言語面、ISO / IEC 10646- 1：1993（修正します）。
[JPEG] JPEG File Interchange Format (Version 1.02). Eric Hamilton, C-Cube Microsystems, Milpitas, CA, September 1, 1992.
[JPEG] JPEGファイル交換フォーマット（バージョン1.02）。エリック・ハミルトン、C-Cubeのマイクロ、ミルピタス、CA、1992年9月1日。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A.、エド、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：ユーザー・アプリケーションのためのスキーマ"。、RFC 4519、2006年6月。
[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.
[RFC4523] Zeilenga、K.、 "LDAP（Lightweight Directory Access Protocol）のX.509証明書のためのスキーマ定義"、RFC 4523、2006年6月。
[X.500] ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994, Information Technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services
[X.500] ITU-T勧告X.500（1993）| ISO / IEC 9594から1：1994、情報技術 - 開放型システム間相互接続 - ディレクトリ：概念、モデルとサービスの概要
[BER] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
[BER] ITU-T勧告X.690（7月2日）| ISO / IEC 8825から1：2002、情報技術 - ASN.1エンコーディング規則：基本符号化規則（BER）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）
Appendix A. Summary of Syntax Object Identifiers
構文オブジェクト識別子の付録A.概要
The following list summarizes the object identifiers assigned to the syntaxes defined in this document.
以下のリストは、この文書で定義された構文に割り当てられたオブジェクト識別子をまとめました。
Syntax OBJECT IDENTIFIER
==============================================================
Attribute Type Description 1.3.6.1.4.1.1466.115.121.1.3
Bit String 1.3.6.1.4.1.1466.115.121.1.6
Boolean 1.3.6.1.4.1.1466.115.121.1.7
Country String 1.3.6.1.4.1.1466.115.121.1.11
Delivery Method 1.3.6.1.4.1.1466.115.121.1.14
Directory String 1.3.6.1.4.1.1466.115.121.1.15
DIT Content Rule Description 1.3.6.1.4.1.1466.115.121.1.16
DIT Structure Rule Description 1.3.6.1.4.1.1466.115.121.1.17
DN 1.3.6.1.4.1.1466.115.121.1.12
Enhanced Guide 1.3.6.1.4.1.1466.115.121.1.21
Facsimile Telephone Number 1.3.6.1.4.1.1466.115.121.1.22
Fax 1.3.6.1.4.1.1466.115.121.1.23
Generalized Time 1.3.6.1.4.1.1466.115.121.1.24
Guide 1.3.6.1.4.1.1466.115.121.1.25
IA5 String 1.3.6.1.4.1.1466.115.121.1.26
Integer 1.3.6.1.4.1.1466.115.121.1.27
JPEG 1.3.6.1.4.1.1466.115.121.1.28
LDAP Syntax Description 1.3.6.1.4.1.1466.115.121.1.54
Matching Rule Description 1.3.6.1.4.1.1466.115.121.1.30
Matching Rule Use Description 1.3.6.1.4.1.1466.115.121.1.31
Name And Optional UID 1.3.6.1.4.1.1466.115.121.1.34
Name Form Description 1.3.6.1.4.1.1466.115.121.1.35
Numeric String 1.3.6.1.4.1.1466.115.121.1.36
Object Class Description 1.3.6.1.4.1.1466.115.121.1.37
Octet String 1.3.6.1.4.1.1466.115.121.1.40
OID 1.3.6.1.4.1.1466.115.121.1.38
Other Mailbox 1.3.6.1.4.1.1466.115.121.1.39
Postal Address 1.3.6.1.4.1.1466.115.121.1.41
Printable String 1.3.6.1.4.1.1466.115.121.1.44
Substring Assertion 1.3.6.1.4.1.1466.115.121.1.58
Telephone Number 1.3.6.1.4.1.1466.115.121.1.50
Teletex Terminal Identifier 1.3.6.1.4.1.1466.115.121.1.51
Telex Number 1.3.6.1.4.1.1466.115.121.1.52
UTC Time 1.3.6.1.4.1.1466.115.121.1.53
Appendix B. Changes from
付録B.変更から
This annex lists the significant differences between this specification and RFC 2252.
この附属書は、この仕様書とRFC 2252との間に有意差を示しています。
This annex is provided for informational purposes only. It is not a normative part of this specification.
この附属書は、情報提供のみを目的として提供されます。これは、この仕様の標準的な部分ではありません。
2. The major part of Sections 4, 5 and 7 has been moved to [RFC4512] and revised. Changes to the parts of these sections moved to [RFC4512] are detailed in [RFC4512].
2.セクション4,5、及び7の主要部分は、[RFC4512]に移動し、修正されました。これらのセクションの部分への変更は、[RFC4512]に詳述されている[RFC4512]に移動しました。
3. BNF descriptions of syntax formats have been replaced by ABNF [RFC4234] specifications.
構文フォーマットの3 BNFの記述は、ABNF [RFC4234]の仕様に置き換えられています。
4. The ambiguous statement in RFC 2252, Section 4.3 regarding the use of a backslash quoting mechanism to escape separator symbols has been removed. The escaping mechanism is now explicitly represented in the ABNF for the syntaxes where this provision applies.
RFC 2252 4.あいまいな文は、区切り記号をエスケープするためのメカニズムを引用バックスラッシュの使用に関するセクション4.3は削除されました。エスケープ機構は現在、明示的にこの規定が適用される構文についてABNFで表されます。
5. The description of each of the LDAP syntaxes has been expanded so that they are less dependent on knowledge of X.500 for interpretation.
彼らは解釈のためX.500の知識にあまり依存しているように5. LDAP構文のそれぞれの説明が拡張されました。
6. The relationship of LDAP syntaxes to corresponding ASN.1 type definitions has been made explicit.
6.対応するASN.1型定義にLDAP構文の関係が明示的に行われています。
7. The set of characters allowed in a <PrintableString> (formerly <printablestring>) has been corrected to align with the PrintableString ASN.1 type in [ASN.1]. Specifically, the double quote character has been removed and the single quote character and equals sign have been added.
7. <PrintableStringタイプ>（以前の<のprintablestring>）で許容される文字の組が[ASN.1]にはPrintableString ASN.1タイプに合わせて修正されています。具体的には、二重引用符を除去し、単一引用符と等号された追加されました。
8. Values of the Directory String, Printable String and Telephone Number syntaxes are now required to have at least one character.
ディレクトリ文字列、表示可能な文字列と電話番号構文の8.値は今、少なくとも一つの文字を持っている必要があります。
9. The <DITContentRuleDescription>, <NameFormDescription> and <DITStructureRuleDescription> rules have been moved to [RFC4512].
9. <DITContentRuleDescription>、<NameFormDescription>と<DITStructureRuleDescription>ルールは、[RFC4512]に移動されています。
10. The corresponding ASN.1 type for the Other Mailbox syntax has been incorporated from RFC 1274.
他のメールボックスの構文10.対応するASN.1タイプは、RFC 1274から組み込まれています。
11. A corresponding ASN.1 type for the LDAP Syntax Description syntax has been invented.
LDAP構文説明構文については、11に対応するASN.1タイプが発明されました。
12. The Binary syntax has been removed because it was not adequately specified, implementations with different incompatible interpretations exist, and it was confused with the ;binary transfer encoding.
12.バイナリ構文は、それが適切に指定されていないため、互換性のない異なる解釈を持つ実装が存在し、それと混同し取り除かれた、バイナリ転送エンコード。
13. All discussion of transfer options, including the ";binary" option, has been removed. All imperatives regarding binary transfer of values have been removed.
「;バイナリ」を含む転送オプションの13すべての議論のオプションは、削除されました。値のバイナリ転送に関するすべての要請が削除されました。
14. The Delivery Method, Enhanced Guide, Guide, Octet String, Teletex Terminal Identifier and Telex Number syntaxes from RFC 2256 have been incorporated.
14.配信方法、拡張ガイド、ガイド、オクテット文字列、テレテックス端末識別子およびRFC 2256からのテレックス番号構文が組み込まれています。
15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has been extended to accommodate empty "and" and "or" expressions.
15. <判定基準>が強化されたガイドとガイドの構文のルールは空「と」と「または」の表現に対応するために拡張されました。
16. An encoding for the <ttx-value> rule in the Teletex Terminal Identifier syntax has been defined.
16. <TTX-値>のエンコーディングテレテックス端末識別子構文でルールが定義されています。
17. The PKI-related syntaxes (Certificate, Certificate List and Certificate Pair) have been removed. They are reintroduced in [RFC4523] (as is the Supported Algorithm syntax from RFC 2256).
17. PKI関連シンタックス（証明書、証明書リストと証明書のペア）が除去されています。 （RFC 2256から支持アルゴリズム構文であるように）、彼らは[RFC4523]に再導入されます。
18. The MHS OR Address syntax has been removed since its specification (in RFC 2156) is not at draft standard maturity.
18. MHSまたはアドレスの構文は、（RFC 2156）でその仕様のドラフト標準の成熟度ではないため削除されました。
19. The DL Submit Permission syntax has been removed as it depends on the MHS OR Address syntax.
それはMHSまたはアドレスの構文に依存して19 DL送信許可構文が削除されました。
20. The Presentation Address syntax has been removed since its specification (in RFC 1278) is not at draft standard maturity.
20.プレゼンテーションアドレスの構文は（RFC 1278）でその仕様のドラフト標準の成熟度ではないため削除されました。
21. The ACI Item, Access Point, Audio, Data Quality, DSA Quality, DSE Type, LDAP Schema Description, Master And Shadow Access Points, Modify Rights, Protocol Information, Subtree Specification, Supplier Information, Supplier Or Consumer and Supplier And Consumer syntaxes have been removed. These syntaxes are referenced in RFC 2252, but not defined.
21. ACI項目、アクセスポイント、オーディオ、データ品質、DSA品質、DSEタイプ、LDAPスキーマ説明、マスターと影のアクセスポイント、変更の権利、プロトコル情報、サブツリー仕様、サプライヤ情報、サプライヤまたはコンシューマとサプライヤとコンシューマの構文削除されています。これらの構文は、RFC 2252で参照が、定義されていません。
22. The LDAP Schema Definition syntax (defined in RFC 2927) and the Mail Preference syntax have been removed on the grounds that they are out of scope for the core specification.
22.（RFC 2927で定義された）LDAPスキーマ定義の構文とメールプリファレンスの構文は、それらがコア仕様の範囲外であるという理由で削除されています。
23. The description of each of the matching rules has been expanded so that they are less dependent on knowledge of X.500 for interpretation.
彼らは解釈のためのX.500の知識にあまり依存しているように、23のマッチングルールのそれぞれの説明が拡張されています。
24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has been added.
RFC 2798から24 caseIgnoreIA5SubstringsMatchマッチングルールが追加されています。
25. The caseIgnoreListSubstringsMatch, caseIgnoreOrderingMatch and caseIgnoreSubstringsMatch matching rules have been added to the list of matching rules for which the provisions for handling leading, trailing and multiple adjoining whitespace characters apply (now through string preparation). This is consistent with the definitions of these matching rules in X.500. The caseIgnoreIA5SubstringsMatch rule has also been added to the list.
25 caseIgnoreListSubstringsMatch、caseIgnoreOrderingMatchとcaseIgnoreSubstringsMatchマッチング規則は末尾、主要処理するための規定に一致するルールのリストに追加されており、複数の隣接する空白文字は、（現在の文字列の準備を介して）適用します。これは、X.500でこれらの一致規則の定義と一致しています。 caseIgnoreIA5SubstringsMatchルールもリストに追加されました。
26. The specification of the octetStringMatch matching rule from RFC 2256 has been added to this document.
26 RFC 2256からoctetStringMatchマッチングルールの仕様は、この文書に追加されました。
27. The presentationAddressMatch matching rule has been removed as it depends on an assertion syntax (Presentation Address) that is not at draft standard maturity.
それはドラフト標準の成熟度ではなく、アサーション構文（プレゼンテーションアドレス）に依存して27 presentationAddressMatchマッチングルールが削除されました。
28. The protocolInformationMatch matching rule has been removed as it depends on an undefined assertion syntax (Protocol Information).
それは未定義のアサーション構文（プロトコル情報）に依存する28 protocolInformationMatchマッチングルールが削除されました。
29. The definitive reference for ASN.1 has been changed from X.208 to X.680 since X.680 is the version of ASN.1 referred to by X.500.
ASN.1のための決定的な基準は、X.680ためX.680にX.208から変更された29はASN.1のバージョンがX.500によって参照されます。
30. The specification of the caseIgnoreListSubstringsMatch matching rule from RFC 2798 & X.520 has been added.
RFC 2798とX.520からcaseIgnoreListSubstringsMatchマッチングルールの30の仕様が追加されています。
31. String preparation algorithms have been applied to the character string matching rules.
31.文字列の作成アルゴリズムは、文字列のマッチングルールに適用されています。
32. The specifications of the booleanMatch, caseExactMatch, caseExactOrderingMatch, caseExactSubstringsMatch, directoryStringFirstComponentMatch, integerOrderingMatch, keywordMatch, numericStringOrderingMatch, octetStringOrderingMatch and wordMatch matching rules from RFC 3698 & X.520 have been added.
RFC 3698とX.520からbooleanMatch、CaseExactMatchの、caseExactOrderingMatch、caseExactSubstringsMatch、directoryStringFirstComponentMatch、integerOrderingMatch、キーワード一致、numericStringOrderingMatch、octetStringOrderingMatchとwordMatchマッチングルールの32仕様が追加されています。
Author's Address
著者のアドレス
Steven Legg eB2Bcom Suite3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA
スティーブン・レッグ・eB2Bcom Suite3、ウッドハウスコーポレートセンター935駅ストリートボックスヒルノース、ビクトリア3129オーストラリア
Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com
電話：+61 3 9896 7830ファックス：+61 3 9896 7801 Eメール：steven.legg@eb2bcom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。