出典: セッションスライド一式および録画の文字起こし、投票結果（polls）
議題は「既存WG文書の進捗確認」（前半・短時間）と「まだWG項目ではない新規提案の温度感確認」（後半・議論中心）の二部構成。後半の Signature-Key、RESET_STREAM_AT、リクエストスマグリング防御、および OHTTP 関連2件が実質的な議論の中心。
1. Resumable Uploads（Marius Kleidl）
- 昨年7月のWGLC以降、90件のissueが起票され82件クローズ、残り8件。残りは編集上の指摘やエッジケースの明確化が中心。
- -11からの主な変更: 最終レスポンス消失に関する規範的記述の削除、サーバ側での
Upload-Completeの再定義、integrity digest セクションの削除（セマンティクスが不明確で実運用経験もなく「理論的な演習」に留まっていたため。将来的な再検討はあり得る）。 - レビュー希望者は残り8件を片付けた新版を待ち、文書全体を新規文書として読むのが推奨。その後2回目のWGLCを目指す。
- ブラウザ統合（HTML Forms / Fetch API）は CORS、resume時のorigin変更、Cookie、CSP などの検討事項があるが議論の場は WHATWG 側。トラッキングissue #3498 にポインタあり。
- Tommy から相互運用性への影響確認。Marius 曰く Apple のネットワークスタックは追随済み、自身の実装は要更新だが規範的変更は相互運用性にほぼ影響しておらず、処理の遅延要因にはならない。
2. Cookies（チェア報告）
- RFC 6265bis は**最終レビュー段階（旧AUTH48。数字で誤解されないよう名称変更された）**に今月入ったところ。著者はホリデーシーズン中。
- Layered Cookie 仕様（HTTP側のワイヤ上の挙動と Fetch 側の実装挙動へ規範的テキストを分割するリファクタ）は継続中だが報告事項なし。次回11月に改めて更新予定。
3. Preliminary Request Denied（Mark Nottingham）
- 本文は安定。残る作業はステータスコードの確定のみ。
- 候補は 419。squatter として Laravel が使用中だが事前協議は未決着。Mark の見解では移行パス（そもそもステータスコードは不要では、というもの）はある。
- 「一実装の squatting を理由にコードを避ける前例を作ると、すぐに立ち行かなくなる」。会場から419支持。ML上で明示的な提案メッセージを出し、反対がなければ419で進め、間もなくWGLCへ。
4. Secondary Certificate Authentication of HTTP Servers
- スコープを縮小し issue は全て処理済み。会場からも賛意。
- 会合後にWGLCを開始。ホリデーシーズンのため期間は3〜4週間に延長。
- Mike Bishop は（ADではなく著者として）「長く取り組んできた。ぜひWGLCへ。著者としてクレジットされているが自分もこのバージョンは久しく読んでいないので last call レビューをする」と発言。
5. Template-Driven HTTP CONNECT Proxying for TCP（Ben Schwartz）
- IETF 125 の draft-10 以降: draft-11 で Proxy-Status trailer を
MAY→MUST NOTに変更（#3389）。Yaroslav Rosomakho と Eric Kinnear から19件のWGLC issue（Willy Tarreau からも追加レビュー）。WGLC は "Revised I-D Needed" で終了し、draft-12 を公開。 - draft-12 は小さな変更が多数だが互換性を壊す変更はなし。
- 未クローズは #3422（FINAL_DATA のエッジケース） のみ。PR #3480/#3481 で対応済みで合意確認待ち。内容は不完全な接続終了のシグナリングとその帰結で、特に TCP ステートマシンが数分間リソースを保持し得ることによるポート枯渇型DoSのリスクに関する追加の助言。
- チェア判断: WGLCの再実施はせず、MLへの通知のみ。チェアレビュー → IETF last call → IESG へ。取りこぼしがあればそこで拾える。
- David Schinazi から（IANA expert の帽子で）「WGLC直後に capsule type を小さい値に割り当て直したい」という要望。複数バージョンの出荷は面倒であり、これらの capsule のセマンティクスが変わる可能性は低い、という理由で合意。expert review レジストリなので誰でも provisional 登録を要求でき、RFC発行時に permanent になる。
- Tommy がシェパードライトアップを担当。
6. HTTP Signature-Key Header（Dick Hardt / Thibault Meunier）※WG項目ではない
RFC 9421 が意図的に空けている「鍵の配布方法」を埋めるヘッダの提案。
- スキームごとに信頼モデルが異なる:
hwk（仮名・鍵thumbprint）、jkt-jwt（仮名＋委譲、ハードウェアenclave鍵が一時的なソフトウェア鍵に self-issued JWT で委譲、TOFU）、jwks_uri（識別）、self-jwt（識別＋クレーム、-06で追加）、jwt、x509（PKI）。 - IETF 125以降5リビジョン。目玉は
dwk（dot well-known）パラメータ — 各プロトコルが独自の .well-known メタデータ文書を定義している問題に対し、署名付きリクエスト自身が自分のメタデータ文書名を伝えることで、汎用の検証器がアプリ固有の知識なしに{id or iss}/.well-known/{dwk}からjwks_uriを取得できるようにするもの。ミドルウェア実装を大幅に簡素化。 - 他に
Accept-Signature用のsigkeyパラメータ、構造化エラー用のSignature-Errorヘッダ（未知のスキーム用エラーも追加予定）。実装者 Joshua Gay のフィードバックで SSRF対策（HTTPS限定、サイズ/タイムアウト上限、リダイレクトポリシー、プライベート/ループバックアドレス拒否、DNS rebinding対策）とキャッシュ規則が -05 で追加。 - 大きな絵: サーバ識別は DNS+TLS+Let's Encrypt で解決済みだがクライアント識別は未解決。mTLS は企業境界を出られず、オープンWebでは全てAPIキー等の共有秘密に落ちる（2024年に GitHub で3900万件の secret 漏洩、5日後も90%が有効という GitGuardian の数字を引用）。AAuth、Email Verification、OpenID Connect Key Binding が本仕様の上に構築されつつあり、TypeScript/Rust/Go/.NET/Elixir のライブラリ実装がある。
議論:
- Mark: 「このグループでアイデンティティの領域に深入りしたくはない — 専門領域ではない。ただしHTTP署名作業の自然な継続と位置づけられるなら適した場所たり得る」。
- Dennis Jackson (Mozilla): 非常に有用そうだが、セキュリティ関連の記述が多く、SEC area と協調して慎重に、特に各インスタンス化が提供すべき proof of possession のセキュリティ特性の言語化に相当の作業が必要。
- Mark（.well-known URI レジストリ expert として）: 任意の .well-known URI を指定できる点が引っかかる。あの名前空間はレジストリ管理下なので footgun になり得る。Dick は「検証側が各 .well-known を理解せずに済むための汎用機構」と回答し継続議論に。
- Ted Hardie: **4.6節（WWW-Authenticate との共存）**でつまずいた。両方を理解するクライアントがどう解決するのか、説明の追記が必要。
- 投票（採択の呼びかけではなく温度感）: 「HTTPBIS でこの作業をすることに興味があるか」→ Yes 16 / No 0 / 意見なし 20（投票終了時の参加者70名）。No ゼロが良いシグナルという評価。
7. Using QUIC Stream Resets with Partial Delivery in HTTP/3（Marten Seemann）※WG項目ではない
QUIC WG で IETF last call 中の RESET_STREAM_AT 拡張（reliable size までのデータ配送を保証）を HTTP/3 で活用する提案。WebTransport 向けに作られ、Chrome/Firefox/Safari の全主要ブラウザと WebTransport 対応サーバで既に実装済み。
提案する3つのユースケース: CONNECT プロキシ（上流接続の確立成功と受信バイト数を伝える）、不正なHTTPフィールド（RFC 9114 §4.2 違反時に、単にリセットするのではなく400と短いエラーメッセージを送ってからリセット）、リクエスト拒否（H3_REQUEST_REJECTED に加えて 429/503 等の具体的ステータスを送る）。
議論はかなり批判的:
- Mike Bishop（帽子なし）: 他は素晴らしいがリクエスト拒否のケースは反対。あのエラーコードのセマンティクスは「アプリケーション層に渡されていない」こと。ステータスコードが返るなら処理されたということで、両方やるのは矛盾。
- Ben Schwartz: classic CONNECT でも CONNECT-TCP でも、実際に TCP へプロキシするなら H3_CONNECT_ERROR は TCP RST に変換される。TCP RST は受信側のバッファ済みデータを無効化するので、reliable reset を使っても守ろうとしたデータは結局落ちる。「やってもいいが意図通りに動かない場面が多い」。方向は対称的で、クライアント側が TCP を直接 HTTP スタックに繋いでいることが多いというだけ。CONNECT-TCP draft への変更提案がないことも確認（回答は No）。
- David Schinazi: RFC 9293 でも reset を受けたら socket の read 呼び出しは失敗しなければならない、と確認。「これらのユースケースの多くは成立しない」。そもそも WebTransport でこれを定義したのは、QUIC 双方向ストリームにメタデータを付随させる手段がなく、接続状態に critical なメタデータをストリームデータ内に置いてしまったから。QUIC の設計が違えば不要だった。「headers フレームだけ確実に届けて残りを吹き飛ばす」ケースだけは魅力的だが、headers を送るのはセマンティクスを語ることであり reset は全部が壊れたという意味なので、HTTPセマンティクスに正しくマップされていない。
- Tommy: CONNECT を扱うなら extended CONNECT とその派生にも触れるべき。より重要なのは「できる」ではなく「クライアントが受け取って何を有用にするのか」を明記すること — エラーログ/レポート用途なのか、何らかのアクションを取るのか。それが書かれれば、どのケースが妥当かを集団で評価できる。
- Mike Bishop（H3エディタの帽子）: server push にまさに同じ問題がある。push ID が unidirectional ストリームのヘッダにあるため、クライアントが push ID を読む前にストリームがリセットされると push promise が永久に未達成に見える（push promise のリークが技術的に可能）。QUIC にこれがあれば使っていた。→ Marten が「draft に追加しましょうか」→「ぜひ」。
- Mark（個人として）: 接続レベルのエラーと HTTP セマンティックエラーの扱いには以前から居心地の悪さがある。何がどの層に属するかを非常にクリーンに考える必要がある。セマンティック層はアプリケーションから見え end-to-end で生き残るが、接続層はそうではない。
- 結論: 関心はあるが検討が必要。Marten が改訂に取り組み、ML で継続。
8. HTTP/1.1 Request Smuggling Defense using Cryptographic Message Binding（Erik Nygren, Akamai）※WG項目ではない
intermediary と downstream の間で、in-band かつ保護されたシグナル（ReqBind / RespBind のシリアル番号）により両者のリクエスト同期のズレを検出して安全に落とす提案。
-00 からの変更: 明示的な脅威モデルの定義（クライアント→intermediary のホップは敵対的と仮定し保護対象外、守るのはそこから下流）、Bound-Request-Init ヘッダによる機構ネゴシエーション（crypto agility と in-band での鍵伝達を可能にし TLS exporter を不要に）、SHA-256 の代替として siphash-2-4、ネゴシエーション手段としての専用 ALPN の示唆。
議論（会場のエネルギーが最も高かった項目）:
- Ben Schwartz: 鍵となる問いは「未改変のHTTP/1.1実装の上に載せられるか」。実装を改変できるなら置き換えもできるはずで、それなら HTTP/2 を使うべき。ただし現 draft を読む限り未改変の標準ライブラリの上で実装可能だと思う — メッセージのワイヤエンコーディングに依存していないため。その代わりボディ表現の詳細の改変は防げない（メッセージ長を知らない）が合理的なトレードオフ。ハッシュではなく単純な非ハッシュの暗号学的MACやストリーム暗号でカウンタを示す方法もあり得る。
- Erik: 次のステップとして複数の HTTP/1.1 実装でどれだけのコード変更が必要か実験する。数百行程度なら価値があるが大規模な変更が必要なら止めるべき。WG採択の前にこれを確かめたい。H1→H2 への移行は実装者にとって大きな転換であり、多くの実装が H2 を H1↔H2 の変換シムとして実装していること自体がこの問題の温床でもある。
- Mark（個人として）: 問題の深刻さは広く認識されている。しかしオーバーヘッドが増え、間違えると派手に壊れるリスクも増える。デプロイシナリオは？ Apache に組み込まれるのか、CDN が顧客と協調して展開するのか。
- Erik: 大きなユースケースは CDN→顧客。Apache、nginx、HAProxy、Envoy 等のフロントプロキシと、その背後の Python/JavaScript ライブラリ実装の HTTP/1.1 API サービスへの実装が価値の源泉。それらのパターンは実際に HTTP/1.1 ホップを含み、かつ正規クライアントと悪意あるクライアントを同一 downstream 接続に多重化していることが多い。「persistent connection を使うな」は性能面でも運用面でも現実的でない。十分な数の実装者の関心（=十分に低い複雑度）がなければやる価値はない。
- Dennis Jackson: draft が参照する学術論文（HTTP-Sync）との関係は？ → Erik: 同じ会社の同僚による収斂進化で、論文側には暗号的防御はない。→ Dennis: 両者が防ぐ攻撃は異なって見える。論文は近年のCVEを精査して何が直り何が直らないかを結論づけている。この draft でも同じ整理をすれば非常に説得力がある。Erik も同意（「十分な数のCVEに対処できなければやる価値がない」）。
- David Schinazi（Envoy の帽子）: 「AIバグポカリプス」の昨今、スマグリング攻撃は観測される攻撃のかなりの割合を占める。この領域の作業を強く支持。TLS exported authenticators は頭が痛くなるので、より単純な選択肢は良い。siphash で十分で、怖い人向けに SHA-256 があるのは良い。提案: INITメッセージに対する応答を持たせる（単なるエコーではなくハッシュを返させる）ことで相手の対応を確認できる。→ Erik: INIT より前に対応表明のネゴシエーションが必要（ALPN等）。さもないと攻撃者が INIT 自体をスマグリングして送り込むリスクがある。
- Chris（Comcast）: 「これが存在してほしいし、既にデプロイ済みであってほしい」。ライブラリに簡単に追加できるという筋書きなら、セキュリティ専門家として「nginx にパッチを当てろ」「ATS にパッチを当てろ」「Go ライブラリにパッチを当てろ、そしてこれを無効化するフラグを切るな」と言える。大量のスマグリング攻撃を観測している。
- Yutaka Oiwa: 20年前からスマグリング問題に取り組み当時から解決策を持っていた。しかし今や実装者の多くは手書きせずライブラリを使っており、その場合 HTTP/2 への移行のコストはほぼゼロ。既に大きな支持者がいるなら良い解かもしれないが、これから実装を頼むなら HTTP/2 の方が確実で信頼できる解では。
- 結論（Mark）: 強い関心がある一方、成功できるかへの懸念もある。Erik は作業を継続して持ち帰ってほしい。将来的な call for adoption はあり得る。（Tommy）採択に賛成する前に見たい性質があれば会場やMLで表明してほしい。（Erik）実装者で共著者になってくれる人を強く求む。
9. A Perfect Forward Secure Extension to Oblivious HTTP（David Schinazi）※WG項目ではない
前提として OHAI WG は作業完了で閉じられ、OHTTP の維持責任は httpbis に移っている。Google は OHTTP ゲートウェイを毎秒約50万リクエスト規模で運用し、Chrome/Android の Safe Browsing 全体をカバー、他ブラウザのオンボーディングも進行中。
提案: クライアントがリクエスト送信時に一時的な鍵ペア (skC, pkC) を生成してゲートウェイに送り、ゲートウェイは pkC で HPKE を使ってレスポンスを暗号化、2つのコンテキストをバインドする。chunked の場合クライアントは新コンテキストに切り替える。結果、クライアントの最初のフライトを除く全てにPFSが付く（最初のフライトが PFS でないのはラウンドトリップを要求しないシステム共通の性質で TLS 0-RTT と同じ）。未解決の問い: コンテキストのバインド方法（info文字列か PSK か）、entropy の要否、regular OHTTP との後方互換性を持たせるか。
議論（賛否が最も割れた項目）:
- Dennis Jackson: 最初のリクエストは変わらない → 「それこそが自分が本当に気にするリクエストでは？」。また config をより頻繁にローテートすれば一種の forward secrecy は得られる。→ David: 双方向RPCでは最初のリクエスト/レスポンスはチャネル設定と認証情報の交換であることが多い。またゲートウェイは単一ではなくフリートであり、クライアントは別リージョンに当たり得るので鍵は広く伝播し漏洩機会が多い。→ Dennis: 「0-RTTは絶対に必要だがPFSは要らない、というのはプロトコルへの要求として噛み合っていない」。→ David: chunked 拡張採択時に「双方向なら CONNECT の上で TLS を使え」と言ったが「0-RTT が絶対に必要で、TLS の 0-RTT はリクエスト間の linkability を生むから使えない」と返された。それを設計要件として受け取った。→ Dennis: TLS に unlinkable な 0-RTT を定義するのは難しくない。またこの HPKE 合成は重要なユースケースを持ち他者が真似するので入念な解析が必要。→ David: 公開前に完全なセキュリティ証明と解析は必ずやる。TLS 側でやる方法について意見交換したいが容易とは到底思えない。
- Kazuho Oku: chunked ゲートウェイを既に提供している会社の立場として、この問題を顧客に説明するのは難しい。1-RTT以降にPFSが適用されることを期待する。0-RTT のセキュリティ低下を気にするならメッセージ送信を遅らせればよく、それはアプリケーションの選択。
- Martin Thomson: その議論には認知的不協和を感じる — アプリは 0-RTT については正しい判断ができるが他については正しい判断ができない、というのは奇妙。安全にするかしないかどちらか。そもそも chunked で欲しかったのはメッセージの逐次処理であり、双方向通信が可能になったのは不本意な副産物。人々がこの用途で使い始め TLS を使いたがらないなら、この道を行くより TLS を直す（unlinkable な 0-RTT プロファイルを見つける）方を好むかもしれない。PFS でない最初のフライトについて教育できるなら「CONNECT がある」ことも教育できるはず。まずユースケースを明確にすべき。
- David: CDN ベンダーからは HTTP ゲートウェイの方が CONNECT より展開しやすいと聞く（社内で CONNECT 担当と chunked 担当が別部署、という現実も）。Google QUIC Crypto には unlinkable な 0-RTT があったが、そのためには HPKE 鍵を安全に伝える手段が必要で QUIC では証明書にバインドしていた。TLS証明書とTLSを少し変更する必要があるなら難しい。
- Jonathan Hoyland: インタラクティブな chunked メッセージをやっている時点で既にセキュリティ的に良くない状態で、obliviousness の保証をかなり失っているのでは。→ David: 漏れるのはクライアント〜リレー間のレイテンシだけで、クライアントIPアドレスの漏洩に比べれば遥かに軽い。→ Jonathan: chunked のセキュリティ考慮事項には、両側を見られる者がどのパケットがどの顧客・どのリクエストに対応するか識別できるという攻撃がある。→ David: 脅威モデルの問題。Googleにとっての脅威はGoogle自身 — Safe Browsing を IP アドレスにアクセスしないという明確な保証付きで全ブラウザに無償提供したい。両側を見られる国家アクターは想定敵ではない。
- Ben Schwartz (Meta): Dennis と同じ理由で懐疑的。チャンク境界の位置次第で部分的にPFSになったりならなかったりするプリミティブは正しく使うのが非常に難しい。→ David: TLS 1.3 の 0-RTT と同じプリミティブ。→ Ben: 鍵のスコープとローテーション頻度が違うので直接比較できるか疑問。TLS 1.3 ではユーザごとに別の鍵で 0-RTT し得る。→ David: unlinkable 0-RTT にすれば同じ問題を抱える。→ Ben: ただし自社にこれとほぼ一致する明確かつ優先度の高いユースケースがある — WhatsApp private processing（ホワイトペーパー公開済み）。chunked OHTTP を双方向バイトストリームとして使い、その中で enclave attested TLS (RA-TLS) を走らせて、まさに同じプライバシー特性を得ている。本番で達成しているがコストがかかっており、もっと良い方法があるはず。この仕様がその答えとは確信できないが、複数企業に共通する再発問題であり、よりクリーンな解を見たい。
- Chris Wood: 有用。これは chunked OHTTP への（括弧付きで）「些細な」拡張であり、解析能力はこの部屋あるいは近しい人々で持っているので心配していない。TLS でもできるかもしれないが、HTTP で既にある程度取り組んだのと同じ困難に直面するし、今の TLS を変えるのは難しく、HTTPの解を本番投入する方が圧倒的に簡単。この路線を探求したい。
- Mike Bishop（OHAI を閉じた AD として）: 「おそらく早すぎたが、当時それは分からなかった」。しかし OHAI が SEC area にあったのには理由がある。このグループでやるなら security directorate からの徹底的なレビューと、HTTPで通常やる以上に厳密な形式的証明を求める。→ Martin Thomson: 「レビューではなく継続的な関与と言うべき」→ 同意。Concealed Auth の RFC で実際にそうした前例あり。「Noではない。極めて慎重に、ということ」。
- Dennis: TLS の 0-RTT はブラウザ側にもより広いユースケースがある。TLSを一機能ずつ別レイヤで再実装していくのは幸福な世界ではない。→ David: chunked OHTTP を出荷済みであの人たちを TLS に移せない。Google の TLS スタックに変更を入れるのはチーム規模の問題もあり複雑。TLS 側の変更がどう見えるか把握して実現性を判断したい（技術的・政治的な障害が多いと思う）。
- Tommy（帽子なし）: chunked の本来の趣旨は主にレスポンス（とリクエスト）の逐次配送であり根本を変えるものではないはず。双方向インタラクティブストリームが本当にその0-RTTの冒頭を必要としているのか、もっと理解すべき。自身の経験では、マルチターンのLLM対話を OHTTP で行っているが、それらは個別の chunked OHTTP リクエストとして（OHTTPレイヤでは unlinkable なまま）行い、セッション再開の識別子はボディ内に入れている。そういう設計がどこまで選択肢になるのか。
- David（補足）: これは chunked なしの通常のHTTPでも同様に機能する。リクエストには PFS が付かないがレスポンスには付く。リクエストの auth トークンは時間でスコープされているので1日後に鍵が漏れてもトークンは無効だが、レスポンスの方が遥かにプライバシーセンシティブなデータを含むケースは多い。
- 結論（Mark）: 関心はあるが懸念もある。懸念の多くはユースケースの明確な記述、エコシステムの他の部分との関係、そして OHTTP が何のためのものかという意図に集中している。「道具箱の道具」という比喩を使ったが、道具は特定の目的のために設計される。議論継続。
10. An Extensible Key Configuration Format for Oblivious HTTP（David Schinazi）
同スライドの後半。大規模運用で判明した既存 key config 形式の2つの問題への対処。
- 問題1（content-type）: WGLC後に、複数のKEMを1つのkey configに入れられるようにする後方互換性のない変更が入った（PQ OHTTP のために X25519 と XWing を併記できるようにするもので変更自体は妥当）が、content-typeが変わらなかった。結果、RFC通りに実装したサーバと、その形式をパースできない既出荷デバイス（David いわく「地球上の40億台に責任があるかもしれない」）が噛み合わない。当時この変更に誰も気づかなかった。
- 問題2（鍵の有効期間）: 鍵は通常週次でローテートするが RFC 9458 には有効期限の指針が事実上ない。Chrome は受信後3日で失効扱い（「3はいい数字だから」）、Android は「RFCが何も言っていないので永久に使い、ゲートウェイが秘密鍵を失っていれば422が返るのでリトライする」。後者は漏洩鍵で暗号化して送ってしまうリスク、前者は端末がオフラインで背景更新に失敗し続けると有効な鍵を捨ててしまう信頼性問題を生む。サーバ側は公開停止後さらに2週間鍵を保持せざるを得ず、取得タイミングによって使える期間が2〜3週間で変動する。
- 提案: content-type を変更し、key config 形式は概ね維持したうえで末尾の隙間に Extensions を追加、NOT_BEFORE / EXPIRATION を定義する（JWT や Private Access Tokens の鍵は既にそうしている）。事前公開により「来週の鍵」「再来週の鍵」を配れ、クライアントは数週間に一度ゲートウェイに到達できれば常に有効な鍵を把握でき、サーバ側の鍵保持期間も短縮できる。
- Mike Bishop: 「クライアントのバグがある」と「どうせ形式を変えるなら」の間には微妙な矛盾がある。やるならやりたい作業に基づいて正当化すべきで、クライアントのバグを理由にすべきでない。→ David: バグは直す。ただし直すにあたってクライアントに両者を区別させる手段が要る。どうせクライアントを更新するなら同時に機能を追加できるという主張。
- 会場からの他の反応は少なく（チャットでは議論あり）、チェアは「皆さん読んで考える時間が必要そう」と締めた。
11. まとめ（チェア）
- OHTTP 関連2件は AD およびセキュリティエリアの関係者と相談し、venue（どこでやるか）の議論から始める必要がある。
- HTTP directorate（他WGのHTTP利用文書をレビューする組織）の参加者募集。BCP 56 と編集ガイドラインを使って AI をレビュー支援に使う試みを始めており、興味深い結果が出ているとのこと。
議事録との差分・補足
- RESET_STREAM_AT の発表者は Marten Seemann、OHTTP 議論で発言している Martin は Martin Thomson（議事録では両方「Martin」表記）。
- 投票の正確な内訳は Yes 16 / No 0 / 意見なし 20（投票終了時の参加者70名）。
- CONNECT-TCP の #3422 は議事録では「議論中」とあるが、録画では PR #3480/#3481 で対応済みで合意確認待ちという状態。