要約

  • 初期の Telnet はバイト空間の上半分を制御信号に割り当てていた。後の仕様は命令の権限を値 255 の IAC に集約し、残る 255 個の値が裸の命令コードと衝突せず流れる道を開いた。
  • 文字どおりのデータ値 255 は IAC IAC と符号化される。Binary Transmission を合意して8ビットデータを開放しても Telnet 制御は消えず、受信側は IAC を探して埋め込まれた命令を処理し続ける。

赤いタイル一枚なら命令、二枚なら一つのデータ

端末プロトコルを通してバイナリーファイルを送る場面を考えよう。次のバイトがたまたま十進数の 255 だったとする。受信器がそれを「次のバイトを命令として読め」と解釈すれば、ファイルの一部がプロトコル構文に飲み込まれる。常にファイルの値だと扱えば、今度はオプションを変更する本物の指示を見落とす。回線上の数値だけでは二つを区別できない。

Telnet は小さな文法を置いた。単独の IAC、すなわち Interpret As Command は制御を開始する。続く値が定義済みの命令コードなら命令となり、場合によってはさらにバイトが続く。一方、IAC の直後にもう一つ IAC が来たときだけ、一個の通常データ値 255 を表す。送信側は二重化し、受信側は対を見分けて枠組み用の一個を取り除く。

これは「直後の何でもリテラルにする」万能な引用符ではない。二番目の IAC はこの位置でだけ、厳密な意味を持つ。IAC の後に来る別の値は、命令やその構文であり続ける。両端が同じ解析状態を共有してこそ、回線上の二バイトがアプリケーションの一バイトへ戻る。

この規則が救ったのは一つの珍しい値だけではない。データと制御を単一接続上の順序に保ちながら、8ビット空間の大部分を恒久的に明け渡さずに済んだ。

最初の Telnet は空間の半分を制御に使った

1972年4月の RFC 318 は、Network Virtual Terminal を中心に当時の正式な ARPANET Telnet を記述した。値 0 から 127 は USASCII、128 から 255 は特別な制御信号に使われた。

異なる文字端末をつなぐことが主目的だった時代には、筋の通った分割だった。上位値ならプロトコル動作を明確に表せ、7ビット ASCII は共通の表示を担えた。しかし、より豊かな文字集合や任意のバイナリーデータを扱おうとすれば、256 通りの半分をアプリケーションが素直に使えないという重さが現れる。

RFC 318 には別の符号体系へ逃げる方法や Transparent モードも登場する。それでも、そこへ移った後に Telnet 信号をどう読むか、ASCII へどう戻るかさえ未定義になり得ると文書自身が認めていた。データの語彙を広げるほど、プロトコルが自分の制御を見つける力が危うくなる。

これは端末機種の不都合ではなく、統治の問題だった。多数の裸の値に制御権限を付ければ、データが同じ値を求めた瞬間、用途が衝突する。

QUOTE 案は解決の輪郭を先に示した

1973年1月の Telnet 論点を扱った RFC 435 は、素直なバイナリーを既定にする案を検討し、QUOTE 文字の追加を提案した。その直後のバイトは常にデータとして解釈する。上位値を命令空間に残したまま、必要な出現だけを文字どおり運べる発想だった。

この案を後の IAC 規則そのもの、まして実運用済みの挙動として語るのは正しくない。ただし、設計圧力をよく映している。データの解釈方式が切り替わっても壊れないエスケープ境界が Telnet には必要だった。

大きく二つの道があった。多くの値を制御用に予約し、多くの衝突を引用するか。あるいは制御への入口を一つの特別値に絞り、その値がデータとして現れた場合だけ追加費用を払うか。後の Internet Telnet は後者を選んだ。

IAC は命令の権限を一つの接頭辞へ圧縮した

1980年6月の RFC 764 は Telnet を、単一の TCP 接続上でデータの間に制御情報を織り込む、8ビットバイト指向の機能と表現した。1983年5月の基盤標準 RFC 854 もこの構造を引き継いだ。

Telnet 命令はすべて値 255 の IAC で始まり、その後に命令コードが来る。WILL、WON'T、DO、DON'T のような交渉命令には対象オプションを示す三番目のバイトが付く。ほかにも、サブネゴシエーション終了、何もしない、Data Mark、割り込み、出力中止、文字消去などの基本機能がある。

交換条件は明快だった。交渉によってデータ空間を広く使えるようにする以上、命令との衝突は最小にしなければならない。IAC 方式では、データとして二重化が必要なのは IAC 自身だけであり、残る 255 個の値は基本命令の枠組みに関して直接通過できる。

ここでいう「透過」は狭い意味である。NVT モードには文字や改行の規約があり、すべての値が意味まで無変更になるという約束ではない。ほかの値が、その数値だけを理由に独立した Telnet 命令と誤認されないということだ。広い上位領域に散っていた制御権限が、一つの門から始まる並びへ移された。

解釈が変わる地点に命令を置けた

データと制御が同じ流れにあることは、順序をそのまま効力発生点に使える利点も生んだ。RFC 854 は、あるオプションが命令送信者から届くデータの扱いを変える場合、送信者が新しい解釈を始めたい位置に交渉命令を挿入するよう求めている。

