要約

  • RFC 1097本文はInternetコミュニティの標準を規定すると書いた。一方、現在のRFC Editor情報ページはIndependent StreamのUnknownと分類し、IETF DatatrackerはIETF標準化プロセス上の正式な地位がないと説明する。
  • 架空のオプションは既定で無効だった。クライアントがDO/WILLで合意して初めて、時間、間隔、メッセージの副交渉に進める。この合意はTelnet端点の状態であり、端末利用者の十分な説明に基づく同意ではない。
  • クライアントに求められたのは、実装依存の方法で表示を試みることだった。副交渉の受信だけでは、発光、知覚、説得、更新、行動のどれも確認できない。

本文の宣言と、本文を分類する権限は別だった

RFC 1097は、外見だけなら通常のTelnetオプション文書である。著者はCMU-NetDevのB. Miller、日付は1989年4月1日。コマンド名、既定値、動機、実装上の注意、例を並べ、SUBLIMINAL-MESSAGEに257を与える。冒頭では、このRFCがInternetコミュニティの標準を規定するとまで述べる。

その文章は、文書が何を主張したかを確定する。しかし主張に制度上の効力を与えない。現在のRFC Editor情報ページは状態をUnknown、ストリームをIndependentと記録する。IETF Datatrackerは、IETFの承認を受けたものではなく、IETF標準化プロセスで正式な地位を持たないとする。

本文と目録は競合する写しではない。前者は保存対象、後者はその対象を分類する権威ある面である。文書自身の一文だけで地位が決まるなら、分類の決定権が分類される側へ移ってしまう。

RFCの保存は、すべてを運用規則にすることではない

RFC 8700はRFCシリーズ50年史の中で、4月1日RFCをIndependent Streamの特別なユーモア文書と説明する。通常の正式な審査・承認手続を経る種類ではないが、その目的に応じて選ばれ、編集される。

RFC 1097は、仕様書の様式を正確に借りることで成立する。利用者に「Use VMS」や「Go home」を瞬間表示する案が、命令の意味やエスケープ処理まで備えているから可笑しい。アーカイブは、Internetに関係する標準だけでなく、実験、情報、歴史、ユーモアも保存する。掲載されたという事実と、標準として拘束力を得たという事実を混ぜてはならない。

潜在的なメッセージにも、まず拒否権があった

土台のTelnetは実在する。RFC 854はTelnetを双方向の8ビット・バイト指向通信とし、共通のNVTを既定状態に置く。追加オプションは一方が提案し、他方が受諾または拒否する。不明なオプションは拒否でき、双方が理解する基準状態へ残れる。

RFC 855では、パラメータ付きオプションを二段階にする。DO/WILLで扱えることを確認してから副交渉に入り、DON'T/WON'Tで終了できる。

RFC 1097もこの骨格を崩さない。WILLは表示の許可を求めるか意志を確認し、WON'Tは拒否する。DOは相手に表示を求めるか許可を与え、DON'Tは表示しないよう要求する。既定値はWON'T/DON'T、つまり何も表示しない状態である。

遠隔側は、接続しただけでローカル画面を所有しない。まずクライアントから限定された能力状態を得る必要がある。風刺の中でも、要求と取得済みの権限は同じではなかった。

257は通常の一覧の向こう側に置かれた

現在のIANA Telnet Optionsレジストリは0から255までを示し、255をExtended-Options-Listに割り当てる。257やSUBLIMINAL-MESSAGEという現在の行はない。

一方、RFC 861は255をEXOPLとして予約し、そこにカプセル化した交渉でさらに256個のオプションを扱う構想を定めていた。RFC 1097の257は通常領域の直後にあるが、例ではIAC DO/WILL/SB SUBLIMINAL-MESSAGEという記号表記だけを用い、EXOPLの実際の枠組みを展開しない。

ここから言えるのは、冗談が実在する拡張境界の近くに置かれたということまでである。257のIANA登録、実パケット、相互運用実装を示す資料ではない。文中の番号とレジストリの割当は別々に確認する必要がある。

合意したのはクライアントであり、人ではなかった

オプション成立後、送信側は16ビットの表示時間、16ビットの反復間隔、文字列を渡す。クライアントは直ちに、かつ一定間隔で表示を試みる。位置と描画方法は受信側実装に委ねられる。値255のバイトを二重化するTelnetの規則も残る。

例では「Use VMS」を送り、「Go home」に差し替え、最後に時間と間隔をゼロ、文字列を空にして停止する。動機は、通常の告知ではTelnet更新を勧められなかったとし、REMOTE-FLOW-CONTROLを挙げる。直前の実在するRFC 1080は、その33番オプションにもDO/WILLの先行合意を求めていた。

しかし、RFC 1097が「同意した」と書く主体はクライアントである。人への説明、内容の選択、目的への許可は記録しない。自動設定や管理者の判断でもWILLは出せる。ソフトウェアの能力状態を「利用者の同意」と呼べば、実際の決定者が見えなくなる。

送信側は文面と時間を選び、受信側は描画を選ぶ。人の注意はこの握手の外側にある。三者の決定面を一つの「合意」に畳むことはできない。

表示の試行から行動までは、観測が連続していない

副交渉の受信で分かるのは、パラメータが届いたことだ。ローカルログで描画処理の呼び出しを確認できるかもしれない。それでも端末の状態が光を生んだか、人がそこにいたか、見ていたか、気づいたか、意味を取ったか、行動したかは別である。

文書は、CMU実装が回線速度、映像能力、蛍光体の残光を考慮したと述べ、Caps Lock LEDでモールス信号を出す版も開発中だとする。これは風刺文書内部の主張であり、配布・運用・効果の独立した証明ではない。

証拠の順番は、保存された文書、公式分類、交渉済み能力、受信パラメータ、ローカル試行、物理表示、人の知覚、説得、行動である。前の段階の成功を、後の段階の結論として使ってはならない。

出典