[要約] RFC 3876は、LDAPv3で一致した値を返すための仕様です。その目的は、LDAPクライアントが一致した値を効率的に取得できるようにすることです。
Network Working Group D. Chadwick
Request for Comments: 3876 University of Salford
Category: Standards Track S. Mullan
Sun Microsystems
September 2004
Returning Matched Values with the Lightweight Directory Access Protocol version 3 (LDAPv3)
一致した値をlightweightディレクトリアクセスプロトコルバージョン3（ldapv3）で返す
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 (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document describes a control for the Lightweight Directory Access Protocol version 3 that is used to return a subset of attribute values from an entry. Specifically, only those values that match a "values return" filter. Without support for this control, a client must retrieve all of an attribute's values and search for specific values locally.
このドキュメントでは、エントリから属性値のサブセットを返すために使用されるLightweight Directory Access Protocolバージョン3のコントロールについて説明します。具体的には、「値の戻り」フィルターに一致する値のみ。このコントロールをサポートすることなく、クライアントは属性のすべての値を取得し、局所的に特定の値を検索する必要があります。
When reading an attribute from an entry using the Lightweight Directory Access Protocol version 3 (LDAPv3) [2], it is normally only possible to read either the attribute type, or the attribute type and all its values. It is not possible to selectively read just a few of the attribute values. If an attribute holds many values, for example, the userCertificate attribute, or the subschema publishing operational attributes objectClasses and attributeTypes [3], then it may be desirable for the user to be able to selectively retrieve a subset of the values, specifically, those attribute values that match some user defined selection criteria. Without the control specified in this document, a client must read all of the attribute's values and filter out the unwanted values, necessitating the client to implement the matching rules. It also requires the client to potentially read and process many irrelevant values, which can be inefficient if the values are large or complex, or there are many values stored per attribute.
LightWeight Directory Access Protocolバージョン3（LDAPV3）[2]を使用してエントリから属性を読み取ると、通常、属性タイプ、または属性タイプとそのすべての値のいずれかを読み取ることのみが可能です。属性値のほんの一部を選択的に読み取ることはできません。属性が多くの値を保持している場合、たとえば、usercertificate属性、またはsubschema公開オブジェクトクラスと属性属性[3]を保持する場合、ユーザーが値、特にそれらのサブセットを選択的に取得できるようにすることが望ましい場合があります。一部のユーザー定義の選択基準に一致する属性値。このドキュメントで指定されたコントロールがなければ、クライアントはすべての属性の値を読み取り、不要な値をフィルタリングする必要があり、一致するルールを実装する必要があります。また、クライアントが多くの無関係な値を読み取り、処理する必要があります。これは、値が大きいか複雑な場合、または属性ごとに保存されている多くの値がある場合は非効率的です。
This document specifies an LDAPv3 control to enable a user to return only those values that matched (i.e., returned TRUE to) one or more elements of a newly defined "values return" filter. This control can be especially useful when used in conjunction with extensible matching rules that match on one or more components of complex binary attribute values.
このドキュメントは、LDAPV3コントロールを指定して、ユーザーが新しく定義された「値リターン」フィルターの1つ以上の要素と一致する（つまり、忠実に返す）値のみを返すことができるようにします。この制御は、複雑なバイナリ属性値の1つ以上のコンポーネントに一致する拡張可能なマッチングルールと組み合わせて使用する場合に特に役立ちます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [4].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [4]に記載されているように解釈される。
The valuesReturnFilter control is either critical or non-critical as determined by the user. It only has meaning for the Search operation, and SHOULD only be added to the Search operation by the client. If the server supports the control and it is present on a Search operation, the server MUST obey the control, regardless of the value of the criticality flag.
ValueRreturnFilterコントロールは、ユーザーが決定するようにクリティカルまたは非クリティカルです。検索操作にのみ意味があり、クライアントが検索操作にのみ追加する必要があります。サーバーがコントロールをサポートし、検索操作に存在する場合、臨界フラグの値に関係なく、サーバーはコントロールに従う必要があります。
If the control is marked as critical, and either the server does not support the control or the control is applied to an operation other than Search, the server MUST return an unavailableCriticalExtension error. If the control is not marked as critical, and either the server does not support the control or the control is applied to an operation other than Search, then the server MUST ignore the control.
コントロールがクリティカルとしてマークされ、サーバーがコントロールをサポートしていないか、コントロールが検索以外の操作に適用されている場合、サーバーは非分解性極端なエラーを返す必要があります。コントロールがクリティカルとしてマークされておらず、サーバーがコントロールをサポートしていないか、コントロールが検索以外の操作に適用されない場合、サーバーはコントロールを無視する必要があります。
The object identifier for this control is 1.2.826.0.1.3344810.2.3.
このコントロールのオブジェクト識別子は1.2.826.0.1.3344810.2.3です。
The controlValue is an OCTET STRING, whose value is the BER encoding [6], as per Section 5.1 of RFC 2251 [2], of a value of the ASN.1 [5] type ValuesReturnFilter.
controlvalueは、asn.1 [5]の値の値のRFC 2251 [2]のセクション5.1に従って[6]のように[6]のように、その値がvalueRreturnFilterの値であるオクテット文字列です。
ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem
SimpleFilterItem ::= CHOICE {
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] SimpleMatchingAssertion }
SimpleMatchingAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
--- at least one of the above must be present
matchValue [3] AssertionValue}
All the above data types have their standard meanings as defined in [2].
上記のすべてのデータ型には、[2]で定義されている標準的な意味があります。
If the server supports this control, the server MUST make use of the control as follows:
サーバーがこの制御をサポートしている場合、サーバーは次のように制御を利用する必要があります。
1) The Search Filter is first executed in order to determine which entries satisfy the Search criteria (these are the filtered entries). The control has no impact on this step.
1) 検索フィルターは、どのエントリが検索条件を満たすかを判断するために最初に実行されます（これらはフィルタリングされたエントリです）。コントロールはこのステップに影響を与えません。
2) If the typesOnly parameter of the Search Request is TRUE, the control has no effect and the Search Request is processed as if the control had not been specified.
2) 検索要求のタイプソンリーパラメーターが真である場合、コントロールには効果がなく、検索要求は制御が指定されていないかのように処理されます。
3) If the attributes parameter of the Search Request consists of a list containing only the attribute with OID "1.1" (specifying that no attributes are to be returned), the control has no effect and the Search Request is processed as if the control had not been specified.
3) 検索要求の属性パラメーターが、OID "1.1"の属性のみを含むリストで構成されている場合、コントロールは効果がなく、検索要求はコントロールがないかのように処理されます。指定された。
4) For each attribute listed in the attributes parameter of the Search Request, the server MUST apply the control as follows to each entry in the set of filtered entries:
4) 検索要求の属性パラメーターにリストされている各属性について、サーバーは、フィルタリングされたエントリのセットの各エントリに次のようにコントロールを適用する必要があります。
i) Every attribute value that evaluates TRUE against one or more elements of the ValuesReturnFilter is placed in the corresponding SearchResultEntry.
i) ValueRreturnFilterの1つ以上の要素に対してTRUEを評価するすべての属性値は、対応するSearchResultentryに配置されます。
ii) Every attribute value that evaluates FALSE or undefined against all elements of the ValuesReturnFilter is not placed in the corresponding SearchResultEntry. An attribute that has no values selected is returned with an empty set of values.
ii）ValueRreturnFilterのすべての要素に対して偽または未定義を評価するすべての属性値は、対応するSearchResultentryに配置されません。選択された値がない属性は、空の値のセットで返されます。
Note. If the AttributeDescriptionList (see [2]) is empty or comprises "*", then the control MUST be applied against every user attribute. If the AttributeDescriptionList contains a "+", then the control MUST be applied against every operational attribute.
注記。astibededescriptionList（[2]を参照）が空または「*」で構成されている場合、すべてのユーザー属性に対してコントロールを適用する必要があります。属性descriptionListに ""が含まれている場合、すべての操作属性に対してコントロールを適用する必要があります。
The control is a superset of the matchedValuesOnly (MVO) boolean of the X.500 Directory Access Protocol (DAP) [8] Search argument, as amended in the latest version [9]. Close examination of the matchedValuesOnly boolean by the LDAP Extensions (LDAPEXT) Working Group revealed ambiguities and complexities in the MVO boolean that could not easily be resolved. For example, it was not clear if the MVO boolean governed only those attribute values that contributed to the overall truth of the filter, or all of the attribute values, even if the filter item containing the attribute was evaluated as false. For this reason the LDAPEXT group decided to replace the MVO boolean with a simple filter that removes any uncertainty as to whether an attribute value has been selected or not.
このコントロールは、最新バージョン[9]で修正されたX.500ディレクトリアクセスプロトコル（DAP）[8]検索引数のMatchedValuesOnly（MVO）ブールのスーパーセットです[8]。LDAP拡張機能（LDAPEXT）ワーキンググループによるMatchedValuesOnlyブールンの綿密な調査により、MVOブールンのあいまいさと複雑さが明らかになりました。たとえば、属性を含むフィルターアイテムがfalseとして評価されたとしても、MVOブール波がフィルターの全体的な真実に寄与する属性値のみを支配するかどうか、またはすべての属性値のみを支配するかどうかは明らかではありませんでした。このため、LDAPEXTグループは、MVOブールンを、属性値が選択されているかどうかの不確実性を削除する単純なフィルターに置き換えることを決定しました。
The purpose of this control is to select zero, one, or more attribute values from each requested attribute in a filtered entry, and to discard the remainder. Once the attribute values have been discarded by this control, they MUST NOT be re-instated into the Search results by other controls.
このコントロールの目的は、フィルタリングされたエントリで要求された各属性からゼロ、1、またはそれ以上の属性値を選択し、残りを破棄することです。属性値がこのコントロールによって破棄されたら、他のコントロールによって検索結果に再注入されてはなりません。
This control acts independently of other LDAP controls such as server side sorting [13] and duplicate entries [10]. However, there might be interactions between this control and other controls so that a different set of Search Result Entries are returned, or the entries are returned in a different order, depending upon the sequencing of this control and other controls in the LDAP request. For example, with server side sorting, if sorting is done first, and value return filtering second, the set of Search Results may appear to be in the wrong order since the value filtering may remove the attribute values upon which the ordering was done. (The sorting document specifies that entries without any sort key attribute values should be treated as coming after all other attribute values.) Similarly with duplicate entries, if duplication is performed before value filtering, the set of Search Result Entries may contain identical duplicate entries, each with an empty set of attribute values, because the value filtering removed the attribute values that were used to duplicate the results.
このコントロールは、サーバー側の並べ替え[13]や重複エントリ[10]などの他のLDAPコントロールとは無関係に機能します。ただし、このコントロールと他のコントロールの間には相互作用があるため、検索結果の別のセットが返されるか、LDAPリクエストのこのコントロールや他のコントロールのシーケンスに応じて、エントリが異なる順序で返されます。たとえば、サーバー側の並べ替えを使用すると、ソートが最初に行われ、値が2番目にフィルタリングされた場合、値フィルタリングが順序付けが行われた属性値を削除する可能性があるため、検索結果のセットが間違った順序であるように見える場合があります。（ソートドキュメントでは、ソートキー属性値のないエントリは、他のすべての属性値の後に来るものとして扱う必要があることを指定します。）同様に、複製エントリと同様に、値フィルタリングの前に複製が実行される場合、検索結果エントリのセットには同一の重複エントリが含まれる場合があります。値フィルタリングが結果を複製するために使用された属性値を削除したため、それぞれが属性値の空のセットを備えています。
For these reasons, the ValuesReturnFilter control in a SearchRequest SHOULD precede other controls that affect the number and ordering of SearchResultEntrys.
これらの理由により、SearchRequestのValueRreturnFilterコントロールは、SearchResultentrysの数と順序に影響を与える他のコントロールに先行する必要があります。
All entries are provided in an LDAP Data Interchange Format (LDIF)[11].
すべてのエントリは、LDAPデータインターチェンジ形式（LDIF）[11]で提供されます。
The string representation of the valuesReturnFilter in the examples below uses the following ABNF [15] notation:
以下の例のValueRreturnFilterの文字列表現は、次のABNF [15]表記を使用します。
valuesReturnFilter = "(" 1*simpleFilterItem ")"
simpleFilterItem = "(" item ")"
where item is as defined below (adapted from RFC2254 [14]).
ここで、アイテムは以下に定義されています（RFC2254 [14]から適応）。
item = simple / present / substring / extensible
simple = attr filtertype value
filtertype = equal / approx / greater / less
equal = "="
approx = "~="
greater = ">="
less = "<="
extensible = attr [":" matchingrule] ":=" value
/ ":" matchingrule ":=" value
present = attr "=*"
substring = attr "=" [initial] any [final]
initial = value
any = "*" *(value "*")
final = value
attr = AttributeDescription from Section 4.1.5 of [1]
matchingrule = MatchingRuleId from Section 4.1.9 of [1]
value = AttributeValue from Section 4.1.6 of [1]
1) The first example shows how the control can be set to return all attribute values from one attribute type (e.g., telephoneNumber) and a subset of values from another attribute type (e.g., mail).
1) 最初の例は、すべての属性値を1つの属性タイプ（たとえば、ThelephonEnumber）からすべての属性値を返すように設定する方法と、別の属性タイプ（例：メール）の値のサブセットを示しています。
The entries below represent organizationalPerson object classes located somewhere beneath the distinguished name dc=ac,dc=uk.
以下のエントリは、著名な名前dc = ac、dc = ukのどこかにある組織パーソンオブジェクトクラスを表しています。
dn: cn=Sean Mullan,ou=people,dc=sun,dc=ac,dc=uk
cn: Sean Mullan
sn: Mullan
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
mail: sean.mullan@hotmail.com
mail: mullan@east.sun.com
telephoneNumber: + 781 442 0926
telephoneNumber: 555-9999
dn: cn=David Chadwick,ou=isi,o=salford,dc=ac,dc=uk
cn: David Chadwick
sn: Chadwick
objectClass: organizationalPerson
objectClass: person
objectClass: inetOrgPerson
mail: d.w.chadwick@salford.ac.uk
An LDAP search operation is specified with a baseObject set to the DN of the search base (i.e., dc=ac,dc=uk), a subtree scope, a filter set to (sn=mullan), and the list of attributes to be returned set to "mail,telephoneNumber" or "*". In addition, a ValuesReturnFilter control is set to ((mail=*hotmail.com)(telephoneNumber=*)).
LDAP検索操作は、検索ベースのDN（つまり、DC = AC、DC = UK）のDNに設定されたベースオブジェクト、サブツリースコープ、（SN = Mullan）に設定されたフィルター、および属性のリストで指定されています。セットを「メール、テレフォンサンバー」または「*」に戻しました。さらに、ValueRreturnFilterコントロールは（（mail =*hotmail.com）（TelephonEnumber =*）に設定されています。
The search results returned by the server would consist of the following entry:
サーバーによって返される検索結果は、次のエントリで構成されます。
dn: cn=Sean Mullan,ou=people,dc=sun,dc=ac,dc=uk
mail: sean.mullan@hotmail.com
telephoneNumber: + 781 442 0926
telephoneNumber: 555-9999
Note that the control has no effect on the values returned for the "telephoneNumber" attribute (all of the values are returned), since the control specified that all values should be returned.
コントロールは、すべての値を返す必要があることを指定したため、コントロールは「テレフォンサンバー」属性に対して返された値（すべての値が返される）に影響しないことに注意してください。
2) The second example shows how one might retrieve a single attribute type subschema definition for the "gunk" attribute with OID 1.2.3.4.5 from the subschema subentry.
2) 2番目の例は、Subschema SubentryからOID 1.2.3.4.5を使用して、「Gunk」属性の単一の属性タイプのサブスキーマ定義をどのように取得するかを示しています。
Assume the subschema subentry is held below the root entry with DN cn=subschema subentry,o=myorg and this holds an attributeTypes operational attribute holding the descriptions of the 35 attributes known to this server (each description is held as a single attribute value of the attributeTypes attribute).
サブセマサブエントリーがdn cn = subschema subentry、o = myorgを使用してルートエントリの下に保持されていると仮定します。astributeTypes属性）。
dn: cn=subschema subentry,o=myorg cn: subschema subentry objectClass: subschema attributeTypes: ( 2.5.4.3 NAME 'cn' SUP name ) attributeTypes: ( 2.5.4.6 NAME 'c' SUP name SINGLE-VALUE ) attributeTypes: ( 2.5.4.0 NAME 'objectClass' EQUALITY obj ectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) attributeTypes: ( 2.5.18.2 NAME 'modifyTimestamp' EQUALITY gen eralizedTimeMatch ORDERING generalizedTimeOrderingMatch SYN TAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) attributeTypes: ( 2.5.21.6 NAME 'objectClasses' EQUALITY obj
DN：CN = Subschema Subentry、O = Myorg CN：Subschema Subentry Objectlass：Subschema astributeTypes：（2.5.4.3 name 'cn' sup name）astibuteTypes：（2.5.4.6 name 'c' sup name single-value）.4.0 name 'objectclass' equality obj ectidentidifiermatch構文1.3.6.1.4.1.1466.115.121.1.1.1.38）シングルバリューなしユーザー修正の使用法directoryoperation）astibuteTypes：（2.5.21.6 name 'objectclasses' equality obj
ectIdentifierFirstComponentMatch SYNTAX 1.3. 6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMat ch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3. 6.1.4.1.1466.115.121.1.44{64} ) attributeTypes: ( 2.5.21.5 NAME 'attributeTypes' EQUALITY obj ectIdentifierFirstComponentMatch SYNTAX 1.3. 6.1.4.1.1466.115.121.1.3 USAGE directoryOperation )
EctidentidifierfirstComponentMatch構文1.3。6.1.4.1.1466.115.121.1.37使用法directoryoperation）属性：（1.2.3.4.5 name 'gunk' equality caseignoremat ch caseignoresubstringsmatch Syntax1.3。6.1.4.1.1.1466.115.121.1.44{64}）21.5 name 'astributetypes' equality obj ectidentididifierfirstcomponentMatch Syntax1.3。6.1.4.1.1466.115.121.1.3Usage DirectoryOperation）
plus another 28 - you get the idea.
さらに28-あなたはアイデアを得ます。
The user creates an LDAP search operation with a baseObject set to cn=subschema subentry,o=myorg, a scope of base, a filter set to (objectClass=subschema), the list of attributes to be returned set to "attributeTypes", and the ValuesReturnFilter set to ((attributeTypes=1.2.3.4.5))
ユーザーは、cn = subschema subentry、o = myorg、scope of base、（objectclass = subschema）に設定されたフィルター、「属性」に設定された属性のリスト、および「属性」に設定されたフィルターを使用して、LDAP検索操作を作成します。valuesreturnfilterは（（astributetypes = 1.2.3.4.5）に設定されています）
The search result returned by the server would consist of the following entry:
サーバーによって返される検索結果は、次のエントリで構成されます。
dn: cn=subschema subentry,o=myorg
attributeTypes: ( 1.2.3.4.5 NAME 'gunk' EQUALITY caseIgnoreMat
ch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.
6.1.4.1.1466.115.121.1.44{64} )
3) The final example shows how the control can be used to match on a userCertificate attribute value. Note that this example requires the LDAP server to support the certificateExactMatch matching rule defined in [12] as the EQUALITY matching rule for userCertificate.
3) 最後の例は、コントロールを使用してusercertificate属性値に一致する方法を示しています。この例では、LDAPサーバーが[12]で定義されているusercertificateの平等マッチングルールとして定義されているcermistexactmatchマッチングルールをサポートする必要があることに注意してください。
The entry below represents a pkiUser object class stored in the directory.
以下のエントリは、ディレクトリに保存されているPkiuserオブジェクトクラスを表しています。
dn: cn=David Chadwick,ou=people,o=University of Salford,c=gb
cn: David Chadwick
objectClass: person
objectClass: organizationalPerson
objectClass: pkiUser
objectClass: inetOrgPerson
sn: Chadwick
mail: d.w.chadwick@salford.ac.uk
userCertificate;binary: {binary representation of a certificate with
a serial number of 2468 issued by o=truetrust ltd,c=gb}
userCertificate;binary: {binary representation of certificate with a
serial number of 1357 issued by o=truetrust ltd,c=gb}
userCertificate;binary: {binary representation of certificate with a
serial number of 1234 issued by dc=certsRus,dc=com}
An LDAP search operation is specified with a baseObject set to
o=University of Salford,c=gb, a subtree scope, a filter set to
(sn=chadwick), and the list of attributes to be returned set to
"userCertificate;binary". In addition, a ValuesReturnFilter control
is set to ((userCertificate=1357$o=truetrust ltd,c=gb)).
The search result returned by the server would consist of the following entry:
サーバーによって返される検索結果は、次のエントリで構成されます。
dn: cn=David Chadwick,ou=people,o=University of Salford,c=gb
userCertificate;binary: {binary representation of certificate with a
serial number of 1357 issued by o=truetrust ltd,c=gb}
This document does not primarily discuss security issues.
このドキュメントでは、主にセキュリティの問題については説明していません。
Note however that attribute values MUST only be returned if the access controls applied by the LDAP server allow them to be returned, and in this respect the effect of the ValuesReturnFilter control is of no consequence.
ただし、LDAPサーバーによって適用されたアクセス制御がそれらを返すことを許可する場合にのみ、属性値を返す必要があり、この点でValueRreturnFilterコントロールの効果は結果ではありません。
Note that the ValuesReturnFilter control may have a positive effect on the deployment of public key infrastructures. Certain PKI operations, like searching for specific certificates, become more scalable, and more practical when combined with X.509 certificate matching rules at the server, since the control avoids the downloading of potentially large numbers of irrelevant certificates which would have to be processed and filtered locally (which in some cases is very difficult to perform).
ValueRreturnFilterコントロールは、公開キーインフラストラクチャの展開にプラスの効果がある可能性があることに注意してください。特定の証明書の検索などの特定のPKI操作は、サーバーでX.509証明書マッチングルールと組み合わせると、よりスケーラブルになり、より実用的になります。ローカルでフィルタリングされています（場合によっては実行が非常に困難です）。
The Matched Values control as an LDAP Protocol Mechanism [7] has been registered as follows:
LDAPプロトコルメカニズム[7]としての一致した値コントロールは、次のように登録されています。
Subject: Request for LDAP Protocol Mechanism Registration
件名：LDAPプロトコルメカニズム登録のリクエスト
Object Identifier: 1.2.826.0.1.3344810.2.3
Description: Matched Values Control
Person & email address to contact for further information:
David Chadwick <d.w.chadwick@salford.ac.uk>
Usage: Control
Specification: RFC3876
Author/Change Controller: IESG
Comments: none
This document uses the OID 1.2.826.0.1.3344810.2.3 to identify the matchedValues control described here. This OID was assigned by TrueTrust Ltd, under its BSI assigned English/Welsh Registered Company number [16].
このドキュメントでは、OID 1.2.826.0.1.3344810.2.3を使用して、ここで説明する一致する値制御を特定します。このOIDは、BSIが英語/ウェールズの登録会社番号を割り当てたTruetrust Ltdによって割り当てられました[16]。
The authors would like to thank members of the LDAPExt list for their constructive comments on earlier versions of this document, and in particular to Harald Alvestrand who first suggested having an attribute return filter and Bruce Greenblatt who first proposed a syntax for this control.
著者は、このドキュメントの以前のバージョンに関する建設的なコメントについて、LDAPextリストのメンバー、特にこのコントロールの構文を最初に提案した属性リターンフィルターとBruce Greenblattを最初に提案したHarald Alvestrandに感謝します。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (w3)", RFC 2251, December 1997.
[2] Wahl、M.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol（W3）」、RFC 2251、1997年12月。
[3] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[3] Wahl、M.、Coulbeck、A.、Howes、T。、およびS. Kille、「Lightweight Directory Access Protocol（V3）：属性構文定義」、RFC 2252、1997年12月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998, Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation
[5] ITU-T推奨X.680（1997）|ISO/IEC 8824-1：1998、情報技術 - 要約構文表記1（asn.1）：基本表記の仕様
[6] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1,2,3:1998 Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
[6] ITU-T推奨X.690（1997）|ISO/IEC 8825-1,2,3：1998情報技術-ASN.1エンコーディングルール：基本エンコーディングルール（BER）、標準エンコードルール（CER）および識別済みエンコードルール（DER）の仕様
[7] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[7] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）のインターネット割り当てされた数字権（IANA）の考慮事項」、BCP 64、RFC 3383、2002年9月。
[8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
[8] itu-t rec。X.511、「ディレクトリ：要約サービス定義」、1993。
[9] ISO/IEC 9594 / ITU-T Rec X.511 (2001) The Directory: Abstract Service Definition.
[9] ISO / IEC 9594 / ITU-T REC X.511（2001）ディレクトリ：抽象サービス定義。
[10] Sermersheim, J., "LDAP Control for a Duplicate Entry Representation of Search Results", Work in Progress, October 2000.
[10] Sermersheim、J。、「検索結果の重複するエントリ表現のためのLDAP制御」、2000年10月の作業。
[11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[11] Good、G。、「LDAPデータインターチェンジ形式（LDIF） - 技術仕様」、RFC 2849、2000年6月。
[12] Chadwick, D. and S.Legg, "Internet X.509 Public Key Infrastructure - Additional LDAP Schema for PKIs", Work in Progress, June 2002
[12] Chadwick、D。およびS.Legg、「インターネットX.509公開キーインフラストラクチャ - PKISの追加LDAPスキーマ」、2002年6月、進行中の作業
[13] Howes, T., Wahl, M., and A. Anantha, "LDAP Control Extension for Server Side Sorting of Search Results", RFC 2891, August 2000.
[13] Howes、T.、Wahl、M。、およびA. Anantha、「サーバーサイドの検索結果の並べ替えのためのLDAP制御拡張」、RFC 2891、2000年8月。
[14] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[14] Howes、T。、「LDAP検索フィルターの文字列表現」、RFC 2254、1997年12月。
[15] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[15] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[16] BRITISH STANDARD BS 7453 Part 1. Procedures for UK Registration for Open System Standards Part 1: Procedures for the UK Name Registration Authority.
[16] 英国標準BS 7453パート1.オープンシステム標準の英国登録手順パート1：英国名登録局の手順。
David Chadwick IS Institute University of Salford Salford M5 4WT England
デビッドチャドウィックはサルフォード大学サルフォード大学M5 4WTイングランドです
Phone: +44 161 295 5351
EMail: d.w.chadwick@salford.ac.uk
Sean Mullan Sun Microsystems One Network Drive Burlington, MA 01803 USA
Sean Mullan Sun Systems One Network Drive Burlington、MA 01803 USA
EMail: sean.mullan@sun.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
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/S HE 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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。