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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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（Uniform Resource Locator）のエントリが指定された数に制限すること、または指定したソートキーリストに従ってソートするように要求することができます。一緒にこれらの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がSrvRplyでのURLエントリが指定された数に制限すること、または指定したソートキーリストに従ってソートするように要求することができます。ディレクトリエージェント（DA）または属性のキーワードを含まなければならない選択および/またはソート機能拡張をサポートしているサービス・エージェント（SA）は、「選択対応」および/またはその広告（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.
選択拡張子を使用して、UAは、UAは、低帯域幅のチャネルを使用している場合に便利ですわずか数（必ずしもすべてではない）のマッチングサービスを、見つけることを選ぶことができます。ソート拡張子を使用して、UAは、複数の候補の中からサービスを選択するためにUAを助けURLエントリを、一致するソートするDA / SAを求めることができます。ソートするために、前者はクライアントに一致する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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
選択エクステンションのフォーマットはA UAが返されるURLエントリの最大数（例えば、n）を制限するために、サービスリクエスト（SrvRqst）にこの拡張を使用して図1に示されています。 DA / SAを選択拡張子を持つSrvRqstを受信したときにDA / SAは、この拡張をサポートしている場合、それが一致するURLエントリの総数（たとえば、m）を示すために、対応するSrvRplyに選択エクステンションを使用しなければならない、そうでなければDA / SAは、[RFC2608]をOPTION_NOT_UNDERSTOOD、対応するSrvRplyにエラーコードを設定しなければなりません。 N <Mが、その後、最初のnマッチングURLエントリが返された場合、他のすべてメートルマッチングURLエントリが返されます。特殊なケースとして、UAは、エントリ自体を取得することなく一致URLエントリの数を取得するためにゼロにNを設定してもよいです。
We denote a Select extension as Select(number). Thus, Select(3) means that the corresponding SrvRply can have at most three URL entries.
私たちは、セレクト（番号）として選択拡張子を示します。このように、選択は（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:
ソート拡張のフォーマットはA UAは、対応SrvRplyにソートキーリストに従ってソートされるURLエントリを要求するSrvRqstにこの拡張を使用して図2に示されています。ソート・キー・リストは以下のように増補バッカス - ナウアフォーム（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
ソート・キー・リスト=ソート・キー/ソート・キー "" ソート・キー・リストのソート・キー=キー名 "：" タイプ "：" 発注の[ "：" REF-値]キー名= attr- RFC 2608タイプ= "S" / "I" の第5章からタグ。文字列型のための「S」。 "i" の整数型の順序付けのために= "+" / " - "; 「+」の順序を増加させるために、 「 - 」注文REF値を下げるため= RFC 2608のセクション5からINTVAL
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]で定義integerOrderingMatch規則を使用します。文字列は、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:
唯一の整数キーは、基準値までの距離に基づくようにソートを引き起こし、基準値を有していてもよいです。などの基準に基づくソート「：I：+：X 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.マッチングサービスの属性Xをソートするステップ1で得られた測定基準を使用してください。
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]で定義されたLDAP（Lightweight Directory Access Protocol）のソート規則から適応されています。 SLPでのその種はベストエフォートであることに注意してください、何のソート誤差はUAにDA / SAから返されません。
(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）各属性は一度だけソート・キー・リストに（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）ソートキーの一つ以上を欠落エントリは、それらの欠落キー（RFC 2891のセクション2.2）のためにNULLを有するものとして扱われます。
(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.
SLPの属性タイプが適用されないように（6）、属性は、一貫性のない値を有していてもよいです。選別の目的のために、一貫性のない値は、属性を整数としてソートされた場合にのみ存在してもよいです。矛盾する値がNULL値として扱われるべきです。
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ソート拡張をサポートしていないか、要求された並べ替えを行うことができない場合は、[RFC2608]をOPTION_NOT_UNDERSTOODに対応SrvRplyにエラーコードを設定しなければなりません。それは正常SrvRqstを処理し、要求されたソートを実行した場合にDA / SAはゼロに対応SrvRplyにエラーコードを設定します。
We denote a Sort extension as Sort(sort-key-list). The following examples illustrate how to use the Sort extension.
私たちは、ソート（ソート・キー・リスト）としてソート拡張を示します。次の例では、ソートの拡張機能を使用する方法を示しています。
o Integer sort on speed (decreasing order).
（降順）の速度でO整数ソート。
Sort(speed:i:-)
ソート（速度：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:-)
ソート（負荷：I：+、スピードた：i :-)
[Note] "+" means increasing order.
[注]「+」は昇順を意味します。
o String sort on model (increasing order).
モデル上のO文字列のソート（昇順）。
Sort(model:s:+)
ソート（モデル：S：+）
[Note] "s" means string sort.
【注意】「s」は、文字列の並べ替えを意味しています。
o Integer sort on speed (increasing order), based on a reference value 12.
基準値12に基づいて、速度にO整数ソート（昇順）。
Sort(speed:i:+:12)
ソート（速度：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
最小負荷でサービスを検索します
Sort(load:i:+)
Select(1)
o Find the three fastest services
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).
選択してSLPの拡張スペースのうち、IANAによって割り当てられている、それぞれ、第2節及び第3節で説明した拡張IDは、0x4002と0x4003を、ソート（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]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン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]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、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]クロッカー、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]ハウズ、T.、ワール、M.と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
コンピュータサイエンスコロンビア大学のWeibin趙省1214アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027から7003
EMail: zwb@cs.columbia.edu
メールアドレス：zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
コンピュータサイエンスコロンビア大学のヘニングSchulzrinneと学科1214アムステルダムアベニュー、MC 0401ニューヨーク、NY 10027から7003
EMail: hgs@cs.columbia.edu
メールアドレス：hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
エリック・グットマンSun MicrosystemsのEichhoelzelstr。 7 74915ヴァイプシュタットドイツ
EMail: Erik.Guttman@sun.com
メールアドレス：Erik.Guttman@sun.com
Chatschik Bisdikian IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA
Chatschik Bisdikian IBM社トーマス・J・ワトソン研究所19スカイラインドライブホーソーン、NY 10532、USA
EMail: bisdik@us.ibm.com
メールアドレス：bisdik@us.ibm.com
William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA
ウィリアム・F.ジェロームIBM社トーマス・J・ワトソン研究所19スカイラインドライブホーソーン、NY 10532、USA
EMail: wfj@us.ibm.com
メールアドレス：wfj@us.ibm.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。