[要約] RFC 3421は、Service Location Protocol（SLP）のための拡張機能の選択とソートに関する規格です。このRFCの目的は、SLPの機能を拡張し、サービスの選択とソートを効率的に行うことです。
Network Working Group W. Zhao
Request for Comments: 3421 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
C. Bisdikian
W. Jerome
IBM
November 2002
Select and Sort Extensions for the Service Location Protocol (SLP)
サービスロケーションプロトコル（SLP）の拡張機能を選択してソートします
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP). These extensions allow a User Agent (UA) to request that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to the specified number, or be sorted according to the specified sort key list. Using these two extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load.
このドキュメントでは、サービスロケーションプロトコル（SLP）の2つの拡張機能（選択とソート）を定義します。これらの拡張機能により、ユーザーエージェント（UA）は、サービス返信（srvrply）のユニフォームリソースロケーター（URL）エントリを指定された番号に制限するか、指定されたソートキーリストに従ってソートすることを要求できます。これらの2つの拡張機能を一緒に使用すると、最大速度や最小負荷のサービスを見つけるなど、最高の一致を発見することができます。
This document defines two extensions (Select and Sort) for SLP [RFC2608]. These extensions allow a UA to request that the URL entries in a SrvRply be limited to the specified number, or be sorted according to the specified sort key list. A Directory Agent (DA) or Service Agent (SA) that supports the Select and/or Sort extensions MUST include the attribute keyword "select-enabled" and/or "sort-enabled" in its advertisement (DAAdvert or SAAdvert). A UA SHOULD check these attributes of the contacting DA/SA before it uses the Select and/or Sort extensions to query the DA/SA.
このドキュメントでは、SLP [RFC2608]の2つの拡張機能（選択と並べ替え）を定義します。これらの拡張機能により、UAはSRVRのURLエントリを指定された番号に制限するか、指定されたソートキーリストに従ってソートすることを要求できます。拡張機能および/またはソートをサポートするディレクトリエージェント（DA）またはサービスエージェント（SA）には、属性キーワード「select-exhabled」および/or "sort-enabled"（daadvertまたはsaadvert）を含める必要があります。UAは、選択および/またはソート拡張機能を使用してDA/SAを照会する前に、連絡先DA/SAのこれらの属性を確認する必要があります。
Using the Select extension, a UA can opt for finding just a few (not necessarily all) matching services, which is useful if the UA uses a low-bandwidth channel. Using the Sort extension, a UA can ask the DA/SA to sort matching URL entries, which helps the UA to choose a service from multiple candidates. Sorting by the server is more efficient than sorting by the client since for sorting purposes, the former does not need to pass the attributes of matching URLs to the client. Furthermore, using the Select and Sort extensions together can facilitate discovering the best match, such as finding a service that has the maximum speed or the minimum load, or has a speed closest to a reference value.
SELECT拡張機能を使用して、UAはほんの数回の（必ずしもすべてではない）一致するサービスを見つけることを選択できます。これは、UAが低帯域幅チャネルを使用する場合に役立ちます。ソート拡張機能を使用して、UAはDA/SAに一致するURLエントリをソートするように依頼することができます。これにより、UAが複数の候補者からサービスを選択するのに役立ちます。サーバーによる並べ替えは、ソート目的のためにクライアントがソートするよりも効率的です。前者は、URLの一致する属性をクライアントに渡す必要はありません。さらに、選択とソートの拡張機能を一緒に使用すると、最大速度または最小負荷のサービスを見つけるか、参照値に最も近い速度を持つサービスを見つけるなど、最高の一致を発見することが容易になります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted according to in BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に従って解釈する。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Select Extension ID = 0x4002 | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, cont'd | Number of URL Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Select Extension
図1.拡張機能を選択します
The format of the Select extension is shown in Figure 1. A UA uses this extension in a Service Request (SrvRqst) to limit the maximum number (say, n) of URL entries to be returned. When a DA/SA receives a SrvRqst with a Select extension, it MUST use a Select extension in the corresponding SrvRply to indicate the total number (say, m) of matching URL entries if the DA/SA supports this extension, otherwise the DA/SA MUST set the error code in the corresponding SrvRply to OPTION_NOT_UNDERSTOOD [RFC2608]. If n < m, then only the first n matching URL entries are returned, else all m matching URL entries are returned. As a special case, a UA may set n to zero to obtain the number of matching URL entries without retrieving the entries themselves.
Select拡張子の形式を図1に示します。UAは、この拡張機能をサービス要求（SRVRQST）で使用して、返されるURLエントリの最大数（たとえば、n）を制限します。DA/SAがSERECT拡張機能を備えたSRVRQSTを受信した場合、DA/SAがこの拡張機能をサポートしている場合、対応するSRVRPLYで選択された拡張機能を使用してURLエントリの総数（たとえば、M）を示す必要があります。SAは、対応するsrvrplyでエラーコードをOption_not_understood [rfc2608]に設定する必要があります。n <mの場合、最初のNマッチングURLエントリのみが返されます。特別なケースとして、UAはnをゼロに設定して、エントリ自体を取得せずに一致するURLエントリの数を取得する場合があります。
We denote a Select extension as Select(number). Thus, Select(3) means that the corresponding SrvRply can have at most three URL entries.
SELECT拡張子を選択（番号）として示します。したがって、選択（3）は、対応するSRVRPLYが最大3つのURLエントリを持つことができることを意味します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sort Extension ID = 0x4003 | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, cont'd | length of <sort-key-list> |<sort-key-list>\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Sort Extension
図2.拡張機能をソートします
The format of the Sort extension is shown in Figure 2. A UA uses this extension in a SrvRqst to request the URL entries in the corresponding SrvRply be sorted according to the sort-key-list. The sort-key-list is defined using Augmented Backus-Naur Form (ABNF) [RFC2234] as follows:
ソートエクステンションの形式を図2に示します。AUAは、SRVRQSTでこの拡張機能を使用して、対応するSRVRPLYのURLエントリをソートキーリストに従ってソートします。ソートキーリストは、次のように、拡張されたバックスノーフォーム（ABNF）[RFC2234]を使用して定義されます。
sort-key-list = sort-key / sort-key "," sort-key-list
sort-key = key-name ":" type ":" ordering [":" ref-value]
key-name = attr-tag from Section 5 of RFC 2608
type = "s" / "i"
; "s" for string type
; "i" for integer type
ordering = "+" / "-"
; "+" for increasing order
; "-" for decreasing order
ref-value = intval from Section 5 of RFC 2608
Each sort-key in the sort-key-list has a key-name, a type specifier, an ordering specifier, and an optional reference value. The key-name MUST be a valid attribute name, and its type is explicitly specified. Although SLP has five attribute types (integer, string, boolean, opaque and keyword), we only consider integer sort and string sort since keyword attributes (they have no values) never need to be sorted, and boolean and opaque attributes can be sorted as strings if needed. The integer sort uses the integerOrderingMatch rule defined in X.520 [X520], whereas the string sort is performed based on lexical ordering. Strings are compared using the rules defined in Section 6.4 of RFC 2608.
ソートキーリストの各ソートキーには、キー名、型指定子、順序指定子、およびオプションの参照値があります。キー名は有効な属性名である必要があり、そのタイプは明示的に指定されています。SLPには5つの属性タイプ（整数、文字列、ブール値、不透明、キーワード）がありますが、キーワード属性（値がない）をソートする必要はなく、ブールとオパークの属性をソートすることができるため、整数と文字列のソートのみを考慮します。必要に応じて文字列。整数ソートは、x.520 [x520]で定義されている整数順序マッチルールを使用しますが、文字列ソートは語彙順序に基づいて実行されます。文字列は、RFC 2608のセクション6.4で定義されているルールを使用して比較されます。
Only integer keys may have a reference value, causing the sort to be based on the distance to the reference value. A reference-based sort, such as "X:i:+:12", requires the following two steps:
整数キーのみが基準値を持つ場合があり、ソートは参照値までの距離に基づいています。「x：i ：： 12」などの参照ベースのソートには、次の2つのステップが必要です。
Step 1. For each matching service, if its attribute X has a value of x, then use |x-12| as its metric.
ステップ1.一致するサービスごとに、属性xがxの値を持っている場合、| x-12 |を使用します。そのメトリックとして。
Step 2. Use the metrics obtained in Step 1 to sort attribute X for matching services.
ステップ2.ステップ1で取得したメトリックを使用して、一致するサービスに属性Xをソートします。
The SLP sort rules are adapted from the Lightweight Directory Access Protocol (LDAP) sort rules defined in RFC 2891 [RFC2891]. Note that sort in SLP is a best effort, no sort error will be returned from a DA/SA to a UA.
SLPソートルールは、RFC 2891 [RFC2891]で定義されているLightWeight Directory Access Protocol（LDAP）ソートルールから採用されています。SLPのソートは最善の努力であり、DA/SAからUAにソートエラーが返されないことに注意してください。
(1) The sort-key-list is in order of highest to lowest sort key precedence (Section 1.1 of RFC 2891).
(1) ソートキーリストは、最高から低いソートキーの優先順位の順にあります（RFC 2891のセクション1.1）。
(2) Each attribute SHOULD only occur in the sort-key-list once (Section 1.1 of RFC 2891). If an attribute is included in the sort-key-list multiple times, only its first occurrence is considered, all other occurrences are ignored.
(2) 各属性は、sort-key-list（RFC 2891のセクション1.1）でのみ発生する必要があります。ソートキーリストに複数回属性が含まれている場合、その最初の発生のみが考慮される場合、他のすべての発生は無視されます。
(3) For a multi-valued attribute, the least value in each entry SHOULD be used in sort (Section 2.2 of RFC 2891).
(3) 多値の属性の場合、各エントリの最小値は、ソートで使用する必要があります（RFC 2891のセクション2.2）。
(4) An entry missing one or more of the sort keys is treated as having NULLs for those missing keys (Section 2.2 of RFC 2891).
(4) 種類のキーの1つ以上が欠落しているエントリは、不足しているキーにヌルがあると扱われます（RFC 2891のセクション2.2）。
(5) NULL is considered as a larger value than all other valid values (Section 2.2 of RFC 2891).
(5) nullは、他のすべての有効な値よりも大きな値と見なされます（RFC 2891のセクション2.2）。
(6) As the attribute type in SLP is not enforced, an attribute may have inconsistent values. For the purpose of sorting, inconsistent values may exist only when an attribute is sorted as integer. Inconsistent values SHOULD be treated as NULLs.
(6) SLPの属性タイプが強制されていないため、属性に一貫性のない値がある場合があります。ソートの目的のために、属性が整数としてソートされた場合にのみ、一貫性のない値が存在する場合があります。一貫性のない値は、ヌルとして扱う必要があります。
When a DA/SA receives a SrvRqst with a Sort extension, it MUST set the error code in the corresponding SrvRply to OPTION_NOT_UNDERSTOOD [RFC2608] if the DA/SA does not support the Sort extension or cannot perform the requested sort. The DA/SA sets the error code in the corresponding SrvRply to zero if it has successfully processed the SrvRqst and performed the requested sort.
DA/SAがソート拡張機能でSRVRQSTを受信した場合、DA/SAがソート拡張機能をサポートしていないか、要求されたソートを実行できない場合、対応するsrvrplyにoption_not_understood [rfc2608]にエラーコードを設定する必要があります。DA/SAは、SRVRQSTを正常に処理し、要求されたソートを実行した場合、対応するSRVRPLYのエラーコードをゼロに設定します。
We denote a Sort extension as Sort(sort-key-list). The following examples illustrate how to use the Sort extension.
ソート拡張機能をソート（sort-key-list）として示します。次の例は、ソート拡張機能の使用方法を示しています。
o Integer sort on speed (decreasing order).
o 速度上の整数ソート（順序の減少）。
Sort(speed:i:-)
[Note] "i" means integer sort, and "-" means decreasing order.
[注]「I」とは整数の種類を意味し、「 - 」とは順序の減少を意味します。
o Integer sort on load (increasing order) and speed (decreasing order).
o 負荷上の整数ソート（順序の増加）と速度（順序の減少）。
Sort(load:i:+,speed:i:-)
[Note] "+" means increasing order.
[注] ""は順序の増加を意味します。
o String sort on model (increasing order).
o 文字列並べ替えモデル（注文の増加）。
Sort(model:s:+)
[Note] "s" means string sort.
[注]「S」は文字列ソートを意味します。
o Integer sort on speed (increasing order), based on a reference value 12.
o 参照値12に基づいて、速度上の整数（順序の増加）。
Sort(speed:i:+:12)
[Note] For example, if we have four matching services, with the "speed" attribute as 8 (URL1), 10 (URL2), 12 (URL3), and 15 (URL4), then the sorted URL list will be "URL3,URL2,URL4,URL1" (based on the metric ordering of |12-12| < |12-10| < |12-15| < |12-8|).
[注]たとえば、「速度」属性を8（url1）、10（url2）、12（url3）、および15（url4）とする4つのマッチングサービスがある場合、ソートされたURLリストは「url3になります。、url2、url4、url1 "（| 12-12 | <| 12-10 | <| 12-15 | <| 12-8 |のメトリック順序に基づく）。
In addition to being used individually, the Select and Sort extensions can be used together to facilitate discovering the best match, such as finding a service with the maximum speed. When these two extensions appear in the same SrvRqst message, they MUST be processed in the order of their presence. We show some examples next.
個別に使用することに加えて、選択とソートの拡張機能を一緒に使用して、最高速度のサービスを見つけるなど、最高の試合を発見することを容易にすることができます。これら2つの拡張機能が同じSRVRQSTメッセージに表示される場合、それらは存在の順に処理する必要があります。次にいくつかの例を示します。
o Find the service with the minimum load
o 最小負荷でサービスを見つけます
Sort(load:i:+)
Select(1)
o Find the three fastest services
o 3つの最速のサービスを見つけます
Sort(speed:i:-)
Select(3)
o Find the service with the minimum load among the three fastest
o 最速の3つの中から最小負荷のサービスを見つける
Sort(speed:i:-)
Select(3)
Sort(load:i:+)
Select(1)
o Find the service that has a speed closest to 12
o 12に最も近い速度を持つサービスを見つける
Sort(speed:i:+:12)
Select(1)
The Select and Sort extension IDs, 0x4002 and 0x4003, described in Section 2 and Section 3, respectively, have been assigned by IANA out of the SLP extension space (RFC 2608, Section 9.1) reserved for "mandatory to implement" extensions (i.e., the 0x4000-0x7FFF range).
セクション2およびセクション3で説明されている拡張およびソートの拡張ID（0x4002および0x4003）は、IANAによってそれぞれSLP拡張スペース（RFC 2608、セクション9.1）から割り当てられています。0x4000-0x7fff範囲）。
There are no new security issues beyond those described in RFC 2608.
RFC 2608に記載されているものを超えて、新しいセキュリティの問題はありません。
Ira McDonald provided good suggestions.
イラ・マクドナルドは良い提案を提供しました。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[X520] International Telephone Union, "The Directory: Selected Attribute Types", X.520, 1997.
[X520]国際電話同盟、「ディレクトリ：選択された属性タイプ」、X.520、1997。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[RFC2891] Howes, T., Wahl, M. and A. Anantha, "LDAP Control Extension for Server Side Sorting of Search Results", RFC 2891, August 2000.
[RFC2891] Howes、T.、Wahl、M。and A. Anantha、「サーバー側の検索結果の並べ替えのためのLDAP制御拡張」、RFC 2891、2000年8月。
Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
ワイビンZhaoコンピュータサイエンスコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027-7003
EMail: zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
ヘニングシュルツリンコンピュータサイエンスコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027-7003
EMail: hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
Erik Guttman Sun Microsystems Eichhoelzelstr。7 74915 Waibstadtドイツ
EMail: Erik.Guttman@sun.com
Chatschik Bisdikian IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA
Chatschik Bisdikian IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne、NY 10532、米国
EMail: bisdik@us.ibm.com
William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA
ウィリアムF.ジェロームIBM Corp.トーマスJ.ワトソンリサーチセンター19スカイラインドライブホーソーン、ニューヨーク10532、米国
EMail: wfj@us.ibm.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。