[要約] RFC 4517は、LDAPの構文とマッチングルールに関する規格であり、LDAPディレクトリへのアクセスを容易にするために設計されています。このRFCの目的は、LDAPの構文とマッチングルールの一貫性と互換性を確保することです。

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

LightWeight Directory Access Protocol(LDAP):構文と一致するルール

Status of This Memo

本文書の位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の現在のエディションを参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2006).

Copyright(c)The Internet Society(2006)。

Abstract

概要

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.

Lightweight Directory Access Protocol(LDAP)ディレクトリに保存されている各属性は、LDAPプロトコルで値が転送される可能性があるため、その値の構造と形式を制限する定義された構文があります。構文の値の比較セマンティクスは、構文定義の一部ではなく、個別に定義された一致するルールを通じて提供されます。一致するルールは、定義された構文もある引数、アサーション値を指定します。このドキュメントでは、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
        
1. Introduction
1. はじめに

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)ディレクトリ[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技術仕様[RFC4510]の不可欠な部分であり、以前に定義されたLDAP技術仕様であるRFC 3377全体を廃止します。

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.

RFC 2252のセクション4、5、および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で説明されています。

2. Conventions
2. 規約

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].

このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "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ルールに従って記述されます。このドキュメントでは、読みやすさのためにラインで包まれています。このような定義が、LDAPプロトコルの属性値として転送される場合(たとえば、LDAPSyntaxesおよびMatchingRules属性[RFC4512]の値として)、それらの値にはラインブレークが含まれません。

3. Syntaxes
3. 構文

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.

このセクションでは、ディレクトリ操作に必要な構文、または一般的な使用が必要な構文を指定します。サーバーは、このドキュメントにリストされているすべての構文を認識する必要がありますが、そうでなければそれらをサポートする必要はなく、他の構文を認識またはサポートする場合があります。ただし、追加の任意の構文の定義は、相互運用性を妨げるため、落胆します。通常、クライアントとサーバーの実装には、新しい構文を動的に認識する機能がありません。

3.1. General Considerations
3.1. 一般的な考慮事項

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]ディレクトリで使用される[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固有のエンコードは、常にOctetに並べられた値を生成します。可能な限り、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構文は、点線型識別子形式で表されるオブジェクト識別子[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.

文字列ベースの構文を持つ属性値の文字数の推奨最小上限、または他のすべての構文の値のオクテットの数は、Syntaxのオブジェクト識別子に従ってCurly Bracesの内側にバインドを追加することによって示される場合があります属性タイプ定義で([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.146.115.121.1.15 {64}」は、ディレクトリサーバーの値が最大64文字の長さであることを示唆していますが、文字列長が長くなる可能性があります。。UTF-8 [RFC3629]は可変長エンコードであるため、ディレクトリ文字列の構文の単一文字は複数のオクテットでエンコードできることに注意してください。したがって、64文字の文字列の長さは64オクテットを超える場合があります。

3.2. Common Definitions
3.2. 一般的な定義

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 /
                                 SLASH / COLON / QUESTION / SPACE
      PrintableString    = 1*PrintableCharacter
      IA5String          = *(%x00-7F)
      SLASH              = %x2F  ; forward slash ("/")
      COLON              = %x3A  ; colon (":")
      QUESTION           = %x3F  ; question mark ("?")
        

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>、<phiphen>、<dot>、<sacl>、および<Space>ルールは[で定義されています。RFC4512]。

3.3. Syntax Definitions
3.3. 構文定義
3.3.1. Attribute Type Description
3.3.1. 属性タイプの説明

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]の<astributeTypedescription>ルールによって定義されます。

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' equality generalizedtimematch generalizedtime-orderingmatch構文の注文1.3.6.1.4.1.1466.115.121.1.24単一値なしユーザー修正使用法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]の属性asn.1タイプに対応しています。

3.3.2. Bit String
3.3.2. ビット文字列

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"
        

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タイプに対応します。

3.3.3. Boolean
3.3.3. ブール

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:

ブールの構文の値は、真またはfalseのブール値の1つです。この構文の値のLDAP固有のエンコードは、次のABNFによって定義されます。

      Boolean = "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 'boolean')

This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].

この構文は、[ASN.1]のブールASN.1タイプに対応しています。

3.3.4. Country String
3.3.4. 国の文字列

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文字のコードの1つです。この構文の値のLDAP固有のエンコードは、次のABNFによって定義されます。

CountryString = 2(PrintableCharacter)

カントリーストリング= 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 'Country String')

This syntax corresponds to the following ASN.1 type from [X.520]:

この構文は、[x.520]の次のasn.1タイプに対応しています。

PrintableString (SIZE (2)) -- ISO 3166 codes only

PrintableString(サイズ(2)) - ISO 3166コードのみ

3.3.5. Delivery Method
3.3.5. 配信方法

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"
        

The <WSP> and <DOLLAR> rules are defined in [RFC4512].

<wsp>および<dollar>ルールは[RFC4512]で定義されています。

Example: telephone $ videotex

例:電話$ 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) }
        
3.3.6. Directory String
3.3.6. ディレクトリ文字列

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
        

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]からのテレットストリング、印刷、または普遍的なストリング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.

X.500で使用されるLDAP固有のエンコードからX.500で使用されるBERエンコーディングにディレクトリ文字列値を変換する実装は、文字列内の特定の文字を許可する代替手段を選択する必要があり、UTF-8エンコードから文字を文字エンコードに変換する必要があります。選択された代替。ディレクトリ文字列値をBERエンコードからLDAP固有のエンコードに変換する場合、文字は、選択した代替の文字エンコードからUTF-8エンコーディングに変換する必要があります。これらの変換は、LDAPの文字列準備アルゴリズム[RFC4518]のトランスコードステップと一致する方法で実行する必要があります。

3.3.7. DIT Content Rule Description
3.3.7. DITコンテンツルールの説明

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]のditcontentruledesscription.1タイプに対応しています。

3.3.8. DIT Structure Rule Description
3.3.8. DIT構造ルールの説明

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 '組織構造ルール'フォーム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]からのditStructureRedesscription.1タイプに対応しています。

