INTERNET DRAFT Weibin Zhao draft-zhao-slp-customization-01.txt Henning Schulzrinne July 20, 2001 Columbia University Expires: January 20, 2002 Chatschik Bisdikian William Jerome IBM Customization for SLP Service Request and Reply 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 (2001). All Rights Reserved. Abstract This document defines the Bound and Sort extensions for the Service Location Protocol to support customization in the UA-DA (User Agent vs. Directory Agent) interaction via Service Request and Service Reply messages. These extensions enable a UA to request a DA to bound (limit) the result size as well as to sort the result list in the Service Reply message. Zhao, et al. Expires: January 20, 2002 [Page 1] Internet Draft SLP Customization July 20, 2001 1. Introduction Currently, the Service Location Protocol (SLP [1]) only uses service properties (type, scope and attribute predicate) for discovery. There is a need to also consider user information, such as user context (e.g., location) and user preference (e.g., the maximum size and ordering of the result list), when multiple services match a Service Request (SrvRqst) so as to customize the Service Reply (SrvRply) to tailor it the user request. Customization for SLP SrvRqst and SrvRply messages can provide several advantages. First, user context is important in some applications, such as location-based discovery (finding a service that is close to the user). Second, bounding (limiting) the result size may be useful when a user has limited resources or uses a low- bandwidth channel. In some cases, a user may just want to find a few services, not tens or hundreds of them. Third, when an ordered result list is needed, server-side sorting is more efficient than client- side sorting in that it can avoid the need to pass attributes to the client (which can be done via the Attribute List extension [2]). In this document, we define the Bound and Sort extensions for SLP to support customization in the UA-DA (User Agent vs. Directory Agent) interaction via SrvRqst and SrvRply messages. These extensions enable a UA to request a DA to bound (limit) the result size as well as to sort the result list in the SrvRply message. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3]. 2. Bound Extension Figure 1 shows the format of the Bound 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bound Extension ID = TBD | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, cont'd | Bound-Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Bound Extension A UA uses the Bound extension in a SrvRqst to bound the maximum number of URL entries (to the Bound-Size) in the corresponding SrvRply. Zhao, et al. Expires: January 20, 2002 [Page 2] Internet Draft SLP Customization July 20, 2001 For a DA that supports the Bound extension, and assume the Bound-Size is N, the DA SHALL return the whole result list if the number of URL entries in the list is less than N, otherwise only return the first N URL entries in the result list. When a DA receives a SrvRqst that has the Bound extension, the DA MUST reply with a SrvRply using a zero as the error code if it successfully processes the request, or using an OPTION_NOT_UNDERSTOOD [1] as the error code if the DA does not support the Bound extension. 3. Sort Extension Figure 2 shows the format of the 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 = TBD | Next Extension Offset (NEO) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NEO, cont'd | Sort-Order | Length of Attribute List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute List \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Sort Extension A UA uses the Sort extension in a SrvRqst to request the DA to sort the result list on the specified attributes in the Sort-Order. If multiple attributes are present in the Attribute List, they are in order of highest to lowest sort key precedence. For each attribute in the Attribute List, if it is an attribute tag, then the natural sort is applied: strings are sorted on strict lexical UTF-8 [4] ordering, integers are sorted on values, and booleans are sorted as true before false. All attribute types SHOULD be obtained from the service template. Sort is not supported for an attribute if the attribute is not defined in the service template, has a type of opaque or keywords, or has multiple values. In the default sorting order (increasing order), sorted entries are followed by unsorted entries, which is the same as the LDAP sorting rule [5]. The Sort-Order is given in a bit-field where 0 is used for increasing order (the default order) and 1 is used for decreasing order. The Sort-Order byte can specify at most 8 attribute sorting orders corresponding to their positions in the Attribute List. For example, Zhao, et al. Expires: January 20, 2002 [Page 3] Internet Draft SLP Customization July 20, 2001 0x00 means that all specified attributes are sorted in increasing order, and 0xA0 means that the first and the third specified attribute are sorted in decreasing order. If an attribute in the Attribute List has a value (e.g., LOCATION = X), then the UA requests the DA to compare the LOCATION attribute value of each matched service with the reference value X (which is the user context). The comparison returns a non-negative metric reflecting the difference of the two compared values. Then the DA SHOULD use these metrics instead of the original LOCATION attribute values to sort matched services. Sorting on difference metrics in terms of a reference value is useful for supporting location-based discovery which needs to compare a service location with a reference location. For example, if there is a printer in room 442 and room 458, respectively, which printer is closer to a user in room 449? A DA can support this reference-based comparison by using a customized comparator, which is associated with an attribute of a service template [6], and can be triggered to perform comparison of two values and return a difference metric. How to manage customized comparators inside a DA is beyond the scope this draft. For a SrvRqst that has the Sort extension, a DA MUST reply with a SrvRply using a zero as the error code if it successfully processes the request, using OPTION_NOT_UNDERSTOOD [1] as the error code if the DA does not support the Sort extension, or using SORT_ERROR (Section 6) as the error code if the DA encounters any sorting errors. 4. Customization Using Bound and Sort Extension The Bound and Sort extension can be used individually or be composed in some ways. For example, maximum speed (or minimum load) can be expressed as a sort followed by a selection of the first entry, and minimum load in the top three fastest machines can be expressed as a {sort, selection, sort, selection} sequence. We use a tuple (bound, bound-size) to represent a Bound extension, and use a tuple (sort, sort-order, attribute-list) to represent a Sort extension. A customization that needs multiple extensions is illustrated as multiple tuples. Example 1. sort in decreasing speed: (sort, 0x80, {speed}) Example 2. bound to three URLs (bound, 3) Zhao, et al. Expires: January 20, 2002 [Page 4] Internet Draft SLP Customization July 20, 2001 Example 3. minimum load: (sort, 0x00, {load}) (bound, 1) Example 4. top three fastest speeds: (sort, 0x80, {speed}) (bound, 3) Example 5. minimum load in the top three fastest speeds: (sort, 0x80, {speed}) (bound, 3) (sort, 0x00, {load}) (bound, 1) Example 6. sort in decreasing speed and increasing load: (sort, 0x80, {speed,load}) Example 7. the nearest service: (sort, 0x00, {location=x}) (bound, 1) 5. Processing the SrvRqst with Bound and Sort Extensions The processing of a SrvRqst can be viewed as having two stages: matching service properties to obtain a result list (may be empty), then customizing this result list according to the user request (specified via the Bound and Sort extensions). Note that a customization may have effects only if the original result list has more than one URL entries. In other words, if the original result list is empty or has only one URL entry, then any customization will produce no effect, and the Bound and Sort extensions can be safely ignored in this case. When multiple Bound and Sort extensions are present in a SrvRqst message, they MUST be processed in sequence. 6. Constants Bound Extension ID TBD (Section 2) Sort Extension ID TBD (Section 3) SORT_ERROR error code TBD (Section 3) 7. Security Considerations Each customized comparator for a reference-based comparison MUST be properly tested before it is enabled for using. Zhao, et al. Expires: January 20, 2002 [Page 5] Internet Draft SLP Customization July 20, 2001 8. References [1] E. Guttman, C. Perkins, J. Veizades and M. Day, "Service location protocol, version 2", RFC 2608, June 1999. [2] E. Guttman, "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001. [3] S. Bradner, "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. [4] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [5] T. Howes, M. Wahl and A. Anantha, "LDAP Control Extension for Server Side Sorting of Search Results", RFC 2891, August 2000. [6] E. Guttman, C. Perkins and J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999. 9. Authors' Addresses Weibin Zhao Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003 Email: {zwb,hgs}@cs.columbia.edu 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 10. Full Copyright Statement Copyright (C) The Internet Society (2001). 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 Zhao, et al. Expires: January 20, 2002 [Page 6] Internet Draft SLP Customization July 20, 2001 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: January 20, 2002 [Page 7]