Summary

  • RFC 887 let a host broadcast Who-Provides? when it did not know a provider address, but silence remained different from an explicit negative answer.
  • A directed Do-You-Provide? required a reply, while information supplied about a third host was only a hint that normally needed direct confirmation.
  • The protocol named resources as length-delimited demultiplexing paths, so support for UDP or a port did not automatically include every specialization above it.

Imagine a newly started machine that knows it needs a gateway but does not know any gateway address. A static list solves the first boot only by moving the uncertainty into configuration. RFC 887, published in December 1983, proposed another move: ask the network for a provider.

The idea sounds simple enough to fit in one sentence. The document did not leave it there. It designed separate messages for open discovery, directed verification and knowledge supplied on somebody else’s behalf. That separation is the enduring lesson. Finding a candidate and confirming a claim are not the same operation.

A resource was a path through the demultiplexer

RLP did not begin with a friendly service label. A resource name began with the number of the lowest Internet protocol used to reach it, followed by an explicit length and a resource-specific identifier. The identifier followed the “natural” quantities used to demultiplex successive layers.

For a UDP Domain Name Server, the example was protocol 17 followed by port 53. A more specialized service could append another component above the port. The format included IDLength so a host could skip a resource specifier it did not understand without losing the boundary of the next one.

Matching proceeded component by component. If a lower component was unsupported, the host did not provide the resource. If the requested name ended exactly where the host’s checks succeeded, it did. If extra components remained after the host had reached the end of what it understood, support for the lower protocol was insufficient.

That rule stopped a broad claim from silently swallowing a narrower one. “I provide TFTP” did not necessarily mean “I provide this crash-dump specialization over TFTP.” Port reachability, application family and application function remained separate.

A broadcast question invited only positive speakers

Who-Provides? was the open question. It was normally broadcast on a local IP network. A receiver that provided at least one requested resource returned an I-Provide reply containing those resources. A receiver with no match could say nothing.

Silence was therefore economical but ambiguous. It could mean no provider, a lost request, a lost reply, a host that did not implement RLP, or a machine that chose not to answer. RFC 919 later described IP broadcast as unreliable, unsequenced and possibly duplicated. It also stressed that every broadcast spends some processing effort on every host that hears it.

RLP’s open query traded configured addresses for shared attention. It was useful precisely when the provider was unknown, but it could not manufacture a network-wide negative fact from missing speech.

An empty directed reply was a different kind of no

Do-You-Provide? asked one named host. Unlike the broadcast form, it required a response even when the host offered none of the listed resources. An empty I-Provide list was an explicit negative confirmation for that host and that request.

RFC 887 prohibited broadcasting this message. If every receiver had to answer even when it had nothing, one question would provoke a reply storm. The protocol matched reply semantics to audience size: positive-only responses for the crowd, mandatory positive or negative responses for one addressee.

Even the explicit negative had a boundary. It did not prove that nobody else provided the resource, that the host would never provide it later, or that a different specialization would fail. It closed a narrower uncertainty than broadcast silence could close.

A smart host could point without vouching

Two further requests, Who-Anywhere-Provides? and Does-Anyone-Provide?, allowed a known “smart” host to answer for other machines. This helped on networks without broadcast and allowed a gateway or directory-like host to relay knowledge acquired elsewhere.

The reply was called They-Provide. RFC 887 was unusually clear about its authority: the querier need not rely on the indirect information unquestioningly. It should usually send a direct Do-You-Provide? to the nominated address before proceeding.

The worked Domain Name Server example turns that rule into a sequence. A smart host first gives an empty answer inside a local-only scope. After the scope is widened, it nominates host S. A direct query to S returns an empty negative. The client then excludes S and asks again; host T is nominated and directly confirms UDP port 53.

Nothing in that sequence requires the smart host to be dishonest when S says no. Its knowledge may simply be stale. The protocol preserves who made which claim, so discovery can be revised without pretending that an indirect directory and a live endpoint share one observation time.

Scope and correlation did not become identity

The Local-Only flag limited reply addresses to the requester’s IP network and told a multihomed responder to use the appropriate local source address. Scope was part of the question, not a cosmetic filter applied afterward.

A 16-bit Message-ID helped match replies to requests. It did not authenticate a responder, authorize use of a service or prevent a forged answer. UDP supplied ports, length and checksum; the checksum was not a cryptographic identity proof. RFC 887 defined no trust system that turned any received claim into permission.

An I-Provide response also stopped short of application effect. It said the responding host claimed the named resource. It did not prove that a later transaction would succeed, that every part of the relevant specification was implemented, or that the requester was entitled to use it.

Later discovery systems moved the boundaries

Later standards offer comparison, not proof of direct descent. RFC 2608 made Service Location Protocol queries about service types and attributes, distinguished User, Service and Directory Agents, and introduced administrative scopes. It also defined authentication for service URLs and attributes while stating that confidentiality was outside the protocol.

RFC 6762 brought DNS-like operations to the local link without a conventional unicast DNS server. RFC 6763 used DNS records to discover named service instances by service type and domain. These designs changed the vocabulary, caches and control surfaces. They did not make the old evidence problem disappear: a record, advertisement or answer still has an issuer, a scope and a time.

The assigned number outlived the operational claim

RFC 887 assigned UDP port 39. The current IANA Service Name and Transport Protocol Port Number Registry lists rlp at port 39 for TCP and UDP. That row is a durable administrative fact, not a deployment census.

RFC 6335 states the larger rule: an assigned service name or port is not an endorsement, and traffic on the port need not belong to the assigned service. A registry can preserve coordination long after it has ceased to reveal who is listening.

Sources and limits

This account uses RFC 887, RFC 919, RFC 2608, RFC 6762, RFC 6763, RFC 6335 and the IANA service-name registry. They establish protocol designs and registry state. They do not establish how widely RLP was deployed, a direct lineage into later discovery protocols, current product behaviour or the availability of any named service.