2. Principles and Terminology (原則と用語)

2.1. Goals of This Document (本文書の目標)

WebRTC プロトコル仕様の目標は、すべて実装された場合、参加者間の最も直接的な可能なパスに沿って送信されるオーディオ、ビデオ、およびデータを使用して、ある実装が別の実装と通信できるようにする一連のプロトコルを規定することです。

本文書は、WebRTC 仕様へのロードマップ (Roadmap) として機能することを意図しています。これは、WebRTC プロトコル仕様の他の部分で使用される用語を定義し、WebRTC コンテキストでさらなる詳細化を必要としない他の仕様への参照をリストし、WebRTC スイートの一部を形成する他の文書へのポインタを提供します。

本文書とそれが参照する文書を読むことにより、WebRTC 互換実装を実装するために必要なすべての情報を得ることができるはずです。

2.2. Relationship between API and Protocol (API とプロトコルの関係)

WebRTC 全体の取り組みは、それぞれが複数の文書で構成される2つの主要部分で構成されています:

• IETF で行われるプロトコル仕様 (Protocol Specification)

• 一連の W3C 文書 [W3C.WD-webrtc] [W3C.WD-mediacapture-streams] で定義される JavaScript API 仕様

これら2つの仕様は、共同で、任意のページに埋め込まれた JavaScript が、ユーザーから適切な承認を得たときに、ブラウザがこれらの仕様をサポートしている限り、オーディオ、ビデオ、および補助データを使用して通信を設定できる環境を提供することを目的としています。ブラウザ環境は、この機能を使用できるアプリケーションの種類を制約しません。

プロトコル仕様は、すべての実装がこの API を実装することを前提としていません；通信している相手がブラウザであるかプロトコル仕様を実装する別のデバイスであるかを知ることが相互運用のために必要であることを意図していません。

プロトコル仕様と API 仕様の間の協力の目標は、プロトコル仕様のすべてのオプションと機能について、そのオプションまたは機能を使用するためにどの API 呼び出しを行うべきかが明確であるべきであり、同様に、任意の API 呼び出しシーケンスについて、どのプロトコルオプションと機能が呼び出されるかが明確であるべきです。もちろん、両方とも実装の制約の対象となります。

以下の用語は、WebRTC スイートを規定する文書全体で使用され、ここで示す特定の意味を持ちます。すべての用語が本文書で使用されるわけではありません。他の用語は、一般的に使用される意味に従って使用されます。

Agent (エージェント): 未定義の用語。"SDP Agent" および "ICE Agent" を参照してください。

Application Programming Interface (API) (アプリケーションプログラミングインターフェース): 通常、プログラミング言語または WebIDL などの抽象的な形式仕様に関連付けられた、その定義されたセマンティクスを持つ一連の呼び出しとイベントの仕様。

Browser (ブラウザ): [HTML5] で定義されている "interactive user agent (インタラクティブユーザーエージェント)" と同義に使用されます。以下の "WebRTC Browser (別名 "WebRTC User Agent")" 定義も参照してください。

Data Channel (データチャネル): メッセージの形式で WebRTC エンドポイント間でデータを送信できる抽象化。2つのエンドポイント間に複数のデータチャネルを持つことができます。

ICE Agent (ICE エージェント): Interactive Connectivity Establishment (ICE) プロトコル [RFC8445] の実装。ICE Agent は SDP Agent でもある可能性がありますが、SDP を使用しない ICE Agent も存在します（たとえば、Jingle [XEP-0166] を使用するもの）。

Interactive (インタラクティブ): ある当事者からのアクションが別の当事者による反応を引き起こすことが期待され、その反応が最初の当事者によって観察できる複数の当事者間の通信であり、アクション/反応/観察に必要な合計時間が数百ミリ秒以下のオーダーである。

Media (メディア): オーディオおよびビデオコンテンツ。ワイヤーなどの "transmission media (伝送媒体)" と混同しないでください。

Media Path (メディアパス): メディアデータがある WebRTC エンドポイントから別のエンドポイントへと移動する経路。

Protocol (プロトコル): その定義されたセマンティクスを持つ、一連のデータユニット、その表現、およびその送信規則の仕様。プロトコルは通常、システム間で行われると考えられています。

Real-Time Media (リアルタイムメディア): コンテンツの生成と表示が時間的に密接に発生することを意図したメディア（数百ミリ秒以下のオーダー）。リアルタイムメディアは、インタラクティブな通信をサポートするために使用できます。

SDP Agent (SDP エージェント): [RFC3264] のセクション3で定義されているように、Session Description Protocol (SDP) の offer/answer 交換に関与するプロトコル実装。

Signaling (シグナリング): メディアパスとデータパスを確立、管理、および制御するために行われる通信。