3.3.9. DN
3.3.9. dn

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構文の値は、エントリ[RFC4512]の(dn)識別名(dn)です。この構文の値のLDAP固有のエンコーディングは、著名な名前[RFC4514]の文字列表現から<distinguedname>ルールによって定義されます。

      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
        

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]のdistinguedname asn.1タイプに対応します。LDAP固有のエンコードに再エンコードされたBERエンコードされた識別名(X.500で使用)は、著名な名前の任意のディレクトリストリングコンポーネントの選択された文字列タイプが選択されていないため、元のBERエンコーディングにとって必ずしも可逆的ではないことに注意してください。識別名のLDAP固有のエンコーディング(セクション3.3.6を参照)。

3.3.10. Enhanced Guide
3.3.10. 拡張ガイド

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"
        
      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 ("!")
        

The <SHARP>, <WSP>, <oid>, <LPAREN>, <RPAREN>, <attributetype>, and <DOLLAR> rules are defined in [RFC4512].

<sharp>、<wsp>、<oid>、<lparen>、<rparen>、<doliveType>、および<dollar>ルールは[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 'Enhanced Guide')

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]の拡張ガイドASN.1タイプに対応します。EnhancedGuideタイプは、[X.520]からの基準ASN.1タイプを参照しています。上記の<true>ルールは空を表します

"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.

"and"基準タイプの値の表現。上記の<false>ルールは、基準タイプの値の空の "または"式を表します。

3.3.11. Facsimile Telephone Number
3.3.11. ファクシミリの電話番号

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"

Fax-Number =電話番号 *(Dollar Fax-Parameter)電話番号= PrintableString Fax-Parameter = "Twodimensional" / "Fineresolution" / "UnlimitedLength" / "B4Length" / "A3Width" / "B4Width" / "" Uncompresded " /"

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で定義されています。<dollar>ルールは[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 'FACSIMILE電話番号')

The Facsimile Telephone Number syntax corresponds to the FacsimileTelephoneNumber ASN.1 type from [X.520].

ファクシミリの電話番号構文は、[x.520]のfacsimiletelephoneNumber asn.1タイプに対応しています。

3.3.12. Fax
3.3.12. ファックス

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].

Fax構文の値は、メモなどのオブジェクトを複製するためにグループ3ファクシミリプロセス[FAX]を使用して生成される画像です。この構文の値のLDAP固有のエンコードは、[FAX]で定義されているグループ3 FAXイメージのオクテットの文字列です。

The LDAP definition for the Fax syntax is:

FAX構文の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 'FAX')

The ASN.1 type corresponding to the Fax syntax is defined as follows, assuming EXPLICIT TAGS:

Fax構文に対応するASN.1タイプは、明示的なタグを仮定して、次のように定義されます。

      Fax ::= CHOICE {
        g3-facsimile  [3] G3FacsimileBodyPart
      }
        

The G3FacsimileBodyPart ASN.1 type is defined in [X.420].

G3FACSIMILEBODYPART ASN.1タイプは[X.420]で定義されています。

3.3.13. Generalized Time
3.3.13. 一般化された時間

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 =世紀の月の日時間[分[2秒 / leap-second]] [fraction] g-time-zone

      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"
        
      second      = ( %x30-35 %x30-39 ) ; "00" to "59"
      leap-second = ( %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 ("-")
        

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-time-zone>の「z」形式を使用する場合、調整された普遍的な時間(グリニッジ平均時間に相当)を表します。それ以外の場合、値は<g-differential>で示されるタイムゾーンのローカル時間を表します。後者の場合、協調的な普遍的な時間は、現地時間の差を差し引くことで計算できます。<g-time-zone>の「z」形式は、<g-differential>よりも優先して使用する必要があります。

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.

<minute>が省略されている場合、<分数>は1時間のほんの一部を表します。それ以外の場合、<second>および<Leap-second>が省略されている場合、<fraction>は1分間を表します。それ以外の場合、<分数>は1秒のほんの一部を表します。

Examples: 199412161032Z 199412160532-0500

例:199412161032Z 199412160532-0500

Both example values represent the same coordinated universal time: 10:32 AM, December 16, 1994.

両方の例の値は、1994年12月16日、午前10時32分、同じ調整された普遍的な時間を表しています。

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]の一般化された時間asn.1タイプに対応し、微分のない現地時間を使用しないという制約があります。

3.3.14. Guide
3.3.14. ガイド

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].

<Object-Class>および<criteria>ルールは、セクション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 'Guide')

The Guide syntax corresponds to the Guide ASN.1 type from [X.520].

ガイド構文は、[x.520]のガイドASN.1タイプに対応しています。

3.3.15. IA5 String
3.3.15. IA5文字列

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文字列構文の値は、ASCII文字セットの国際バージョンであるInternational Alphabet 5(IA5)[T.50]のゼロ、1つ、またはそれ以上の文字の文字列です。この構文の値のLDAP固有のエンコーディングは、セクション3.2の<ia5string>ルールに準拠している、非verted文字列の文字列です。

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 String')

This syntax corresponds to the IA5String ASN.1 type from [ASN.1].

この構文は、[asn.1]のia5string asn.1タイプに対応しています。

3.3.16. Integer
3.3.16. 整数

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」で表されます)。エンコーディングは、次のABNFによって定義されます。

      Integer = ( HYPHEN LDIGIT *DIGIT ) / number
        

The <HYPHEN>, <LDIGIT>, <DIGIT>, and <number> rules are defined in [RFC4512].

<ハイフン>、<ldigit>、<digit>、および<number>ルールは[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タイプに対応しています。

3.3.17. JPEG
3.3.17. jpeg

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 -- })
        
3.3.18. LDAP Syntax Description
3.3.18. LDAP構文の説明

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:

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].

UBSchema(整数)の値は、実装が定義されています。[x.520]には、非規範的な定義が表示されます。

3.3.19. Matching Rule Description
3.3.19. 一致するルールの説明

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'構文1.3.6.1.4.1.146.115.121.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]のmatchingRuledesscription.1タイプに対応しています。

3.3.20. Matching Rule Use Description
3.3.20. 一致するルールの使用説明

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].

一致するルールを使用する値説明構文は、拡張ビームルート検索フィルター[RFC4511]に一致するルールを適用できる属性タイプを示します。この構文の値のLDAP固有のエンコーディングは、[RFC4512]の<matchingRuleUsedescription>ルールによって定義されます。

Example: ( 2.5.13.16 APPLIES ( givenName $ surname ) )

例:(2.5.13.16が適用されます(与えられた$ surname))

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]のMatchingRuleSedesscription.1タイプに対応しています。

