RFC 3421

Select and Sort Extensions for the Service Location Protocol (SLP)

📅 published November 2002, from ietf

RFC 3421: Select and Sort Extensions for the Service Location Protocol (SLP) 🎀

Okay bestie, this is RFC 3421, and the title says it all ✨ It's about two extensions for SLP called Select and Sort 💅 It came out in November 2002 🍓 It's an Experimental document, which means it defines an Experimental Protocol and not an official standard 🧪 The authors are W. Zhao and H. Schulzrinne (Columbia University), E. Guttman (Sun Microsystems), and C. Bisdikian and W. Jerome (IBM) 💜 The title block doesn't list anything it obsoletes or updates, so it's a fresh one 🌸 It's filed under the Network Working Group heading 🫶

Status of this Memo 📜

Okay so this memo defines an Experimental Protocol for the Internet community 🧪 It doesn't specify an Internet standard of any kind. They're asking for discussion and suggestions for improvement, and distribution of the memo is unlimited 💖

Copyright (C) The Internet Society (2002). All Rights Reserved. 🌈

Abstract ✨

This document defines two extensions (Select and Sort) for the Service Location Protocol (SLP) 🦋 They let a User Agent (UA) ask that the Uniform Resource Locator (URL) entries in a Service Reply (SrvRply) be limited to a specified number, or be sorted by a specified sort key list 🔥 Using both together can help you find the best match, like a service with the maximum speed or the minimum load 🏆

1. Introduction 💖

Okay so this document defines the same two extensions, Select and Sort, for SLP [RFC2608] 🎀 They let a UA ask that the URL entries in a SrvRply be limited to a specified number, or be sorted according to a 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 👀

Using Select, a UA can opt for finding just a few matching services (not necessarily all of them), which is super useful if the UA is on a low-bandwidth channel 🐢 Using Sort, a UA can ask the DA/SA to sort the matching URL entries, which helps the UA pick a service from multiple candidates 🧚 Sorting on the server is more efficient than sorting on the client, since the server doesn't have to pass the attributes of the matching URLs to the client at all 🚀 And using Select and Sort together can help you discover the best match, like finding a service with the maximum speed or the minimum load, or one with 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 BCP 14, RFC 2119 [RFC2119] 📖

2. Select Extension 🍓

Here's the Select extension layout, bestie 🧩

    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

So the format 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 that get returned 💫 When a DA/SA gets a SrvRqst with a Select extension, it MUST use a Select extension in the corresponding SrvRply to report the total number (say, m) of matching URL entries, but only 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 get returned. Otherwise all m matching URL entries are returned 🎯 And here's the special case: a UA can set n to zero to get the number of matching URL entries without actually retrieving the entries themselves 🌈

We write a Select extension as Select(number). So Select(3) means the corresponding SrvRply can have at most three URL entries 💜

3. Sort Extension 🦋

Here's the Sort extension layout 🧩

    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

The format of the Sort extension is in Figure 2 💅 A UA uses it in a SrvRqst to ask that 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] like this:

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 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 🔒 SLP has five attribute types (integer, string, boolean, opaque and keyword), but only integer sort and string sort are considered 💁‍♀️ Keyword attributes have no values, so they never need sorting, and boolean and opaque attributes can be sorted as strings if needed 🧠 Integer sort uses the integerOrderingMatch rule defined in X.520 [X520], and string sort is done by lexical ordering. Strings are compared using the rules in Section 6.4 of RFC 2608 🔤

Only integer keys can have a reference value, which makes the sort based on the distance to that reference value 🎯 A reference-based sort, like "X:i:+:12", takes two steps:

Step 1. For each matching 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 matching services.

The SLP sort rules are adapted from the Lightweight Directory Access Protocol (LDAP) sort rules in RFC 2891 [RFC2891] 🌸 Heads up, though: sort in SLP is best effort, so no sort error gets returned from a DA/SA to a UA 🫶

  1. The sort-key-list goes from 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 shows up in the sort-key-list multiple times, only its first occurrence is considered, and all the other occurrences are ignored 🙅‍♀️
  3. For a multi-valued attribute, the least value in each entry SHOULD be used in the 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 missing keys (Section 2.2 of RFC 2891) 🫥
  5. NULL is considered a larger value than all other valid values (Section 2.2 of RFC 2891) 📈
  6. Since the attribute type in SLP isn't enforced, an attribute may have inconsistent values. For sorting purposes, inconsistent values can only exist when an attribute is sorted as an integer. Inconsistent values SHOULD be treated as NULLs 🧩

When a DA/SA gets 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 doesn't support the Sort extension or can't perform the requested sort ❌ The DA/SA sets the error code in the corresponding SrvRply to zero if it successfully processed the SrvRqst and performed the requested sort ✅

We write a Sort extension as Sort(sort-key-list). Here are some examples to make it click 🧁

  • Integer sort on speed (decreasing order).
Sort(speed:i:-)

[Note] "i" means integer sort, and "-" means decreasing order.

  • Integer sort on load (increasing order) and speed (decreasing order).
Sort(load:i:+,speed:i:-)

[Note] "+" means increasing order.

  • String sort on model (increasing order).
Sort(model:s:+)

[Note] "s" means string sort.

  • Integer sort on speed (increasing order), based on a reference value 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|). 🤯

10. Authors' Addresses ✨

okay so this is the crew that wrote it, bestie 🫶 and yes, they all have real addresses listed so you know exactly who to thank (or yell at) 💅

Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 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

EMail: hgs@cs.columbia.edu

Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany

EMail: Erik.Guttman@sun.com

Chatschik Bisdikian IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA

EMail: bisdik@us.ibm.com

William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA

EMail: wfj@us.ibm.com

okay now the legal bit, and I'm not gonna pretend it's the most exciting thing ever 😭 but it matters, so here it is in full:

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.

Acknowledgement 🌸

Funding for the RFC Editor function is currently provided by the Internet Society.

📦 where this page comes from