要約

  • RFC 779は、Telnetクライアントが利用者の居場所を印字可能な文字列として遠隔ホストに渡すSEND-LOCATIONオプションを定めた。
  • 初期状態では使わず、クライアントの申し出、サーバーの同意、本文の送信、一覧への反映という別々の段階を踏む。

1981年、同僚を探すためにコンピューターへ聞くと、名前と端末の置かれた場所が分かることがあった。ところが別の研究所からログインしている人については、遠隔ホストが知っているのは接続元の施設名だけ、という場合がある。建物の名前を聞いても、机のそばの電話は鳴らせない。Earl KillianのRFC 779は、Telnetの利用者側プログラムから、もう少し役に立つ場所の説明を送る手順を示した。

背景には、共有コンピューターの人間的な名簿があった。NAME/FINGERを定めたRFC 742は、現在ログイン中の人を列挙する応答に氏名と、判明する範囲で端末の物理的な場所を含めるよう述べていた。手元の電話や部屋が分かれば、近くの同僚に用事を伝えられる。遠隔ログインはこの名簿に穴を開けた。サーバーは相手の施設を知るが、施設内のどの端末に人が座っているかは分からない。

Killianが用意したTelnetのオプション番号は23、SEND-LOCATION。初期状態では双方とも使わない。クライアントが利用者の場所を知っていれば、まずWILL SEND-LOCATIONで送信を申し出る。受け取って使えるサーバーはDO SEND-LOCATIONと答える。合意の後、クライアントはIAC SBとIAC SEで囲んだ副交渉に印字可能なASCII文字列を入れて送る。送り手が知っている説明を運ぶ仕組みで、機械が勝手に座標を測る仕組みではなかった。

断るための動詞もある。WON'Tなら送信側が拒否し、DON'Tなら相手に送らないよう要求する。サーバーが求め、クライアントが応じない場合もある。合意ができた後も、場所の文字列はセッション中に後から送れる。申し出、受諾、実際の文字列は別の出来事だ。ログインしただけで机の札が自動的に遠くへ飛んでいくわけではない。

先例はRFC 734のSUPDUPにあった。そこでは利用者側からコンソールの場所を文字列で送り、サーバーが通常それを保存してwhoの表示に用いた。RFC 779は同じ生活上の用件をTelnetのオプション交渉に移した。近くのプログラムが場所を知り、遠くのプログラムが受け取って扱う。どちらにも役割があった。

NAME/FINGERは人の一覧に載せたい情報を述べ、SEND-LOCATIONはTelnetからサーバーへその情報を届ける手段を述べた。RFC 779は、ITSのシステムなら受け取った場所を利用できると挙げる。受信後の表示は各サーバーの仕事である。文字列が届いたという事実と、誰かの画面に現れたという事実は、名簿係の机を挟んでいる。

この小さな追加には当時の切実さがある。「あの施設から接続中」では広すぎる。部屋や近くの電話まで分かれば、一緒にシステムを使う人は同僚を見つけられる。その情報を他の利用者が見る一覧へ載せるかどうかも、遠隔ホスト側の判断になる。RFC 779は二ページで、利用者側が説明を渡すこととサーバー側が名簿を作ることを分けていた。

Telnetは端末の会話を運ぶ。そこには端末の前に座る人の生活も少し混ざる。コンピューターが「研究所のどこかです」よりよい返事をするには、まず本人側から一枚の場所札を受け取る必要があった。