Summary

  • RFC 1498 separated four named objects—services or users, nodes, network attachment points and paths—and described three successive bindings needed to reach a service.
  • A table saying that the Lockheed DIALOG service ran on node 5 expressed one changeable service-to-node relationship. Editing the row could move the service to node 6; it did not rename the service or either node.
  • A resolver answer or address is therefore evidence of a current binding in a longer chain. Authentication, authority, route viability, delivery and application outcome require their own receipts.

The row that changed while the name did not

Imagine a network table with one uncomplicated statement: the Lockheed DIALOG Service is running on node 5. An operator later edits the row so that DIALOG runs on node 6. What changed?

Not the meaning of “Lockheed DIALOG Service.” That name remained associated with a particular service, its management and its stored material. Not the identity of node 5 or node 6. The table changed only the current association between the service and a node.

That distinction is the most revealing passage in RFC 1498, Jerome Saltzer's On the Naming and Binding of Network Destinations. Published as an Informational RFC in August 1993, the paper had first appeared in a 1982 volume on local computer networks. Its age is part of the point. Before contemporary service discovery, cloud scheduling or mobile networking acquired their present names, the conceptual error was already visible: people treated a record that said where something was running as though the record could redefine what the thing was.

Saltzer explained why an actual rename would be harder. The association between the service name and the service was not contained in that one convenient table. It also lived in programs, documentation, handwritten notes and advertising. Changing the service-to-node row moved execution. Renaming the service required changing a much wider world of references.

The table was powerful, but only within its layer.

Four objects before three familiar words

Network vocabulary often began with a compact triad: a name says what is wanted, an address says where it is, and a route says how to get there. RFC 1498 did not reject that formulation. It argued that three labels left too much room for interpretation.

The paper instead began with the objects. First came services and users: functions such as time, accounting or packet forwarding, and the clients that use them. Second came nodes: computers that run services or user programs. Third came network attachment points: the ports or places where a node connects to a network. Fourth came paths: the courses between attachment points through links and forwarding nodes.

This inventory makes a common sentence less innocent. “The address of the service” may refer to a node that currently runs it, an attachment point that currently reaches that node, or a value used to select a path. If the speaker does not identify the object and the binding context, the word address compresses several claims into one syllable.

RFC 1498 also warned against reading object type from typography. A printable string is not inherently a service name. A binary value is not inherently a node name. A hierarchical form is not inherently the name of an attachment point. Any of the four object types can have names in any useful form, and one object can have more than one form of name.

The semantic question comes before the glyphs: what object does this value name, and in what context is its binding maintained?

Reaching a service was a three-stage discovery

Once the objects were separated, movement became easier to describe. A service may run on one or more nodes and move between them without losing its identity. A node may use one or more attachment points and move between them without becoming a different node. Paths between a pair of attachment points may change without changing either endpoint.

To send a packet to a service, the model therefore needs three successive discoveries:

  1. find a node on which the service operates;
  2. find an attachment point through which that node can be reached;
  3. find a path from the sender's attachment point to the chosen destination attachment point.

RFC 1498 called the corresponding functions service name resolution, node name location and route service. They are conceptually distinct even when one machine performs more than one of them.

Nor must each stage yield a single answer. Several nodes may run the service. A node may be multihomed. Several paths may reach an attachment point. Path quality can influence which node is preferable, so choices made at different levels can interact. A table may return a list or a partial binding, with the final selection delayed until the last moment and recorded outside the network's binding services.

This is a crucial limit on the evidentiary value of one observed answer. A returned attachment point proves that a resolver supplied that candidate under a particular state and query. It does not prove that no other candidate existed, which policy selected it, whether the route remained usable or whether the application accepted the resulting communication.

Ethernet saved a table by fusing two names

The paper tested its model against Ethernet. A node could carry a 48-bit identifier and use it wherever it physically attached along an Ethernet. The value could reasonably be interpreted as a node name because the node supplied it, or as an attachment-point name because an interface watched for it on the network.

In binding terms, the design made the node name and attachment-point name the same value. That permanent association had practical advantages. The node could move without network-record changes. One level of binding table disappeared. A multihomed node could present the same identifier on different Ethernets, simplifying alternate-path discovery.

The simplification also consumed expressive power. If one node needed two independently addressable attachments on the same Ethernet, two identifiers could make other records believe there were two nodes. Reusing one identifier avoided that illusion but prevented a sender from selecting one attachment specifically.

Nothing here proves that the fusion was a mistake. RFC 1498 judged the advantages likely greater in that setting. The lesson is narrower: removing a table does not abolish the objects that table would have related. It freezes one binding and inherits the resulting trade-off.

The friendly ARPANET name pointed lower than it looked

The ARPANET NCP example exposed the opposite problem. Character strings such as RADC-Multics looked like node or service names. In the paper's analysis, they actually named network attachment points—in that case, an ARPANET IMP port.

That placement mattered when a node moved. Reattaching the computer to another port could require users to learn a new visible name or require tables across other nodes to change. Parallel attachment required another string identity. A mnemonic's friendliness encouraged people to attribute it to the service, but the operational namespace ended lower in the chain.

Mail made the mismatch visible. Several computers could accept mail for one another. If the node named by the user's familiar string was down, the user might need to request what appeared to be a different service name to reach the same function elsewhere. The service had redundancy; the name did not express it at the service layer.

A label can be memorable and still name the wrong object for the decision a user wants to make.

One answer could hide two bindings

Implementation can compress the model. A name server may accept a service name and return a list of attachment points. Mechanically, one request has performed both service-to-node resolution and node-to-attachment location. A distributed routing algorithm can then choose a path without presenting itself as a visible third service.

The compression is useful. It is not proof that the intermediate relations ceased to exist. When a result is wrong or stale, diagnosis still asks which association failed: was the service no longer on that node, did the node leave that attachment point, or did the path disappear?

Later Internet documents carried related pressure into new contexts. RFC 1958 advised applications to use names rather than hard-coded addresses and treated modular separation as an architectural virtue. RFC 2101 distinguished IPv4 identifier and locator requirements, calling their use of the same address fields a contingent historical fact. RFC 2956 recorded the problems caused when node identity and delivery location remain mingled. These texts do not amend RFC 1498. They show how long the same compression continued to demand careful interpretation.

A route stopped before the outcome

Saltzer offered a broad reading of address: an address of a service can be a name of a node that runs it; an address of a node can be a name of an attachment point; an address of that attachment point can be a name of a path. A route to a service also needs to identify the relevant activity inside the node, such as a socket.

Even this fuller route is not a delivery receipt. It does not say that the service was listening, that the peer was authentic, that policy authorized the exchange, that the response arrived or that a business action completed. RFC 1498 explicitly says security issues are not discussed.

The trustworthy record must therefore keep the chain open: exact service name and namespace; resolver query and time; all returned nodes; node-to-attachment state; candidate and selected paths; activity or socket identifier; transport transcript; application response; and the actor that made each choice. A screenshot of one address cannot substitute for those receipts.

Heng Lu's accounts of running-code primacy, localized future decision and reality layers sharpen the institutional boundary. A coordination table can make interoperable action possible. It does not become the service, the operator, the running path or a standing mandate over them. The record should be interpreted at the lowest layer it actually executes.

RFC 1498's enduring gift was not another preferred definition of address. It was a method for refusing false compression: name the objects, expose the bindings, and demand a receipt at every changeable boundary.

Sources