3.3.21. Name and Optional UID
3.3.21. 名前とオプションのuid

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 = distinguedname [sharp bitstring]

The <BitString> rule is defined in Section 3.3.2. The <distinguishedName> rule is defined in [RFC4514]. The <SHARP> rule is defined in [RFC4512].

<bitstring>ルールは、セクション3.3.2で定義されています。<distinguedname>ルールは[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>.

「#」文字は、著名な名前の文字列表現で発生する可能性がありますが、<nameandoptionaluid>で<distinguishedname>がエンコードされている場合、この文字の追加の脱出は実行されないことに注意してください。

      Example:
         1.3.6.1.4.1.1466.0=#04024869,O=Test,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タイプに対応しています。

3.3.22. Name Form Description
3.3.22. 名前フォームの説明

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)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タイプに対応しています。

3.3.23. Numeric String
3.3.23. 数値文字列

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:

数値文字列構文の値は、1つ以上の数字と空間のシーケンスです。この構文の値のLDAP固有のエンコーディングは、以下のABNFに準拠している、非vanted文字の文字列です。

      NumericString = 1*(DIGIT / SPACE)
        

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 'Numeric String')

This syntax corresponds to the NumericString ASN.1 type from [ASN.1].

この構文は、[asn.1]のnumericsstring asn.1タイプに対応しています。

3.3.24. Object Class Description
3.3.24. オブジェクトクラスの説明

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 'country' sup top structuralはc 5月(searchguide $ description))

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]のobjectClassdesscription.1タイプに対応します。

3.3.25. Octet String
3.3.25. オクテット文字列

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:

Octet String構文の値は、ゼロ、1つ、またはより任意のオクテットのシーケンスです。この構文の値のLDAP固有のエンコーディングは、次のABNFに適合するオクテットの非回転シーケンスです。

      OctetString = *OCTET
        

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:

Octet Stringの構文の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 'Octet String')

This syntax corresponds to the OCTET STRING ASN.1 type from [ASN.1].

この構文は、[asn.1]のoccet string asn.1タイプに対応しています。

3.3.26. OID
3.3.26. oid

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].

OID構文の値は、オブジェクト識別子です。いくつかのオブジェクトまたは仕様のアイテムを一意に識別する2つ以上の非陰性整数のシーケンスです。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タイプに対応します。

3.3.27. Other Mailbox
3.3.27. その他のメールボックス

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 = mailbox-typeドルメールボックスメールボックスタイプ= 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].

<mailbox-type>ルールは、メールボックスが存在するメールシステムのタイプ(「McImail」など)を表し、<mailbox-type>で説明されているメールシステムの実際のメールボックスです。<printablestring>および<ia5string>ルールは、セクション3.2で定義されています。<dollar>ルールは[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:

他のメールボックス構文に対応するASN.1タイプは、明示的なタグを仮定して、次のように定義されます。

      OtherMailbox ::= SEQUENCE {
          mailboxType  PrintableString,
          mailbox      IA5String
      }
        
3.3.28. Postal Address
3.3.28. 郵便住所

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
        

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].

郵便アドレス値の各文字列(すなわち、<line>)は、 "\"および "$"文字が文字列で発生した場合、「\ "および「$」文字が逃げられることを除いて、UTF-8 [RFC3629]文字列としてエンコードされます。\ "文字に続いて、文字の2つの16進数桁コードが続きます。<dollar>および<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 Main St. $ Anytown、CA 12345 $ USA \ 241,000,000懸賞$ PO Box 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]の郵便放棄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-postal-lineおよびub-postal-string(両方の整数)の値は、実装が定義されています。非規範的な定義は[x.520]に表示されます。

3.3.29. Printable String
3.3.29. 印刷可能な文字列

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>ルールで指定されているように、1つ以上のラテンアルファベット、数値、および選択された句読文字の文字列です。

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>ルールに準拠している、非vertedの文字列です。

Example: This is a PrintableString.

例:これはPrintableStringです。

The LDAP definition for the PrintableString syntax is:

( 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 'Printable String')

This syntax corresponds to the PrintableString ASN.1 type from [ASN.1].

この構文は、[asn.1]のprintablestring asn.1タイプに対応しています。

3.3.30. Substring Assertion
3.3.30. サブストリングアサーション

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つ、またはより多くの文字サブストリングのシーケンスです。すなわち、一致することの一致として[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 ]
        
      initial  = substring
      any      = ASTERISK *(substring ASTERISK)
      final    = substring
      ASTERISK = %x2A  ; asterisk ("*")
        
      substring           = 1*substring-character
      substring-character = %x00-29
                            / (%x5C "2A")  ; escaped "*"
                            / %x2B-5B
                            / (%x5C "5C")  ; escaped "\"
                            / %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つの16進数桁コード。

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 'Substring Assertion')

This syntax corresponds to the SubstringAssertion ASN.1 type from [X.520].

この構文は、[x.520]の副局面asn.1タイプに対応しています。

3.3.31. Telephone Number
3.3.31. 電話番号

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>ルールに準拠している、非verted文字列の文字列です。

Examples: +1 512 315 0280 +1-512-315-0280 +61 3 9896 7830

例:1 512 315 0280 1-512-315-0280 61 3 9896 7830

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(サイズ(1..ub-telephone-number))

The value of ub-telephone-number (an integer) is implementation defined. A non-normative definition appears in [X.520].

UB-Telephone-Number(整数)の値は、実装が定義されています。[x.520]には、非規範的な定義が表示されます。

3.3.32. Teletex Terminal Identifier
3.3.32. Teletex端子識別子

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
        
      ttx-value-octet = %x00-23
                        / (%x5C "24")  ; escaped "$"
                        / %x25-5B
                        / (%x5C "5C")  ; escaped "\"
        

/ %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で定義されています。<dollar>ルールは[RFC4512]で定義されています。

The LDAP definition for the Teletex Terminal Identifier syntax is:

TeleTex端子識別子の構文の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 'Teletexターミナル識別子')

This syntax corresponds to the TeletexTerminalIdentifier ASN.1 type from [X.520].

この構文は、[x.520]のテレットエクシールディレクションasn.1タイプに対応しています。

3.3.33. Telex Number
3.3.33. テレックス番号

A value of the Telex Number syntax specifies the telex number, country code, and answerback code of a telex terminal.

