要約

  • Mark Nottinghamは「HTTP/3」という名称を提案し、QUIC上でHTTPの意味を運ぶ対応付けを、QUICの転送機能とは別のHTTPプロトコルとして見せようとした。
  • 提案には保守の移管も含まれていた。公開後はHTTP/3とQPACKをHTTPワーキンググループが維持するという考えで、後のIETFの憲章にはその役割分担が記録されている。
  • 境界は判断と保守の所在を明確にするが、名称だけで互換性や導入が保証されるわけではない。Nottingham個人が名称や標準を決めたのでもない。

2018年後半、「QUIC」という言葉は二つのものを指すことがあった。ひとつはトランスポートプロトコル、もうひとつはその上でHTTPを動かすための対応付けだ。作業を追っていない人には、両者がひとつの成果物のように見え始めていた。呼び名の問題にとどまらず、どのワーキンググループが将来の変更を受け持つかにも関わる混同だった。

10月28日、Mark NottinghamはQUICワーキンググループのメーリングリストに提案を送った。HTTP文書を「HTTP/3」と名付け、最終的なALPN識別子にはh3を使うという案である。HTTP/2と同じく、これはHTTPの意味をワイヤ上のプロトコルに結び付ける別の方法だと分かるようにし、QUICそのものと混同されないようにする。提案理由は、本人が送ったメールに残っている。

彼は名称だけを提案したのではない。公開後にはHTTP/3とQPACKの保守をHTTPワーキンググループに引き継ぐべきだとも述べた。あるグループで文書を書くことと、その文書の将来をずっと管理することは別である。QUICの仕組みを作るグループが最初のHTTP対応付けを進めるのは自然だが、HTTPの拡張や意味に関する後続の判断はHTTPを担当するグループが受け持つ方が筋が通る。名前は「何の仕様か」を示し、移管案は「次の判断を誰が担うか」を示した。

会議記録は賛成と決定権を分けている

IETF 103のQUICワーキンググループでは、名称について議論が行われた。HTTP/3はHTTP/2の後継という意味に読めるという意見がある一方、新しい名前が分岐を示すのではないかと懸念する参加者もいた。Nottinghamは、HTTP/2がHTTP/1.1を廃止したり置き換えたりしたわけではないと指摘した。重要なのは、HTTPの意味と、それを運ぶワイヤ上のプロトコルを区別することだという。

議事録の「ハム」は正式な投票ではない。名称変更への賛意はおおむね70対30、HTTPbisに決定を委ねることへの賛意はほぼ全員だったと記録されている。後者の方が役割をよく表す。文書はQUICの作業から生まれたが、HTTPの名前を決めるのはHTTPコミュニティだ。Nottinghamも、HTTPの命名はHTTPコミュニティに残す必要があると述べた。

10月のメールには「Chair hat」と明記されている。バンコクでの議論は短くし、際限のない名称論争を避けたいという。開発者や利用者に分かりやすく伝える責任はあるが、技術作業にも時間を残すべきだという判断だ。議長は論点を整え、時間を管理できる。しかし、その枠組みは合意に代わる命令ではない。

層が見えると名称は正確になる

後に公開された仕様も、この区別を保っている。RFC 9114はHTTP/3を「QUIC上のHTTP意味論の対応付け」と説明する。RFC 9110はHTTPの意味論を定め、RFC 9000はQUICトランスポートを定義する。HTTP/3はQUICの信頼性ある順序付きストリーム配送やセキュリティを利用する一方、HTTPメッセージの意味とアプリケーション上の役割を保つ。名称が示すのは対応付けであり、二つの層の統合ではない。

ALPNのh3も、公開名HTTP/3と同じ用途ではない。これはプロトコル交渉中にワイヤ上で使う識別子だ。HTTP/3という名称は仕様と作業を分類する。h3は接続相手とプロトコルを選ぶために使われる。Nottinghamのメールによれば、RFC公開までは名称を正式化せず、ワイヤ上でも使わない予定だった。識別子が実装の互換性を左右する前なら、提案を見直す余地が残る。

保守の分担も、標語だけでは終わらなかった。2018年版のHTTPbis憲章は、QUICグループによるHTTP/3の公開後、必要に応じてHTTPbisがHTTP/3とQPACKを含む拡張を維持・開発すると定めた。現在のHTTP憲章はHTTP/3とQPACKをHTTPの中核仕様に挙げている。現在のQUIC憲章にも、HTTP/3の対応付けとQPACKはQUICグループが起点を作り、今はHTTPグループが保守していると記載されている。

ただし、この境界は壁ではない。QUICグループにはHTTP/3のqlogイベントを扱う文書も掲載されている。転送とアプリケーションの観測が交わる仕事まで一方のグループから排除するという意味ではない。中核となるHTTP対応付けを誰が保守するかを定めつつ、QUIC側の仕組みに関わる事項は引き続き協力して扱う。実システムでは両方の層が接するからだ。

公開は導入を代行しない

HTTP/3という名前が付いても、クライアントが自動的にその通信を始めるわけではない。サーバーが受け付ける保証も、経路上で問題なく届く証明もない。RFCとALPN識別子は共通の参照点を作る。その後の交渉、相互運用、フォールバック、導入判断は実装者に残る。名前は分類の誤りを減らすが、普及率や性能を測る指標ではない。

だからこそ提案の効用は範囲を定めて考えられる。HTTP仕様はメッセージの意味とQUICへの対応付けを記す。QUIC仕様は配送、輻輳制御、転送の安全性を定める。憲章は継続的な保守担当を示す。運用者と実装者は、その仕様を採用するか、どのように使うかを決める。それぞれの記録が答える問いは異なる。

Nottinghamの貢献は、彼ひとりでHTTP/3と名付けたり保守を移管したりしたことではない。名称と将来の責任分担を結び付け、名前はHTTPコミュニティが決めるべきだと主張した点にある。議事録と憲章が、その後の判断を記録している。新しい仕様を見るときは、何が共有され、何が変わり、誰が各部分を保守し、実装側に何が残されているかを確認するとよい。

参考資料