Signaling Path (シグナリングパス): シグナリングを転送するためにシグナリングに参加するエンティティ間で使用される通信チャネル。シグナリングパス内のエンティティは、メディアパス内のエンティティよりも多い可能性があります。

WebRTC Browser (WebRTC ブラウザ) (別名 "WebRTC User Agent" または "WebRTC UA"): 上記のプロトコル仕様と JavaScript API の両方に準拠するもの。

WebRTC Non-Browser (WebRTC 非ブラウザ): プロトコル仕様に準拠するが、JavaScript API を実装すると主張しないもの。これは、"WebRTC device (WebRTC デバイス)" または "WebRTC native application (WebRTC ネイティブアプリケーション)" とも呼ばれます。

WebRTC Endpoint (WebRTC エンドポイント): WebRTC ブラウザまたは WebRTC 非ブラウザ。プロトコル仕様に準拠します。

WebRTC-Compatible Endpoint (WebRTC 互換エンドポイント): WebRTC エンドポイントと正常に通信できるが、WebRTC エンドポイントの一部の要件を満たすことができない可能性があるエンドポイント。これにより、このようなエンドポイントをネットワークに接続できる場所が制限されたり、他のエンドポイントに提供するセキュリティ保証が制限されたりする可能性があります。これは本仕様によって制約されません；それがまったく言及される場合、それは WebRTC エンドポイントに課される要件が WebRTC 互換エンドポイントに与える影響を指摘するためです。

WebRTC Gateway (WebRTC ゲートウェイ): 非 WebRTC エンティティへのメディアトラフィックを仲介する WebRTC 互換エンドポイント。

すべての WebRTC ブラウザは WebRTC エンドポイントであるため、WebRTC エンドポイントに対する要求は WebRTC ブラウザにも適用されます。

WebRTC 非ブラウザは、ブラウザが JavaScript アプリケーションをホストするのと同様の方法でアプリケーションをホストできる可能性があり、通常は他の言語で API を提供することによって行われます。たとえば、アプリケーションにロードされることを意図した C++ API を提供するライブラリとして実装される場合があります。この場合、JavaScript と同様のセキュリティ考慮事項が必要になる可能性があります；ただし、このような API はここで定義または参照されていないため、本文書はこれらのインターフェースに対して特定の規則を提供できません。

WebRTC ゲートウェイは、別の文書 [WebRTC-Gateways] で説明されています。

2.3. On Interoperability and Innovation (相互運用性とイノベーションについて)

"IETF のミッションステートメント" [RFC3935] は、「インターネットに対する標準の利点は相互運用性にあります -- 標準を実装する複数の製品が協力して、インターネットのユーザーに価値のある機能を提供できることです」と述べています。

インターネット上の通信は、しばしば2つのフェーズで行われます:

• 2つの当事者が、何らかのメカニズムを通じて、両方がサポートできる機能について通信します。

• それらは、その共有された通信機能を使用して通信するか、共通点を見つけられない場合は通信を諦めます。

通信機能については、多くの選択肢があることがよくあります；インターネットの歴史は、あらゆる種類のプロトコルにおける多くの種類のオプションの提案、標準化、実装、および成功または失敗に満ちています。

必須実装 (Mandatory-to-Implement) 機能セットを持つ目標は、交渉の失敗を防ぐことであり、交渉を先取りまたは防止することではありません。

必須実装機能セットの存在は、(1) 仕様に準拠し、(2) 相手がその仕様の基本レベルでの通信を受け入れる意思がある限り、正常に通信できるという保証を提供するため、展開市場の強力な変化者として機能します。

代替案（つまり、必須実装機能を持たないこと）は、通信できないことを意味するものではありません；それは単に、通信パートナーシップの一部になるためには、標準 "およびその他のもの" を実装する必要があることを意味します。この "およびその他のもの" は通常、ある種のプロファイル (Profile) と呼ばれます；インターネットの精神に最も反するバージョンでは、その "およびその他のもの" は特定のベンダーの製品のみを使用する必要があることで構成されます。

2.4. Terminology (用語)

本文書の中で使用されるキーワード「MUST (しなければならない)」、「MUST NOT (してはならない)」、「REQUIRED (必須である)」、「SHALL (すべきである)」、「SHALL NOT (すべきでない)」、「SHOULD (推奨される)」、「SHOULD NOT (推奨されない)」、「RECOMMENDED (推奨)」、「NOT RECOMMENDED (非推奨)」、「MAY (してもよい)」、「OPTIONAL (任意)」は、BCP 14 [RFC2119] [RFC8174] に記載されているように解釈されるものとし、ここに示すようにすべて大文字で表示される場合に限ります。

---