オープンスクリーン・アプリケーション・プロトコル

1. 序論

Open Screen Application Protocol は、共有された視聴者向けに Web コンテンツを レンダリングできるデバイスへブラウザーを接続する。通常、これらは インターネット接続テレビ、HDMI ドングル、スマートスピーカーなどのデバイスである。

Open Screen Application Protocol は、ブラウザーとデバイス間のさまざまな 接続技術によってサポートされることを意図している。ブラウザーとデバイスが互いを 発見し認証できるようにするための特定の要件があるが、これらの要件は複数の可能な実装によって 満たされてもよい。相互運用性を最大化するため、ブラウザーとデバイスは Open Screen Network Protocol をサポートするべきであり、これはブラウザーとデバイスが ローカルエリアネットワーク上で互いを発見し、接続し、認証するための方法を提供する。

Open Screen Application Protocol は、ブラウザーが URL を提示し、HTML の media element のリモート再生を開始し、メディア データを別のデバイスへストリーミングできるようにする。

Open Screen Application Protocol は拡張可能であることを意図しており、 追加の機能を時間とともに追加できる。これには、既存の Web API への追加や 新しい Web API が含まれ得る。

付随する 解説は、 このプロトコルに関するさらなる背景を提供する。

1.1. 用語

Open Screen Protocol agent（または OSP agent）とは、このプロトコルの任意の実装（ブラウザー、 ディスプレイ、スピーカー、またはその他のソフトウェア）である。

一部の OSP agent は Presentation API をサポートする。この API により、controlling user agent は Web コンテンツの提示を 別のデバイス上で開始できる。簡潔に、この agent を controller と呼ぶ。 receiving user agent は Web コンテンツをレンダリングする責任を持ち、これを 簡潔に receiver と呼ぶ。Web コンテンツ自体は presentation と呼ばれる。

一部の OSP agent は Remote Playback API もサポートする。その API により、agent は media element を remote playback device 上にレンダリングできる。この文書では、提示と リモート再生の間で用語を一貫させ、短くするため、これを receiver と呼ぶ。同様に、リモート再生を開始、終了、制御する agent を指すために controller という用語を用いる。

メディアストリーミングについては、メディアストリームを送信する OSP agent を media sender と呼び、メディアストリームを受信する agent を media receiver と呼ぶ。なお、 agent は media sender と media receiver の両方であり得る。

Presentation API または Remote Playback API に固有の追加の用語および慣用表現については、 それぞれの仕様を参照されたい。

2. 要件

2.1. Agent 発見要件