Telex番号の値の値は、Telex端末のTelex番号、国コード、および回答バックコードを指定します。

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

Telex-Number =実際の数ドルカントリーコードドルの回答バックaltual-number = printablestringカントリーコード= printablestring応答バック= printablestring

The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].

<printableString>ルールは、セクション3.2で定義されています。<dollar>ルールは[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 'Telex Number')

This syntax corresponds to the TelexNumber ASN.1 type from [X.520].

この構文は、[X.520]のTelexNumber ASN.1タイプに対応しています。

3.3.34. UTC Time
3.3.34. UTC時間

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固有のエンコードは、UTCTIMEタイプの[ASN.1]で定義された形式に従い、次のABNFで説明されています。

      UTCTime         = year month day hour minute [ second ]
                           [ u-time-zone ]
      u-time-zone     = %x5A  ; "Z"
                        / u-differential
        
      u-differential  = ( MINUS / PLUS ) hour minute
        

The <year>, <month>, <day>, <hour>, <minute>, <second>, and <MINUS> rules are defined in Section 3.3.13. The <PLUS> rule is defined in [RFC4512].

<年>、<月>、<day>、<hour>、<minute>、<second>、および<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-time-zone>の「z」形式が使用されている場合、調整されたユニバーサル時間を表します。それ以外の場合、値は現地時間を表します。後者の場合、<u-differential>が提供されている場合、局所時間と微分を減算することにより、調整された普遍的な時間を計算できます。<u-time-zone>は時間の値で存在する必要があり、<u-time-zone>の「z」形式は<u-differential>よりも優先されて使用する必要があります。

The LDAP definition for the UTC Time syntax is:

UTC Time構文の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 Time')

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]からのutctime asn.1タイプに対応します。

4. Matching Rules
4. 一致するルール

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]とエントリの名前を比較すると、それらは使用されます。エントリを変更する場合、一致するルールを使用して、削除する値を識別し、属性が2つの等しい値を含むのを防ぎます。

Matching rules that are required for directory operation, or that are in common use, are specified in this section.

このセクションでは、ディレクトリ操作に必要なルールを一致させる、または一般的に使用するルールを指定します。

4.1. General Considerations
4.1. 一般的な考慮事項

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

一致するルールは、属性valueassertionまたはmatchingRuleasSertion [RFC4511]を介して属性値に適用されます。属性valueassertionまたは一致した断層が未定義に評価される条件は、他の場所で指定されています[RFC4511]。アサーションが未定義でない場合、アサーションの結果は、選択したマッチングルールを適用した結果です。一致するルールは、一致するルールの説明で指定されているように、真の、場合によっては未定義に評価されます。それ以外の場合、それは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]のアサーション値は、属性タイプのサブストリングマッチングルールのアサーション構文ではなく、属性タイプの等式マッチングルールのアサーション構文に準拠することに注意してください。概念的には、サブストリングフィルター全体が、ルールを適用する前に、サブストリングマッチングルールのアサーション値に変換されます。

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タイプの条件を満たす場合、他のドキュメントで定義された追加の構文に適用できます。

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]の等式マッチングルール(平等)、一致するルール(順序)、またはサブストリングマッチングルール(subst)として使用するのに適しているかどうかを示します。

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およびKeyWordMatchマッチングルールを実装できますが、セクション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.

サーバーは、同じサブセマエントリの属性および一致するルール属性の値によって参照される一致するルールの定義を、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フィルターをサポートする場合、サーバーはMatchingRuleUse属性を使用して、選択したマッチングルールの適用性(拡張機能フィルター)を指名属性タイプに示すことができます。

4.2. Matching Rule Definitions
4.2. 一致するルール定義

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、caseexactordingmatch、caseexactsubstringsmatch、caseexactia5match、caseignoreia5match、caseignoreiaia5substringsmatch、caseignorElistmatch、caseignorematrysubstringsmatch、事例StComponentMatch、TelephonEnumberMatch、TelefonEnumberSubstringsMatch、および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.

Transcode、正規化、禁止、および確認Bidiの手順は、一致するルールごとに同じです。ただし、マップと重要でない文字処理手順は、以下のセクションのこれらのマッチングルールの説明で詳述されているように、特定のルールに依存します。

4.2.1. bitStringMatch
4.2.1. BitStringMatch

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名「BitStringMatch」Syntax 1.3.6.1.4.1.146.115.121.1.6)

The bitStringMatch rule is an equality matching rule.

BitStringMatchルールは、平等マッチングルールです。

4.2.2. booleanMatch
4.2.2. booleanmatch

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タイプがブール値である構文の属性値(ブールの構文など)を比較します。

The rule evaluates to TRUE if and only if the attribute value and the assertion value are both TRUE or both FALSE.

ルールは、属性値とアサーション値がTrueまたは両方がfalseである場合にのみ、Trueに評価されます。

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名前「booleanmatch」構文1.3.6.1.4.1.146.115.121.1.7)

The booleanMatch rule is an equality matching rule.

booleanmatchルールは、平等マッチングルールです。

4.2.3. caseExactIA5Match
4.2.3. caseexactia5match

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ルールは、IA5 string構文のアサーション値を、対応するASN.1タイプがIA5ストリングである構文の属性値(IA5 String Syntaxなど)と比較します。

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名 'Caseexactia5Match' Syntax 1.3.6.1.4.1.146.115.121.1.1.26)

The caseExactIA5Match rule is an equality matching rule.

Caseexactia5Matchルールは、平等マッチングルールです。

4.2.4. caseExactMatch
4.2.4. caseexactmatch

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タイプがディレクトリストリングまたは代替のいずれかのasn.1タイプがある構文の属性値(例えば、ディレクトリ文字列、印刷可能な文字列、国の文字列、または電話番号の構文)の属性値を比較します。StringタイプのDirectoryStringのタイプは、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 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'構文1.3.6.1.4.1.146.115.121.15)

The caseExactMatch rule is an equality matching rule.

caseexactmatchルールは、平等マッチングルールです。

4.2.5. caseExactOrderingMatch
4.2.5. caseexactorderingmatch

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タイプがディレクトリストリングまたはその代替の1つを持つ構文の属性値(例えば、ディレクトリ文字列、印刷可能な文字列、国の文字列、または電話番号の構文)の属性値を比較します。文字列タイプ。

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.

