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
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.
版权所有（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）定义了两个扩展（选择和排序）。这些扩展允许用户代理（UA）请求将服务应答（SrvRply）中的统一资源定位器（URL）条目限制为指定的数量，或根据指定的排序键列表进行排序。同时使用这两个扩展可以帮助发现最佳匹配，例如找到具有最大速度或最小负载的服务。
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]定义了两个扩展（选择和排序）。这些扩展允许UA请求将SrvRply中的URL条目限制在指定的数量内，或根据指定的排序键列表进行排序。支持Select和/或Sort扩展的目录代理（DA）或服务代理（SA）必须在其播发（DAAD或SAAdvert）中包含属性关键字“Select enabled”和/或“Sort enabled”。UA应在使用Select和/或Sort扩展查询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的属性传递给客户端。此外，同时使用Select和Sort扩展可以帮助发现最佳匹配，例如查找具有最大速度或最小负载的服务，或者具有最接近参考值的速度的服务。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应根据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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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收到带有Select扩展名的SrvRqst时，如果DA/SA支持此扩展名，则必须在相应的SrvRply中使用Select扩展名来指示匹配URL条目的总数（例如，m），否则DA/SA必须将相应SrvRply中的错误代码设置为选项“未理解”[RFC2608]。如果n<m，则只返回前n个匹配的URL条目，否则返回所有m个匹配的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扩展名表示为Select（number）。因此，Select（3）意味着对应的SrvRply最多可以有三个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>\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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所示。UA在SrvRqst中使用此扩展来请求根据排序键列表对相应SRVRP中的URL条目进行排序。排序键列表使用扩展的Backus Naur表单（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
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有五种属性类型（整数、字符串、布尔、不透明和关键字），但是我们只考虑整数排序和字符串排序，因为关键字属性（它们没有值）永远不需要排序，布尔和不透明属性可以按需要排序为字符串。整数排序使用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:
只有整数键可以具有参考值，从而导致排序基于到参考值的距离。基于引用的排序（如“X:i:+:12”）需要以下两个步骤：
Step 1. For each matching service, if its attribute X has a value of x, then use |x-12| as its metric.
第一步。对于每个匹配服务，如果其属性X的值为X，则使用| X-12 |作为其度量。
Step 2. Use the metrics obtained in Step 1 to sort attribute X for matching services.
第二步。使用步骤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]中定义的轻型目录访问协议（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) 每个属性只能在排序键列表中出现一次（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节）。
(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中的错误代码设置为选项“未理解”[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（排序键列表）。以下示例说明了如何使用排序扩展。
o Integer sort on speed (decreasing order).
o 速度整数排序（降序）。
Sort(speed:i:-)
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:-)
Sort(load:i:+,speed:i:-)
[Note] "+" means increasing order.
[注]“+”表示递增顺序。
o String sort on model (increasing order).
o 模型上的字符串排序（递增顺序）。
Sort(model:s:+)
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)
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），那么排序后的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.
除了单独使用之外，Select和Sort扩展还可以一起使用，以便于发现最佳匹配，例如查找速度最高的服务。当这两个扩展出现在同一条SrvRqst消息中时，必须按照它们出现的顺序进行处理。接下来我们将展示一些示例。
o Find the service with the minimum load
o 找到负载最小的服务
Sort(load:i:+)
Select(1)
Sort(load:i:+)
Select(1)
o Find the three fastest services
o 查找三种最快的服务
Sort(speed:i:-)
Select(3)
Sort(speed:i:-)
Select(3)
o Find the service with the minimum load among the three fastest
o 在三个最快的服务中找到负载最小的服务
Sort(speed:i:-)
Select(3)
Sort(load:i:+)
Select(1)
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)
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从为“强制实施”扩展（即0x4000-0x7FFF范围）保留的SLP扩展空间（RFC 2608，第9.1节）中分配。
There are no new security issues beyond those described in RFC 2608.
除了RFC 2608中描述的安全问题外，没有其他新的安全问题。
Ira McDonald provided good suggestions.
Ira McDonald提供了很好的建议。
[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.和M.Day，“服务位置协议，版本2”，RFC 26081999年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.和A.Anantha，“搜索结果服务器端排序的LDAP控制扩展”，RFC 28912000年8月。
Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
赵伟斌哥伦比亚大学计算机科学系，地址：纽约州纽约市阿姆斯特丹大道1214号，邮编：0401，邮编：10027-7003
EMail: zwb@cs.columbia.edu
EMail: zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
Henning Schulzrinne哥伦比亚大学计算机科学系，地址：纽约州纽约市阿姆斯特丹大道1214号，邮编：0401，邮编：10027-7003
EMail: hgs@cs.columbia.edu
EMail: hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
埃里克·古特曼太阳微系统公司。74915德国威伯斯塔特
EMail: Erik.Guttman@sun.com
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研究中心美国纽约州霍桑市天际大道19号，邮编10532
EMail: bisdik@us.ibm.com
EMail: bisdik@us.ibm.com
William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA
William F.Jerome IBM Corp.Thomas J.Watson研究中心美国纽约州霍桑市天际大道19号，邮编10532
EMail: wfj@us.ibm.com
EMail: 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编辑功能的资金目前由互联网协会提供。