発見要件を定義する [Issue #342]

2.2. トランスポート層要件

トランスポート層要件を定義する [Issue #342]

2.3. Presentation API 要件

1. controller は、 receiver が特定の presentation request URL をレンダリングする能力を 合理的に有しているかどうかを判定できなければならない。

2. controller は、presentation request URL と presentation identifier が与えられたとき、 receiver 上で新しい presentation を開始できなければならない。

3. controller は、receiver 上の既存の presentation に対して、その presentation request URL と presentation identifier が与えられたとき、新しい PresentationConnection を作成できなければならない。

4. controller と presentation の間の PresentationConnection を閉じ、接続が閉じられた理由を両当事者へ通知できなければならない。

5. 複数の controller が単一の presentation に同時に接続できなければならない。

6. controller により送信されたメッセージは、presentation（またはその逆）へ 信頼性があり、順序どおりに配信されなければならない。

7. メッセージを配信できない場合、controller は receiver（またはその逆）に対して、 理由 error で接続を閉じるべきであることを通知できなければならない。

8. controller と presentation は DOMString メッセージ（ECMAScript では string 型として表される）を送受信できなければならない。

9. controller と presentation はバイナリ メッセージ（HTML5 では Blob オブジェクト、または ECMAScript では ArrayBuffer または ArrayBufferView 型として表される）を送受信できなければならない。

10. controller は、その presentation request URL と presentation identifier が与えられたとき、 presentation を終了するよう receiver に通知できなければならない。

11. receiver は、presentation が終了したとき、接続されているすべての controller に通知できなければならない。

2.4. Remote Playback API 要件

1. controller は、与えられた HTMLMediaElement について、互換性のある receiver が少なくとも 1 つ存在するかどうかを、 即時にも継続的にも知ることができなければならない。

2. controller は、互換性のある receiver に対して HTMLMediaElement の リモート再生を開始できなければならない。

3. controller は、HTMLMediaElement からのメディアソースを URL として、およびテキスト トラックを、互換性のある receiver へ送信できなければならない。

4. controller は、HTMLMediaElement からのメディアデータを、互換性のある receiver へ送信できなければならない。

5. リモート再生中、controller と remote playback device は、 HTMLMediaElement の media element state を同期できなければならない。

6. リモート再生中、controller または receiver のいずれかは、 相手方から切断できなければならない。

7. controller は、リモート再生中のテキストのレンダリングを支援するため、 locale およびテキスト方向の情報を receiver に渡せるべきである。

2.5. 非機能要件

1. 低価格のスマートフォン、スマート TV、ストリーミングデバイスに見られるものと同様の 控えめなハードウェア要件を用いて OSP agent を実装できるべきである。agent のハードウェア仕様については Device Specifications 文書を参照されたい。

2. プロトコル操作が失敗したとき、agent はユーザーに分かりやすい情報を提示するべきである。 たとえば、controller が presentation を開始できない場合、それがネットワークエラー、 認証エラー、または presentation コンテンツの読み込み失敗であったかを controller インターフェイスで報告できるべきである。

3. agent 間のメッセージ遅延は、対話的な利用を可能にするため最小化されるべきである。 たとえば、ある agent のフォームに入力したテキストが presentation にリアルタイムで 表示されることが快適であるべきである。ゲームやマウス利用におけるリアルタイム遅延は理想的だが、 要件ではない。

4. presentation またはリモート再生を開始する controller は、receiver がその locale で コンテンツをレンダリングできるよう、自身の優先 locale を receiver に伝えるべきである。

5. 基本 API の実験および強化を促進するため、仕様で明示的に定義されていない任意機能により アプリケーションプロトコルを拡張できるべきである。

3. メタデータ発見

さらなるメタデータを知るため、agent は agent-info-request メッセージを送信し、 agent-info-response メッセージを受信してもよい。任意の agent は、別のデバイスの状態と能力について知るため、 いつでもこの要求を送信してよく、それらは agent-info-response 内の agent-info メッセージによって記述される。

agent が自身の agent-info メッセージ内のいずれかの情報を変更した場合、 新しい agent-info を含む agent-info-event メッセージを、他のすべての接続済み agent へ （agent-info-request を待たずに） 送信するべきである。

agent-info メッセージは、次のフィールドを含む。

display-name (required)

agent の表示名。requester によりユーザーへ表示されることを意図している。 requester は、responder が認証されていない場合、または表示名が変更された場合、 UI を通してそれを示すべきである。

model-name (optional)

agent がハードウェアデバイスである場合、そのデバイスのモデル名。 これは主にデバッグ目的で使用されるが、requesting agent のユーザーへ 表示されてもよい。

capabilities (required)

agent がサポートする制御プロトコル、役割、メディア型。 存在は能力を示し、不在は能力の欠如を示す。 capabilities は、音声、映像、またはその両方を受信するかに応じて 異なるアイコンを描画するなど、agent がユーザーへどのように提示されるかに 影響するべきである。

state-token (required)

[0-9A-Za-z] の範囲の 8 文字からなるランダムな英数字値。 この値は agent が最初の接続を行う前に設定され、agent がリセットされた場合、またはこのプロトコルに関連する すべての状態を失った場合には新しい値に設定されなければならない。

locales (required)

localized content の表示に対する agent の優先 locales。ユーザーの優先順に並ぶ。 各項目は RFC5646 language tag である。

各種 capabilities は次の意味を持つ。

receive-audio

agent は、サポートする他のプロトコルを介して音声をレンダリングできる。それら他の プロトコルは、ストリーミングプロトコルにおける特定の音声コーデックのサポートなど、 より具体的な能力を報告してもよい。

receive-video

agent は、サポートする他のプロトコルを介して映像を受信できる。それら他の プロトコルは、ストリーミングプロトコルにおける特定の映像コーデックのサポートなど、 より具体的な能力を報告してもよい。

receive-presentation

agent は presentation protocol を用いて presentations を受信できる。

control-presentation

agent は presentation protocol を用いて presentations を制御できる。

receive-remote-playback

agent は remote playback protocol を用いてリモート再生を受信できる。

control-remote-playback

agent は remote playback protocol を用いてリモート再生を制御できる。

receive-streaming

agent は streaming protocol を用いてストリーミングを受信できる。

send-streaming

agent は streaming protocol を用いてストリーミングを送信できる。

NOTE: 既知のすべての capabilities（この仕様で定義されるもの、および § 10 Protocol Extensions を通じたもの）の一覧については Capabilities Registry を参照されたい。

QUIC に依存しないよう書き直すか、 agent-status messages を network spec へ移動する [Issue #343]

listening agent が advertising agent からメッセージを受信したい場合、または advertising agent が listening agent へメッセージを送信したい場合、QUIC 接続を維持したいことがある。 どちらの側もメッセージの送受信の目的で接続を維持する必要がなくなったなら、接続は エラーコード 5139 で閉じられるべきである。QUIC 接続を維持するため、agent は agent-status-request メッセージを送信してもよく、 agent-status-request メッセージを受信した任意の agent は agent-status-response メッセージを送信するべきである。そのような メッセージは、QUIC idle_timeout transport parameter より高い頻度で送信されるべきであり（QUIC の Transport Parameter Encoding を参照）、 QUIC PING frames は使用されるべきではない。idle_timeout transport parameter は 25 秒が推奨される。 agent は、QUIC stream 上でメッセージが送信されるたびに idle_timeout より短いタイマーがリセットされるかのように 振る舞うべきである。タイマーが期限切れになった場合、 agent-status-request メッセージが送信されるべきである。

listening agent が advertising agent へメッセージを送信したい場合、 listening agent は advertising agent へ「オンデマンド」で接続できる。接続を維持する必要はない。

OSP agent がネットワーク接続を一時停止する場合（例: 省電力のため）、 ネットワーク接続が復元されたら、それ以前に接続していた OSP agent への QUIC 接続の再開を試みるべきである。 再接続したら、それらの agent へ agent-status-request メッセージを送信するべきである。

agent-info および agent-status-response メッセージは、 § 10.1 Protocol Extension Fields で説明されるように、 この仕様で定義されていない追加情報を含むよう拡張されてもよい。

4. CBOR を用いるメッセージ配信

QUIC に依存しないよう書き直す [Issue #343]

メッセージは CBOR を用いてシリアライズされる。 メッセージのグループを順序どおりに送信するには、そのメッセージのグループは 1 つの QUIC stream で送信されなければならない。 独立したメッセージグループ（グループ間の順序依存性がないもの）は、異なる QUIC streams で送信されるべきである。 複数の CBOR シリアライズ済みメッセージを同じ QUIC stream に入れるため、次が使用される。

各メッセージについて、OSP agent は単方向 QUIC stream に 次を 書き込まなければならない。

1. メッセージの型を表す type key。variable-length integer としてエンコードされる （type keys については Appendix A: Messages を参照）

2. CBOR としてエンコードされたメッセージ。

agent が認識しない type key のメッセージを受信した場合、agent は application error code 404 で QUIC 接続を閉じなければならず、CONNECTION_CLOSE frame の reason phrase に未知の type key を含めるべきである。

variable-length integers は、QUIC で使用される Variable-Length Integer Encoding によりエンコードされる。

多くのメッセージは request および response であるため、それらに共通の形式を定義する。 request と response は、requester により選択される符号なし整数である request ID を含む。 response は、関連付けられている request の request ID を含まなければならない。

4.1. Type Key の後方互換性

メッセージが時間とともに変更または拡張される際、古いバージョンのメッセージを理解する agent との 後方互換性を維持するため、特定の規則に従わなければならない。

1. 必須フィールドがメッセージに追加される、またはメッセージから削除される場合 （メッセージに直接、またはフィールドのフィールドを通じて間接的に）、新しい type key がそのメッセージに割り当てられなければならない。これは実質的に新しいメッセージであり、 受信 agent が新しい type key を理解していることが分かっている場合を除き、 送信されてはならない。

2. 任意フィールドがメッセージに追加される場合（メッセージに直接、または フィールドのフィールドを通じて間接的に）、追加されたフィールドを理解しない古い受信 agent の 振る舞いが、そのフィールドを含める新しい送信 agent と互換であるなら、 type key は変更されなくてもよい。 そうでない場合、新しい type key が割り当てられなければならない。

3. 任意フィールドがメッセージから削除される場合（メッセージから直接、または フィールドのフィールドを通じて間接的に）、削除されたフィールドを理解しない新しい受信 agent の 振る舞いが、そのフィールドを含める古い送信 agent と互換であるなら、 type key は変更されなくてもよい。 そうでない場合、新しい type key が割り当てられなければならない。

4. audio-frame などの array-based messages には、必須フィールドを追加または削除してはならない。

5. Presentation Protocol

この節は、Presentation API により定義される presentations の開始、終了、および制御のための Open Screen Protocol の利用を定義する。 § 5.1 Presentation API は、 Presentation API 内の API が この節で定義されるプロトコルメッセージにどのように対応するかを定義する。

特定の presentation request URL または URL の集合について、どの receivers が available presentation displays であるかを知るため、 controller は次の値を持つ presentation-url-availability-request メッセージを送信してもよい。

urls

presentation URLs のリスト。空であってはならない。

watch-duration

可用性が変化した場合に、その URL についての更新を controller が受け取りたい期間。

watch-id

URL 可用性に関する更新を送信するとき receiver が使用しなければならない識別子。 これにより controller は receiver がどの URL を参照しているかを知る。

応答として、receiver は次の値を持つ presentation-url-availability-response メッセージを 1 つ送信するべきである。

url-availabilities

URL availability states のリスト。各 state は、request 内の一致する URL に リストインデックスで対応しなければならない。

watch が有効である間（watch-duration が期限切れになっていない間）、receivers は URL availabilities が変化したとき presentation-url-availability-event メッセージを送信するべきである。 そのような event は次の値を含む。

watch-id

presentation-url-availability-response で与えられた watch-id。 可用性が変化した presentation URLs を参照するために使用される。

url-availabilities

URL availability states のリスト。各 state は、watch-id により参照される request の URL に対応しなければならない。

これらのメッセージはすべての controller にブロードキャストされないことに注意されたい。 これらは、元の availability request の watch duration 内で availability state が変化した URL について availability を要求した controller に個別に送信される。

省電力を transport requirement として追加し、次を削除する。 [Issue #342]

電力を節約するため、controller は QUIC 接続を切断し、後で再接続して availability requests を送信し、 availability responses および updates を受信してもよい。再接続時に QUIC connection ID が 同じである場合も、そうでない場合もある。

presentation を開始するため、controller は次の値を持つ presentation-start-request メッセージを receiver に送信してもよい。

presentation-id

presentation identifier

url

選択された presentation URL

headers

presentation URL を取得するために receiver が使用するべき headers。たとえば、 Presentation API の section 6.6.1 は、HTTP Accept-Language header が 提供されるべきであると述べている。

presentation identifier は Presentation API の section 6.1 によって定義される制限に従わなければならず、 少なくとも 16 個の ASCII 文字で構成されなければならない。

receiver が presentation-start-request を受信したとき、 presentation URL が取得され読み込まれた後、または receiver がそうすることに失敗した後に、 presentation-start-response メッセージを送り返すべきである。 失敗した場合、適切な result（invalid-url や timeout など）で応答しなければならない。 成功した場合、success result で応答しなければならない。

さらに、response は次を含まなければならない。

connection-id

両 agent が互いに connection messages を送信するために使用できる ID。 実装を容易にするため receiver により選択される。message receiver が connection-id を選択する場合、 接続間で ID を一意に保てるため、message demuxing/routing が容易になる。

response は次を含むべきである。

http-response-code

presentation URL の取得から返された数値の HTTP response code（リダイレクト後）。

presentation message を送信するため、controller または receiver は次の値を持つ presentation-connection-message を送信してもよい。

connection-id

presentation-start-response または presentation-connection-open-response messages からの ID。

message

presentation message data。

次の NOTE を任意の message transport の transport requirement として書き直す。 [Issue #342]

NOTE: OSP agent は、厳密に必要なもの（すなわち CBOR serialization）を超えて 送受信されるメッセージの buffering および processing を最小化するべきである。Message payloads はリアルタイムデータとして扱われるべきであり、それらは agent 間での media streams の playback の同期や、その他の低遅延ユースケースに用いられ得る。 [ITU-R-BT.1359-1] で推奨される同期しきい値は、media playback 中の有効な lip sync を可能にするため、 agent 間の総 processing latency（serialization、buffering、network latency を含む）が 45 ms 以下でなければならないことを示唆している。

presentation を終了するため、controller は次の値を持つ presentation-termination-request メッセージを送信してもよい。

presentation-id

終了する presentation の ID。

reason

application が終了を要求した場合は application-request に、 user が終了を要求した場合は user-request に設定する。 （これらは presentation-termination-request 内の reason に対する唯一の有効値である。）

receiver が presentation-termination-request を受信したとき、要求元の controller へ presentation-termination-response メッセージを 送り返すべきである。

また、presentation-termination-event メッセージを送信することにより、 他の controller に終了を通知するべきである。また、controller からの要求なしに presentation を終了する場合にも 同じメッセージを送信できる。このメッセージは次の値を含む。

presentation-id

終了された presentation の ID。

source

終了が presentation-termination-request に応答したものである場合は controller に設定し、そうでない場合は receiver に設定する。

reason

presentation が終了された詳細な理由。

controller からの incoming connection requests を受け入れるため、receiver は次の値を含む presentation-connection-open-request メッセージを受信し、 処理しなければならない。

presentation-id

接続する presentation の ID。

url

接続する presentation の URL。

receiver は、 presentation-connection-open-request メッセージを受信したら、 次の値を含む presentation-connection-open-response メッセージを 送り返すべきである。

result

成功または失敗、および失敗の理由を示す code

connection-id

両 agent が互いに connection messages を送信するために使用できる ID。 実装を容易にするため receiver により選択される （message receiver が connection-id を選択する場合、接続間で ID を一意に保てるため、 message demuxing/routing が容易になる）。

connection-count

incoming connection request を受信した presentation への open connections の新しい数。

presentation-connection-open-response メッセージが成功を示す場合、 receiver は、その presentation への active presentation connection を持つ他のすべての endpoints に対して、 次の値を持つ presentation-change-event も送信するべきである。

presentation-id

新しい presentation connection を受信した presentation の ID。

connection-count

その presentation への open connections の新しい合計数。

controller は、次の値を持つ presentation-connection-close-event メッセージを receiver へ送信することにより、 presentation を終了せずに connection を閉じてもよい。

connection-id

閉じられた connection の ID。

reason

close-method-called または connection-object-discarded に設定する。

receiver も、presentation を終了せずに connection を閉じてもよい。そうする場合、 次の値を持つ presentation-connection-close-event メッセージを controller へ送信するべきである。

connection-id

閉じられた connection の ID。

reason

close-method-called または connection-object-discarded に設定する。

connection-count

残っている open presentation connections の数。

receiver が（任意の理由で）presentation connection を閉じる場合、その presentation への open connection を持つ他のすべての controllers に対して、次の値を持つ presentation-change-event を送信するべきである。

presentation-id

connection を閉じたばかりの presentation の ID。

connection-count

残っている open presentation connections の数。

Note: agent が presentation connection を閉じる場合、それは常に成功するため、 request および response messages は不要である。presentation の終了要求は成功または失敗し得るため、 response message が必要である。

5.1. Presentation API

Open Screen Protocol agent のうち、 Presentation API の controlling user agent であるものは、 control-presentation capability をサポートしなければならない。 OSP agent のうち、 Presentation API の receiving user agent であるものは、 receive-presentation capability をサポートしなければならない。 同じ OSP agent が controlling user agent かつ receiving user agent であってもよい。

これは、Presentation API が § 5 Presentation Protocol をどのように使用するかを示す。

section 6.4.2 が「This list of presentation displays ... is populated based on an implementation specific discovery mechanism」と述べるとき、 controller は receiver を発見するために、この仕様で前に定義された mDNS、QUIC、agent-info-request、および presentation-url-availability-request メッセージを 使用してもよい。

section 6.4.2 が「To further save power, ... implementation specific discovery of presentation displays can be resumed or suspended.」と述べるとき、agent は前節で定義された 省電力機構を使用してもよい。

section 6.3.4 が「Using an implementation specific mechanism, tell U to create a receiving browsing context with D, presentationUrl, and I as parameters.」と述べるとき、U（controller）は D （receiver）へ presentation-start-request メッセージを送信してもよく、 I は presentation identifier に、presentationUrl は選択された presentation URL に対応する。

section 6.3.5 が 「establish a presentation connection with newConnection」と述べるとき、 U を newConnection の presentationURL とし、I を newConnection. の presentation identifier とする。agent は、U を url に、 I を presentation-id にして presentation-connection-open-request メッセージを送信するべきである。

section 6.5.2 が「Using an implementation specific mechanism, transmit the contents of messageOrData as the presentation message data and messageType as the presentation message type to the destination browsing context」と述べるとき、 controller は messageOrData を presentation message data として presentation-connection-message を送信してもよい。 messageType は encoded CBOR type に埋め込まれており、message に追加の値を必要としないことに注意されたい。

section 6.5.5 が「Start to signal to the destination browsing context the intention to close the corresponding PresentationConnection」と述べるとき、agent は destination browsing context とともに presentation-connection-close-event メッセージを相手の agent へ送信してもよく、必要な場合には presentation-change-event を送信してもよい。

section 6.5.6 が「Send a termination request for the presentation to its receiving user agent using an implementation specific mechanism」と述べるとき、controller は reason を application-request として presentation-termination-request メッセージを receiver へ 送信してもよい。

section 6.7.1 が「it MUST listen to and accept incoming connection requests from a controlling browsing context using an implementation specific mechanism」と述べるとき、receiver は presentation-connection-open-request を受信し処理しなければならない。

section 6.7.1 が「Establish the connection between the controlling and receiving browsing contexts using an implementation specific mechanism.」と述べるとき、receiver は presentation-connection-open-response メッセージと、 必要な場合には presentation-change-event メッセージを送信しなければならない。

6. 時刻の表現

§ 7 Remote Playback Protocol および § 8 Streaming Protocol は、 time scale の観点から時点および duration を表現する。 time scale とは、精度を失うことなく値を有理数として表現できるようにする、 time values の共通分母である。time scale は、video で一般的な time scale である 90000 Hz に対する 90000 のように、hertz で表される。

7. リモート再生プロトコル

この節は、 Remote Playback API により定義されるメディアのリモート再生を開始、終了、 および制御するための Open Screen Protocol の使用を定義する。 § 7.2 Remote Playback API は、 Remote Playback API 内の API が、この節で定義されるプロトコルメッセージに どのように対応するかを定義する。

この節で定義されるすべてのメッセージについて、完全な CDDL 定義は Appendix A: Messages を参照されたい。

特定の URL または URL の集合について、どの receiver が compatible remote playback devices であるかを知るため、 controller は、次の値を持つ remote-playback-availability-request メッセージを送信してもよい。

sources

media resources のリスト。 remote-playback-start-request メッセージで指定されるものと同じである。 空であってはならない。

headers

receiver が urls を取得するために使用するべき headers。たとえば、 Remote Playback API の section 6.2.4 は、Accept-Language header が 提供されるべきであると述べている。

watch-duration

可用性が変化した場合に、controller がその URL に関する更新を受け取りたい期間。

watch-id

URL の可用性に関する更新を送信するとき、receiver が使用しなければならない識別子。 これにより、controller は receiver がどの URL を参照しているかを知る。

応答として、receiver は次の値を持つ remote-playback-availability-response メッセージを送信するべきである。

url-availabilities

URL availability states のリスト。各 state は、request 内の対応する URL に リストインデックスで対応しなければならない。

receivers はその後（現在時刻に request の watch-duration を加えた時点まで）、URL availabilities が変化した場合に remote-playback-availability-event メッセージを送信するべきである。 そのような event は次の値を含む。

watch-id

remote-playback-availability-response で与えられた watch-id。 可用性が変化した remote playback URLs を参照するために使用される。

url-availabilities

URL availability states のリスト。各 state は、watch-id により参照される request の URL に対応しなければならない。

これらのメッセージはすべての controller にブロードキャストされないことに注意されたい。 これらは、元の availability request の watch duration 内で availability state が変化した URL について availability を要求した controller に個別に送信される。

省電力を transport requirement として追加し、次を削除する。 [Issue #342]

電力を節約するため、controller は QUIC 接続を切断し、 後で再接続して availability requests を送信し、availability responses および updates を受信してもよい。再接続時の QUIC connection ID は 同じであっても、同じでなくてもよい。

リモート再生を開始するため、controller は次の値を持つ remote-playback-start-request メッセージを receiver に 送信してもよい。

remote-playback-id

このリモート再生の識別子。すべてのリモート再生の間で グローバルに一意であるべきである。

Note: version 4（疑似乱数）UUID は remote-playback-id の要件を満たすため、推奨される。

sources (optional)

controller が receiver 上での再生のために選択した media resources。各 source は source URL を含まなければならず、 media resource について利用可能な場合は extended MIME type を含むべきである。sources が欠落しているか空である場合、 controller は streaming session を用いて encoded media を送信するため、 remoting フィールドが設定されなければならない。

text-track-urls

media resources に関連付けられた text tracks の URL。

controls

リモート再生の初期状態を変更するための初期 controls。 § 7.1 Remote Playback State and Controls で定義される。controller は、receiver がそれらをサポートするかを知る前に、 receiver がサポートすることが任意である controls を送信してもよい。 receiver がそれらをサポートしない場合、それらを無視し、controller は remote-playback-start-response メッセージから receiver がそれらをサポートしないことを知る。

remoting (optional)

このリモート再生に関連付けられた streaming session を開始するための parameters。 含まれない場合、streaming session は開始されない。 sources が欠落しているか空である場合に必須である。

receiver が remote-playback-start-request メッセージを受信したとき、 remote-playback-start-response メッセージを送り返すべきである。 通常は media resource が読み込まれる前にすばやくそうするべきであり、 代わりに remote-playback-state-event メッセージで読み込みの進行状況の更新を与える。 ただし、receiver が resource の読み込みをまったく試みないと決定した場合を除く。 試みないことを選んだ場合、適切な failure result（timeout または invalid-url など）で 応答しなければならない。さらに、response は次を含まなければならない。

state

§ 7.1 Remote Playback State and Controls で定義される、リモート再生の初期状態。

remoting (optional)

このリモート再生に関連付けられて開始された streaming session への response。 含まれない場合、streaming session は開始されない。

streaming session が開始された場合、 streaming-session-modify-request や video-frame などの streaming messages は、 streaming session が streaming-session-start-request および streaming-session-start-response で開始されたかのように、 その streaming session に対して使用できる。streaming session は remote playback が終了される前に終了されてもよいが、remote playback が先に 終了された場合、それに関連付けられた streaming session は自動的に終了される。

controller がリモート再生の状態を変更したい場合（たとえば pause、resume、skip など）、 次の値を持つ remote-playback-modify-request メッセージを送信してもよい。

remote-playback-id

変更するリモート再生の ID。

controls

§ 7.1 Remote Playback State and Controls で定義される、更新された controls。

receiver が remote-playback-modify-request を受信したとき、 応答として次の値を持つ remote-playback-modify-response メッセージを送信するべきである。

state

§ 7.1 Remote Playback State and Controls で定義される、リモート再生の更新された状態。

controller からの変更要求なしに remote playback の状態が変化した場合 （たとえば、receiver 上での user interaction により skips または pauses した場合）、 receiver は remote-playback-state-event を controller に送信してもよい。

receiver は、次の場合には常に remote-playback-state-event メッセージを送信するべきである。

次のいずれかの methods が呼び出された場合:

• HTMLMediaElement.fastSeek()

• HTMLMediaElement.pause()

• HTMLMediaElement.play()

最後に送信された remote-playback-state-event メッセージ以降、次のいずれかの attributes が観測可能に変化した場合:

• HTMLMediaElement.currentSrc

• HTMLMediaElement.networkState

• HTMLMediaElement.readyState

• HTMLMediaElement.error

• HTMLMediaElement.duration

• HTMLMediaElement.buffered

• HTMLMediaElement.seekable

• HTMLMediaElement.playbackRate

• HTMLMediaElement.paused

• HTMLMediaElement.seeking

• HTMLMediaElement.ended

• HTMLMediaElement.volume

• HTMLMediaElement.muted

• HTMLMediaElement.audioTracks

• HTMLMediaElement.videoTracks

• HTMLMediaElement.textTracks

• HTMLVideoElement.videoWidth

• HTMLVideoElement.videoHeight

playback に関連付けられた timeline offset が、最後に送信された remote-playback-state-event メッセージ以降に変化した場合:

関連付けられた HTMLMediaElement インスタンスで stalled event を発火する必要がある場合。

最後の remote-playback-state-event メッセージから 250ms を超えて経過し、かつ次のいずれかの attributes が、最後の remote-playback-state-event メッセージ以降に観測可能に変化した場合。 新しい連続的に変化する attributes はすべてこの規則に該当する。

• HTMLMediaElement.played

• HTMLMediaElement.currentTime

NOTE: media element は、250ms ごとまたはそれより早く timeupdate event を発火することが要求される。

remote-playback-id

状態が変化した remote playback の ID。

state

§ 7.1 Remote Playback State and Controls で定義される、remote playback の更新された状態。

remote playback を終了するため、controller は次の値を持つ remote-playback-termination-request メッセージを送信してもよい。

remote-playback-id

終了する remote playback の ID。

reason

remote playback が終了される理由。

receiver が remote-playback-termination-request を受信したとき、 controller へ remote-playback-termination-response メッセージを 送り返すべきである。

receiver が controller からの要求なしに remote playback を終了する場合、 次の値を持つ remote-playback-termination-event メッセージを controller へ送信しなければならない。

remote-playback-id

終了された remote playback の ID。

reason

remote playback が終了された理由。

Remote Playback API section 6.2.7 で述べられているように、remote playback を終了するとは、controller が もはや remote playback を制御しないことを意味し、receiver 上での media のレンダリングを 必ずしも停止するものではない。receiver が media のレンダリングを停止するかどうかは、 receiver の実装に依存する。

7.1. リモート再生の状態と制御

remote playback の状態に関して controller と receiver が同期した状態を保つため、 controller は state を変更する controls を送信してもよく （たとえば remote-playback-modify-request メッセージを介して）、 receiver は state changes に関する更新を送信してもよい （たとえば remote-playback-state-event メッセージを介して）。

controller により送信される controls は、次の個別の control values を含み、それぞれ任意である。これにより controller は、 毎回すべての control values を指定することなく、1 つまたは多数の control values を一度に変更できる。存在しない control value は変更がないことを示す。 存在する control value は、下で定義される変更を示す。これらの controls は、 HTMLMediaElement の設定可能な attributes および methods を意図的に反映している。

source

media resource を変更する。詳細は HTMLMediaElement.src を参照されたい。 remote-playback-start-request メッセージの初期 controls では 使用してはならない（これはすでに media resource を含む）。

preload

media をどの程度積極的に preload するかを設定する。詳細は HTMLMediaElement.preload を参照されたい。 remote-playback-start-request メッセージの初期 controls、または source が変更されるときにのみ使用されるべきである。 初期 controls で設定されない場合、それは receiver の判断に委ねられる。 これは receiver がサポートすることが任意であり、サポートされない場合、receiver は それがまったく設定されなかったかのように振る舞う。

loop

media を loop するかどうかを設定する。詳細は HTMLMediaElement.loop を参照されたい。 remote-playback-start-request の初期 control でのみ 使用されるべきである。初期 controls で設定されない場合、false と仮定される。

paused

true の場合は pause、false の場合は resume する。詳細は HTMLMediaElement.pause() および HTMLMediaElement.play() を参照されたい。初期 controls で設定されない場合、それは receiver の判断に委ねられる。

muted

true の場合は mute、false の場合は unmute する。詳細は HTMLMediaElement.muted を参照されたい。初期 controls で設定されない場合、それは receiver の判断に委ねられる。

volume

audio volume を 0.0 から 1.0 までの包括範囲に設定する。詳細は HTMLMediaElement.volume を参照されたい。初期 controls で設定されない場合、それは receiver の判断に委ねられる。

seek

正確な時刻へ seek する。詳細は HTMLMediaElement.currentTime を参照されたい。

fast-seek

可能な限り高速に近似的な時刻へ seek する。詳細は HTMLMediaElement.fastSeek() を参照されたい。

playback-rate

media が再生される rate を設定する。詳細は HTMLMediaElement.playbackRate を参照されたい。初期 controls で設定されない場合、それは receiver の判断に委ねられる。 これは receiver がサポートすることが任意であり、サポートされない場合、receiver は それがまったく設定されなかったかのように振る舞う。

poster

video data が利用できないときに表示する画像の URL を設定する。詳細は poster frame を参照されたい。初期 controls で設定されない場合、poster は使用されず、 receiver は video data が利用できないときに何をレンダリングするかを選択できる。 これは receiver がサポートすることが任意であり、サポートされない場合、receiver は それがまったく設定されなかったかのように振る舞う。

enabled-audio-track-ids

含まれる audio tracks を ID により有効化し、他のすべての audio tracks を無効化する。詳細は HTMLMediaElement.audioTracks を参照されたい。

selected-video-track-id

指定された video track を ID により選択し、他のすべての video tracks を選択解除する。詳細は HTMLMediaElement.videoTracks を参照されたい。

added-text-tracks

指定された kinds、labels、および languages を持つ text tracks を追加する。詳細は HTMLMediaElement.addTextTrack() を参照されたい。これは receiver がサポートすることが任意であり、サポートされない場合、 receiver はそれがまったく設定されなかったかのように振る舞う。

changed-text-tracks

ID により text tracks を変更する。他のすべての text tracks は変更されない。 mode を設定し、cues を追加し、id により cues を削除する。詳細は HTMLMediaElement.textTracks を参照されたい。将来の仕様またはこの仕様への extensions は、 text-track-cue に新しい fields （text size、alignment、position など）を追加することが期待されることに注意されたい。 cues の追加および削除は receiver がサポートすることが任意であり、サポートされない場合、 receiver は cues が追加も削除もされなかったかのように振る舞う （追加と削除の両方は "added-cues" のサポートによって示される）。 HTMLMediaElement.textTracks で指定されているように、cue ID が無効である場合 （追加されていない ID を削除する、または同じ ID を 2 回追加するなど）、 receiver は text track change を拒否してもよい。

receiver により送信される states は、次の個別の state values を含み、 それぞれ任意である。これにより receiver は、毎回すべての state values を指定することなく、複数の state value について controller を一度に更新できる。 存在しない state value は、その state が変化していないことを示す。

supports

receiver がサポートする controls。これらは media resource に応じて異なってもよく、 media resource も変化しない限り変化するべきではない。 remote-playback-start-response メッセージ内の初期 state では、 default は空（何もサポートしない）である。

source

現在の media resource。参照: HTMLMediaElement.currentSrc。 controller がどの media resource が playback 用に選択されたかを知るため、 remote-playback-start-response メッセージ内の初期 state に 存在しなければならない。

loading

media resource の読み込みに対する network activity の状態。参照: HTMLMediaElement.networkState。 remote-playback-start-response メッセージ内の初期 state では、 default は empty（NETWORK_EMPTY） である。

loaded

読み込まれた media の状態（再生に十分な量が読み込まれているかどうか）。参照: HTMLMediaElement.readyState。 remote-playback-start-response メッセージ内の初期 state では、 default は nothing（HAVE_NOTHING） である。

error

remote playback の継続を妨げる重大な error が発生した。参照: HTMLMediaElement.error および media error codes。 remote-playback-start-response メッセージ内の初期 state では、 default は no error である。

epoch

media timeline の "zero time"。epoch からのミリ秒で表される。 timeline offset および HTMLMediaElement.getStartDate() を参照されたい。 remote-playback-start-response メッセージ内の初期 state では、 default は unknown epoch であり、null によって表される。

duration

media timeline の duration。秒で表される。参照: HTMLMediaElement.duration。 remote-playback-start-response メッセージ内の初期 state では、 default は unknown duration であり、null によって表される。

buffered-time-ranges

media が buffered された time ranges。参照: HTMLMediaElement.buffered。 remote-playback-start-response メッセージ内の初期 state では、 default は empty array である。

played-time-ranges

通常再生中に playback position が到達した time ranges。参照: HTMLMediaElement.played。 remote-playback-start-response メッセージ内の初期 state では、 default は empty array である。

seekable-time-ranges

controller または receiver により media が seek 可能な time ranges。参照: HTMLMediaElement.seekable。 remote-playback-start-response メッセージ内の初期 state では、 default は empty array である。

position

playback position。参照: official playback position および HTMLMediaElement.currentTime。 remote-playback-start-response メッセージ内の初期 state では、 default は 0 である。

playbackRate

1.0 が「通常速度」である scale 上の現在の playback rate。参照: HTMLMediaElement.playbackRate。 remote-playback-start-response メッセージ内の初期 state では、 default は 1.0 である。

paused

media が paused しているかどうか。参照: HTMLMediaElement.paused。 remote-playback-start-response メッセージ内の初期 state では、 default は false である。

seeking

receiver が seeking しているかどうか。参照: HTMLMediaElement.seeking。 remote-playback-start-response メッセージ内の初期 state では、 default は false である。

stalled

true の場合、十分な media が読み込まれていないため media は再生されておらず、 false の場合はそうではない。stalled event を参照されたい。 remote-playback-start-response メッセージ内の初期 state では、 default は false である。

ended

media が end に到達したかどうか。参照: HTMLMediaElement.ended。 remote-playback-start-response メッセージ内の初期 state では、 default は false である。

volume

0.0 から 1.0 までの scale 上の現在の playback volume。参照: HTMLMediaElement.volume。 remote-playback-start-response メッセージ内の初期 state では、 default は 1.0 である。

muted

audio が muted（volume value を上書き）されている場合は true、そうでない場合は false。 参照: HTMLMediaElement.muted。 remote-playback-start-response メッセージ内の初期 state では、 default は false である。

resolution

video の「intrinsic width」および「intrinsic width」。参照: HTMLVideoElement.videoWidth および HTMLVideoElement.videoHeight。 remote-playback-start-response メッセージ内の初期 state では、 default は unknown resolution であり、null によって表される。

audio-tracks

個別に enabled または disabled にできる available audio tracks。参照: HTMLMediaElement.audioTracks。 remote-playback-start-response メッセージ内の初期 state では、 default は empty array である。

video-tracks

available video tracks。選択できるのは 1 つだけである。参照: HTMLMediaElement.videoTracks。 remote-playback-start-response メッセージ内の初期 state では、 default は empty array である。

text-tracks

個別に shown、hidden、または disabled にできる available text tracks。参照: HTMLMediaElement.textTracks。 controller は text tracks に cues を追加し、text tracks から cues を削除することもできる。 remote-playback-start-response メッセージ内の初期 state では、 default は empty array である。

Media positions、durations、および time ranges は、HTML で指定される media timeline の観点で定義され、これは 0 と media duration の間の小数秒である。

NOTE: Open Screen agent は、 Appendix C: Media Time Conversions の手順を用いて、 media timeline 上の値と、個々の media frames とともに送信される media sync time との間で変換できる。

7.2. Remote Playback API

Open Screen Protocol agent のうち、 Remote Playback API を実装するものは、 control-remote-playback capability をサポートしなければならない。それは send-streaming capability をサポートしてもよく、これにより HTMLMediaElement の media data を media remoting を通じて送信できる。

OSP agent のうち、 Remote Playback API の remote playback device であるものは、 receive-remote-playback capability をサポートしなければならない。それは receive-streaming capability をサポートしてもよく、これにより HTMLMediaElement data を media remoting を通じて受信できる。

同じ OSP agent が Remote Playback API を実装し、 かつその API の remote playback device であってもよい。

これは、Remote Playback API が § 7 Remote Playback Protocol で定義される messages をどのように使用するかを示す。

section 5.2.1.2 が「このリストには remote playback devices が含まれ、 実装固有の discovery mechanism に基づいて構成される」と述べ、 section 5.2.1.4 が「利用可能な remote playback devices を取得する （実装固有の mechanism を用いて）」と述べるとき、user agent は、この仕様で前に定義された mDNS、QUIC、 agent-info-request, および remote-playback-availability-request messages を用いて receivers を発見してもよい。 remote-playback-availability-request URLs は availability sources set を 含まなければならない。

section 5.2.4 が「device に対する remote の接続を要求する。この step の実装は user agent に固有である。」および「現在の media element state を remote playback state と同期する」と述べるとき、controller は remote playback を開始するため、 remote-playback-start-request message を receiver に送信してもよい。 remote-playback-start-request URLs は remote playback source を含まなければならない。現在の Remote Playback API は単一の source のみを許可するが、protocol は複数を許可しており、将来の Remote Playback API のバージョンでは複数が許可される可能性がある。

section 5.2.4 が「user agent を remote playback device に接続し、remote playback source を再生するために使用される mechanism は、 user agent の実装上の選択である。その接続は、media element state と remote playback state を同期した状態に保つため、media commands を remote playback device へ運び、media playback state を受信できる双方向 messaging abstraction を提供する必要があるだろう」と述べるとき、controller は local media element の変化に基づいて remote playback state を変更するため、 remote-playback-modify-request messages を receiver に送信してもよく、 remote playback state の変化に基づいて local media element を変更するため、 remote-playback-modify-response および remote-playback-state-event messages を受信してもよい。

section 5.2.7 が「device からの remote の切断を要求する。この step の実装は user agent に固有である」と述べるとき、controller は remote-playback-termination-request message を receiver に送信してもよい。

8. ストリーミングプロトコル

この節は、media sender から media receiver へ media を streaming するための Open Screen Protocol の使用を定義する。

Open Screen Protocol agent が media sender である場合、それは send-streaming capability を advertise しなければならない。OSP agent が media receiver である場合、それは receive-streaming capability を advertise しなければならない。同じ agent が media sender と media receiver の両方であってもよい。

8.1. ストリーミングプロトコルの能力

receive-audio (required)

audio を受信するための capabilities のリスト。fields の説明については下記を参照。

receive-video (required)

video を受信するための capabilities のリスト。fields の説明については下記を参照。

format type は audio および video capabilities の基礎として使用される。 Formats は次の fields で構成される。

codec-name (required)

[WEBCODECS-CODEC-REGISTRY] に列挙され、 その registry で参照される codec-specific registrations によりさらに指定される、 完全修飾 codec string。

codec-name について、Open Screen agents は、 [WEBCODECS-CODEC-REGISTRY] に列挙されない codecs について、 [RFC6381] で説明される単一 codec の codec parameter も受け入れてよい。

Audio capabilities は上記の format type に、次の追加 fields を加えて構成される。

max-audio-channels (optional)

media receiver がサポートできる audio channels の最大数を示す任意 field。デフォルト値は "2" であり、 stereo speaker channel setup を意味する。

min-bit-rate (optional)

media receiver が処理できる最小 audio bit rate を kilobits per second で示す任意 field。デフォルトでは最小値はない。

Video capabilities も同様に、上記の format type に 次の追加 fields を加えて構成される。

max-resolution (optional)

media receiver が処理可能な最大 video-resolution（width, height）を示す 任意 field。デフォルトでは最大値はない。

max-frames-per-second (optional)

media receiver が処理可能な最大 frames-per-second を示す任意 field。 デフォルトでは最大値はない。

max-pixels-per-second (optional)

media receiver が処理可能な最大 pixels-per-second を pixels per second で示す 任意 field。デフォルトでは最大値はない。

min-video-bit-rate (optional)

device が処理可能な最小 video bit rate を kilobits per second で示す 任意 field。デフォルトでは最小値はない。

aspect-ratio (optional)

その理想的な aspect ratio を示す任意 field。たとえば、16:10 display は、この値として 1.6 を返して自身の優先 content scaling を示せる。デフォルトは none。

color-gamut (optional)

media receiver により decode および render できる最も広い color space を示す 任意 field。media sender はこの値を用いて video の encode 方法を 決定してもよく、より狭い color spaces はすべてサポートされると仮定するべきである。 有効値は ColorGamut in the Media Capabilities API に対応する。デフォルト値は "srgb" である。

NOTE: "p3" のサポートは "srgb" のサポートを意味し、 "rec2020" のサポートは "p3" および "srgb" のサポートを意味する。

hdr-formats (optional)

media receiver により decode および render できる HDR transfer functions および metadata formats を示す 任意 field。各 video-hdr-format は transfer-function と hdr-metadata の 2 つの fields で構成される。

transfer-function field は有効な TransferFunction でなければならず、hdr-metadata field は有効な HdrMetadataType でなければならない。どちらも Media Capabilities API で定義される。

video-hdr-format に transfer-function が提供され、 hdr-metadata が提供されない場合、media receiver は関連付けられた metadata なしで transfer-function を render できる。 （これは、たとえば "hlg" transfer-function の場合に該当する。）

media receiver は hdr-formats. 内の重複 entries を無視するべきである。 hdr-formats が何も列挙されていない場合、media receiver はいかなる HDR formats も decode できない。

native-resolutions (optional)

media receiver がサポートし、"native" とみなす video-resolutions を示す任意 field。 これは scaling が不要であることを意味する。 デフォルト値は none。

supports-scaling (optional)

media receiver が、native-resolutions list（提供される場合）に列挙されていない video-resolution、または異なる aspect ratio で提供される content を scale できるかどうかを示す任意 boolean field。デフォルト値は true。

supports-rotation (optional)

media receiver が rotation field が設定された video frames を受信できるかどうかを示す任意 boolean field。デフォルト値は true。

8.2. セッション

streaming session を開始するため、sender は次の fields を持つ streaming-session-start-request message を送信してもよい。

streaming-session-id

streaming session を識別する。（sender, receiver）ペアに対して一意でなければならない。後で streaming session を変更または終了するために使用できる。これらの ID は、 § 9 Requests, Responses, and Watches で指定されるように、 state-token に関して他の ID と同様に扱われるべきである。

desired-stats-interval

receiver が stats messages を sender に送信するべき頻度を示す。

stream-offers

receiver が sender から要求できる streams を示す。

各 stream offer は次の fields を含む。

media-stream-id

提供されている media stream を識別する。 streaming session 内で一意でなければならない。receiver が media session を要求するために使用できる。これらの ID は、 § 9 Requests, Responses, and Watches で指定されるように、 state-token に関して他の ID と同様に扱われるべきである。

display-name

ユーザーに表示されることを意図した任意の名前。receiver が、受信する media streams を ユーザーに選択させてもよく、または receiver によって自動的に受信される場合、 media stream が何であるかについてユーザーに情報を与えることができる。

audio

提供される audio encodings のリスト。audio encoding は一連の encoded audio frames である。Encodings は、codec など、receiver がその encoding を decode する方法を知るために必要な fields を定義する。 それらは codec および関連 fields によって異なってもよいが、同じ audio の異なる encodings であるべきである。

video

提供される video encodings のリスト。video encoding は一連の encoded video frames である。Encodings は、codec や default duration など、receiver がその encoding を decode する方法を知るために必要な fields を定義する。 それらは codec や潜在的に他の fields によって異なってもよいが、同じ video の異なる encodings であるべきである。

data

提供される data encodings のリスト。data encoding は一連の data frames である。Encodings は、data type や default duration など、receiver がその encoding を解釈する方法を知るために必要な fields を定義する。 それらは data type や潜在的に他の fields によって異なってもよいが、同じ data の異なる encodings であるべきである。 （異なる data の encodings には、同じ media stream 内の異なる encodints ではなく、 distinct media streams を使用する。）

提供される各 audio encoding は次の fields を定義する。

encoding-id

提供されている audio encoding を識別する。 media stream 内で一意でなければならない。これらの ID は、 § 9 Requests, Responses, and Watches で指定されるように、 state-token に関して request IDs と同様に扱われるべきである。

codec-name

encoding によって使用される codec の名前。 § 8.1 Streaming Protocol Capabilities 内の codec-name と同じ rules に従う。

time-scale

すべての audio frames で使用される time scale。 これにより senders は、各 audio-frame messages に time scale を含めないことで audio-frame messages を小さくできる。

default-duration:

audio frame の duration。これにより senders は、 default duration を持つ audio-frame messages に duration を含めないことで audio-frame messages を小さくできる。

提供される各 video encoding は次の fields を定義する。

encoding-id

提供されている video encoding を識別する。 media stream 内で一意でなければならない。これらの ID は、 § 9 Requests, Responses, and Watches で指定されるように、 state-token に関して request IDs と同様に扱われるべきである。

codec-name

encoding によって使用される codec の名前。 § 8.1 Streaming Protocol Capabilities 内の codec-name と同じ rules に従う。

time-scale

すべての video frames で使用される time scale。 これにより senders は、各 video-frame messages に time scale を含めないことで video-frame messages を小さくできる。

default-duration:

video frame の default duration。これにより senders は、 default duration を持つ video-frame messages に duration を含めないことで video-frame messages を小さくできる。

default-rotation:

video frame の default rotation。これにより senders は、 default rotation を持つ video-frame messages に rotation を含めないことで video-frame messages を小さくできる。

提供される各 data encoding は次の fields を定義する。

encoding-id

提供されている data encoding を識別する。 media stream 内で一意でなければならない。これらの ID は、 § 9 Requests, Responses, and Watches で指定されるように、 state-token に関して request IDs と同様に扱われるべきである。

data-type-name

encoding によって使用される data type の名前。

time-scale

すべての data frames で使用される time scale。 これにより senders は、各 data-frame messages に time scale を含めないことで data-frame messages を小さくできる。

default-duration:

data frame の duration。これにより senders は、 default duration を持つ data-frame messages に duration を含めないことで data-frame messages を小さくできる。

streaming-session-start-request message を受信した後、receiver は 次の fields を持つ streaming-session-start-response message を 送り返すべきである。

desired-stats-interval

sender が stats messages を receiver に送信するべき頻度を示す。

stream-requests

receiver が sender から受信したい media streams を示す。

各 stream request は次の fields を含む。

media-stream-id

要求された stream の ID。

audio (optional)

encoding ID による、要求された audio encoding

video (optional)

encoding ID による、要求された video encoding。target resolution と maximum frame rate を 含んでもよい。sender は maximum frame rate を超えるべきではなく、 target bitrate で送信することを試みるべきであり、少量であればそれを超えてもよい。

data (optional)

encoding ID による、要求された data encoding

streaming session 中、receiver は、変更された stream-requests のリストを含む streaming-session-modify-request を送信することにより、encodings について行った requests を変更できる。sender が streaming-session-modify-request を受信したとき、 streaming-session-modify-response を送り返し、 streaming-session-modify-request からの new request の適用が成功したかどうかを示すべきである。

NOTE: sender が、 streaming-session-start-response または streaming-session-modify-request 内で receiver により選択されたもの以外の encoding を送信したい場合、現在の session を終了し、 新しい session を開始しなければならない。

最後に、sender は streaming-session-terminate-request command を送信することにより、 streaming session を終了してもよい。receiver が streaming-session-terminate-request を受信したとき、 streaming-session-terminate-response を 送り返すべきである。receiver は任意の時点で終了でき、 streaming-session-terminate-event message を送信することにより sender に通知できる。

8.3. 音声

Media senders は、 次の keys および values を持つ audio-frame messages（Appendix A: Messages を参照）を送信することにより、 media receivers へ audio を送信してもよい。 audio frame message は、ある時間範囲の encoded audio samples の集合を含む。 codec と timeline を共有する一連の encoded audio frames は audio encoding を形成する。

ほとんどの Open Screen Protocol messages と異なり、これは struct-based grouping ではなく array-based grouping を使用する。 required fields については、これにより wire 上の bytes をより効率的に使用できる。 これは streaming audio にとって重要であり、payload は通常非常に小さく、overhead の 1 byte ごとが 相対的に大きいためである。array-based grouping で optional values に対応するため、 array 内の 1 つの optional field が、struct-based grouping のすべての optional values を保持するために使用される。 これにより、効率性と柔軟性の良いバランスが提供されることが期待される。

QUIC 固有の事項に 依存しないように次を書き直す。 [Issue #343]

audio frames を順不同で送信できるようにするため、それらは separate QUIC streams で送信されるべきである。

encoding-id

この audio frame が属する media encoding を識別する。これは、 codec、codec properties、 time scale、および default duration など、 （audio-encoding-offer message からの） encoding の fields を参照するために使用できる。 encoding id を通じて encoding の fields を参照することは、 各 frame に重複情報を送信することを避けるのに役立つ。

start-time

audio frame の time range の開始を識別する。 end time は start time と duration から推測できる。 time scale は、 encoding-id により参照される audio-encoding-offer message の time-scale field 内の値に等しい。

duration

存在する場合、audio frame の duration。存在しない場合、 duration は encoding-id により参照される audio-encoding-offer message の default-duration field に等しい。 time scale は、 encoding-id により参照される audio-encoding-offer message の time-scale field 内の値に等しい。

sync-time

存在する場合、この audio frame（したがって、この encoding）の start time を、 異なる timelines 上の他の media encodings の start time と同期するために使用される時刻。 それは wall clock time であってもよいが、そうである必要はない。 media sender により選択される任意の clock であり得る。

payload

encoded audio。codec は、 encoding-id により参照される audio-encoding-offer message の codec-name field に等しい。

8.4. 映像

Media senders は、次の keys および values を持つ video-frame messages（Appendix A: Messages を参照）を送信することにより、 media receivers へ video を送信してもよい。video frame message は、特定の時点または特定の time range（duration が既知の場合）における encoded video frame（encoded image）を含む。 codec と timeline を共有する一連の encoded video frames は video encoding を形成する。

QUIC 固有の事項に 依存しないように次を書き直す。 [Issue #343]

video frames を順不同で送信できるようにするため、それらは separate QUIC streams で送信されてもよい。encoding が、independent frame まで遡って 前のものに依存する encoded video frames の長い chain である場合、 independent frame から始まり最後の dependent frame で終わる単一の QUIC stream で それらを送信することが理にかなう場合がある。

encoding-id

この video frame が属する media encoding を識別する。 これは、codec、codec properties、time scale、および default rotation など、encoding の fields を参照するために使用できる。 encoding id を通じて encoding の fields を参照することは、 各 frame に重複情報を送信することを避けるのに役立つ。

sequence-number

frame および encoding 内でのその順序を識別する。 encoding 内では、より大きい sequence numbers はより後の start times を意味する。 encoding 内では、sequence numbers の gaps は frames が欠落していることを意味する。

depends-on

存在する場合、この frame が依存する frames の sequence numbers。 sequence numbers が負である場合、それは relative sequence numbers として扱われ、 その sequence numbers はこの frame の sequence number に加算することで計算される。 空である場合、これは independent frame（key frame）である。 存在しない場合、default value は [-1] である。

start-time

video frame の time range の開始を識別する。 end time は start time と duration から推測できる。 time scale は、 encoding-id により参照される video-encoding-offer message の time-scale field 内の値に等しい。

duration

存在する場合、video frame の duration。存在しない場合、それは duration が unknown であることを意味する。time scale は、 encoding-id により参照される video-encoding-offer message の time-scale field 内の値に等しい。

sync-time

存在する場合、この frame（したがって、この encoding）の start time を、 異なる timelines 上の他の media encodings の start time と同期するために使用される時刻。

rotation

存在する場合、decoding 後かつ rendering 前に frame をどのように rotated するべきかを示す。Rotation は 90 度単位の時計回りである。 default は、encoding-id により参照される video-encoding-offer message の default-rotation field に等しい。

payload

encoded video frame（encoded image）。codec は、 encoding-id により参照される video-encoding-offer message の codec-name field に等しい。

8.5. データ

Media senders は、次の keys および values を持つ data-frame messages（Appendix A: Messages を参照）を 送信することにより、timed data を media receivers に送信してもよい。data frame message は、 audio および video と同期できる任意の payload を含む。 data type と timeline を共有する一連の data frames は data encoding を形成する。

QUIC 固有の事項に 依存しないように次を書き直す。 [Issue #343]

data frames を順不同で送信できるようにするため、それらは separate QUIC streams で送信されてもよいが、特定の data の type にとって意味がある場合は、 複数の data frame が 1 つの QUIC stream で送信されてもよい。

encoding-id

この data frame が属する data encoding を識別する。これは、 data の type および time scale など、 encoding の fields を参照するために使用できる。encoding id を通じて encoding の fields を参照することは、 各 frame に重複情報を送信することを避けるのに役立つ。

sequence-number

frame および encoding 内でのその順序を識別する。 encoding 内では、より大きい sequence numbers はより後の start times を意味する。 encoding 内では、sequence numbers の gaps は frames が欠落していることを意味する。

start-time

data frame の time range の開始を識別する。 end time は start time と duration から推測できる。 time scale は、 encoding-id により参照される data-encoding-offer message の time-scale field 内の値に等しい。

duration

存在する場合、data frame の duration。存在しない場合、 duration は encoding-id により参照される data-encoding-offer message の default-duration field に等しい。 time scale は、 encoding-id により参照される data-encoding-offer message の time-scale field 内の値に等しい。

sync-time

存在する場合、この data frame（したがって、この encoding）の start time を、 異なる timelines 上の他の media encodings の start time と同期するために使用される時刻。

payload

data。data type は、encoding-id により参照される data-encoding-offer message の data-type-name field に等しい。

8.6. フィードバック

media receiver は、key frame requests などの feedback を media sender に送信できる。

video key frame は、次の keys および values を持つ video-request message を送信することで 要求される。

QUIC 固有の事項に 依存しないように次を書き直す。 [Issue #343]

video frames を順不同で送信できるようにするため、それらは separate QUIC streams で送信されてもよい。

encoding-id

media sender が新しい key frame を送信するべき encoding。

sequence-number

encoding 内での順序を与える。 encoding 内では、より大きい sequence numbers は以前のものを無効にする。 media sender は、より大きい sequence number が処理された後では、より小さい sequence numbers を無視してもよい。 これは、順不同の requests が必要以上に多くの key frames を生成することを防ぐためである。

highest-decoded-frame-sequence-number: uint

設定されている場合、media sender は最後に decoded された frame に依存する video frame を生成してもよい。設定されていない場合、media sender は independent（key）frame を生成しなければならない。

8.7. 統計

streaming session 中、sender は receiver が要求した interval で streaming-session-sender-stats-event により stats を送信するべきである。 送信しているすべての media streams について、次の stats をすべて送信するべきである。 streaming-session-sender-stats-event message は 次の fields を含む。

streaming-session-id

これらの stats が適用される streaming session の ID。

system-time

monotonic system clock を用いて、stats が計算された時刻。

audio

audio に固有の stats。複数の encodings の stats を一度に送信できるが、 stats が変化していない場合、encodings は含まれる必要がない。下記を参照。

video

video に固有の stats。複数の encodings の stats を一度に送信できるが、 stats が変化していない場合、encodings は含まれる必要がない。下記を参照。

Audio encoding sender stats は次の fields を含む。

encoding-id

stats が適用される encoding の ID。

cumulative-sent-frames

送信された frames の総数。

cumulative-encode-delay

送信された frames の encoding に費やされた時間の合計。

Video encoding sender stats は次の fields を含む。

encoding-id

stats が適用される encoding の ID。

cumulative-sent-duration

送信されたすべての audio frames のすべての durations の合計。

cumulative-encode-delay

送信された frames の encoding に費やされた時間の合計。

cumulative-dropped frames

network、CPU、またはその他の contraints により送信されなかった frames の総数。

streaming session 中、receiver は sender が要求した interval で streaming-session-receiver-stats-event により stats を送信するべきである。 受信しているすべての media streams について、次の stats をすべて送信するべきである。

receiver が frames を playout する前に保持するため buffer を使用している場合、 remote-buffer-status field を用いてその buffer の status も送信するべきである。 それは次の 3 つの values のいずれかを持てる。

• enough-data: buffer は data が多すぎる状態でも、data が不足している状態でもない。

• insufficient-data: buffer は underrun し、予定された playout 時刻に十分な frame data を持たない。

• too-much-data: 現在の send rate では、buffer は overrun し、将来の frame data は playout 可能になる前に破棄される。

insufficient-data の status を受信した sender は、自身の send rate を増加させるか、将来の frames についてより効率的な encoding に切り替えるべきである。 too-much-data の status を受信した sender は、自身の send rate を減少させるべきである。

receiver が buffering なしで frames をただちに再生している場合、それは常に buffering status として enough-data を報告するべきである。

streaming-session-receiver-stats-event message は 次の fields を含む。

streaming-session-id

これらの stats が適用される streaming session の ID。

system-time

monotonic system clock を用いて、stats が計算された時刻。

audio

audio に固有の stats。複数の encodings の stats を一度に送信できるが、 stats が変化していない場合、encodings は含まれる必要がない。下記を参照。

video

video に固有の stats。複数の encodings の stats を一度に送信できるが、 stats が変化していない場合、encodings は含まれる必要がない。下記を参照。

Audio encoding receiver stats は次の fields を含む。存在しない場合、 その値が前回の値から変化していないことを示す。

encoding-id

stats が適用される encoding の ID。

cumulative-decoded-frames

受信および decoded された audio frames の総数。

cumulative-received-duration

受信されたすべての audio frames のすべての durations の合計。

cumulative-lost-duration

lost として検出されたすべての audio frames のすべての durations の合計。

cumulative-buffer-delay

frames が receipt と playout の間で buffered された時間の合計。

cumulative-decode-delay

受信された frames の decoding に費やされた時間の合計。

remote-buffer-status : streaming-buffer-status

この encoding に対する remote buffer の status。

Video encoding receiver stats は次の fields を含む。存在しない場合、 その値が前回の値から変化していないことを示す。

encoding-id

stats が適用される encoding の ID。

cumulative-decoded-frames

受信および decoded された video frames の総数。

cumulative-lost-frames

lost として検出された video frames の総数。

cumulative-buffer-delay

frames が receipt と render の間で buffered された時間の合計。

cumulative-decode-delay

受信された frames の decoding に費やされた時間の合計。

remote-buffer-status : streaming-buffer-status

この encoding に対する remote buffer の status。

9. リクエスト、レスポンス、および監視

Open Screen Protocol 内の複数の sub-protocols には、 requests、responses、watches、および events として機能する messages がある。ほとんどの requests は request-id を持ち、request を受信する agent は、同じ request-id を持つ reponse message を正確に 1 つ返さなければならない。watch request は watch-id を持ち、request を受信する agent は、watch request が期限切れになるまで、 同じ watch-id を持つ任意個数の event messages を response として送信してもよい。

request-id および watch-id values は、各 agent が保持する counter から割り当てられる unsigned integer IDs であり、その counter は 1 から始まり、 各 ID ごとに 1 ずつ増加する。agent が自身の state-token を変更するたび、 counter を 1 にリセットしなければならない。

agent が、別の agent が（新しい state-token を advertise したことにより） 自身の state をリセットしたことを見た場合、その agent に対する requests、responses、 watches および events を破棄するべきである。

一方が state を失った場合に一意でなければ混乱を招く他の ID、たとえば streaming-session-id、media-session-id、および encoding-id なども同じように扱われるべきである。

QUIC 固有の事項に 依存しないように次を書き直す。 [Issue #343]

Note: Request および watch IDs は、 agents 間の特定の QUIC connection には結び付けられない。 QUIC connection が閉じられた場合、agent は相手方に関連する requests、responses、watches、または events を破棄するべきではない。これにより agents は未使用の connections を閉じることで電力を節約できる。

Note: Request および watch IDs は agents 間で一意ではない。agent は、request ID を、それを送信した agent の一意識別子 （certificate fingerprint など）と組み合わせて、複数の agents にわたる requests を追跡できる。

10. プロトコル拡張

Open Screen Protocol agents は、この仕様で定義されない extension messages を交換してもよい。 これは experimentation、customization、またはその他の目的で使用できる。

新しい extension messages を追加するため、extension authors は public registry において、 message type keys の範囲を持つ capability ID を登録しなければならない。 その後、agents は、自身の agent-info message の capabilities field に対応する capability ID を含めることにより、 extension を受け入れることを示してもよい。

Capability IDs 1-999 は Open Screen Protocol による使用のために予約されている。 Capability IDs 1000 以上は extensions に利用可能である。extension message type keys の有効な範囲については Appendix B: Message Type Key Ranges を参照されたい。

Note: public registry の目的は、 複数の extension authors の capability IDs と message type keys の間の conflicts を防ぐことである。

Agents は、対応する extension capability ID を advertise していない別の agent に extension messages を送信してはならない。

Note: agents が未知の message type keys をどう扱うかについては、 § 4 Message delivery using CBOR を参照されたい。

実装を単純化し、extension protocols の標準化へのより容易な道を提供するため、extension messages も CBOR で encode されることが推奨される。 しかし、これは要求されない。non-CBOR extensions をサポートする agents は、CBOR messages と non-CBOR extension messages の混在を含む QUIC streams を decode できなければならない。

10.1. プロトコル拡張フィールド

agent が Open Screen Protocol により定義される任意の map-valued CBOR message type に additional extension fields を追加することは合法である。 Extension fields は optional でなければならず、Open Screen Protocol message は、 その field が設定されている場合と設定されていない場合の両方で意味をなさなければならない。

Agents は audio-frame message に直接 extended fields を追加してはならない。 代わりに、それらをその nested optional value に追加してもよい。

Extension fields は、Open Screen Protocol messages 内の integer keys との conflicts を避けるため、 string keys を使用するべきである。agent は、別の agent の agent-info が、その agent が extension fields を理解することを示す extension capability ID を advertise しない限り、 その agent に extension fields を送信するべきではない。

11. セキュリティとプライバシー

Open Screen Application Protocol は、2 つの OSP agents が user および application data を交換することを可能にする。したがって、その security および privacy considerations は慎重に検討されるべきである。まず、W3C Security and Privacy Questionnaire を用いて protocol 自体を評価する。次に、 Presentation API および Remote Playback API により推奨される security and privacy guidelines が満たされるかどうかを検討する。 最後に、agents がこれらの security and privacy requirements を満たすために使用できる 推奨 mitigations について議論する。

11.1. 脅威モデル

11.1.1. 同一オリジンポリシー違反

Presentation API は、各 origin の同意（API の使用を通じて）により、 controlling pages と presentations の間の cross-origin communication を可能にする。 これは、 postMessage() を介し、 targetOrigin が * である cross-origin communication に類似している。 しかし、Presentation API は各 message とともに source origin information を伝えない。したがって、Open Screen Protocol は その agents 間で origin information を伝えない。

presentation identifier は、 unrestricted cross-origin access に対する一定の保護を担うが、 PresentationConnection により接続された parties の厳密な authentication は application level で行われなければならない。

11.2. Open Screen Application Protocol のセキュリティおよびプライバシーに関する考慮事項

11.2.1. 個人を識別可能な情報および高価値 データ

protocol により交換される次の data は、personally identifiable and/or high value data であり得る。

1. Presentation URLs および availability results

2. Presentation identifiers

3. Presentation connection IDs

4. Presentation connection messages

5. Remote playback URLs

6. Remote playback commands and status messages

Presentation identifiers は、Presentation URL と組み合わせて 実行中の presentation に接続するために使用できるため、high value data と見なされる。

agent-info を通じて提供される data は、 合理的に confidential にすることはできず、public と見なされるべきである。

• display name

• device model name

• agent の capabilities

• Preferred locales

この data は personally identifiable と見なされないが、attacker による変更や他の値への置換を防ぐために 保護することが重要である。

11.2.2. クロスオリジン状態に関する考慮事項

以前の session によって開始された presentation に再接続することにより、 Presentation API を通じて browsing sessions をまたいだ origin state への access が可能である。 この scenario は Presentation API § 7.2 Cross-origin access で扱われる。

Receiver availability は user の network context に応じて cross-origin で利用可能である。この data の Web への exposure についても、 Presentation API § 7.1 Personally identifiable information および Remote Playback API § 6.1 Personally identifiable information で議論されている。

11.2.3. 他のデバイスへのオリジンアクセス

設計上、Open Screen Protocol は Web から receivers への access を可能にする。 protocol を実装することにより、これらの devices は自らを Web に利用可能にしていることを認識しており、 それに応じて設計されるべきである。

以下では、これらの devices の malicious use を防ぐための mitigation steps について議論する。

11.2.4. プライベートブラウジングモード

Open Screen Protocol 自体は、user agent の通常の browsing と private browsing modes を区別しない。

generic transport requirements を反映するよう更新する。 [Issue #342]

しかし、user agents は、同じ user agent instance からの normal browsing と private browsing に対して、別々の authentication contexts および QUIC connections を使用することが推奨される。これにより、OSP agents が同じ user による normal browsing と private browsing で生じる activities を照合することがより困難になる。

11.2.5. 永続的状態

agent は、agent-info message または他の application messages から、以前に接続した agents の identity を persist する可能性が高い。

しかし、この data は通常 Web には exposed されず、display selection または display authentication process 中の user agent の native UI を通じてのみ exposed される。user agent が browsing data を消去するとき、この data を消去するか 保持するかは実装上の選択であり得る。

11.2.6. その他の考慮事項

Open Screen Protocol は Web に対し、次のものへの追加 access を付与しない。

• 新しい script loading mechanisms

• user の location への access

• device sensors への access

• user の local computing environment への access

• user agent の native UI に対する control

• user agent の security characteristics

11.3. Presentation API に関する考慮事項

Presentation API § 7 Security and privacy considerations は、Open Screen Protocol に対して 次の requirements を課している。

1. Presentation URLs および presentation identifiers は、 cross-origin access guidelines に従い、presentation に接続することを許可された parties の間で private に保たれるべきである。

2. 複数の user agent profiles を表す connections が presentation に対して作成されたとき、 user interface guidelines に従い、controllers および receivers は通知されるべきである。

3. controllers と receivers の間の messaging は、presentation connections 間の messaging に関する guidelines に従い、authenticated かつ confidential であるべきである。

generic transport requirements を反映するよう更新する。 [Issue #342]

Open Screen Protocol は、次によりこれらの considerations に対処する。

1. presentation URLs、IDs、または messages が交換される前に、 mutual authentication および TLS-secured QUIC connection を要求する。

2. agents が active connections の数を追跡できるよう、個々の PresentationConnections に対して explicit messages および connection IDs を追加する。

11.4. Remote Playback API に関する考慮事項

Remote Playback API § 6 Security and privacy considerations も、 controllers と receivers の間の messaging は authenticated かつ confidential であるべきであると述べている。

generic transport requirements を反映するよう更新する。 [Issue #342]

この consideration は、remote playback related messages が交換される前に、 mutual authentication および TLS-secured QUIC connection を要求することにより扱われる。

11.5. 緩和戦略

11.5.1. 悪意のある入力

OSP agents は、parsing vulnerabilities を悪用して target device を compromise しようとする malicious input に対して堅牢であるべきである。

CBOR は、JSON や XML のような代替と比べ、このような attacks に対して脆弱性が低いことを意図している。 それでも、agents は fuzz testing のような approaches を用いて徹底的にテストされるべきである。

可能な場合、OSP agents（content rendering components を含む）は、 vulnerabilities が user data に access したり、persistent exploits につながったりすることを防ぐため、 sandboxing のような defense-in-depth techniques を使用するべきである。

11.6. ユーザーインターフェイスに関する考慮事項

この仕様は、OSP agents の security relevant user interfaces について特定の requirements を設けない。しかし、agent が 別の agent を authentication する前に、user interface は、 その agent からの agent-info またはその他の data が authentication により verified されていないことを明確にするべきである。

11.6.1. インスタンス名および表示名

generic discovery requirements を反映するよう更新する。 [Issue #342]

DNS-SD Instance Names は authentication 前に user が見る主要な情報であるため、 これらの names の慎重な presentation が必要である。

Agents は Instance Names を unverified information として扱わなければならず、 successful QUIC connection 後に agent-info message を通じて受信した display name の prefix であるかどうかを確認するべきである。agent が この確認を行うと、その name を verified display name として表示できる。

Agents は、DNS-SD からの truncated display names ではなく、complete display names のみを user に表示するべきである。 truncated display name は、完全な形で verified display name として表示される前に、上記のように verified されるべきである。

Appendix A: Messages

次の messages は、Concise Data Definition Language syntax を用いて定義される。integer keys が使用される場合、 field の名前を示すため、その行に comment が付加される。この仕様における object definitions は、 wire 上の bytes 数を減らしつつ、各 key について human-readable name を維持するため、 この通常とは異なる syntax を持つ。optional fields の容易な indexing を可能にするため、 object arrays の代わりに integer keys が使用される。

各 root message（別の message に enclosed されずに QUIC stream に入れることができるもの）は、 message type key を示す comment を持つ。

小さい numbers は、より頻繁に送信される、または非常に小さい、またはその両方である message のために予約されるべきであり、 大きい numbers は、送信頻度が低い、または大きい、またはその両方である messages のために予約されるべきである。 なぜなら、小さい type keys は wire 上でより小さく encode されるからである。

; type key 10
agent-info-request = {
  request
}

; type key 11
agent-info-response = {
  response
  1: agent-info ; agent-info
}

; type key 120
agent-info-event = {
  0: agent-info ; agent-info
}

agent-capability = &(
  receive-audio: 1
  receive-video: 2
  receive-presentation: 3
  control-presentation: 4
  receive-remote-playback: 5
  control-remote-playback: 6
  receive-streaming: 7
  send-streaming: 8
)

agent-info = {
  0: text ; display-name
  1: text ; model-name
  2: [* agent-capability] ; capabilities
  3: text ; state-token
  4: [* text] ; locales
}

; type key 12
agent-status-request = {
  request
  ? 1: status ; status
}

; type key 13
agent-status-response = {
  response
  ? 1: status ; status
}

status = {
  0: text ; status
}

request = (
  0: request-id ; request-id
)

response = (
  0: request-id ; request-id
)

request-id = uint

microseconds = uint

epoch-time = int

media-timeline = float64

media-timeline-range = [
  start: media-timeline
  end: media-timeline
]

watch-id = uint

; type key 14
presentation-url-availability-request = {
  request
  1: [1* text] ; urls
  2: microseconds ; watch-duration
  3: watch-id ; watch-id
}

; type key 15
presentation-url-availability-response = {
  response
  1: [1* url-availability] ; url-availabilities
}

; type key 103
presentation-url-availability-event = {
  0: watch-id ; watch-id
  1: [1* url-availability] ; url-availabilities
}

; idea: use HTTP response codes?
url-availability = &(
  available: 0
  unavailable: 1
  invalid: 10
)

; type key 104
presentation-start-request = {
  request
  1: text ; presentation-id
  2: text ; url
  3: [* http-header] ; headers
}

http-header = [
  key: text
  value: text
]

; type key 105
presentation-start-response = {
  response
  1: &result ; result
  2: uint ; connection-id
  ? 3: uint ; http-response-code
}

presentation-termination-source = &(
  controller: 1
  receiver: 2
  unknown: 255
)

presentation-termination-reason = &(
  application-request: 1
  user-request: 2
  receiver-replaced-presentation: 20
  receiver-idle-too-long: 30
  receiver-attempted-to-navigate: 31
  receiver-powering-down: 100
  receiver-error: 101
  unknown: 255
)

; type key 106
presentation-termination-request = {
  request
  1: text ; presentation-id
  2: presentation-termination-reason ; reason
}

; type key 107
presentation-termination-response = {
  response
  1: &result ; result
}

; type key 108
presentation-termination-event = {
  0: text ; presentation-id
  1: presentation-termination-source ; source
  2: presentation-termination-reason ; reason
}

; type key 109
presentation-connection-open-request = {
  request
  1: text ; presentation-id
  2: text ; url
}

; type key 110
presentation-connection-open-response = {
  response
  1: &result ; result
  2: uint ; connection-id
  3: uint ; connection-count
}

; type key 113
presentation-connection-close-event = {
  0: uint ; connection-id
  1: &(
    close-method-called: 1
    connection-object-discarded: 10
    unrecoverable-error-while-sending-or-receiving-message: 100
  ) ; reason
  ? 2: text ; error-message
  3: uint ; connection-count
}

; type key 121
presentation-change-event = {
  0: text ; presentation-id
  1: uint ; connection-count
}

; type key 16
presentation-connection-message = {
  0: uint ; connection-id
  1: bytes / text ; message
}

result = (
  success: 1
  invalid-url: 10
  invalid-presentation-id: 11
  timeout: 100
  transient-error: 101
  permanent-error: 102
  terminating: 103
  unknown-error: 199
)

; type key 17
remote-playback-availability-request = {
  request
  1: [* remote-playback-source] ; sources
  2: microseconds ; watch-duration
  3: watch-id ; watch-id
}

; type key 18
remote-playback-availability-response = {
  response
  1: [* url-availability] ; url-availabilities
}

; type key 114
remote-playback-availability-event = {
  0: watch-id ; watch-id
  1: [* url-availability] ; url-availabilities
}

; type key 115
remote-playback-start-request = {
  request
  1: remote-playback-id ; remote-playback-id
  ? 2: [* remote-playback-source] ; sources
  ? 3: [* text] ; text-track-urls
  ? 4: [* http-header] ; headers
  ? 5: remote-playback-controls ; controls
  ? 6: {streaming-session-start-request-params} ; remoting
}

remote-playback-source = {
  0: text; url
  1: text; extended-mime-type
}

; type key 116
remote-playback-start-response = {
  response
  ? 1: remote-playback-state ; state
  ? 2: {streaming-session-start-response-params} ; remoting
}

; type key 117
remote-playback-termination-request = {
  request
  1: remote-playback-id ; remote-playback-id
  2: &(
    user-terminated-via-controller: 11
    unknown: 255
  ) ; reason
}

; type key 118
remote-playback-termination-response = {
  response
  1: &result ; result
}

; type key 119
remote-playback-termination-event = {
  0: remote-playback-id ; remote-playback-id
  1: &(
    receiver-called-terminate: 1
    user-terminated-via-receiver: 2
    receiver-idle-too-long: 30
    receiver-powering-down: 100
    receiver-crashed: 101
    unknown: 255
  ) ; reason
}

; type key 19
remote-playback-modify-request = {
  request
  1: remote-playback-id ; remote-playback-id
  2: remote-playback-controls ; controls
}

; type key 20
remote-playback-modify-response = {
  response
  1: &result ; result
  ? 2: remote-playback-state ; state
}

; type key 21
remote-playback-state-event = {
  0: remote-playback-id ; remote-playback-id
  1: remote-playback-state ; state
}

remote-playback-id = uint

remote-playback-controls = {
  ? 0: remote-playback-source ; source
  ? 1: &(
    none: 0
    metadata: 1
    auto: 2
  ) ; preload
  ? 2: bool ; loop
  ? 3: bool ; paused
  ? 4: bool ; muted
  ? 5: float64 ; volume
  ? 6: media-timeline ; seek
  ? 7: media-timeline ; fast-seek
  ? 8: float64 ; playback-rate
  ? 9: text ; poster
  ? 10: [* text] ; enabled-audio-track-ids
  ? 11: text ; selected-video-track-id
  ? 12: [* added-text-track] ; added-text-tracks
  ? 13: [* changed-text-track] ; changed-text-tracks
}

remote-playback-state = {
  ? 0: {
    0: bool ; rate
    1: bool ; preload
    2: bool ; poster
    3: bool ; added-text-track
    4: bool ; added-cues
  } ; supports
  ? 1: remote-playback-source ; source
  ? 2: &(
    empty: 0
    idle: 1
    loading: 2
    no-source: 3
  ) ; loading
  ? 3: &(
    nothing: 0
    metadata: 1
    current: 2
    future: 3
    enough: 4
  ) ; loaded
  ? 4: media-error ; error
  ? 5: epoch-time / null ; epoch
  ? 6: media-timeline / null ; duration
  ? 7: [* media-timeline-range] ; buffered-time-ranges
  ? 8: [* media-timeline-range] ; seekable-time-ranges
  ? 9: [* media-timeline-range] ; played-time-ranges
  ? 10: media-timeline ; position
  ? 11: float64 ; playbackRate
  ? 12: bool ; paused
  ? 13: bool ; seeking
  ? 14: bool ; stalled
  ? 15: bool ; ended
  ? 16: float64 ; volume
  ? 17: bool ; muted
  ? 18: video-resolution / null ; resolution
  ? 19: [* audio-track-state] ; audio-tracks
  ? 20: [* video-track-state] ; video-tracks
  ? 21: [* text-track-state] ; text-tracks
}

added-text-track = {
  0: &(
    subtitles: 1
    captions: 2
    descriptions: 3
    chapters: 4
    metadata: 5
  ) ; kind
  ? 1: text ; label
  ? 2: text ; language
}

changed-text-track = {
  0: text ; id
  1: text-track-mode ; mode
  ? 2: [* text-track-cue] ; added-cues
  ? 3: [* text] ; removed-cue-ids
}

text-track-mode = &(
  disabled: 1
  showing: 2
  hidden: 3
)

text-track-cue = {
  0: text ; id
  1: media-timeline-range ; range
  2: text ; text
}

media-sync-time = [
  value: uint
  scale: uint
]

media-error = [
  code: &(
    user-aborted: 1
    network-error: 2
    decode-error: 3
    source-not-supported: 4
    unknown-error: 5
  )
  message: text
]

track-state = (
  0: text ; id
  1: text ; label
  2: text ; language
)

audio-track-state = {
  track-state
  3: bool ; enabled
}

video-track-state = {
  track-state
  3: bool ; selected
}

text-track-state = {
  track-state
  3: text-track-mode ; mode
}

; type key 22
audio-frame = [
  encoding-id: uint
  start-time: uint
  payload: bytes
  ? optional: {
    ? 0: uint ; duration
    ? 1: media-sync-time ; sync-time
  }
]

; type key 23
video-frame = {
  0: uint ; encoding-id
  1: uint ; sequence-number
  ? 2: [* int] ; depends-on
  3: uint ; start-time
  ? 4: uint ; duration
  5: bytes ; payload
  ? 6: uint ; video-rotation
  ? 7: media-sync-time ; sync-time
}

; type key 24
data-frame = {
  0: uint ; encoding-id
  ? 1: uint ; sequence-number
  ? 2: uint ; start-time
  ? 3: uint ; duration
  4: bytes ; payload
  ? 5: media-sync-time ; sync-time
}

ratio = [
  antecedent: uint
  consequent: uint
]

; type key 122
streaming-capabilities-request = {
  request
}

; type key 123
streaming-capabilities-response = {
  response
  1: streaming-capabilities ; streaming-capabilities
}

streaming-capabilities = {
  0: [* receive-audio-capability] ; receive-audio
  1: [* receive-video-capability] ; receive-video
  2: [* receive-data-capability] ; receive-data
}

format = {
  0: text ; codec-name
}

receive-audio-capability = {
  0: format ; codec
  ? 1: uint ; max-audio-channels
  ? 2: uint ; min-bit-rate
}

video-resolution = {
  0: uint ; height
  1: uint ; width
}

video-hdr-format = {
  0: text; transfer-function
  ? 1: text; hdr-metadata
}

receive-video-capability = {
  0: format ; codec
  ? 1: video-resolution ; max-resolution
  ? 2: ratio ; max-frames-per-second
  ? 3: uint ; max-pixels-per-second
  ? 4: uint ; min-bit-rate
  ? 5: ratio ; aspect-ratio
  ? 6: text ; color-gamut
  ? 7: [* video-resolution] ; native-resolutions
  ? 8: bool ; supports-scaling
  ? 9: bool ; supports-rotation
  ? 10: [* video-hdr-format] ; hdr-formats
}

receive-data-capability = {
  0: format ; data-type
}

; type key 124
streaming-session-start-request = {
  request
  streaming-session-start-request-params
}

; type key 125
streaming-session-start-response = {
  response
  streaming-session-start-response-params
}

; A separate group so it can be used in remote-playback-start-request
streaming-session-start-request-params = (
  1: uint ; streaming-session-id
  2: [* media-stream-offer] ;  stream-offers
  3: microseconds ; desired-stats-interval
)

; type key 126
streaming-session-modify-request = {
  request
  streaming-session-modify-request-params
}

; A separate group so it can be used in remote-playback-start-response
streaming-session-start-response-params = (
  1: &result ; result
  2: [* media-stream-request] ; stream-requests
  3: microseconds ; desired-stats-interval  
)

streaming-session-modify-request-params = (
  1: uint ; streaming-session-id
  2: [* media-stream-request] ; stream-requests
)

; type key 127
streaming-session-modify-response = {
  response
  1: &result ; result
}

; type key 128
streaming-session-terminate-request = {
  request
  1: uint ; streaming-session-id
}

; type key 129
streaming-session-terminate-response = {
  response
}

; type key 130
streaming-session-terminate-event = {
  0: uint ; streaming-session-id
}

media-stream-offer = {
  0: uint ; media-stream-id
  ? 1: text ; display-name
  ? 2: [1* audio-encoding-offer] ; audio
  ? 3: [1* video-encoding-offer] ; video
  ? 4: [1* data-encoding-offer] ; data
}

media-stream-request = {
  0: uint ; media-stream-id
  ? 1: audio-encoding-request ; audio
  ? 2: video-encoding-request ; video
  ? 3: data-encoding-request ; data
}

audio-encoding-offer = {
  0: uint ; encoding-id
  1: text ; codec-name
  2: uint ; time-scale
  ? 3: uint ; default-duration
}

video-encoding-offer = {
  0: uint ; encoding-id
  1: text ; codec-name
  2: uint ; time-scale
  ? 3: uint ; default-duration
  ? 4: video-rotation ; default-rotation
}

data-encoding-offer = {
  0: uint ; encoding-id
  1: text ; data-type-name
  2: uint ; time-scale
  ? 3: uint ; default-duration
}

audio-encoding-request = {
  0: uint ; encoding-id
}

video-encoding-request = {
  0: uint ; encoding-id
  ? 1: video-resolution ; target-resolution
  ? 2: ratio ; max-frames-per-second
}

data-encoding-request = {
  0: uint ; encoding-id
}

video-rotation = &(
  ; Degrees clockwise
  video-rotation-0: 0
  video-rotation-90: 1
  video-rotation-180: 2
  video-rotation-270: 3
)

sender-stats-audio = {
  0: uint ; encoding-id
  ? 1: uint ; cumulative-sent-frames
  ? 2: microseconds ; cumulative-encode-delay
}

sender-stats-video = {
  0: uint ; encoding-id
  ? 1: microseconds ; cumulative-sent-duration
  ? 2: microseconds ; cumulative-encode-delay
  ? 3: uint ; cumulative-dropped-frames
}

; type key 131
streaming-session-sender-stats-event = {
  0: uint; streaming-session-id
  1: microseconds ; system-time
  ? 2: [1* sender-stats-audio] ; audio
  ? 3: [1* sender-stats-video] ; video
}

streaming-buffer-status = &(
  enough-data: 0
  insufficient-data: 1
  too-much-data: 2
)

receiver-stats-audio = {
  0: uint ; encoding-id
  ? 1: microseconds ; cumulative-received-duration
  ? 2: microseconds ; cumulative-lost-duration
  ? 3: microseconds ; cumulative-buffer-delay
  ? 4: microseconds ; cumulative-decode-delay
  ? 5: streaming-buffer-status ; remote-buffer-status
}

receiver-stats-video = {
  0: uint ; encoding-id
  ? 1: uint ; cumulative-decoded-frames
  ? 2: uint ; cumulative-lost-frames
  ? 3: microseconds ; cumulative-buffer-delay
  ? 4: microseconds ; cumulative-decode-delay
  ? 5: streaming-buffer-status ; remote-buffer-status
}

; type key 132
streaming-session-receiver-stats-event = {
  0: uint; streaming-session-id
  1: microseconds ; system-time
  ? 2: [1* receiver-stats-audio] ; audio
  ? 3: [1* receiver-stats-video] ; video
}

付録 B: メッセージ型キーの範囲

次の付録は、メッセージ型キーの範囲がどのように分割されるかを説明する。 有効な値は 1 から 2⁶⁴ までである。

各 type key は、wire 上で 1、2、4、または 8 bytes の 可変長整数 としてエンコードされる。 各 wire byte size について、keys の 1/4 から 1/2 が extensions のために利用可能である。

付録 C: メディア時刻変換

与えられた audio または video frame の media synchronization timestamp と media timeline value の間で変換するには、次の式を使用できる。

media-timeline-value = media-zero-time + (value / scale)

ここで:

• media-zero-time は、HTML で定義される media timeline の origin であり、 IEEE-754 double precision floating point number [IEEE-754] に変換される。

• value および scale は、 対応する audio-frame または video-frame の sync-time field で渡される値である。

• value / scale は、double floating point precision で計算されるべきである。

• media-timeline-value は IEEE-754 double precision floating point number [IEEE-754] である。

media-timeline-value で overflow が発生した場合、表現可能な最大値が 使用されるべきである。