ルールは、コードポイントの照合順序で、準備された属性値文字列が準備されたアサーション値文字文字列よりも早く表示される場合にのみ、真のものに評価されます。つまり、属性値は「より少ない」アサーション値です。

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'構文1.3.6.1.4.1.146.115.121.15)

The caseExactOrderingMatch rule is an ordering matching rule.

caseexactorderingmatchルールは、順序付けルールです。

4.2.6. caseExactSubstringsMatch
4.2.6. caseexactsubstringsmatch

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タイプがディレクトリストリングまたはその代替品のいずれかである、対応するASN.1タイプの属性値(例:文字列タイプ。

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)アサーション値の調製されたサブストリングが、アサーション値のサブストリングの順序での属性値文字文字列の分離部分を一致させる場合にのみtrueを評価します。存在すると、準備された属性値文字文字列の先頭と一致し、(3)a <ファイナル>サブストリングは、存在する場合、準備された属性値の文字列の終わりと一致します。準備されたサブストリングは、対応する文字が同じコードポイントを持っている場合、準備された属性値文字列の一部と一致します。

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'構文1.3.6.1.4.1.146.115.121.1.58)

The caseExactSubstringsMatch rule is a substrings matching rule.

caseexactsubstringsmatchルールは、サブストリングスマッチングルールです。

4.2.7. caseIgnoreIA5Match
4.2.7. caseignoreia5match

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ルールは、IA5 string構文のアサーション値を、対応するASN.1タイプがIA5Stringである構文の属性値(IA5 String Syntaxなど)を比較します。

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'構文1.3.6.1.4.1.146.115.121.1.1.1.1.1.14666.115.1151.1151.1151.1151.11.1121.1466)

The caseIgnoreIA5Match rule is an equality matching rule.

caseignoreia5matchルールは、平等マッチングルールです。

4.2.8. caseIgnoreIA5SubstringsMatch
4.2.8. caseignoreia5substringsmatch

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)アサーション値の調製されたサブストリングが、アサーション値のサブストリングの順序での属性値文字文字列の分離部分を一致させる場合にのみtrueを評価します。存在すると、準備された属性値文字文字列の先頭と一致し、(3)a <ファイナル>サブストリングは、存在する場合、準備された属性値の文字列の終わりと一致します。準備されたサブストリングは、対応する文字が同じコードポイントを持っている場合、準備された属性値文字列の一部と一致します。

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'構文1.3.6.1.4.1.146.115.121.1.1.1.58)

The caseIgnoreIA5SubstringsMatch rule is a substrings matching rule.

caseignoreia5substringsmatchルールは、サブストリングスマッチングルールです。

4.2.9. caseIgnoreListMatch
4.2.9. caseignorElistmatch

The caseIgnoreListMatch rule compares an assertion value that is a sequence of strings 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.

CaseignorElistMatchルールは、一連の文字列であるアサーション値を、対応するASN.1タイプがディレクトリストリング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}

DirectoryStringのシーケンス{ub-match}

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'構文1.3.6.1.4.1.146.115.121.1.1.41)

The caseIgnoreListMatch rule is an equality matching rule.

caseignorElistmatchルールは、平等マッチングルールです。

4.2.10. caseIgnoreListSubstringsMatch
4.2.10. caseignorElistsubstringsmatch

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.

caseignororElistsubstringsmatchルールは、サブストリングアサーション構文のアサーション値を、対応するasn.1タイプがディレクトリストリング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.

ルールは、Assertion値が属性値の文字列を連結することによって形成された文字文字列に従って、アサーション値が一致している場合にのみtrueを評価します。アサーション値の値は、属性値の元の文字列の複数に及ぶ連結文字列のサブストリングと一致すると見なされます。

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 )

構文1.3.6.1.4.1.1466.115.121.1.58)

The caseIgnoreListSubstringsMatch rule is a substrings matching rule.

caseignorElistsubstringsmatchルールは、サブストリングスマッチングルールです。

4.2.11. caseIgnoreMatch
4.2.11. caseignorematch

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タイプがディレクトリストリングまたはその代替のいずれかである構文の属性値(たとえば、ディレクトリ文字列、印刷可能な文字列、国の文字列、または電話番号の構文)の属性値を比較します。文字列タイプ。

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'構文1.3.6.1.4.1.146.115.121.15)

The caseIgnoreMatch rule is an equality matching rule.

caseignorematchルールは、平等マッチングルールです。

4.2.12. caseIgnoreOrderingMatch
4.2.12. caseignoreOrderingMatch

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タイプがディレクトリストリングまたはその代替のいずれかのasn.1タイプの属性値(例:ディレクトリ文字列、印刷可能な文字列、国の文字列、または電話番号の構文)と比較します。文字列タイプ。

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.

ルールは、コードポイントの照合順序で、準備された属性値文字列が準備されたアサーション値文字文字列よりも早く表示される場合にのみ、真のものに評価されます。つまり、属性値は「より少ない」アサーション値です。

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'構文1.3.6.1.4.1.146.115.121.15)

The caseIgnoreOrderingMatch rule is an ordering matching rule.

caseignoreorderingmatchルールは、順序付けルールです。

4.2.13. caseIgnoreSubstringsMatch
4.2.13. caseignoresubstringsmatch

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タイプがディレクトリストリングまたはその代替品の1つである、対応するasn.1タイプの属性値(例:文字列タイプ。

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)アサーション値の調製されたサブストリングが、アサーション値のサブストリングの順序での属性値文字文字列の分離部分を一致させる場合にのみtrueを評価します。存在すると、準備された属性値文字文字列の先頭と一致し、(3)a <ファイナル>サブストリングは、存在する場合、準備された属性値の文字列の終わりと一致します。準備されたサブストリングは、対応する文字が同じコードポイントを持っている場合、準備された属性値文字列の一部と一致します。

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'構文1.3.6.1.4.1.146.115.121.1.58)

The caseIgnoreSubstringsMatch rule is a substrings matching rule.

caseignoresubstringsmatchルールは、サブストリングスマッチングルールです。

4.2.14. directoryStringFirstComponentMatch
4.2.14. DirectoryStringFirstComponentMatch

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タイプがディレクトリストリング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.

ルールは、Assertion値がCaseignorematchのルールを使用して属性値の最初のコンポーネントと一致する場合にのみTrueに評価されます。

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'構文1.3.6.1.1.1466.115.121.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ルールは、平等マッチングルールです。DirectoryStringFirstComponentMatchを使用して2つの属性値(該当する構文の)を比較する場合、最初に属性値の1つからアサーション値を導き出す必要があります。アサーション値は、その属性値の最初のコンポーネントを取得することにより、属性値から導出できます。

