Summary

  • RFC 3421 let an SLP client ask a server to sort matching service URLs and return only a selected number, but the first URL was first only under the requested keys and the server's stored attributes.
  • The reply kept different quantities separate: m was the total match count, n capped the returned subset, missing or inconsistent values became NULL, and the order of Sort and Select stages could change the winner.

A winner appeared before a connection existed

Service discovery sounds like a search for something alive. A client wants a nearby printer, a lightly loaded server or a device with a particular capability. Yet a directory normally answers from advertisements and attributes. It can compare those records before any TCP connection, application exchange or current performance measurement occurs.

That difference drove RFC 3421, published in November 2002 as an Experimental extension to the Service Location Protocol. SLP already allowed a User Agent to request services from a Directory Agent or Service Agent. The extension added two transformations: Sort could order matching URLs by named attributes, and Select could limit how many URLs came back.

The machinery was useful precisely because a complete reply could be wasteful on a narrow link. It also created an easy overclaim. “First in the returned list” sounds like “best service.” The RFC's actual evidence was narrower: this entry came first after one server applied these declared comparison rules to the attributes it held.

Select kept the total apart from the subset

A client sends Select(n) to request at most n URL entries. A supporting server returns Select(m), where m is the total number of matches. If n is smaller than m, only the first n entries travel. If n is at least m, all matches travel.

The special case Select(0) makes the distinction especially clear. The client receives the number of matches without receiving any matching URL. Count and inventory are separate facts. A monitoring system that turns m into “m endpoints were examined” would be wrong: the client may have examined none, and the directory may itself be working from registrations rather than live probes.

Likewise, a response containing three URLs does not prove there were only three matches. It may prove only that the requester set n to three. The total, the returned subset, the candidates later attempted and the services that succeeded need different fields.

Sort defined a model, not a measurement

The Sort extension carries an ordered list of keys. Each key names an attribute, declares string or integer comparison, chooses increasing or decreasing order and may include an integer reference value. Keys earlier in the list have higher precedence.

Reference sorting is revealing. If the request says that speed should be closest to 12, the server computes the absolute distance between each stored value and 12. The URL with speed 12 sorts before 10, 15 and 8. This is a correct mathematical result over the recorded attribute. It is not a new speed test.

String comparison is lexical under SLP's rules; integer comparison follows the referenced matching rule. Repeating a key does not create a second vote: only its first occurrence counts. These details make the ranking reproducible while exposing its policy. The request decides what matters, how it is typed and whether high or low wins.

Missing data did not disappear

Real directories contain incomplete and inconsistent registrations. RFC 3421 assigns missing sort keys a NULL value, and NULL sorts after every valid value. A value inconsistent with a requested integer sort is also treated as NULL. For a multi-valued attribute, the least value is used.

Those rules prevent an implementation from improvising silently, but they have consequences. A service with no load attribute falls behind every service with a valid load, regardless of its real load. A service advertising several loads is represented by its least value for sorting, not its average, maximum or latest. An incorrectly typed value becomes absence for that comparison.

The ordered list is therefore also a report about data shape. A low rank might mean a valid high load, a missing field or a type mismatch. The reply alone does not distinguish those causes unless the underlying attributes and processing record remain available.

Order could change which candidates survived

RFC 3421 requires multiple Select and Sort extensions to be processed in their order of appearance. Sort by speed, then Select three, then sort those three by load, then Select one: the result is the least-loaded service among the three fastest according to the stored data.

Reverse the first two operations and the candidate population changes. Select three before sorting means some services may be discarded before speed is examined. Sorting the full set by load and selecting one answers a different question again.

This was not an accidental implementation detail. The extension chain was a small query plan. Every Select stage changed what later stages were allowed to see. A final winner cannot be interpreted without the ordered plan, just as a database result cannot be reconstructed from its last ORDER BY while ignoring an earlier limit.

Capability advertisement preceded use

A Directory Agent or Service Agent supporting the extensions advertises select-enabled and/or sort-enabled. A User Agent should check those attributes before sending the corresponding request. If a server does not support an extension, or cannot perform the requested sort, it returns OPTION_NOT_UNDERSTOOD.

The capability advertisement is evidence about declared support, not the freshness of every attribute. A successful zero error code establishes that the request was processed and the sort performed. It does not establish that the load value was measured recently, that its author was trusted, that every eligible service had registered or that the chosen URL will answer.

The RFC also calls sorting best effort. That phrase should narrow confidence, not erase the documented rules. Operators can verify the request, capability, reply code, key sequence and returned order. They still need separate evidence for the directory snapshot and for the world beyond it.

Mandatory extension space did not make deployment universal

IANA assigned Select and Sort identifiers 0x4002 and 0x4003 from SLP's range reserved for mandatory-to-implement extensions. That registry position describes the extension framework. It does not transform an Experimental RFC into proof that every historical or present SLP product deployed it correctly.

The capability keywords remain operationally important. Documentary status, number assignment, advertised support, processed request and successful service use are different layers. Treating one as a substitute for all the others turns a traceable chain into folklore.

Ranking needed a second journey

After discovery, the client still has work. It may resolve or parse the URL, open a connection, negotiate the application protocol, authenticate a peer and perform the requested operation. A failure at any step does not retroactively make the directory's sorting arithmetic false. It shows that sorting and service outcome had different scopes.

This is the durable history inside a small Experimental extension. RFC 3421 did not merely save bandwidth. It exposed the policy embedded in “best”: attribute author, snapshot time, data type, comparison direction, NULL rule, key precedence and truncation order. Once those inputs are visible, the top result can be useful without becoming omniscient.

Sources and limits

The primary record is available as RFC Editor HTML, plain text, the RFC Editor information page, the IETF Datatracker document page, its history and references, plus the RFC Editor errata search.

SLP context comes from the original RFC 2165, SLPv2 RFC 2608, service templates RFC 2609, the API in RFC 2614, the LDAP sorting model in RFC 2891, attribute-list extension RFC 3059, IPv6 use in RFC 3111, vendor extensions in RFC 3224, mesh enhancement in RFC 3528, remote discovery in RFC 3832 and the IANA Service Location templates registry. The analytical distinction between specification and operating proof follows Heng Lu's essays on running code as primary and minimum initial specification.

These sources establish protocol rules and documentary history. They do not measure deployment, registration completeness, attribute freshness, current latency, present load or service success.