Summary

  • RFC 779 defined a Telnet option that let a client offer a printable location string to a remote host, addressing the gap between knowing a visitor's originating site and knowing where that person could be found.
  • The sequence had separate decisions: default refusal, the client's offer, the server's agreement, a subsequent location message and the server's choice to use it in a listing.

A colleague looking for you in 1981 could ask a computer. The reply might give your name, the host you were using and the room where the terminal stood. Log in from another institution, though, and the remote computer often had only the originating site. “Somewhere at that lab” was a poor instruction for placing a telephone call. Earl Killian's RFC 779 offered a small extension to Telnet: let the user's program tell the server where the user was sitting.

The motivation belonged to the social life of early networked computers. In the earlier NAME/FINGER specification, RFC 742, a request for a list of current users called for names and physical terminal locations where those could be determined. The report might also include an idle time or job name. Such a list helped people find a nearby colleague or ring a phone close to their terminal. A remote login disrupted that arrangement. The server could identify the site that supplied the network connection, but it could not infer a particular desk within that site.

Killian's proposal gave the missing detail a route across the Telnet session. The client, when it knew the user's location, could offer option 23, SEND-LOCATION. The starting state was off on both sides. A client sent WILL SEND-LOCATION to offer the capability. A server able to use it answered DO SEND-LOCATION. Only then could the client put a sequence of printable ASCII characters into a Telnet subnegotiation, bounded by IAC SB and IAC SE. The location was text supplied by the user side, with no coordinates, room directory or automatic sensing specified. A line of text could be as informal as the local site found useful.

The four-letter Telnet verbs made the exchange slightly comic, but they did work. WON'T let a side refuse to send; DON'T let the other side demand that it stop. A server could request a location with DO, and a client could decline. After agreement, the client was free to send the text later in the session. Offer, acceptance and content were separate events. The small protocol gave the server a field it had lacked while leaving each end a choice about using the option.

There was precedent. The SUPDUP display protocol, RFC 734, had a command for sending console-location text to the remote system. Its description said that the server normally saved it for a who listing. RFC 779 brought the same practical concern into Telnet's option negotiation. The new feature was no mysterious discovery of a user's whereabouts. The nearby machine or person supplied a string, and the distant machine decided how to handle it.

That division matters to the story. NAME/FINGER described what a user listing should contain when location could be determined; SEND-LOCATION described a way to deliver a location to a Telnet server. The specification did not require every server to print the supplied value on every public query. It named ITS as an example of a system able to use it. The historical mechanism is the handoff from client knowledge into server-side context. The directory desk in the next room still had its own rules.

In retrospect, the choice looks like a small piece of network hospitality with a long tail. The remote host could make an otherwise faceless login more useful to the people sharing its machines: a name plus a reachable room or telephone instead of a vague institutional label. The same string passed from the user side to a system whose list other users might read. The interesting engineering decision sits exactly there. Telnet negotiated before transmitting; the server's presentation was a further decision. RFC 779 kept the steps distinct in just two pages.

For a protocol concerned with terminal sessions, it showed how much human context travelled beside the terminal's characters. A login was also a person at a desk, somewhere reachable—or at least someone who chose to provide a way to be found. The computer could finally give a better answer than “try the whole building.”