4.2.15. distinguishedNameMatch
4.2.15. Distinguednamematch

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ルールは、DN構文のアサーション値を、対応するASN.1タイプがDistinguedNameである構文の属性値(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)は、同じ数の属性値アサーションと最初のRDNの各属性値アサーション(AVA)がある場合にのみ、属性値のRDNと同じです。同じ属性タイプの2番目の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名「DistinguishedNameMatch」構文1.3.6.1.4.1.146.115.121.1.12)

The distinguishedNameMatch rule is an equality matching rule.

DistinguishedNameMatchルールは、平等マッチングルールです。

4.2.16. generalizedTimeMatch
4.2.16. GeneralizedTimematch

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タイプが一般化された時間である構文の属性値(一般化された時間構文など)を比較します。

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名「GeneralizedTimematch」構文1.3.6.1.4.1.146.115.121.1.1.24)

The generalizedTimeMatch rule is an equality matching rule.

GeneralizedTimeMatchルールは、平等マッチングルールです。

4.2.17. generalizedTimeOrderingMatch
4.2.17. GeneralizedTime -OrderingMatch

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.

GeneralizedTime -OrderingMatchルールは、一般化された時間構文のアサーション値の時間順序を、対応するASN.1タイプが一般化された時間である構文の属性値(一般化された時間構文など)を比較します。

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.

このルールは、属性値がアサーション値で表される普遍的な調整時間よりも早い普遍的な調整時間を表す場合にのみ真である。

The LDAP definition for the generalizedTimeOrderingMatch rule is:

GeneralizedTime -OrderingMatchルールのLDAP定義は次のとおりです。

( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )

(2.5.13.28 name 'generalizedtime -orderingmatch'構文1.3.6.1.4.1.146.115.121.1.24)

The generalizedTimeOrderingMatch rule is an ordering matching rule.

GeneralizedTime -OrderingMatchルールは、順序付けルールです。

4.2.18. integerFirstComponentMatch
4.2.18. integerFirstComponentMatch

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タイプの構文の属性値(例: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.

ルールは、アサーション値と属性値の最初のコンポーネントが同じ整数値である場合にのみ、真のものに評価されます。

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名 'integerfirstcomponentmatch'構文1.3.6.1.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ルールは、平等マッチングルールです。IntegerFirstComponentMatchを使用して2つの属性値(該当する構文の)を比較する場合、最初に属性値の1つからアサーション値を導き出す必要があります。アサーション値は、その属性値の最初のコンポーネントを取得することにより、属性値から導出できます。

4.2.19. integerMatch
4.2.19. integermatch

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タイプが整数である構文の属性値(整数構文など)を比較します。

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名前「Integermatch」構文1.3.6.1.4.1.146.115.121.1.27)

The integerMatch rule is an equality matching rule.

Integermatchルールは、平等マッチングルールです。

4.2.20. integerOrderingMatch
4.2.20. integerorderingmatch

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タイプが整数である構文の属性値(整数構文など)を比較します。

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名前 'integerorderingmatch'構文1.3.6.1.4.1.146.115.121.1.27)

The integerOrderingMatch rule is an ordering matching rule.

integerorderingmatchルールは、順序付けルールです。

4.2.21. keywordMatch
4.2.21. keywordmatch

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.

KeyWordMatchルールは、ディレクトリ文字列構文のアサーション値を、対応するASN.1タイプがディレクトリストリングである構文の属性値(例:ディレクトリ文字列構文)を比較します。

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:

KeyWordMatchルールのLDAP定義は次のとおりです。

( 2.5.13.33 NAME 'keywordMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

(2.5.13.33名前「keywordmatch」構文1.3.6.1.4.1.146.115.121.15)

4.2.22. numericStringMatch
4.2.22. numericStringMatch

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.

比較のための属性値とアサーション値を準備する際に、文字はマップの準備ステップでケース折りたたまれることはなく、重要ではない文字処理のみが重要でない文字処理ステップに適用されます。

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'構文1.3.6.1.4.1.146.115.121.1.36)

The numericStringMatch rule is an equality matching rule.

NumericStringMatchルールは、平等マッチングルールです。

4.2.23. numericStringOrderingMatch
4.2.23. NumericStringOrderingMatch

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.

ルールは、コードポイントの照合順序で、準備された属性値文字列が準備されたアサーション値文字文字列よりも早く表示される場合にのみ、真のものに評価されます。つまり、属性値は「より少ない」アサーション値です。

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.

比較のための属性値とアサーション値を準備する際に、文字はマップの準備ステップでケース折りたたまれることはなく、重要ではない文字処理のみが重要でない文字処理ステップに適用されます。

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'構文1.3.6.1.4.1.146.115.121.1.36)

The numericStringOrderingMatch rule is an ordering matching rule.

NumericStringOrderingMatchルールは、順序付けルールです。

4.2.24. numericStringSubstringsMatch
4.2.24. numericStringsubstringsmatch

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タイプが数値ストリングである構文の属性値(たとえば、数値文字列構文)と比較します。

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)アサーション値の調製されたサブストリングが、アサーション値のサブストリングの順序での属性値文字文字列の分離部分を一致させる場合にのみtrueを評価します。存在すると、準備された属性値文字文字列の先頭と一致し、(3)a <ファイナル>サブストリングは、存在する場合、準備された属性値の文字列の終わりと一致します。準備されたサブストリングは、対応する文字が同じコードポイントを持っている場合、準備された属性値文字列の一部と一致します。

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.

比較のための属性値とアサーション値を準備する際に、文字はマップの準備ステップでケース折りたたまれることはなく、重要ではない文字処理のみが重要でない文字処理ステップに適用されます。

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'構文1.3.6.1.4.1.1466.115.121.1.58)

The numericStringSubstringsMatch rule is a substrings matching rule.

numericStringsubstringsmatchルールは、サブストリングマッチングルールです。

4.2.25. objectIdentifierFirstComponentMatch
4.2.25. ObjectidifierFirstComponentMatch

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.

ObjecidefierfirfirstComponentMatchルールは、OID構文のアサーション値を構文の属性値と比較します(例:属性タイプ説明、DITコンテンツルール説明、LDAP構文の説明、一致するルールの説明、ルールの使用説明、名前形式の説明、またはオブジェクトクラス説明構文)対応する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.

