Zusammenfassung

  • RFC 779 gab einem Telnet-Client die Möglichkeit, dem entfernten Host einen lesbaren Standorttext zu schicken. Aus dem Namen eines Instituts konnte so eine brauchbare Angabe für die Suche nach einem Menschen werden.
  • Der Weg war gestuft: Die Option begann ausgeschaltet; Client und Server mussten sich einigen, dann konnte der Client den Text senden und der Server über dessen Anzeige entscheiden.

Wer 1981 einen Kollegen sprechen wollte, konnte dessen Rechner nach angemeldeten Benutzern fragen. Eine Liste mit Namen, Raum und vielleicht einem Telefon in der Nähe war fast ein Empfangstresen. Bei einer Anmeldung aus einem anderen Institut sah der entfernte Rechner häufig bloß den Herkunftsort der Verbindung. „Er ist im Institut“ half dem Anrufer ungefähr so viel wie „Er ist in der Stadt“. Earl Killian beschrieb in RFC 779 eine Telnet-Erweiterung, die diese Lücke mit einem kurzen Text füllen sollte.

Der Gedanke kam aus dem Alltag gemeinsam genutzter Maschinen. RFC 742 über NAME/FINGER schilderte eine Abfrage der gerade angemeldeten Benutzer. Deren Namen und physische Terminalstandorte sollten erscheinen, soweit das System sie bestimmen konnte. Auch Leerlaufzeiten oder laufende Aufgaben waren möglich. Die Liste half, jemanden am Terminal zu finden oder ein Telefon in dessen Nähe zu erreichen. Beim entfernten Login blieb dem Server als eigene Beobachtung oft nur der Name des Ursprungsstandorts. Ein Campus ist für diese Aufgabe eine ziemlich große Zimmernummer.

Killian gab der Ergänzung den Namen SEND-LOCATION und die Telnet-Optionsnummer 23. Der Ausgangszustand lautete WON'T und DON'T: Es wurde zunächst kein Standort übertragen. Kannte das Programm auf Benutzerseite die Angabe, konnte es WILL SEND-LOCATION anbieten. Ein Server, der sie verwenden wollte, antwortete mit DO SEND-LOCATION; er konnte die Übertragung mit DO auch selbst erbitten. Erst nach der Einigung folgte der Inhalt: druckbare ASCII-Zeichen in einer Unterverhandlung zwischen IAC SB und IAC SE. Die Beschreibung kam vom Platz des Benutzers; sie konnte so schlicht sein wie eine Raumnummer oder die Durchwahl eines Telefons.

Die knappen Befehle regelten auch die Ablehnung. WON'T bedeutete, dass eine Seite nicht senden wollte; DON'T verlangte vom Gegenüber, damit aufzuhören. Nach erfolgreicher Aushandlung durfte der Client den Text später während derselben Sitzung liefern. Ein Angebot, die Zustimmung und die eigentliche Nachricht waren drei Ereignisse. Ein viertes begann erst danach: Der Server musste den empfangenen Text in seine örtlichen Regeln für Benutzerlisten einordnen.

Eine ältere Spur führte zum SUPDUP-Display-Protokoll in RFC 734. Dort konnte ein Benutzerkommando den Standort der Konsole an das ferne System schicken; dieses speicherte die Angabe gewöhnlich für eine who-Liste. RFC 779 brachte denselben sozialen Wunsch in die Verhandlungssprache von Telnet. Die Maschine am Schreibtisch kannte die nähere Umgebung, die Maschine am anderen Ende hatte die Liste. SEND-LOCATION war der Bote zwischen ihnen.

NAME/FINGER beschrieb die sichtbare Auskunft über angemeldete Menschen. SEND-LOCATION beschrieb einen möglichen Zufluss für die Auskunft bei Telnet-Sitzungen. RFC 779 nannte ITS als System, das die Angabe nutzen konnte. Wie ein einzelner Host sie tatsächlich ausgab, blieb eine Entscheidung seines Programms. Gerade deshalb lohnt es sich, die Stationen zu zählen: Ein Server kann einen Text erhalten, ohne ihn auf jede Abfrage zu drucken. Der Empfangstresen führt sein eigenes Buch.

Die kleine Option war technisch bescheiden und menschlich sehr genau. Aus einer Verbindung „von dort“ konnte eine Verbindung „von diesem Raum aus“ werden. Für die Person, die den Kollegen suchte, lagen Welten zwischen diesen Auskünften. Für die Person am Terminal lag darin ebenfalls eine Entscheidung: Ihr Client bot die Beschreibung an; die andere Maschine bestimmte ihre Verwendung. RFC 779 brauchte nur wenige Protokollwörter, um einen Netzlogin um eine erstaunlich altmodische Frage zu erweitern: Wo kann ich Sie erreichen?