HTTPヘッダに構造を与えるStructured Field ValuesにDateが追加される

HTTPヘッダの値に、リストや辞書といったデータ構造を定義する『RFC8941 Structured Field Values for HTTP』という仕様があります。
(ヘッダと書きましたが、フィールドという用語た正しいので仕様上はStructured Field Valuesという名称になってます)

これに新しく、Date値を追加する議論が行われています

RFC8941 Structured Field Values

すでに出版されているStructured Field Valuesでは、ヘッダの値として次の値を定義しています。

• List
• Dictionary
• Item
• Integer
• Decimal
• String
• Token
• Byte Sequence
• Boolean

例えば、Dictionaryであれば次のような構造です。

Example-Dict: rating=1.5, feelings=(joy sadness)

IETFで新しいHTTPヘッダを策定する際にこのStructured Field Valuesの仕様に則って定義すれば、シンタックスも曖昧性が無く、パーサーも再利用できるようになります (*すでに定義された全てのヘッダがこのルールでパースできるとは限りません)。

sfbis

RFC8941 の改訂版として "draft-ietf-httpbis-sfbis-01" が現在議論されています。この提案仕様は、新しくDate値が追加されています。

日付を表すHTTPヘッダは多くありますが、文字列で日付を示すよりUNIXタイムで示せるようにしたいという要望も出ておりました。それに答える形になっています。

Date値は次のように@で始まります。

Example-Date: @1659578233

Document Picture-in-Picture が便利

ピクチャーインピクチャー (PIP)

ピクチャーインピクチャー (PIP)は、ブラウザ上で小窓で動画視聴できる仕組みです。

例えば、YouTube上で右クリックして、『ピクチャー イン ピクチャー』を選択すると

次のように小窓で動画を再生してくれます。

他のタブを表示したり、ウィンドウを最小化しても再生され続けるため、作業しながらの視聴時に大変助かります。

Document Picture-in-Picture

現在の『ピクチャー イン ピクチャー』はHTMLVideoElementでしか行なえません。そのためYouTubeのプレイヤー操作(シークバー操作やショートカットキーによる早送り/巻き戻し)は出来ません。

現在 任意のHTMLElements を『ピクチャー イン ピクチャー』可能にする「Document Picture-in-Picture Explained」の議論がされいます。

Chrome Canaryですでに動くので試します。

YouTubeで動画を再生しながら、次のスクリプトをデベロッパーツールから実行します。

  const player = document.querySelector("#player");
    const pipOptions = {
    initialAspectRatio: player.clientWidth / player.clientHeight,
    copyStyleSheets: true,
  };
  pipWindow = await documentPictureInPicture.requestWindow(pipOptions);
  const playerContainer = document.querySelector("#player");
  playerContainer.classList.add("pip-mode");
  pipWindow.document.body.append(player);

プレーヤーが『ピクチャー イン ピクチャー』できた (スクショは、タブは切り替えた様子)

セキュリティ関連のHTTPヘッダを一括指定する Baseline ヘッダ

現在のWebでは、セキュリティ上レスポンスヘッダで色々なものを指定します。Webデベロッパーは個別に指定しなければなりません。

そこで、セキュリティ関連のヘッダを推奨デフォルト値に設定できるようにする「Baseline ヘッダ (Opt-into Better Defaults)」が、GoogleのMike West氏によって提案されています。

まだたたき台であり、これからW3CのWebAppSec WGで議論されている予定になっています。

Baseline ヘッダ

次のようにレスポンスヘッダを指定します。

Baseline: Security=2022

これは、次のヘッダを送信するのと同様です。

Content-Security-Policy: script-src 'self';
                         object-src 'none';
                         base-uri 'none';
                         require-trusted-types-for 'script';
                         trusted-types 'none';
Cross-Origin-Embedder-Policy: credentialless
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Permissions-Policy: /* TBD; some reasonable baseline configuration */
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN

各種セキュリティ関連のヘッダを指定し、XSSを防ぎ、クロスオリジンからの読み込みなどを制限します。

各ヘッダは個別に上書きすることが出来ます。

