要約

  • RFC 3080は、一つのBEEPセッションに複数の独立した交換を収容した。チャネル0は管理を担当し、各アプリケーション・チャネルの構文と意味は受理されたプロファイルが決めた。
  • 接続成功、greeting、能力の提示、チャネル作成、プロトコル応答、外部効果は同じ証拠ではない。

接続後にも、合意は残っていた

両端が通信路を開き、チャネル0のgreetingを正しく解釈できても、最初のstartに並べたプロファイルがすべて拒否されることはある。配線もセッション管理も正常だが、共通のアプリケーション会話は存在しない。

2001年3月のRFC 3080は、この隙間を設計の中心に置いた。BEEP coreは、接続指向で非同期なやり取りのための汎用カーネルである。一つの利用者アイデンティティの下で複数の交換を同時かつ独立に進めるが、接続そのものに単一の用途を押しつけなかった。

下位の写像さえ別文書だった。RFC 3081は、一つのBEEPセッションを一つのTCP接続へ載せた。TCPの成立は運搬路の受領証であり、プロファイル選択や処理権限の受領証ではない。

チャネル0は仕事をせず、仕事場を作った

開始時に定義されるのはチャネル0だけである。greeting、対応プロファイルの通知、チャネルの開始と終了、セッションの解放を扱った。

greetingにURIが載っていても、そのプロファイルを使うチャネルが生まれたわけではない。startで番号と候補を提示し、受信側が一つを肯定応答で選ぶ必要がある。選べなければ拒否する。広告と契約の間に、明確な返信が置かれていた。

番号の分配は単純だった。initiatorは正の奇数、listenerは正の偶数を使う。中央の採番者なしで双方が新しいチャネルを提案できる。共通規則は衝突回避に必要な範囲へ抑えられていた。

プロファイルが会話の文法を持った

coreが定めたのは交換形式である。MSGが始め、RPYまたはERRが一対一の結果を返す。ANSは複数の答えを運び、NULが列を閉じる。メッセージ番号は交換を区別し、ペイロードのシーケンス番号はチャネル上の全フレームに沿って進む。

異なるチャネルのフレームは交差できた。同じ分割メッセージは自分のチャネル内で順序を守り、複数のANSだけはanswer numberで後から組み直せた。この規則は並行性を許すが、公平性や完了を保証しない。

後続仕様は意味の所有者を示す。RFC 3195はsyslogの信頼配送をプロファイルにした。RFC 4227のSOAPはbootからreadyへ進む独自状態を持った。RFC 4744のNETCONFではmanager/agentとBEEPのinitiator/listenerを同一視しなかった。接続を開いた側が、アプリケーション権限まで持つわけではない。

TLS後は古い記憶を捨てる

RFC 3080は初期調整用チャネルと継続データ用チャネルを分けた。TLSやSASLは、継続交換の前にセッションの条件を変える。一度に活動できる調整チャネルは一つだった。

TLSが成功すると、保護前にキャッシュしたセッション情報を破棄しなければならない。中間者が改変した可能性があるからだ。新しい暗号化は古い観測を正しいものに変えない。

認証済みの相手にも、各チャネルでアクセス制御が必要だった。アイデンティティとプライバシー水準に応じて、処理の前に判断する。誰かが分かったことと、その命令を受け入れることは別である。

多重化にはチャネルごとの財布が要る

RFC 3081は共有接続の弱点を扱った。TCPのフロー制御は接続単位なので、一つの遅いチャネルが他を飢えさせたり、デッドロックを作ったりし得る。

そこでチャネルごとのsliding windowとSEQが加わった。新しいチャネルの初期枠は4096オクテットで、受信側は次に期待する番号と受け入れ可能量を通知した。信頼配送はTCPの仕事であり、この枠は共通資源を会話間で配るためのものだった。

ポートの終わりと設計の終わりは違う

BEEPにはsyslog、SOAP、NETCONFなどのプロファイルが作られた。その後RFC 9900はNETCONF over BEEPとNETCONF over SOAPのポート番号を解放し、サービス名は残した。

この経緯は、RFC公開を普及実績と見なす誤りも、ポート解放を設計否定と見なす誤りも退ける。仕様、登録、実装、利用にはそれぞれ時間がある。

RFC 3080の価値は、低い層の成功に高い層を代弁させなかったことだ。greetingは能力通知、startの応答はチャネル束縛、RPYは交換結果にすぎない。設定が残ったか、ログが書かれたか、サービスが変わったかは、さらに上で確かめる必要がある。

出典

  1. https://www.rfc-editor.org/info/rfc3080
  2. https://www.rfc-editor.org/rfc/rfc3080.html
  3. https://datatracker.ietf.org/doc/rfc3080/
  4. https://www.rfc-editor.org/rfc/rfc3081.html
  5. https://www.rfc-editor.org/rfc/rfc3117.html
  6. https://www.rfc-editor.org/rfc/rfc3195.html
  7. https://www.rfc-editor.org/rfc/rfc4227.html
  8. https://www.rfc-editor.org/rfc/rfc4744.html
  9. https://www.rfc-editor.org/rfc/rfc9900.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/