要約

  • RFC 2351は、消失時に再試行できる対話型Type Aと、高い保護・複数宛先・優先度を要するType Bを、別の性質を保ったままTCP/IPへ写像した。
  • TCP接続とMATIPセッションの受諾が示すのは、相手と通信条件が合ったことまでである。座席の確保、発券、再試行の安全性、個別メッセージの責任移転までは示さない。

1998年の航空会社には、新しいネットワークと古い業務が同居していた。TCP/IPスタックは安価になり、イントラネットは普及し始めた。一方、各地の事務所にはP1024BやP1024Cの端末が多数残り、中央の予約・発券アプリケーションをすぐに置き換える計画はなかった。

RFC 2351のMATIPは、この時間差を埋めるための仕様だった。TCPと航空アプリケーションの間に共通の写像を置き、相互運用できない独自ゲートウェイへの依存を減らす。ただし、業務そのものをTCPの意味へ作り替えない。この範囲設定が重要だった。

Type Aでは沈黙の後に再送が起きた

Type Aは、航空会社の事務所や旅行代理店から中央の予約・発券ホストへ向かう対話型通信などを扱った。リアルタイムで優先度は高いが、保護は限定的で、破棄されることもある。RFCは、データ消失により応答がなければ利用者が要求を重ねて送れると記している。

これは全操作の冪等性を保証する文言ではない。空席を再照会することと、同じ販売処理を再実行することは違う。RFC 2351は、全航空アプリケーションに共通の取引ID、重複排除台帳、照合手続きを規定していない。沈黙の後の要求が再送か、重複か、別の正当な操作かは、業務状態を持つ上位層が判断する。

MATIPは、その判断先へ通信を振り分けるための文脈を残した。セッション開始時にサブタイプ、文字コード、表示形式、ヘッダー、 multiplexingを合意する。H1、H2、A1、A2でIPアドレスとは独立に端末群を識別でき、ホスト間通信にはFlow IDも使える。これらは選択子であり、予約権限やホスト側の確定処理を証明する本人確認書ではない。

Type Bは別の責任を運んだ

Type Bはメッセージ通信で、即時性よりも高い保護、複数宛先、四段階の優先度を重視した。RFC 2351の層構造では、BATAPがMATIPの上に位置し、Type Bのアプリケーション間保護を担う。

Type BのSession OpenにはPROTECがあり、端末間のMessaging Responsibility Transferプロトコルを示す。両端の方式が合わなければ、Open Confirmはセッションを拒否できる。送信側と受信側はHLDで表すことも、IPアドレスの組で表すこともできた。

方式の一致は、個別メッセージの責任移転そのものではない。同じPROTECを理解していても、データはBATAPなどの合意済みサービスに受け入れられ、所定の確認を得て、アプリケーション状態と照合されなければならない。複数宛先の一つが受け取っただけで全宛先の完了とも言えない。

ポート番号は交通を分け、結果は決めなかった

Type AにはTCP 350番、Type Bには351番が割り当てられた。パラメータ集合ごとに別のTCP接続とMATIPセッションを作る。Session Openが条件を提示し、Open Confirmが受諾または拒否し、Session CloseがMATIPを閉じる。MATIP独自のkeep-aliveはなく、タイムアウトはTCPに依存した。

二つのライフサイクルは重なるが同一ではない。TCPが切れればMATIPは維持できない一方、MATIPを閉じてもTCPを閉じる必要はない。したがって、生きているTCP接続は航空アプリケーションの稼働証明ではなく、受諾済みMATIPセッションも業務完了証明ではない。

RFC 793のTCPが提供するのは、プロセス間の信頼できる順序付きバイトストリームである。RFC 1122はホストが通信層で守るべき要件をまとめた。どちらも座席在庫、発券番号、Type B受信者の責任受諾を見ることはできない。

必要な証拠は段階ごとに異なる。経路、TCP確立、MATIP Session Open、Open Confirm、許可されたASCU・Flow ID・HLD、データ到達、アプリケーション確認、責任移転、業務状態の確定、重複や部分失敗の照合である。一つの信号へ圧縮すれば、下位層に存在しない知識を与えてしまう。

セキュリティ注意書きは橋の限界を示した

RFC 2351は、ASCUの静的設定またはユーザーIDとパスワードを認識手段として挙げ、IPやアプリケーション層でのファイアウォール制御、任意のIPsec ESP・AHを記した。現在RFC Editorは、静的識別子や平文らしきパスワードは堅牢でなく、健全なIPsec保護が任意に留まったと注意を付している。

これはMATIPの価値を否定しない。移行と相互運用の橋が、古い識別子から暗号学的権限を生み出せないことを示す。RFC 4301のIPsecも、ポリシーとSecurity Associationを用意する。実際の交換が期待通り保護されたかは、能力の有無ではなく運用記録で確かめる必要がある。

RFC 2351の歴史的な教訓は、共通化の境界にある。IPで運ぶところまでは共通化できる。沈黙、確認、責任、完了の意味は、それを観測できるアプリケーションに残さなければならない。

出典