ルールは、Assertion値がObjectidentifierMatchのルールを使用して属性値の最初のコンポーネントと一致する場合にのみTrueに評価されます。

The LDAP definition for the objectIdentifierFirstComponentMatch matching rule is:

ObjectididifierfirstComponentMatchマッチングルールのLDAP定義は次のとおりです。

( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )

(2.5.13.30 name 'objectididifierfirstComponentMatch'構文1.3.6.1.1.146.115.121.1.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.

ObjectididifierFirstComponentMatchルールは、平等マッチングルールです。ObjectididifierFirstComponentMatchを使用して(該当する構文の)2つの属性値を比較する場合、最初に属性値の1つからアサーション値を導き出す必要があります。アサーション値は、その属性値の最初のコンポーネントを取得することにより、属性値から導出できます。

4.2.26. objectIdentifierMatch
4.2.26. Objectidentifiermatch

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ルールは、OID構文のアサーション値を、対応するASN.1タイプがオブジェクト識別子である構文の属性値(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に評価されます。つまり、<oid>の<数字>形式で明示的に表されるか、<descr>形式で暗黙的に表されているかどうかにかかわらず、同じ整数のシーケンスです([rfc4512]を参照)。

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'構文1.3.6.1.4.1.146.115.121.1.38)

The objectIdentifierMatch rule is an equality matching rule.

ObjectidentifierMatchルールは、平等マッチングルールです。

4.2.27. octetStringMatch
4.2.27. OctetStringMatch

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ルールは、Octet String構文のアサーション値を、対応するASN.1タイプがOctet String ASN.1タイプです。

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.

ルールは、属性値とアサーション値が同じ長さであり、対応するオクテット(位置)が同じである場合にのみ、真のものに評価されます。

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名「OctetStringMatch」Syntax 1.3.6.1.4.1.146.115.121.1.40)

The octetStringMatch rule is an equality matching rule.

OctetStringMatchルールは、平等マッチングルールです。

4.2.28. octetStringOrderingMatch
4.2.28. OctetStringOrderingMatch

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ルールは、Octet String構文のアサーション値を、対応するASN.1タイプがOctet String ASN.1タイプです。

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に評価されます。このルールは、最初のオクテットから最後のオクテットまで、そして最も重要なビットからオクテット内の最も重要なビットまでのオクテットの弦を比較します。異なるビットの最初の発生により、文字列の順序が決まります。ゼロビットは少し先になります。文字列に異なる数のオクテットが含まれているが、長い文字列が短い文字列の長さまでの短い文字列と同一である場合、より短い文字列は長い文字列の前にあります。

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名「OctetStringOrderingMatch」構文1.3.6.1.4.1.146.115.121.1.1.40)

The octetStringOrderingMatch rule is an ordering matching rule.

OctetStringOrderingMatchルールは、順序付けルールです。

4.2.29. telephoneNumberMatch
4.2.29. TelephonEnumberMatch

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タイプが電話番号を表す印刷物です。

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.

比較のための属性値とアサーション値を準備する際に、文字はマップの準備ステップでケース折りたたまれ、テレフォンサンバーの取るに足らない文字処理のみが、重要でない文字処理ステップに適用されます。

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.146.115.121.1.50)

The telephoneNumberMatch rule is an equality matching rule.

TelephonEnumberMatchルールは、平等マッチングルールです。

4.2.30. telephoneNumberSubstringsMatch
4.2.30. TelephonEnumberSubstringsmatch

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)アサーション値の調製されたサブストリングが、アサーション値のサブストリングの順序での属性値文字文字列の分離部分を一致させる場合にのみtrueを評価します。存在すると、準備された属性値文字文字列の先頭と一致し、(3)a <ファイナル>サブストリングは、存在する場合、準備された属性値の文字列の終わりと一致します。準備されたサブストリングは、対応する文字が同じコードポイントを持っている場合、準備された属性値文字列の一部と一致します。

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.

比較のために属性値とアサーション値のサブストリングを準備する際に、文字はマップの準備ステップでケース折りたたまれ、テレフォンサンバーの取るに足らない文字処理のみが、重要でない文字処理ステップに適用されます。

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'構文1.3.6.1.1.1466.115.121.1.58)

The telephoneNumberSubstringsMatch rule is a substrings matching rule.

TelephonEnumberSubstringsmatchルールは、サブストリングスマッチングルールです。

4.2.31. uniqueMemberMatch
4.2.31. UniqueMemberMatch

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ルールは、対応するasn.1タイプがnameandoptionaluidである構文の属性値(例:名前とオプションのuid構文)の名前とオプションの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.

ルールは、distinguishednamematchルールといずれかに従って、アサーション値と属性値の<distinguedname>コンポーネントが一致した場合にのみ、trueを評価します。(2)<bittring>コンポーネントは、属性値とアサーション値の両方に存在し、アサーション値の<bittring>コンポーネントは、bittringmatchルールに従って属性値の<bitstring>コンポーネントと一致します。

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名前「UniqueMemberMatch」構文1.3.6.1.4.1.146.115.121.1.1.34)

The uniqueMemberMatch rule is an equality matching rule.

UniqueMemberMatchルールは、平等マッチングルールです。

4.2.32. wordMatch
4.2.32. ワードマッチ

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タイプがディレクトリストリングである構文の属性値(例:ディレクトリ文字列構文)を比較します。

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.

このルールは、Assertion Valueが属性値の任意の単語に従って、アサーション値が一致する場合にのみTrueに評価されます。単語の正確な定義は実装固有です。

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'構文1.3.6.1.4.1.146.115.121.15)

5. Security Considerations
5. セキュリティに関する考慮事項

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固有のエンコーディングは、標準エンコーディングを定義しません。つまり、LDAP固有のエンコードから他のエンコード(例えば、BER)への変換と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構文を再構築することはできません。たとえば、LDAP固有のエンコードへの著名なエンコードルール(der)[BER]からDERエンコードに戻る変換は、元のDERエンコードを再現しない場合があります。したがって、LDAP固有のエンコーディングは、DERの可逆性が必要な場合は使用しないでください。たとえば、デジタル署名の検証用。代わりに、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.

