要約

  • PTTHではトランスポート側が先にチャネルを開き、プロキシが後からHTTP要求を送れる。
  • 提案憲章は認証と要求の認可を含む。外向き接続だけで全面的なアクセスが成立するわけではない。

バックエンドが先に接続する。その後、プロキシが要求を送り返す。

Protocol for Transposed Transactions over HTTP（PTTH）の狙いは、厳しいファイアウォール内のワーカーがプロキシへ外向き接続を張り、そのチャネルでHTTP要求を受けることだ。トランスポート層のクライアントが、転置された要求ではHTTPサーバー役を担う。

ワーカーごとの受信ポートや固定アドレスを減らせる可能性がある。ただし難しい判断は一段移動する。チャネル確立後、プロキシは何を要求できるのか。

IETFの作業憲章案は外部レビュー中で、2026年11月5日のIESG会議に載っている。11月2日時点では提案にすぎず、憲章もPTTH標準も承認されていない。

2025年7月のIETF 123では、隠れたバックエンド、CDN拡張、要求の優先制御、ゼロトラスト、HTTPを他プロトコルの土台にする案が示された。限られたパスを受けるCDNワーカーと汎用トンネルでは、権限の範囲が違う。

会議記録は、ワーカーがプロキシ設定を送ると要求ルーティングに影響し得る点を問題にした。認証方法、URL空間の制限、HTTPを別用途の土台にした場合の作業範囲も問われた。会場投票は作業継続を支持したが、導入需要や範囲を確定していない。

2026年7月のIETF 126では、接続確立、要求の認可、容量・制御を別の仕事として整理した。最初の二つは初期段階で必要、容量や制御は導入ごとに異なるとされた。ワーカーがプロキシ設定に影響する権限も再び議論された。

提案憲章には、受信意思の表示、双方の認証、許可する要求の特定、ルーティングの指針が含まれる。同じ接続で両端が要求を送れるかは未決だ。新しい認証基盤やトランスポート、サーバー発見、容量要求、HTTP意味論の変更は対象外となる。

この線引きで、単なる接続が制御面へ広がるかが決まる。接続は到達性を作るが、受け入れや経路、失効を決めない。各社が独自規則を持てば運用者には継ぎはぎが残る。標準が広がりすぎれば、一本のチャネルが信頼境界を越える入口になり得る。

認証済みワーカー、許可範囲、プロキシの判断、期限・失効、監査記録を一組で確かめたい。なければ動くトンネルが示すのは転送であって認可ではない。

出典：IETF提案憲章、IETF 123議事録、IETF 126議事録、PTTH個人ドラフト。