受信側は、別回線から届く「いつか先で変わる」という曖昧な通知を受けない。旧状態のデータを読み、流れの中で命令に出会い、その後を新状態で読む。一つの順序付き会話の内部に、解釈の境界を引ける。

その代わり解析器の責任は重い。TCP は今回 IAC だけを渡し、次の読み出しで後続バイトを渡すかもしれない。セグメント境界は Telnet のレコード境界ではない。実装は「接頭辞を見たが続きはまだ」という状態を持ち、二重化を一度だけ解かなければならない。二個とも残せばデータが変わり、命令の IAC 対までデータとして畳めば制御が消える。

TCP が保証するのは順序であり、Telnet が与えるのは文法である。どちらもストリームを自動でメッセージ列にしてはくれない。

サブネゴシエーションも同じエスケープに従う

オプションには可否だけでなくパラメーターが必要なものもある。RFC 855 はサブネゴシエーションを IAC SB、オプションコード、パラメーター、そして終端の IAC SE と定める。受信側がパラメーター形式を知らなくても、枠を探せば末尾へ進める。

では、パラメーター自身に値 255 が含まれたらどうするのか。RFC 855 は一般規則をそのまま適用し、二重化を求める。さもなければパラメーターが Telnet 構文の始まりに見えたり、隣の値と組んで偽の終端を作ったりする。

これは階層化された枠組みの小さな模範である。オプションは自分のパラメーターの意味を決められるが、基盤 Telnet 層は IAC の管轄を手放さない。拡張の自由は、共有ストリームを守る値の再定義まで含まない。

この境界があるから、理解できないことが即座に破綻を意味しない。文字どおりの 255 が正しく逃がされていれば、基盤解析器は未知のペイロードでも本物の IAC SE まで進める。

バイナリーモードは8ビットを開いたが制御を消さなかった

任意のバイナリーデータこそ、接頭辞設計の決定的な試験だった。RFC 856 はオプション 0 の Binary Transmission を定義する。これは方向ごとに独立して交渉され、一方が8ビットバイナリーの受信に同意しても逆方向は従来の解釈に残り得る。

有効になると、IAC に先行されないバイトは8ビットのバイナリーデータとして扱われる。それでも IAC IAC はデータ値 255 であり、IAC と有効な Telnet 命令の並びは命令のままである。Binary が変えるのはデータの扱いであって、TCP ストリーム全体を Telnet から見えなくするのではない。

もし 128 から 255 のすべてが制御を担い続けていたなら、バイナリーモードは空間の半分を引用するか、命令を諦めるしかなかった。入口を一値に集中させることで、ほぼ全てのバイナリー値は直接流れ、オプション変更も同じ接続に残せた。

したがって Binary は「交渉後の生 TCP」ではない。Telnet の枠組みを保ったまま採用されるデータ規約である。

ホスト要件は忘れてはならない例外として刻んだ

1989年10月の RFC 1123 は、この挙動を明示的なホスト要件にした。Telnet オプションはデータストリームのどこにでも現れ得るため、データとして送る IAC は二重化しなければならない。Binary の交渉後も、受信側は IAC を走査し、埋め込まれた命令に従い、データ値 255 の二重化を要求する。

一方、別の変換は止まる。Binary モードでは通常の復帰文字変換や行末規約を適用してはならない。この対照がありがちな近道を禁じる。「バイナリー」は文字処理を止めてもよいが、Telnet 解析器を止める合図ではない。

現在の IANA Telnet Options レジストリー は、Binary Transmission の 0 を含むオプション名前空間と参照文書を維持している。これは現在の導入率調査ではない。また、オプション番号 255 と、データストリームで値 255 を持つ IAC は別の対象である。同じ数字でもプロトコル上の役割は一つにならない。

一度の反復が、一つの順序付き会話を守った

IAC の二重化を配線上の細事として片づけると、設計の本質を見落とす。それは三つの権限を分けた。アプリケーションは 255 を含めデータを選ぶ。Telnet 送信層は、その値が偶然命令の意味を得ない形へ符号化する。受信層は、二重表現と本物の指示を見分ける解析器を所有する。

中央サービスがセッションを検査する必要はなく、命令専用の第二接続も要らない。共通層が小さな不変条件を定め、あらゆるオプションとデータモードがそれを守る。エコー、端末種別、文字解釈、レコード境界は拡張できても、IAC を黙って奪うことはできない。

費用は永続する。すべての実装が走査し、文字どおりの 255 は回線上でもう一バイト使い、不完全な接頭辞には状態が要り、誤ったエスケープは後続の解釈をすべてずらし得る。利益も永続する。データと制御は一緒に発展でき、ただの値が境界なしに命令権限へ化けない。

そのバイトは、二つになれば強くなるから反復したのではない。最初の一つが命令の境界を引き受けたから、次の一つがデータであり続けられたのである。

出典と限界

初期の半空間設計は RFC 318、QUOTE の議論は RFC 435 による。RFC 764 と RFC 854 は制御を織り込むストリームと IAC 文法、RFC 855 はサブネゴシエーションのエスケープ、RFC 856 は Binary の挙動、RFC 1123 はホスト要件、IANA レジストリー はオプション名前空間を示す。これらから現在の利用比率、個別製品の適合性、解析器の安全性、暗号化や認証、全ホストに共通する採用日を結論づけることはできない。