セキュリティに敏感なフィールドを解釈する場合(特に、アクセスを付与または拒否するために使用されるフィールド)、実装は、使用される特定のエンコードに関係なく、基礎となる抽象値で一致するルールの比較が行われるようにする必要があります。

6. Acknowledgements
6. 謝辞

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. Wahl、A。Coulbeck、T。Howes、およびS. KilleのRFC2252の改訂版です。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ワーキンググループからの入力に基づいています。著者は、この文書の初期のドラフトを編集してくれたキャシー・ダリーと、この改訂への重要な貢献についてジム・セルマーズハイムとカート・ジレンガに感謝したいと思います。

7. IANA Considerations
7. IANAの考慮事項

The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry [BCP64] as indicated by the following templates:

インターネットに割り当てられた番号局(IANA)は、次のテンプレートで示されているように、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
        
      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の記述子は、BCP 64のObjectIdentifierSmatch(外部\ `s ')として誤って登録されていました。RFC4517を参照して、以下に変更されました。

      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
        
8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献

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

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

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

[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。

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

[RFC4234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強:ABNF」、RFC 4234、2005年10月。

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

[RFC4510] Zeilenga、K。、ed。、「Lightweight Directory Access Protocol(LDAP):技術仕様ロードマップ」、RFC 4510、2006年6月。

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

[RFC4511] Sermersheim、J.、ed。、「Lightweight Directory Access Protocol(LDAP):The Protocol」、RFC 4511、2006年6月。

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

[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol(LDAP):ディレクトリ情報モデル」、RFC 4512、2006年6月。

[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.

[RFC4514] Zeilenga、K.、ed。、「Lightweight Directory Access Protocol(LDAP):著名な名前の文字列表現」、RFC 4514、2006年6月。

[RFC4518] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006.

[RFC4518] Zeilenga、K。、「Lightweight Directory Access Protocol(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。、「Internet Assigned Numbers Authority(IANA)Lightwight Directory Access Protocol(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] International Reference Alphabet(IRA)(以前の国際アルファベットNo. 5またはIA5)情報技術 - 情報交換用7ビットコード化された文字セット、ITU-T推奨T.50、1992

[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(07/02)|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)。Eric Hamilton、C-Cube Microsystems、Milpitas、CA、1992年9月1日。

8.2. Informative References
8.2. 参考引用

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

[RFC4519] Sciberras、A.、ed。、「Lightweight Directory Access Protocol(LDAP):ユーザーアプリケーションのスキーマ」、RFC 4519、2006年6月。

[RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006.

[RFC4523] Zeilenga、K。、「X.509証明書のLightweight Directory Access Protocol(LDAP)スキーマ定義」、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(07/02)|ISO/IEC 8825-1:2002、情報技術-ASN.1エンコーディングルール:基本エンコードルール(BER)、標準エンコーディングルール(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 RFC 2252
付録B. RFC 2252からの変更

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.

この付属書は、情報目的のみで提供されます。この仕様の規範的な部分ではありません。

1. The IESG Note has been removed.

1. IESGノートが削除されました。

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.

4. RFC 2252のあいまいな声明、セクション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.

5. 各LDAP構文の説明は拡張されているため、解釈のためのX.500の知識に依存しません。

6. The relationship of LDAP syntaxes to corresponding ASN.1 type definitions has been made explicit.

6. LDAP構文と対応するASN.1タイプ定義との関係が明示的になっています。

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. ディレクトリ文字列、印刷可能な文字列、電話番号の構文の値は、少なくとも1つの文字を持つ必要があります。

9. The <DITContentRuleDescription>, <NameFormDescription> and <DITStructureRuleDescription> rules have been moved to [RFC4512].

9.

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.

11. LDAP構文の説明構文の対応する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からの送達方法、強化ガイド、ガイド、Octet String、Teletex端子識別子、Telex番号の構文が組み込まれています。

15. The <criteria> rule for the Enhanced Guide and Guide syntaxes has been extended to accommodate empty "and" and "or" expressions.

15. 強化されたガイドおよびガイド構文の<sriteria>ルールは、空に対応するために拡張されています」と「または」式が拡張されました。

16. An encoding for the <ttx-value> rule in the Teletex Terminal Identifier syntax has been defined.

16. TeleTex端子識別子構文の<TTX-Value>ルールのエンコーディングが定義されています。

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関連の構文(証明書、証明書リスト、証明書のペア)が削除されました。それらは[RFC4523]で再導入されています(RFC 2256のサポートされているアルゴリズム構文と同様)。

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.

19. DL送信許可構文は、MHSまたはアドレス構文に依存するため、削除されました。

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. LDAPスキーマ定義の構文(RFC 2927で定義)とメール優先構文は、コア仕様の範囲外であるという理由で削除されました。

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.

23. 一致する各ルールの説明は拡張されているため、解釈のためのX.500の知識に依存しません。

24. The caseIgnoreIA5SubstringsMatch matching rule from RFC 2798 has been added.

24. RFC 2798の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. caseignororElistsubstringsmatch、caseignore -orderingmatch、およびcaseignoreorouresubstringsmatchマッチングルールは、リーディング、トレーリング、および複数の隣接する白人文字を処理するための規定が適用されるマッチングルールのリストに追加されました(現在)。これは、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. プレゼンテーションAddressMatchマッチングルールは、ドラフトの標準満期ではないアサーション構文(プレゼンテーションアドレス)に依存するため、削除されました。

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.

29. X.680はX.500で言及されているASN.1のバージョンであるため、ASN.1の決定的な参照はX.208からX.680に変更されました。

30. The specification of the caseIgnoreListSubstringsMatch matching rule from RFC 2798 & X.520 has been added.

30. RFC 2798およびX.520のcaseignorElistsubstringsmatchマッチングルールの仕様が追加されました。

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.

32. BooleanMatch、caseexactmatch、caseexactorderingmatch、caseexactsubstringsmatch、directorystringfirstcomponentmatch、integerorderingmatch、keywordsondordermatringmatch、numericsstringordoryingmatch、octetstringorderingmatch、およびrfc 3698&x.520からのワードマッチマッチングの仕様の仕様。

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
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2006).

Copyright(c)The Internet Society(2006)。

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

この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織(もしあれば)が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。

Intellectual Property

知的財産

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

IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。

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

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

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

IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。

Acknowledgement

謝辞

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

RFCエディター機能の資金は、IETF管理サポートアクティビティ(IASA)によって提供されます。