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)
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）インターネット協会（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.
ライトウェイトディレクトリアクセスプロトコルバージョン3（LDAPv3）によるエントリから属性を読み取るとき、[2]は、属性タイプまたは属性タイプとそのすべての値のいずれかを読み取るために、通常のみ可能です。選択的に属性値のほんの一部を読み取ることはできません。属性はオペレーショナル属性のobjectClassesとattributeTypes属性を公開する多くの値、例えば、userCertificate属性、またはサブスキーマを保持している場合、ユーザが選択具体的には、それらの値のサブセットを取得することができるようにするために、[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.
この文書では、新たに定義された「値戻り」フィルタの1つの以上の要素（すなわち、TRUEに戻される）一致値のみを返すようにユーザーを可能にするためのLDAPv3コントロールを指定します。複合バイナリ属性値の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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
ユーザーによって決定されるvaluesReturnFilter制御が重要または非重要のどちらかです。それだけで、検索操作のための意味を持ち、かつ唯一のクライアントが検索操作に追加する必要があります。サーバーがコントロールをサポートし、それが検索操作に存在する場合、サーバーは関係なく、重要度フラグの値を、制御に従わなければなりません。
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.
コントロールが重要としてマークされ、いずれかのコントロールまたはコントロールをサポートしていないサーバが検索以外の操作に適用されている場合は、サーバーはunavailableCriticalExtensionエラーを返さなければなりません。コントロールが重要としてマークされていない、のいずれかまたはコントロールをサポートしていないサーバが検索以外の操作に適用されている場合、サーバはコントロールを無視しなければなりません。
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の値の値がBER符号化である[6]、RFC 2251のセクション5.1の通り、[2] OCTET STRINGを、[5] ValuesReturnFilter型です。
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）検索フィルタは、第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）検索要求のtypesOnlyパラメータがTRUEの場合、制御は効果がありませんし、コントロールが指定されていなかったかのように検索要求が処理されます。
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）ValuesReturnFilterの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.
ⅱ）ValuesReturnFilterのすべての要素に対してFALSEまたは未定義評価されたすべての属性値は、対応の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.
注意。 AttributeDescriptionListは（[2]参照）が空であるか、または「*」を含む場合、制御は、すべてのユーザ属性に対して適用されなければなりません。 AttributeDescriptionListは「+」が含まれている場合、制御は、すべての操作属性に対して適用されなければなりません。
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.
コントロールは、X.500ディレクトリアクセスプロトコル（DAP）のmatchedValuesOnly（MVO）ブールのスーパーセットである[8]の検索引数、最新バージョンで修正された[9]。 LDAP拡張機能によってmatchedValuesOnlyブールの精密検査（LDAPEXT）ワーキンググループは、容易に解決することができませんでしたMVOブールでの曖昧さと複雑さを明らかにしました。 MVOブール属性を含むフィルタ項目がfalseと評価された場合でも、全体的なフィルタの真実、または属性値の全てに貢献しただけで、それらの属性値を支配たとえば、それが明確ではなかったです。このため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つ、またはそれ以上の属性値を選択し、残りを廃棄することです。属性値は、この制御によって破棄された後、彼らは他のコントロールにより、検索結果に再instatedてはなりません。
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要求で、このコントロールと他のコントロールの順序に応じて、異なる順序で返されるようにしかし、このコントロールと他のコントロールとの相互作用があるかもしれません。たとえば、ソートが最初に行われた場合、ソートサーバ側、および値戻りフィルタリング秒で、検索結果のセットは、値フィルタリングは発注が行われた時に属性値を削除することができるので、間違った順序でのように見えることがあります。 （ソート文書が何らかのキー属性値なしのエントリは、他のすべての属性値の後に来るものとして扱われるべきであることを指定する。）同様に重複したエントリと、重複値フィルタリングの前に行われた場合、検索結果エントリのセットは、同一の重複するエントリを含んでいてもよいです属性値の空のセットとそれぞれ、値のフィルタリング結果を複製するために使用された属性値を除去するためです。
For these reasons, the ValuesReturnFilter control in a SearchRequest SHOULD precede other controls that affect the number and ordering of SearchResultEntrys.
これらの理由から、SearchRequestでValuesReturnFilter制御は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:
以下の実施例でvaluesReturnFilterの文字列表現は、以下のABNF [15]表記を使用します。
valuesReturnFilter = "(" 1*simpleFilterItem ")" simpleFilterItem = "(" item ")"
valuesReturnFilter = "（" 1 * simpleFilterItem "）" simpleFilterItem = "（" アイテム "）"
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]
アイテム=シンプル/本/サブ/拡張可能なシンプル= ATTRのfilterType値のfilterType =等しく/約/大きな/より少ない等しい= "=" およそ= "〜=" より大きい= "> =" 未満= "<=" 拡張可能=のATTR [ "：" matchingrule] "=" 値/ "：" matchingrule "=" 値本= ATTR "= *" ストリング= ATTR "=" [初期]任意[最終]初期=値任意= "*"（*値 "*"）[1] matchingrule = MatchingRuleIdの4.1.5項から[1]のセクション4.1.6から[1]の値= AttributeValueのセクション4.1.9から最終値= ATTR =のAttributeDescription
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つの属性タイプ（例えば、telephoneNumberの）別の属性タイプ（例えば、メール）から値のサブセットからのすべての属性値を返すように設定することができる方法を示しています。
The entries below represent organizationalPerson object classes located somewhere beneath the distinguished name dc=ac,dc=uk.
以下のエントリは、識別名のDC = AC、DC =英国の下にどこかにorganizationalPersonオブジェクトクラスを表します。
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
DN：CN =ショーン・ミュラン、OU =人、DC =日、DC = AC、DC =英国CN：ショーン・ミュランSN：ミュランのobjectClass：organizationalPersonをオブジェクトクラス：人のobjectClass：inetOrgPersonのメール：sean.mullan@hotmail.comメール：ミュラン@ east.sun.com telephoneNumberの：+ 781 442 0926 telephoneNumberの：555-9999ます。dn：CN =デビッド・チャドウィック、OU = ISI、O =サルフォード、DC = AC、DC =英国CN：デヴィッド・チャドウィックSN：チャドウィックのobjectClass：organizationalPersonをオブジェクトクラス：人のobjectClass：inetOrgPersonのメール：dwchadwick@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に設定baseObjectで指定されている（即ち、DC = AC、DC =英国）、サブツリースコープ（SN =ミュラン）に設定し、フィルタ、および属性のリストがあることが「メール、telephoneNumberの」または「*」に設定戻りました。また、ValuesReturnFilter制御は（（メール= * 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
DN：CN =ショーン・ミュラン、OU =人、DC =日、DC = AC、DC =英国メール：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.
コントロールは、コントロールがすべての値が返されるべきであることを指定したので、値は、「telephoneNumberの」属性（すべての値が返される）に返さに影響を与えないことに注意してください。
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）第二の例は、1つのサブスキーマサブエントリからOID 1.2.3.4.5と「ネバネバ」属性の単一属性タイプのサブスキーマの定義を取得する方法を示します。
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 =サブスキーマサブエントリとルートエントリの下に保持されたO = MYORG、これは（それぞれの説明は、単一の属性値として保持され、このサーバに知られている35個の属性の記述を保持attributeTypes属性オペレーショナル属性を保持しますattributeTypes属性）が属性。
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 =サブスキーマサブエントリ、O = MYORG CN：サブスキーマサブエントリオブジェクトクラス：サブスキーマattributeTypes属性：（2.5.4.3 NAME 'CN' SUP名）attributeTypes属性：（2.5.4.6 NAME 'C' SUP名単一値）attributeTypes属性：（2.5 .4.0 NAME 'オブジェクトクラス' 平等OBJ ectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38）attributeTypes属性：（generalizedTimeOrderingMatch SYN税1.3.6.1.4.1.1466.115.121.1.24オーダー2.5.18.2 NAME 'modifyTimestampの' 平等GEN eralizedTimeMatch SINGLE-VALUE-USER NO-MODIFICATIONのUSAGE directoryOperation）attributeTypes属性：（2.5.21.6 NAME 'のobjectClasses' 平等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 )
ectIdentifierFirstComponentMatch SYNTAX 1.3。 6.1.4.1.1466.115.121.1.37 USAGE directoryOperation）attributeTypes属性：（1.2.3.4.5 NAME 'ネバネバ' 平等caseIgnoreMat CH SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3 6.1.4.1.1466.115.121.1.44 {64}）attributeTypes属性：（2.5。 21.5 NAME 'attributeTypes属性' 平等OBJ ectIdentifierFirstComponentMatch SYNTAX 1.3。6.1.4.1.1466.115.121.1.3 USAGE 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))
ユーザは、属性のリストが「attributeTypes属性」に設定返される= MYORG O、CN =サブスキーマサブエントリに設定baseObject、塩基の範囲に設定されたフィルタ（オブジェクトクラス=サブスキーマ）でLDAP検索操作を作成し、そしてValuesReturnFilterは（（attributeTypes属性= 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} )
DN：CN =サブスキーマサブエントリ、O = MYORG attributeTypes属性：（1.2.3.4.5 NAME 'ネバネバ' 平等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属性値に一致させるために使用することができる方法を示しています。この例では、のuserCertificateの等価マッチングルールとして[12]で定義さcertificateExactMatchマッチング規則をサポートするために、LDAPサーバを必要とすることに留意されたいです。
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}
DN：CN =デビッド・チャドウィック、OU =人、サルフォード大学= O、C = GB CN：デヴィッド・チャドウィックオブジェクトクラス：人のobjectClass：organizationalPersonをオブジェクトクラス：pkiUserオブジェクトクラス：のinetOrgPerson SN：チャドウィックメール：dwchadwick@salford.ac.ukのuserCertificate ;バイナリ：のuserCertificate {= truetrust株式会社、C = GBのOで発行された2468のシリアル番号証明書のバイナリ表現};バイナリ：= truetrust株式会社、C = Oでによって発行された1357のシリアル番号証明書の{バイナリ表現GB}のuserCertificate;バイナリ：{DCによって発行された1234のシリアル番号証明書のバイナリ表現= 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)).
LDAP検索操作は、O =サルフォード大学、C = GB、サブツリースコープ（SN =チャドウィック）に設定し、フィルタに設定され、属性のリストが「;バイナリのuserCertificate」に設定返されるbaseObjectで指定されています。また、ValuesReturnFilter制御は（（のuserCertificate = 1357 $ O = truetrust株式会社、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}
DN：CN =デビッド・チャドウィック、OU =人、サルのO =大学、C = GBのuserCertificate;バイナリ：{0 = truetrust株式会社、C = GBによって発行された1357のシリアル番号証明書のバイナリ表現}
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サーバによって適用されるアクセス制御がそれらを返すことを許可した場合の値のみが返されなければならない属性、およびこの点でValuesReturnFilter制御の効果は全く重要であることに注意してください。
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).
ValuesReturnFilterコントロールは、公開鍵インフラストラクチャの展開にプラスの効果を持っていることに注意してください。コントロールが処理されなければならない無関係の証明書の潜在的に大量のダウンロードを回避するので、サーバにX.509証明書マッチングルールと組み合わせた場合、よりスケーラブルになる、特定の証明書を検索する、より実用的なような特定のPKI操作、 （いくつかのケースで実行することは非常に困難である）ローカルで濾過しました。
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
オブジェクト識別子：1.2.826.0.1.3344810.2.3説明：マッチした値のコントロール人とEメールアドレスは、詳細のために連絡する：デビッド・チャドウィック<dwchadwick@salford.ac.uk>使用方法：コントロール仕様：RFC3876著者/変更コントローラ：IESGコメント： 無し
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].
このドキュメントでは、ここで説明するmatchedValuesコントロールを識別するためにOID 1.2.826.0.1.3344810.2.3を使用しています。このOIDは、そのBSI割り当てられた英語/ウェールズの登録会社番号[16]の下で、TrueTrust株式会社によって割り当てられました。
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リストのメンバーに感謝したい、特に最初の最初のこのコントロールの構文を提案した属性リターンフィルタとブルース・グリーンブラットを持つ提案ハラルドAlvestrandになります。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、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]ワール、M.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（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]ワール、M.、Coulbeck、A.、ハウズ、T.、およびS. Kille、 "軽量のディレクトリアクセスプロトコル（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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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）の仕様、Canonicalの符号化規則（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、BCP 64、RFC 3383、2002年9月K.、 "LDAP（Lightweight Directory Access Protocol）のためのIANA（Internet Assigned Numbers Authority）に考慮事項"。
[8] ITU-T Rec. X.511, "The Directory: Abstract Service Definition", 1993.
[8] ITU-T勧告。 X.511、 "ディレクトリ：抽象サービス定義"、1993年。
[9] ISO/IEC 9594 / ITU-T Rec X.511 (2001) The Directory: Abstract Service Definition.
[9] ISO / IEC 9594 / ITU-T勧告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]グッド、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]チャドウィック、D.とS.Legg、「インターネットX.509公開鍵基盤 - PKIのための追加の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]ハウズ、T.、ワール、M.、およびA. Anantha、 "検索結果のサーバサイドソーティングのためのLDAP制御拡張"、RFC 2891、2000年8月。
[14] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997.
[14]ハウズ、T.、 "LDAP検索フィルタの文字列表現"、RFC 2254、1997年12月。
[15] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[15]クロッカー、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イングランドの研究所大学IS
Phone: +44 161 295 5351 EMail: d.w.chadwick@salford.ac.uk
電話：+44 161 295 5351 Eメール：d.w.chadwick@salford.ac.uk
Sean Mullan Sun Microsystems One Network Drive Burlington, MA 01803 USA
ショーン・ミュランSun Microsystemsの一つのネットワークドライブバーリントン、MA 01803 USA
EMail: sean.mullan@sun.com
メールアドレス：sean.mullan@sun.com
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the 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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。