RFC3876 日本語訳
3876 Returning Matched Values with the Lightweight Directory AccessProtocol version 3 (LDAPv3). D. Chadwick, S. Mullan. September 2004. (Format: TXT=24233 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Chadwick
Request for Comments: 3876 University of Salford
Category: Standards Track S. Mullan
Sun Microsystems
September 2004
コメントを求めるワーキンググループD.チャドウィック要求をネットワークでつないでください: 3876年のソルフォード大学カテゴリ: 標準化過程S.Mullanサン・マイクロシステムズ2004年9月
Returning Matched Values with the
Lightweight Directory Access Protocol version 3 (LDAPv3)
ライトウェイト・ディレクトリ・アクセス・プロトコルバージョン3がある戻っているMatched Values(LDAPv3)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはエントリーから属性値の部分集合を返すのに使用されるライトウェイト・ディレクトリ・アクセス・プロトコルバージョン3のためのコントロールについて説明します。 「値は戻る」というフィルタに合っているそれらの値だけ。 このコントロールのサポートがなければ、クライアントは特定の値の属性のすべて、値と検索を局所的に検索しなければなりません。
1. Introduction
1. 序論
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
エントリーからライトウェイト・ディレクトリ・アクセス・プロトコルバージョン3(LDAPv3)[2]を使用することで属性を読むとき、通常、単に属性タイプと属性タイプかそのすべての値のどちらかを読むのは可能です。 選択的にまさしく属性値のいくつかを読むのは可能ではありません。 属性がサブスキーマ出版の操作上の属性の例えばuserCertificateが結果と考える多くの値か、objectClassesとattributeTypes[3]を持っているなら、ユーザが選択的に値の部分集合を検索できるのは、明確に望ましいかもしれません、いくつかのユーザの定義された選択評価基準に合っているそれらの属性値。 クライアントは、本書では指定されたコントロールがなければ、属性の値のすべてを読んで、求められていない値を無視しなければなりません、合っている規則を実装するクライアントを必要として。 また、それはクライアントを必要とします。
Chadwick & Mullan Standards Track [Page 1] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[1ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
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.
潜在的に、多くの無関係の値を読んで、処理するか、または属性単位で保存された多くの値があります。(値が大きいか、または複雑であるなら、値は効率が悪い場合があります)。
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コントロールを指定する、(TRUEを返す、)、新たに定義されて、「値は戻る」というフィルタの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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[4])で説明されるように本書では解釈されることであるべきです。
2. The valuesReturnFilter Control
2. valuesReturnFilterコントロール
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コントロールは、重要であるか、または非臨界です。 検索操作、およびSHOULDだけのためにクライアントによって検索操作に加えられるように意味して、それはそうしただけです。 サーバがコントロールをサポートして、それが検索操作のときに存在しているなら、サーバはコントロールに従わなければなりません、臨界旗の値にかかわらず。
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は値が[6]をコード化するBERであるOCTET STRINGです、RFC2251[2]、ASN.1[5]タイプValuesReturnFilterの価値のセクション5.1に従って。
ValuesReturnFilter ::= SEQUENCE OF SimpleFilterItem
ValuesReturnFilter:、:= SimpleFilterItemの系列
SimpleFilterItem ::= CHOICE {
equalityMatch [3] AttributeValueAssertion,
substrings [4] SubstringFilter,
greaterOrEqual [5] AttributeValueAssertion,
lessOrEqual [6] AttributeValueAssertion,
present [7] AttributeDescription,
approxMatch [8] AttributeValueAssertion,
extensibleMatch [9] SimpleMatchingAssertion }
SimpleFilterItem:、:= 選択equalityMatch[3]AttributeValueAssertion、サブストリング[4]SubstringFilter、greaterOrEqual[5]AttributeValueAssertion(lessOrEqual[6]AttributeValueAssertion)は[7] AttributeDescriptionを寄贈します、approxMatch[8]AttributeValueAssertion、extensibleMatch[9]SimpleMatchingAssertion
Chadwick & Mullan Standards Track [Page 2] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[2ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
SimpleMatchingAssertion ::= SEQUENCE {
matchingRule [1] MatchingRuleId OPTIONAL,
type [2] AttributeDescription OPTIONAL,
--- at least one of the above must be present
matchValue [3] AssertionValue}
SimpleMatchingAssertion:、:= 系列matchingRule[1]MatchingRuleId OPTIONAL、タイプ[2]AttributeDescription OPTIONAL、-、--少なくとも上記の1つが現在の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) 検索Filterは、最初に、どのエントリーが検索評価基準を満たすかを決定するために実行されます(これらはフィルターにかけることのエントリーです)。 コントロールはこのステップに影響力を全く持っていません。
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) 検索RequestのtypesOnlyパラメタがTRUEであるなら、コントロールは効き目がありません、そして、まるでコントロールが指定されていないかのように検索Requestは処理されます。
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) Requestは、検索の属性パラメタであるなら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) 検索Requestの属性パラメタに記載された各属性のために、サーバはフィルターにかけることのエントリーのセットにおける各エントリーに以下のコントロールを適用しなければなりません:
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.
ii) 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が「+」を含んでいるなら、あらゆる操作上の属性に対してコントロールを適用しなければなりません。
Chadwick & Mullan Standards Track [Page 3] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[3ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
3. Relationship to X.500
3. X.500との関係
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ディレクトリAccessプロトコル(DAP)[8]検索議論のmatchedValuesOnly(MVO)論理演算子のスーパーセットです、最新版[9]で修正されるように。 LDAP Extensions(LDAPEXT)作業部会によるmatchedValuesOnly論理演算子の吟味は容易に決議できなかったMVO論理演算子におけるあいまいさと複雑さを明らかにしました。 例えば、MVO論理演算子がフィルタの総合的な真実、または属性値のすべてに貢献したそれらの属性値だけを決定したかどうかは、明確ではありませんでした、属性を含むフィルタの品目が誤るとして評価されたとしても。 LDAPEXTグループが、MVO論理演算子を簡単なフィルタに取り替えると決めたこの理由で、属性値が選択されたかどうかに関してそれはどんな不確実性も取り除きます。
4. Relationship to other LDAP Controls
4. 他のLDAP Controlsとの関係
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コントロールを単独行動を取ります。 しかしながら、このコントロールと他のコントロールとの相互作用があるかもしれないので、異なった検索Result Entriesを返すか、または異なったオーダーでエントリーを返します、LDAP要求におけるこのコントロールと他のコントロールの配列であることによって。 例えば、サーバサイドソーティングで、1番目、および2番目をフィルターにかける値のリターンをソーティングにするなら、検索Resultsのセットは値のフィルタリングが注文が行われた属性値を取り除くかもしれないので間違ったオーダーにあるように見えるかもしれません。 (ソーティングドキュメントは、少しも分類用キー属性値のないエントリーが他のすべての属性値に続くとして扱われるべきであると指定します。) 同様に、複製が値のフィルタリングの前に実行されるなら、写しエントリーで、検索Result Entriesのセットは同じ写しエントリーを含むかもしれません、それぞれ属性値の空集合で、値のフィルタリングが結果をコピーするのに使用された属性値を取り除いたので。
For these reasons, the ValuesReturnFilter control in a SearchRequest SHOULD precede other controls that affect the number and ordering of SearchResultEntrys.
これらの理由、SearchRequest SHOULDでのValuesReturnFilterコントロールがSearchResultEntrysの数と注文に影響する他のコントロールに先行するので。
Chadwick & Mullan Standards Track [Page 4] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[4ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
5. Examples
5. 例
All entries are provided in an LDAP Data Interchange Format (LDIF)[11].
LDAP Data Interchange Format(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は.5セクション4.1[1] matchingrule=MatchingRuleIdからセクション4.1.9からどんな[最終的]の初期の=価値のどんな=「*」*(値の「*」)最終的な=値attrも=AttributeDescriptionとも値がセクション4.1.6からのAttributeValueと等しい[1]と「等しい」[初期の]。[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人の属性タイプ(例えば、telephoneNumber)と値の部分集合からすべての属性値を返すようにどう設定できるかを最初の例は別の属性タイプ(例えば、メール)から示しています。
The entries below represent organizationalPerson object classes located somewhere beneath the distinguished name dc=ac,dc=uk.
以下でのエントリーは分類名dc=ac、dc=ukの下のどこかに位置した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はショーンMullanと等しく、ouは人々と等しく、dcは太陽、dc=ac、dc=uk cnと等しいです: ショーンMullan sn: Mullan objectClass: organizationalPerson objectClass: 人のobjectClass: inetOrgPersonメール: sean.mullan@hotmail.com メール: mullan@east.sun.com telephoneNumber: +781 442 0926telephoneNumber: 555-9999
Chadwick & Mullan Standards Track [Page 5] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[5ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
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はデヴィッドChadwick、ou=isi、o=salford、dc=ac、dc=uk cnと等しいです: デヴィッドChadwick sn: チャドウィックobjectClass: organizationalPerson objectClass: 人のobjectClass: inetOrgPersonメール: 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索敵行動はbaseObjectセットで検索ベース(すなわち、dc=ac、dc=uk)のDN、下位木範囲、(sn=mullan)へのフィルタセット、および「メール、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はショーンMullanと等しく、ouは人々と等しく、dcは太陽、dc=ac、dc=ukメールと等しいです: sean.mullan@hotmail.com telephoneNumber: +781 442 0926telephoneNumber: 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) 2番目の例はサブスキーマ副次的記載から.5を「ぬるぬるしたもの」がOID1.2.3で.4を結果と考えるので1つがどうただ一つの属性タイプサブスキーマ定義を検索するかもしれないかに示しています。
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).
サブスキーマ副次的記載が以下に保持されて、35の属性の記述がこのサーバに知られるままにしながらサブスキーマ副次的記載、o=myorg、およびDN cn=これがある根のエントリーが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と等しいです: サブスキーマ副次的記載objectClass: サブスキーマattributeTypes: (.4.3NAME'cn'SUPが命名する2.5) attributeTypes: (2.5.4.6NAME'c'SUP名前SINGLE-VALUE) attributeTypes: (2.5.4.0NAME'objectClass'EQUALITY obj ectIdentifierMatch SYNTAX1.3.6.1.4、.1、.1466、.115、.121、.1、.38) attributeTypes: (2.5に、.18.2NAME'modifyTimestamp'EQUALITYがeralizedTimeMatch ORDERING generalizedTimeOrderingMatch SYN TAX1.3.6に情報を得る、.1、.4、.1、.1466、.115、.121、.1、.24SINGLE-VALUE NO-USER- MODIFICATION USAGE directoryOperation) attributeTypes: (2.5.21.6NAME'objectClasses'EQUALITY obj
Chadwick & Mullan Standards Track [Page 6] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[6ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
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構文1.3。 directoryOperation) 6.1.4.1.1466.115.121.1.37 用法attributeTypes: (1.2.3.4.5NAME'ぬるぬるしたもの'EQUALITY caseIgnoreMat ch SUBSTR caseIgnoreSubstringsMatch SYNTAX1.3. 6.1.4.1.1466.115、.121、.1、.44、64) attributeTypes: (2.5.21.5NAME'attributeTypes'EQUALITY obj ectIdentifierFirstComponentMatch 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=副次的記載に用意ができているbaseObject、ベースの範囲、フィルタが、(objectClass=サブスキーマ)、属性のリストに「attributeTypes」へのセットに返されるように設定して、ValuesReturnFilterがセットしたo=myorgとのLDAP索敵行動を作成します。(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: o=myorg attributeTypes、cnはサブスキーマ副次的記載と等しいです: (1.2.3.4.5NAME'ぬるぬるしたもの'EQUALITY caseIgnoreMat ch SUBSTR caseIgnoreSubstringsMatch SYNTAX1.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属性値で合うのにどうコントロールを使用できるかを示しています。 この例がEQUALITYマッチングが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はデヴィッドChadwickと等しく、ouは人々と等しく、oはソルフォード大学、c=gb cnと等しいです: デヴィッドチャドウィックobjectClass: 人のobjectClass: organizationalPerson objectClass: pkiUser objectClass: inetOrgPerson sn: チャドウィックメール: d.w.chadwick@salford.ac.uk userCertificate;、バイナリー: 2468年の通し番号がある証明書の2進法表示がo=truetrust ltd、c=gbで発行した、userCertificate;、バイナリー: 1357年の通し番号がある証明書の2進法表示がo=truetrust ltd、c=gbで発行した、userCertificate;、バイナリー: 1234年の通し番号がdc=certsRusによって発行されている証明書の2進法表示、dc=com
Chadwick & Mullan Standards Track [Page 7] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[7ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
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=大学に用意ができているbaseObject、c=gb、下位木範囲、(sn=chadwick)に設定されたフィルタ、およびリストで指定されて、セットに返す、「userCertificate;、2進、」 さらに、ValuesReturnFilterコントロールは((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}
dn: cnはデヴィッドChadwickと等しく、ouは人々と等しく、oはソルフォード大学、c=gb userCertificateと等しいです;、バイナリー: 1357年の通し番号がo=truetrust ltdによって発行されている証明書の2進法表示、c=gb
6. Security Considerations
6. セキュリティ問題
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操作は、よりスケーラブルで、より実用的になります、コントロールが局所的(いくつかの場合、実行するのは非常に難しい)に処理されて、フィルターにかけられなければならない潜在的に多くの無関係の証明書のダウンロードを避けるので。
7. IANA Considerations
7. IANA問題
The Matched Values control as an LDAP Protocol Mechanism [7] has been registered as follows:
LDAPプロトコルMechanism[7]が以下の通り登録されたとき、Matched Valuesは制御します:
Subject: Request for LDAP Protocol Mechanism Registration
Subject: 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 記述: 詳細のために連絡する取り組んでいるValues Control PersonとEメールアドレス: デヴィッド Chadwick <d.w.chadwick@salford.ac.uk 、gt;、用法: 仕様を制御してください: RFC3876はコントローラを書くか、または変えます: IESGはコメントします: なし
Chadwick & Mullan Standards Track [Page 8] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[8ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
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].
このドキュメントはOID1.2を使用します。.826 .0 .1 .3344810 .2 .3 ここで説明されたmatchedValuesコントロールを特定するために。 このOIDはイギリスの、または、ウェールズのRegistered会社番号[16]が割り当てられたBSIの下でTrueTrust Ltdによって割り当てられました。
8. Acknowledgements
8. 承認
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.
作者は、だれが最初にこのコントロールのための構文を提案したかを特にこのドキュメントの以前のバージョンの彼らの建設的なコメントと、最初に属性リターンフィルタを持っていることを提案したハラルドAlvestrandとブルース・グリーンブラットへのLDAPExtリストのメンバーに感謝したがっています。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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)」、RFC2251 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)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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/IEC8824-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/IEC8825-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.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC3383、2002年9月。
Chadwick & Mullan Standards Track [Page 9] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[9ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
9.2. Informative References
9.2. 有益な参照
[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 ITU9594/T Rec X.511(2001)ディレクトリ: 抽象的なサービス定義。
[10] Sermersheim, J., "LDAP Control for a Duplicate Entry
Representation of Search Results", Work in Progress, October
2000.
[10] J.、「検索結果の写しエントリー表現のためのLDAPコントロール」というSermersheimは進歩、2000年10月に働いています。
[11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
Specification", RFC 2849, June 2000.
[11] いいぞ、G.、「LDAPデータは形式(LDIF)を交換します--技術的な仕様」、RFC2849、6月2000日
[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公開鍵基盤--、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] ハウズ、T.、ウォール、M.、およびA.Anantha、「検索のサーバサイドソーティングのためのLDAPコントロール拡張子は結果として生じます」、RFC2891、2000年8月。
[14] Howes, T., "The String Representation of LDAP Search Filters",
RFC 2254, December 1997.
[14] ハウズ、T.、「LDAP検索フィルタのストリング表現」、RFC2254、1997年12月。
[15] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[15] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[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] イギリスの標準のBS7453第1部。 オープンシステム規格第1部のためのイギリスの登録のための手順: イギリスへの手順は登録局を命名します。
Chadwick & Mullan Standards Track [Page 10] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[10ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
10. Authors' Addresses
10. 作者のアドレス
David Chadwick IS Institute University of Salford Salford M5 4WT England
デヴィッドChadwickはソルフォードソルフォードM5 4WTイギリスの研究所大学です。
Phone: +44 161 295 5351 EMail: d.w.chadwick@salford.ac.uk
以下に電話をしてください。 +44 5351年の161 295メール: d.w.chadwick@salford.ac.uk
Sean Mullan Sun Microsystems One Network Drive Burlington, MA 01803 USA
ショーンMullanサン・マイクロシステムズ1ネットワークドライブバーリントン、MA01803米国
EMail: sean.mullan@sun.com
メール: sean.mullan@sun.com
Chadwick & Mullan Standards Track [Page 11] RFC 3876 Returning Matched Values with LDAPv3 September 2004
チャドウィックとMullan標準化過程[11ページ]RFC3876帰りは値をLDAPv3 September 2004に合わせました。
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Chadwick & Mullan Standards Track [Page 12]
チャドウィックとMullan標準化過程[12ページ]
一覧
スポンサーリンク
