[要約] RFC 2891は、LDAPサーバー側で検索結果をソートするための制御拡張を定義しています。目的は、クライアントがサーバーにソートの負荷をかけずに効率的に検索結果をソートできるようにすることです。
Network Working Group T. Howes
Request for Comments: 2891 Loudcloud
Category: Standards Track M. Wahl
Sun Microsystems
A. Anantha
Microsoft
August 2000
LDAP Control Extension for Server Side Sorting of Search Results
サーバー側の検索結果のソートのためのLDAPコントロール拡張機能
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
This document describes two LDAPv3 control extensions for server side sorting of search results. These controls allows a client to specify the attribute types and matching rules a server should use when returning the results to an LDAP search request. The controls may be useful when the LDAP client has limited functionality or for some other reason cannot sort the results but still needs them sorted. Other permissible controls on search operations are not defined in this extension.
このドキュメントでは、サーバー側の検索結果の並べ替えのための2つのLDAPV3制御拡張機能について説明します。これらのコントロールにより、クライアントは、結果をLDAP検索リクエストに返すときに、サーバーが使用する属性タイプとマッチングルールを指定できます。LDAPクライアントの機能が制限されている場合、または他の理由で結果をソートできないが、それでもソートする必要がある場合、コントロールは役立つ場合があります。この拡張機能では、検索操作に関する他の許容制御は定義されていません。
The sort controls allow a server to return a result code for the sorting of the results that is independent of the result code returned for the search operation.
ソートコントロールにより、サーバーは、検索操作のために返された結果コードとは独立した結果の並べ替えの結果コードを返すことができます。
The key words "MUST", "SHOULD", and "MAY" used in this document are to be interpreted as described in [bradner97].
このドキュメントで使用されている「必須」、「必須」、「可能性」は、[bradner97]で説明されているように解釈されるべきです。
This control is included in the searchRequest message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
このコントロールは、[LDAPV3]のセクション4.1.12で定義されているように、LDAPMessageのコントロールフィールドの一部としてSearchRequestメッセージに含まれています。
The controlType is set to "1.2.840.113556.1.4.473". The criticality MAY be either TRUE or FALSE (where absent is also equivalent to FALSE) at the client's option. The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE:
ControlTypeは「1.2.840.11356.1.4.473」に設定されています。クライアントのオプションでは、臨界性は真またはfalse（存在しない場合もfalseと同等です）のいずれかです。ControlValueはOctet Stringで、その値は次のシーケンスの値のBERエンコードです。
SortKeyList ::= SEQUENCE OF SEQUENCE {
attributeType AttributeDescription,
orderingRule [0] MatchingRuleId OPTIONAL,
reverseOrder [1] BOOLEAN DEFAULT FALSE }
The SortKeyList sequence is in order of highest to lowest sort key precedence.
sortkeylistシーケンスは、最も高いソートキーの優先順位の順にあります。
The MatchingRuleId, as defined in section 4.1.9 of [LDAPv3], SHOULD be one that is valid for the attribute type it applies to. If it is not, the server will return inappropriateMatching.
[LDAPV3]のセクション4.1.9で定義されているMatchingRuleidは、適用される属性タイプに有効なものである必要があります。そうでない場合、サーバーは不適切なマッチングを返します。
Each attributeType should only occur in the SortKeyList once. If an attributeType is included in the sort key list multiple times, the server should return an error in the sortResult of unwillingToPerform.
それぞれの属性タイプは、sortKeyListで1回のみ発生する必要があります。属性キーリストに複数回属性キーリストに含まれている場合、サーバーはUnwilltoPerformのsortresultのエラーを返す必要があります。
If the orderingRule is omitted, the ordering MatchingRule defined for use with this attribute MUST be used.
OrderingRuleが省略されている場合、この属性で使用するために定義された注文マッチングルールを使用する必要があります。
Any conformant implementation of this control MUST allow a sort key list with at least one key.
このコントロールのコンフォーマント実装では、少なくとも1つのキーを備えたソートキーリストを許可する必要があります。
This control is included in the searchResultDone message as part of the controls field of the LDAPMessage, as defined in Section 4.1.12 of [LDAPv3].
このコントロールは、[LDAPV3]のセクション4.1.12で定義されているように、LDAPMessageのコントロールフィールドの一部としてSearchResultDoneメッセージに含まれています。
The controlType is set to "1.2.840.113556.1.4.474". The criticality is FALSE (MAY be absent). The controlValue is an OCTET STRING, whose value is the BER encoding of a value of the following SEQUENCE:
ControlTypeは「1.2.840.11356.1.4.474」に設定されています。臨界性は偽です（存在しない場合があります）。ControlValueはOctet Stringで、その値は次のシーケンスの値のBERエンコードです。
SortResult ::= SEQUENCE {
sortResult ENUMERATED {
success (0), -- results are sorted
operationsError (1), -- server internal failure
timeLimitExceeded (3), -- timelimit reached before
-- sorting was completed
strongAuthRequired (8), -- refused to return sorted
-- results via insecure
-- protocol
adminLimitExceeded (11), -- too many matching entries
-- for the server to sort
noSuchAttribute (16), -- unrecognized attribute
-- type in sort key
inappropriateMatching (18), -- unrecognized or
-- inappropriate matching
-- rule in sort key
insufficientAccessRights (50), -- refused to return sorted
-- results to this client
busy (51), -- too busy to process
unwillingToPerform (53), -- unable to sort
other (80)
},
attributeType [0] AttributeDescription OPTIONAL }
The sortKeyRequestControl specifies one or more attribute types and matching rules for the results returned by a search request. The server SHOULD return all results for the search request in the order specified by the sort keys. If the reverseOrder field is set to TRUE, then the entries will be presented in reverse sorted order for the specified key.
SortKeyRequestControlは、検索リクエストによって返された結果の1つ以上の属性タイプと一致するルールを指定します。サーバーは、ソートキーによって指定された順序で、検索要求のすべての結果を返す必要があります。リバースオーダーフィールドがtrueに設定されている場合、エントリは指定されたキーの逆並べ替えられた順序で表示されます。
There are six possible scenarios that may occur as a result of the sort control being included on the search request:
検索リクエストに含まれているソートコントロールの結果として発生する可能性のある6つのシナリオがあります。
1 - If the server does not support this sorting control and the client specified TRUE for the control's criticality field, then the server MUST return unavailableCriticalExtension as a return code in the searchResultDone message and not send back any other results. This behavior is specified in section 4.1.12 of [LDAPv3].
1-サーバーがこのソートコントロールをサポートせず、クライアントがコントロールのクリティカリティフィールドに対して真に指定されている場合、サーバーはSearchResultDoneメッセージのリターンコードとしてUNABAILABLECRITICALEXTENSIONを返す必要があり、他の結果を送信しません。この動作は、[LDAPV3]のセクション4.1.12で指定されています。
2 - If the server does not support this sorting control and the client specified FALSE for the control's criticality field, then the server MUST ignore the sort control and process the search request as if it were not present. This behavior is specified in section 4.1.12 of [LDAPv3].
2-サーバーがこのソートコントロールをサポートせず、クライアントがコントロールの臨界フィールドにfalseを指定した場合、サーバーはソートコントロールを無視し、検索要求を存在しないかのように処理する必要があります。この動作は、[LDAPV3]のセクション4.1.12で指定されています。
3 - If the server supports this sorting control but for some reason cannot sort the search results using the specified sort keys and the client specified TRUE for the control's criticality field, then the server SHOULD do the following: return unavailableCriticalExtension as a return code in the searchResultDone message; include the sortKeyResponseControl in the searchResultDone message, and not send back any search result entries.
3-サーバーがこのソートコントロールをサポートしているが、何らかの理由で指定されたソートキーを使用して検索結果をソートできない場合、クライアントはコントロールの臨界フィールドに真に指定されている場合、サーバーは次のことを行う必要があります。SearchResultDoneメッセージ;SearchResultDoneメッセージにsortKeyResponseControlを含め、検索結果エントリを送信しないでください。
4 - If the server supports this sorting control but for some reason cannot sort the search results using the specified sort keys and the client specified FALSE for the control's criticality field, then the server should return all search results unsorted and include the sortKeyResponseControl in the searchResultDone message.
4-サーバーがこのソートコントロールをサポートしているが、何らかの理由で指定されたソートキーを使用して検索結果をソートできない場合、クライアントはコントロールの臨界フィールドにfalseを指定している場合、サーバーはすべての検索結果を整理されていない場合、SearchResultDoneにSortKeyResponseControlを含める必要があります。メッセージ。
5 - If the server supports this sorting control and can sort the search results using the specified sort keys, then it should include the sortKeyResponseControl in the searchResultDone message with a sortResult of success.
5-サーバーがこのソートコントロールをサポートし、指定されたソートキーを使用して検索結果を並べ替えることができる場合、SeartResultdoneメッセージにSortrestrestresult of Successのメッセージにsortkeyresponsecontrolを含める必要があります。
6 - If the search request failed for any reason and/or there are no searchResultEntry messages returned for the search response, then the server SHOULD omit the sortKeyResponseControl from the searchResultDone message.
6-検索要求が何らかの理由で失敗した場合、および/または検索応答のためにSearchResultentryメッセージが返されない場合、サーバーはSeartResultDoneメッセージからsortKeyResponseControlを省略する必要があります。
The client application is assured that the results are sorted in the specified key order if and only if the result code in the sortKeyResponseControl is success. If the server omits the sortKeyResponseControl from the searchResultDone message, the client SHOULD assume that the sort control was ignored by the server.
クライアントアプリケーションは、SortKeyResponseControlの結果コードが成功した場合にのみ、結果が指定されたキー順序でソートされることを保証します。サーバーがSeartResultDoneメッセージからsortKeyResponseControlを省略した場合、クライアントはソートコントロールがサーバーによって無視されていると想定する必要があります。
The sortKeyResponseControl, if included by the server in the searchResultDone message, should have the sortResult set to either success if the results were sorted in accordance with the keys specified in the sortKeyRequestControl or set to the appropriate error code as to why it could not sort the data (such as noSuchAttribute or inappropriateMatching). Optionally, the server MAY set the attributeType to the first attribute type specified in the SortKeyList that was in error. The client SHOULD ignore the attributeType field if the sortResult is success.
SeartResultDoneメッセージにサーバーに含まれる場合、sortKeyResponseControlは、結果がsortkeyRequestControlで指定されたキーに従ってソートされた場合、または適切なエラーコードに設定された場合、Sortrestresultをいずれかの成功に設定する必要があります。データ（nosuchattributeや不適切なマッチングなど）。オプションで、サーバーは、誤っているsortKeyListで指定された最初の属性タイプに属性タイプを設定する場合があります。Sortresultが成功した場合、クライアントは属性タイプのフィールドを無視する必要があります。
The server may not be able to sort the results using the specified sort keys because it may not recognize one of the attribute types, the matching rule associated with an attribute type is not applicable, or none of the attributes in the search response are of these types. Servers may also restrict the number of keys allowed in the control, such as only supporting a single key.
属性タイプのいずれかを認識しない可能性があるため、指定されたソートキーを使用して結果を並べ替えられない場合があります。種類。サーバーは、単一のキーのみをサポートするなど、制御に許可されるキーの数を制限する場合があります。
Servers that chain requests to other LDAP servers should ensure that the server satisfying the client's request sort the entire result set prior to sending back the results.
チェーンが他のLDAPサーバーに要求するサーバーは、クライアントの要求を満たすサーバーが結果を送信する前に結果全体をソートすることを確認する必要があります。
If a server receives a sort request, the client expects to receive a set of sorted results. If a client submits a sort request to a server which chains the request and gets entries from multiple servers, and the client has set the criticality of the sort extension to TRUE, the server MUST merge sort the results before returning them to the client or MUST return unwillingToPerform.
サーバーがソートリクエストを受信した場合、クライアントはソートされた結果のセットを受信することを期待しています。クライアントがリクエストをチェックし、複数のサーバーからエントリを取得するサーバーにソートリクエストを送信し、クライアントがソート拡張機能の重要性をtrueに設定した場合、サーバーは結果をクライアントに返す前にマージする必要があります。unvilltoperformを返します。
An entry that meets the search criteria may be missing one or more of the sort keys. In that case, the entry is considered to have a value of NULL for that key. This standard considers NULL to be a larger value than all other valid values for that key. For example, if only one key is specified, entries which meet the search criteria but do not have that key collate after all the entries which do have that key. If the reverseOrder flag is set, and only one key is specified, entries which meet the search criteria but do not have that key collate BEFORE all the entries which do have that key.
検索条件を満たすエントリには、種類のキーの1つ以上が欠落している場合があります。その場合、エントリはそのキーに対してnullの値があると見なされます。この標準では、nullは、そのキーの他のすべての有効な値よりも大きな値であると考えています。たとえば、1つのキーのみが指定されている場合、検索条件を満たしているが、そのキーを持っているすべてのエントリの後にそのキーの照合がないエントリがあります。ReverseDorderフラグが設定され、1つのキーのみが指定されている場合、検索基準を満たしているが、そのキーがあるすべてのエントリの前にそのキーが照合されないエントリがあります。
If a sort key is a multi-valued attribute, and an entry happens to have multiple values for that attribute and no other controls are present that affect the sorting order, then the server SHOULD use the least value (according to the ORDERING rule for that attribute).
ソートキーがマルチ値属性であり、エントリがたまたまその属性の複数の値を持ち、ソート順に影響する他のコントロールが存在しない場合、サーバーは最小値を使用する必要があります（そのための順序付け規則に従って、属性）。
When the sortKeyRequestControl control is included with the pagedResultsControl control as specified in [LdapPaged], then the server should send the searchResultEntry messages sorted according to the sort keys applied to the entire result set. The server should not simply sort each page, as this will give erroneous results to the client.
[ldapaged]で指定されているように、sortkeyrequestcontrolコントロールがpagedresultscontrolコントロールに含まれている場合、サーバーは結果セット全体に適用されたソートキーに従ってソートされたSearchResultentryメッセージを送信する必要があります。サーバーは、各ページを単純にソートする必要はありません。これにより、クライアントに誤った結果が得られるためです。
The sortKeyList must be present on each searchRequest message for the paged result. It also must not change between searchRequests for the same result set. If the server has sorted the data, then it SHOULD send back a sortKeyResponseControl control on every searchResultDone message for each page. This will allow clients to quickly determine if the result set is sorted, rather than waiting to receive the entire result set.
sortKeyListは、ページ結果の各SearchRequestメッセージに存在する必要があります。また、同じ結果セットに対してSearchRequests間で変更してはなりません。サーバーがデータをソートした場合、各ページのすべてのSearchResultDoneメッセージでsortKeyResponseControlコントロールを送信する必要があります。これにより、結果セット全体を受信するのを待つのではなく、結果セットがソートされているかどうかをクライアントがすばやく判断できます。
Implementors and administrators should be aware that allowing sorting of results could enable the retrieval of a large number of records from a given directory service, regardless of administrative limits set on the maximum number of records to return.
実装者と管理者は、結果の並べ替えを許可することで、最大記録の記録の数に設定された管理制限に関係なく、特定のディレクトリサービスから多数のレコードの取得を可能にすることができることに注意する必要があります。
A client that desired to pull all records out of a directory service could use a combination of sorting and updating of search filters to retrieve all records in a database in small result sets, thus circumventing administrative limits.
すべてのレコードをディレクトリサービスから引き出したいクライアントは、検索フィルターのソートと更新の組み合わせを使用して、小さな結果セットのデータベース内のすべてのレコードを取得して、管理制限を回避できます。
This behavior can be overcome by the judicious use of permissions on the directory entries by the administrator and by intelligent implementations of administrative limits on the number of records retrieved by a client.
この動作は、管理者によるディレクトリエントリの権限の賢明な使用と、クライアントが取得したレコードの数に管理制限のインテリジェントな実装によって克服できます。
[LDAPv3] Wahl, M, Kille, S. and T. Howes, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[LDAPV3] Wahl、M、Kille、S。、およびT. Howes、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。
[Bradner97] Bradner, S., "Key Words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[Bradner97] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[LdapPaged] Weider, C., Herron, A., Anantha, A. and T. Howes, "LDAP Control Extension for Simple Paged Results Manipulation", RFC 2696, September 1999.
[ldappaged] Weider、C.、Herron、A.、Anantha、A。and T. Howes、「単純なページ結果操作のためのLDAP制御拡張」、RFC 2696、1999年9月。
Anoop Anantha Microsoft Corp. 1 Microsoft Way Redmond, WA 98052 USA
Anoop Anantha Microsoft Corp. 1 Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 882-8080
EMail: anoopa@microsoft.com
Tim Howes Loudcloud, Inc. 615 Tasman Dr. Sunnyvale, CA 94089 USA
Tim Howes Loudcloud、Inc。615 Tasman Dr. Sunnyvale、CA 94089 USA
EMail: howes@loudcloud.com
Mark Wahl Sun Microsystems, Inc. 8911 Capital of Texas Hwy Suite 4140 Austin, TX 78759 USA
Mark Wahl Sun Microsystems、Inc。8911 Texas Hwy Suite 4140 Austin、TX 78759 USA
EMail: Mark.Wahl@sun.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。