INTERNET DRAFT Weibin Zhao draft-zhao-slp-customization-05.txt Henning Schulzrinne [Target Category: Experimental] Columbia University August 29, 2002 Erik Guttman Expires: March 1, 2003 Sun Microsystems Chatschik Bisdikian William Jerome IBM Selection and Sort Extension for SLP Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines the Selection and Sort Extension for the Service Location Protocol. These extensions allow a User Agent to request that the URL entries in a Service Reply be bounded 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. Zhao, et al. Expires: March 1, 2003 [Page 1] Internet Draft SLP Customization August 29, 2002 1. Introduction This document defines the Selection and Sort Extension for the Service Location Protocol (SLP [RFC2608]). These extensions allow a User Agent (UA) to request that the URL entries in a Service Reply (SrvRply) be bounded 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 Selection and/or Sort Extension MUST include the attribute keyword "selection-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 Selection and/or Sort Extension to query the DA/SA. Using the Selection Extension, a UA can opt for finding a few (not all) 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 matched URL entries, which helps the UA to choose a service from multiple candidates. As sort at the server side does not need to pass attributes to the UA, it is more efficient than sort at the client side. Furthermore, using the Selection and Sort Extension 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. 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 RFC 2119 [RFC2119]. 2. Selection Extension 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Selection Extension ID = TBD1 | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, cont'd | Number of URL Entries | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Selection Extension The format of the Selection 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 Selection Extension, it MUST use a Selection Extension in the corresponding SrvRply to indicate the total number (say m) of matched 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 Zhao, et al. Expires: March 1, 2003 [Page 2] Internet Draft SLP Customization August 29, 2002 matched URL entries are returned, else all m matched URL entries are returned. As a special case, a UA may set n to zero to obtain the number of matched URL entries without retrieving the entries themselves. We denote a Selection Extension as Select(number). Thus, Select(3) means that the corresponding SrvRply can have at most three URL entries. 3. Sort Extension 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 = TBD2 | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, cont'd | length of |\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Sort Extension 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 ABNF [RFC2234] as follows: 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. Zhao, et al. Expires: March 1, 2003 [Page 3] Internet Draft SLP Customization August 29, 2002 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: Step 1. For each matched service, if its attribute X has a value of x, then use |x-12| as its metric. Step 2. Use the metrics obtained in Step 1 to sort attribute X for matched services. The SLP sort rules are adapted from the 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. (1) The sort-key-list is in order of highest to lowest sort key precedence (section 1.1 of RFC 2891). (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. (3) For a multi-valued attribute, the least value in each entry SHOULD be used in sort (section 2.2 of RFC 2891). (4) An entry missing one or more of the sort keys is treated as having NULLs for those missed keys (section 2.2 of RFC 2891). (5) NULL is considered as a larger value than all other valid values (section 2.2 of RFC 2891). (6) As the attribute type in SLP is not enforced, an attribute may have inconsistent values. For the purpose of sort, inconsistent values may exist only when an attribute is sorted as integer. Inconsistent values SHOULD be treated as NULLs. When a DA/SA receives a SrvRqst with a Sort Extension, the DA/SA SHOULD set the error code in the corresponding SrvRply to OPTION_NOT_UNDERSTOOD [RFC2608] if the DA/SA does not support the Sort Extension, or to zero if the DA/SA has successfully performed the requested sort. 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). Sort(speed:i:-) Zhao, et al. Expires: March 1, 2003 [Page 4] Internet Draft SLP Customization August 29, 2002 [Note] "i" means integer sort, and "-" means decreasing order. o Integer sort on load (increasing order) and speed (decreasing order). Sort(load:i:+,speed:i:-) [Note] "+" means increasing order. o String sort on model (increasing order). Sort(model:s:+) [Note] "s" means string sort. o Integer sort on speed (increasing order), based on a reference value 12. Sort(speed:i:+:12) For example, if we have four matched 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|). 4. Using the Selection and Sort Extension Together In addition to being used individually, the Selection and Sort Extension 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. o Find the minimum load Sort(load:i:+) Select(1) o Find the top three speeds Sort(speed:i:-) Select(3) o Find the minimum load among the top three speed Sort(speed:i:-) Select(3) Sort(load:i:+) Zhao, et al. Expires: March 1, 2003 [Page 5] Internet Draft SLP Customization August 29, 2002 Select(1) o Find the service that has a speed closest to 12 Sort(speed:i:+:12) Select(1) 5. IANA Considerations The Selection and Sort extension IDs, TBD1 and TBD2, described in Section 2 and Section 3, respectively, are to be 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). 6. Security Considerations There are no new security issues beyond those described in RFC 2608. 7. Acknowledgments Ira McDonald provided good suggestions. 8. Normative References [RFC2608] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location protocol, version 2", RFC 2608, June 1999. [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. 9. Non-normative References [X520] International Telephone Union, "The Directory: Selected Attribute Types", X.520, 1997. [RFC2234] D. Crocker and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2891] T. Howes, M. Wahl and A. Anantha, "LDAP Control Extension for Server Side Sorting of Search Results", RFC 2891, August 2000. 10. Authors' Addresses Weibin Zhao Henning Schulzrinne Department of Computer Science Columbia University Zhao, et al. Expires: March 1, 2003 [Page 6] Internet Draft SLP Customization August 29, 2002 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 Email: {zwb,hgs}@cs.columbia.edu Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany Email: Erik.Guttman@sun.com Chatschik Bisdikian William F. Jerome IBM T. J. Watson Research Center P.O.Box 218 Yorktown Heights, NY 10598-0218 Email: {bisdik,wfj}@us.ibm.com 11. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. 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. Zhao, et al. Expires: March 1, 2003 [Page 7]