ブラウザからPCの負荷状況を取得する Compute Pressure API

PCの負荷状況に合わせて、Webサイトでの処理を軽量なものに切り替えたい場合があります。

それを可能にする仕組みである「Compute Pressure API 」がChromeで実装が進められています。なお、仕様の方もW3Cで「Compute Pressure Level 1」が公開されています

例

Compute Pressure APIを使うと、PCのCPU負荷が4段階で確認できます。

• Nominal: 負荷が低い状態
• Fair: システムは正常に動作しており、追加のワークロードを実行できる
• Serious: 負荷が高い状態。追加のワークロードを実行するとCriticalになりうる
• Critical: 負荷が限界に近い状態

詳しいCPU情報はプライバシーの観点から公開しない設計になっています。

実行例

Compute Pressure API は現在Chromeの開発版で動作確認できます。
https://github.com/w3c/compute-pressure/blob/main/HOWTO.md を参考に実行しています。

サンプルでは、Observerを介して状態が変わる際にCallbackで負荷状態を出力しています。

function pressureObserverCallback(updates) {
  console.log("cpu pressure state = " + updates[0].state);
  console.log("timestamp = " + updates[0].time);
}

// Create observer with 1s sample rate.
observer = new PressureObserver(pressureObserverCallback, { sampleRate: 1 });

// Start observer.
await observer.observe("cpu");

実装のmemo

各 state の具体的なCPU使用率については仕様上では規定されていません。そこで、Chromeが実際にどのように判断しているかコードを一応確認しておきます。

今のところ、Nominal (30%未満), Fair (60%未満), Serious(90%未満), Critical (100%以下) となっているようです。ただし、より高度なアルゴリズムの利用も検討されているようですね。

  // TODO(crbug.com/1342528): A more advanced algorithm that calculates
  // PressureState using PressureSample needs to be determined.
  // At this moment the algorithm is the simplest possible
  // with thresholds defining the state.
  mojom::PressureState state = mojom::PressureState::kN4ominal;
  if (sample.cpu_utilization < 0.3)
    state = mojom::PressureState::kNominal;
  else if (sample.cpu_utilization < 0.6)
    state = mojom::PressureState::kFair;
  else if (sample.cpu_utilization < 0.9)
    state = mojom::PressureState::kSerious;
  else if (sample.cpu_utilization <= 1.00)
    state = mojom::PressureState::kCritical;
  else
    NOTREACHED() << "unexpected value: " << sample.cpu_utilization;

