Summary

  • RFC 3059 let an SLPv2 User Agent ask for every returned service URL to carry its full registered attribute list. The request used a deliberately empty extension; the reply filled one extension per URL.
  • Because extension 0x0002 was optional and ignorable, a reply without it was a fallback signal, not proof of an empty attribute set. A requested SLP SPI could also cause omission when the responder could not supply the required authentication block.

The shortcut began with an intentional blank

Service discovery has two different questions hidden inside it. Which services match? What facts distinguish one matching service from another? SLPv2 originally answered those questions with different messages. A User Agent sent a Service Request and received Service URLs. It then used Attribute Requests to obtain the properties attached to a chosen URL or service type.

RFC 3059, published as a Proposed Standard in February 2001, joined those receipts without pretending they were the same fact. The User Agent inserted an Attribute List Extension into its Service Request. In that request-side form, the Service URL Length and Attribute List Length were both zero, and both fields were omitted. The blank was operative syntax: it asked the Service Agent or Directory Agent to attach attribute data to the reply.

That detail prevents a tempting but serious mistake. Zero-length fields in the request did not say that a service had no URL or attributes. They expressed a request for richer output. The meaning came from message direction and context, not from the visual emptiness of the fields.

One URL, one attribute receipt

A responder supporting the extension returned one Attribute List Extension for every URL Entry in the Service Reply. Each extension contained the corresponding Service URL and the service's entire registered attribute list. The document said the extensions should follow the same order as the URL Entries, but it also put the URL inside each extension.

The URL was therefore the durable join key. Order could reveal a malformed or surprising reply, but order alone was not the identity of the relationship. An implementation that zipped two arrays and discarded the explicit URL would be replacing a protocol identifier with a local convenience.

“Entire attribute list” also had a boundary. It meant the list held by the responding SA or DA for that service in the language indicated by the Service Request. It did not mean every fact about the running endpoint. A registration could be stale until its lifetime expired; an attribute could be absent from the advertisement; a service could be unreachable after discovery. RFC 3059 optimized delivery of registered description, not observation of live execution.

The optional number mattered

IANA assigned the Attribute List Extension the identifier 0x0002. Under RFC 2608, IDs from 0x0000 through 0x3FFF named standardized extensions that were optional to implement and ignored when unrecognized. That choice made the optimization compatible with older peers. An implementation that did not know the extension could still return an ordinary Service Reply.

The safety mechanism created an evidentiary obligation for the client. A reply without extension 0x0002 was not a negative answer about attributes. RFC 3059 told the User Agent to assume that the responder did not support the extension and to issue an Attribute Request for each URL from the Service Reply. Compatibility was bought with extra work at the edge.

This is different from later SLP extensions whose identifiers occupied a mandatory-to-implement range and whose unknown request could produce OPTION_NOT_UNDERSTOOD. RFC 3421's Select and Sort design is useful contrast, not a retroactive rule. “An SLP extension” never described one universal failure behavior.

Authentication made omission more ambiguous

The request could carry an SLP Security Parameter Index. If it did, every returned Attribute List Extension had to include an authentication block for that SPI. If the SA or DA did not support, or was unable to return, the required block, it had to omit the extension.

That means the wire-visible absence had at least two relevant routes: the responder might not implement extension 0x0002, or it might be unable to satisfy the requested authentication context. RFC 3059 still prescribed the same practical client response—fall back to Attribute Requests. It did not license the client to manufacture a richer diagnosis from silence.

An authentication block was valuable but bounded. RFC 2608 described it as a way to verify that covered contents had not been modified and had been transmitted by an authorized agent, under the SPI's keying material and expiry. Passing that check did not prove that the advertised service was reachable now, that a user was allowed to invoke it, or that the application transaction would succeed.

A faster catalogue was still a catalogue

The extension compressed a conversation. Without it, discovering four URLs and learning their attributes could require one Service Request plus four Attribute Requests. With mutual support, the same descriptive package could arrive in one reply. That changed latency and message count, not the authority of the underlying data.

The distinction matters whenever a system treats missing enrichment as zero. A UI may display no capabilities because enrichment was not returned. An inventory may count no properties because a compatibility path was skipped. An automated selector may discard a usable candidate because it confused “not carried here” with “known absent.” RFC 3059's fallback rule was an early, compact warning against all three errors.

The historical design also placed cost where it belonged. A responder could remain compatible without implementing the optimization. A User Agent that wanted complete selection information had to notice the missing receipt and spend the extra round trips. The protocol did not let the consumer convert saved work into invented certainty.

Sources