(https://source.chromium.org/chromium/chromium/src/+/main:services/device/compute_pressure/platform_collector.cc)

IETFでeBPFの標準化の議論

先月行われたIETF 115において、eBPFの一部ドキュメントをIETFからRFCとして出すか？という議論が行われました。

まだ議論の段階で結論は出ていないが、簡単にメモとして残しておく。

なお、僕自身はKernel, eBPF方面に明るいわけではない...

eBPF サイドミーティング

IETFでは会期中に特定トピックについて議論するサイドミーティングが行われます。IETF 115において「eBPF standardization side meeting」が開催されました。

eBPF Foundationのほうからは、Dave Thaler氏らを中心にeBPF Steering Committeeから数名と、IETF参加者がサイドミーティングに出席したようです。

概要

eBPF Foundation は、eBPF クロスプラットフォーム ドキュメントをどこで公開するかについて検討しています。主な候補は次の4つです：

1. eBPF Foundation で発行
2. eBPF Foundation によって公開され、ISO 番号が割り当てられるように ISO へ提出
3. Independent Stream RFC として公開
4. IETF RFC として公開

特に4点目をメインにディスカッションされました。技術的な部分はIETFでは関与しない想定だが、標準化のフローなどが適合するかなどが議論されました。一方でIETF内ではどのエリアで取り扱うかについて意見が出ましたが、INTやROUTINGが候補として上がっていました。

また標準化団体からの公開する必要性については、特にハードウェアベンダーが実装のために標準化仕様を望んでることが話されていました。

現在のeBPFドキュメントの管理

議論の中では現在のドキュメント管理状況についても説明されまいた。

現在、eBPFドキュメントは、Kernelのツリーに配置されています。

eBPF FoudationのGithubミラーリポジトリもあるようです (URL)。

パッチとしてebpf MLに投げられて、そこからリポジトリにマージされます。

(引用: eBPF side meeting @ IETF 115 - YouTube )

標準化候補のドキュメント

eBPFのうち次のドキュメントがIETFでの標準化候補としてあげられていました。

• ISA
• ELF file format
• BPF type format
• Compiler expectations
• Verifier expectations
• Cross-platform map types
• Cross-platform program types

今後

引き続きさらなる議論が必要ということで、IETFにこの議論をするMLが出来ました。

subscribeはこちらから
Bpf Info Page

IETF116 Yokohamaをもっと楽しむために (その1) ~参加申し込み~

IETFではインターネットで使用されているプロトコルの標準化を行っています。TCPやHTTPの仕様がRFCという文書として公開されているのをご存知の方も多いでしょう。

そのIETFは、年3回オフラインのミーティングを実施しており、次回(2023年3月25日~) の開催地は横浜(Yokohama)となっております。

前回日本で開催されたのは2015年ですので、8年ぶりということになります。プロトコルの標準化の会議を実際に見る貴重な機会になるかとおもいますので、これを機会に参加しようと思われる方もいるでしょう。

そんな方のために、よりIETFを楽しむための幾つか記事を書いていこうかと思います。

• 1.「参加申し込み」
• 2.「予習/事前の議論のキャッチアップ」
• 3.「WG紹介, ホットトピック紹介」
• 4.「当日の流れ/会議の流れ」

特にIETFのミーティングは、メーリングリストや前回の会議の続きでディスカッションされることが多いですし、Draftの細部のディスカッションが多いため個人的には予習していったほうが良いかと思います。

何はともあれ、まずは参加申込みが必要です。今回は参加申し込みについて書いていきます。

その他ご質問あればお気軽にどうぞー

申込み

IETF 116の申込みは https://registration.ietf.org/116/ からすでに行うことが出来ます

2月6日までは Earliy Bird期間であり、お安く申し込みすることが出来ます(Week Passで700$)。期限が過ぎても割高ではありますが3月13日まで参加申し込みは出来ます。

IETFは1週間かけて行われ、チケットによって参加形態が異なります。

• Week Pass: 1週間の参加券
• One Day Pass: 1日参加券
• Studnet Pass: 学生用参加券
• Hackathon: 土日行われるハッカソン

申込みフォームの入力

申込みフォームについては、英語ですが悩むところは無いと思います。まずは、IETF用アカウントを作成して、個人情報の入力が必要です。

• "T-shirt"
  • 現地で貰えるTシャツです。サイズを申告しとくと良いでしょう。
• "How many IETF meetings have you attended?"
  • 初参加の場合は"this is my first"を選択すると良いでしょう。名札にNew Commerシールが付いてきます。これがあるとNew Comer限定の懇親会/ディナー会に参加できます。WGチェアなどとも話せる貴重な機会だと思います。
• attendees mailing list
  • 参加者向けのメーリングリストに登録されます。アジェンダ情報のアップデート、海外の方向けの旅行情報、遺失物の連絡などのやりとりがされます。また、全体懇親会 Social Event(有料) のチケット情報などが流れます。
• Policies
  • IETFの参加ポリシーになります。目を通していただくことになりますが... 特に大きく気をつけることはないかと思います

なお、支払いは基本的にはクレジットカードかPaypalとなってます。支払いが完了するとレシートが発行されます。

ハッカソン

IETF期間中(土日)にハッカソンが開催されます。参加には無料の申込みが必要です
(Week Passを購入しててもHackathon申込みをしてないと開催部屋に入れてくれません)

雰囲気としては、こんな感じで有志で集まってプロトコルの開発をしたりします。

(画像引用: https://www.ietf.org/blog/ietf114-hackathon/)

参考までに前回のIETF115の資料はここらへんです

• 開発テーマ一覧: IETF 115 Hackathon | IETF Community Wiki
• 発表スライド: https://github.com/IETF-Hackathon/ietf115-project-presentations

社会人向け

イベント参加フローが各社あると思いますので、それに準じて進める必要があります。

• 参加の社内申請 (参加目的の説明 + 予算確保)
• 参加費用 (+ 遠方の方は旅費) の稟議
  • 初参加者ディナー、全体懇親会は有料ですので、必要があれば合わせて費用申請する。
• 開催後にレポートの作成

参加については、ハッカソンに参加しない場合は月曜からで問題ないと思います。また、金曜はお昼でセッションが終わるので夕方の時間で移動は可能かと思います。

つづき

その2はこちら
asnokaze.hatenablog.com

Media over QUICの base draft について

IETFではQUICを使ってライブ映像などのメディアを転送するためのプロトコルの標準化を進めています。

MoQ (Media over QUIC) WGでは、今までユースケースや要件の整理を行ってきました。そうして、配信者からのアップロード(ingest) + 視聴者への配信 (distribution)をユースケースとして、メディアをQUIC上で配送するプロトコルの標準化を目指しています。

議論の中では、各社が独自に開発してきたプロトコルの紹介も行われました。

• Facebook: RUSH - Reliable (unreliable) streaming protocol
• Twitch: Warp - Segmented Live Media Transport (draft 01)
• Cisco: QuicR - Media Delivery Protocol over QUIC

先月行われたMoQ WGの中間会議では、各社の提案をもとに、メディアを転送するためのコモンプロトコルの設計について発表がありました。
(スライドpdf)

それが今回取り上げる、base draftと呼ばれるものです。

Base Draft

中間会議のあと、実際に提案仕様として提出されたのが「Warp - Segmented Live Media Transport (draft02)」です。プロトコルの名称は、Warpの名前を冠していますが中身はメディア転送用のcommon protocolになっています(参照: MLでの投稿)。先に上げたTwitch, Facebook(Meta), Ciscoの方の共著になっています。

ingestやdistributionなどの用途まではまだ設計されていませんが、その用途でもcommon protocolがベースになるものと思われます。

まだ、メディアを転送するための必要最低限を定義しただけで、設計のたたき台という意味が強そうです。

ざっくり次のような感じです

• WebTransportを用いた、一方向ストリーム
  • 拡張で双方向ストリームもサポート
• CDNなどのリレーサーバを意識した設計
  • 明示的な順序付け
  • 優先度
• セグメントとしてfragmented MP4を利用 (その他も使えるようにする)
• (HTTP DATAGRAMは拡張でサポート?)

( メディアエンコーディングする都合、ソフトウェアエンコーディング/ハードウェアエンコーディングを色々考慮されてそうだが、僕個人が詳しくないのでよく分からず... )

Base Draftのメッセージ

「Warp - Segmented Live Media Transport (draft02)」はまだたたき台で、必要最低限の部分しか定義されていませんが、ストリームの様子を見ていきます。

現在仕様では、ストリーム上でやり取りされるメッセージは次のようになっています。

各ストリームでは次のメッセージが送信されます

• HEADERS: セグメントを配送するためのメタデータ。優先度や依存関係を指定できる
• SEGMENT: fragmented MP4 (初期化フラグメントを持つか、それを持つ他のストリームに依存する必要がある)
• APP: 任意のデータ
• GOAWAY: 接続のGracefullシャットダウンを要求する (クライアントに接続し直させる)

HTTPではストリーム上でやり取りされるデータをフレームと読んでいましたが、メディアの用語との混乱を避けるため、ストリーム上でやり取りされるデータをメッセージと呼びます。

HEADERSメッセージ

セグメントを配送するためにHEADERSメッセージを送ります。これらの情報はリレーする際にも利用されます。

HEADERSは次のフィールドを持ちます。

• id: HEADERSメッセージの一意な識別子
• order: 配送順序を指定する整数値。この順番に配送されるように優先制御される。
• depends: セグメントのデコーディングに必要な依存関係を配列値として指定する。