2. Principles and Terminology (Prinzipien und Terminologie)

2.1. Goals of This Document (Ziele dieses Dokuments)

Das Ziel der WebRTC-Protokollspezifikation ist es, eine Reihe von Protokollen zu spezifizieren, die, wenn sie alle implementiert sind, es einer Implementierung ermöglichen, mit einer anderen Implementierung unter Verwendung von Audio, Video und Daten zu kommunizieren, die entlang des direktesten möglichen Pfades zwischen den Teilnehmern gesendet werden.

Dieses Dokument ist als Roadmap zu den WebRTC-Spezifikationen gedacht. Es definiert Begriffe, die von anderen Teilen der WebRTC-Protokollspezifikationen verwendet werden, listet Verweise auf andere Spezifikationen auf, die im WebRTC-Kontext keine weitere Ausarbeitung benötigen, und gibt Hinweise auf andere Dokumente, die Teil der WebRTC-Suite sind.

Durch das Lesen dieses Dokuments und der Dokumente, auf die es verweist, sollte es möglich sein, alle Informationen zu erhalten, die für die Implementierung einer WebRTC-kompatiblen Implementierung erforderlich sind.

2.2. Relationship between API and Protocol (Beziehung zwischen API und Protokoll)

Die gesamte WebRTC-Bemühung besteht aus zwei Hauptteilen, die jeweils aus mehreren Dokumenten bestehen:

• Eine Protokollspezifikation (Protocol Specification), die in der IETF durchgeführt wird

• Eine JavaScript-API-Spezifikation, die in einer Reihe von W3C-Dokumenten [W3C.WD-webrtc] [W3C.WD-mediacapture-streams] definiert ist

Zusammen zielen diese beiden Spezifikationen darauf ab, eine Umgebung bereitzustellen, in der JavaScript, das in eine beliebige Seite eingebettet ist, in der Lage ist, Kommunikation unter Verwendung von Audio, Video und Hilfsdaten herzustellen, wenn es von seinem Benutzer ordnungsgemäß autorisiert wird, solange der Browser diese Spezifikationen unterstützt. Die Browserumgebung schränkt nicht ein, in welchen Arten von Anwendungen diese Funktionalität verwendet werden kann.

Die Protokollspezifikation geht nicht davon aus, dass alle Implementierungen diese API implementieren; es ist nicht beabsichtigt, dass es für die Interoperabilität notwendig sein soll zu wissen, ob die Entität, mit der man kommuniziert, ein Browser oder ein anderes Gerät ist, das die Protokollspezifikation implementiert.

Das Ziel der Zusammenarbeit zwischen der Protokollspezifikation und der API-Spezifikation ist, dass für alle Optionen und Merkmale der Protokollspezifikation klar sein sollte, welche API-Aufrufe durchzuführen sind, um diese Option oder dieses Merkmal auszuüben; ebenso sollte für jede Sequenz von API-Aufrufen klar sein, welche Protokolloptionen und -merkmale aufgerufen werden. Beide unterliegen natürlich Implementierungsbeschränkungen.

Die folgenden Begriffe werden in den Dokumenten verwendet, die die WebRTC-Suite spezifizieren, mit den hier angegebenen spezifischen Bedeutungen. Nicht alle Begriffe werden in diesem Dokument verwendet. Andere Begriffe werden gemäß ihren allgemein verwendeten Bedeutungen verwendet.

Agent: Nicht definierter Begriff. Siehe "SDP Agent" und "ICE Agent".

Application Programming Interface (API) (Anwendungsprogrammierschnittstelle): Eine Spezifikation einer Reihe von Aufrufen und Ereignissen, normalerweise an eine Programmiersprache oder eine abstrakte formale Spezifikation wie WebIDL gebunden, mit ihrer definierten Semantik.

Browser: Synonym verwendet mit "interactive user agent (interaktiver Benutzeragent)", wie in [HTML5] definiert. Siehe auch die Definition "WebRTC Browser (auch bekannt als "WebRTC User Agent")" unten.

Data Channel (Datenkanal): Eine Abstraktion, die das Senden von Daten zwischen WebRTC-Endpunkten in Form von Nachrichten ermöglicht. Zwei Endpunkte können mehrere Datenkanäle zwischen sich haben.

ICE Agent (ICE-Agent): Eine Implementierung des Interactive Connectivity Establishment (ICE)-Protokolls [RFC8445]. Ein ICE-Agent kann auch ein SDP-Agent sein, aber es gibt ICE-Agenten, die SDP nicht verwenden (z. B. solche, die Jingle [XEP-0166] verwenden).

Interactive (Interaktiv): Kommunikation zwischen mehreren Parteien, bei der die Erwartung besteht, dass eine Aktion einer Partei eine Reaktion einer anderen Partei hervorrufen kann und dass die Reaktion von der ersten Partei beobachtet werden kann, wobei die für die Aktion/Reaktion/Beobachtung erforderliche Gesamtzeit in der Größenordnung von einigen hundert Millisekunden oder weniger liegt.

Media (Medien): Audio- und Videoinhalte. Nicht zu verwechseln mit "transmission media (Übertragungsmedien)" wie Drähten.

Media Path (Medienpfad): Der Pfad, dem die Mediendaten von einem WebRTC-Endpunkt zu einem anderen folgen.

Protocol (Protokoll): Eine Spezifikation einer Reihe von Dateneinheiten, ihrer Darstellung und ihrer Übertragungsregeln mit ihrer definierten Semantik. Ein Protokoll wird normalerweise als zwischen Systemen stattfindend betrachtet.

Real-Time Media (Echtzeitmedien): Medien, bei denen die Erzeugung und Anzeige des Inhalts zeitlich eng zusammen auftreten sollen (in der Größenordnung von einigen hundert Millisekunden oder weniger). Echtzeitmedien können zur Unterstützung interaktiver Kommunikation verwendet werden.

SDP Agent (SDP-Agent): Die Protokollimplementierung, die am Offer/Answer-Austausch des Session Description Protocol (SDP) beteiligt ist, wie in [RFC3264], Abschnitt 3, definiert.

Signaling (Signalisierung): Kommunikation, die auftritt, um Medienpfade und Datenpfade zu etablieren, zu verwalten und zu steuern.

Signaling Path (Signalisierungspfad): Die Kommunikationskanäle, die zwischen Entitäten verwendet werden, die an der Signalisierung teilnehmen, um die Signalisierung zu übertragen. Es können mehr Entitäten im Signalisierungspfad sein als im Medienpfad.

WebRTC Browser (WebRTC-Browser) (auch bekannt als "WebRTC User Agent" oder "WebRTC UA"): Etwas, das sowohl der oben genannten Protokollspezifikation als auch der JavaScript-API entspricht.

WebRTC Non-Browser (WebRTC-Nicht-Browser): Etwas, das der Protokollspezifikation entspricht, aber nicht behauptet, die JavaScript-API zu implementieren. Dies kann auch als "WebRTC device (WebRTC-Gerät)" oder "WebRTC native application (WebRTC-Native-Anwendung)" bezeichnet werden.

WebRTC Endpoint (WebRTC-Endpunkt): Entweder ein WebRTC-Browser oder ein WebRTC-Nicht-Browser. Er entspricht der Protokollspezifikation.

WebRTC-Compatible Endpoint (WebRTC-kompatibler Endpunkt): Ein Endpunkt, der in der Lage ist, erfolgreich mit einem WebRTC-Endpunkt zu kommunizieren, aber möglicherweise nicht alle Anforderungen eines WebRTC-Endpunkts erfüllen kann. Dies kann einschränken, wo im Netzwerk ein solcher Endpunkt angeschlossen werden kann, oder kann die Sicherheitsgarantien einschränken, die er anderen bietet. Er ist durch diese Spezifikation nicht eingeschränkt; wenn er überhaupt erwähnt wird, dann um die Auswirkungen auf WebRTC-kompatible Endpunkte der Anforderungen zu beachten, die an WebRTC-Endpunkte gestellt werden.

WebRTC Gateway (WebRTC-Gateway): Ein WebRTC-kompatibler Endpunkt, der Medienverkehr zu Nicht-WebRTC-Entitäten vermittelt.

Alle WebRTC-Browser sind WebRTC-Endpunkte, daher gilt jede Anforderung an einen WebRTC-Endpunkt auch für einen WebRTC-Browser.

Ein WebRTC-Nicht-Browser kann in der Lage sein, Anwendungen auf ähnliche Weise zu hosten, wie ein Browser JavaScript-Anwendungen hosten kann, typischerweise durch das Anbieten von APIs in anderen Sprachen. Beispielsweise kann er als Bibliothek implementiert werden, die eine C++-API anbietet, die zum Laden in Anwendungen bestimmt ist. In diesem Fall können ähnliche Sicherheitsüberlegungen wie für JavaScript erforderlich sein; da solche APIs hier jedoch nicht definiert oder referenziert werden, kann dieses Dokument keine spezifischen Regeln für diese Schnittstellen geben.

WebRTC-Gateways werden in einem separaten Dokument [WebRTC-Gateways] beschrieben.

2.3. On Interoperability and Innovation (Über Interoperabilität und Innovation)

Das "IETF Mission Statement" [RFC3935] besagt, dass "Der Nutzen einer Norm für das Internet in der Interoperabilität liegt -- dass mehrere Produkte, die eine Norm implementieren, zusammenarbeiten können, um wertvolle Funktionen für die Benutzer des Internets bereitzustellen."

Kommunikation im Internet findet häufig in zwei Phasen statt:

• Zwei Parteien kommunizieren durch einen bestimmten Mechanismus, welche Funktionalität sie beide unterstützen können.

• Sie verwenden diese gemeinsame kommunikative Funktionalität zur Kommunikation oder, wenn sie nichts Gemeinsames finden, geben sie die Kommunikation auf.

Für die kommunikative Funktionalität können oft viele Auswahlmöglichkeiten getroffen werden; die Geschichte des Internets ist voll von Vorschlägen, Standardisierung, Implementierung und Erfolg oder Misserfolg vieler Arten von Optionen, in allen Arten von Protokollen.

Das Ziel, einen Satz von obligatorisch zu implementierenden (Mandatory-to-Implement) Funktionen zu haben, besteht darin, das Scheitern der Verhandlung zu verhindern, und nicht darin, die Verhandlung vorwegzunehmen oder zu verhindern.

Das Vorhandensein eines Satzes von obligatorisch zu implementierenden Funktionen dient als mächtiger Modifikator des Bereitstellungsmarktes, indem es eine Garantie bietet, dass Sie erfolgreich kommunizieren können, solange (1) Sie einer Spezifikation entsprechen und (2) die andere Partei bereit ist, Kommunikation auf dem Basisniveau dieser Spezifikation zu akzeptieren.

Die Alternative (d. h. keine obligatorisch zu implementierende Funktion zu haben) bedeutet nicht, dass Sie nicht kommunizieren können; es bedeutet nur, dass Sie, um Teil der Kommunikationspartnerschaft zu sein, den Standard "und dann noch etwas" implementieren müssen. Dieses "und dann noch etwas" wird normalerweise als eine Art Profil (Profile) bezeichnet; in der Version, die der Internet-Ethik am meisten widerspricht, besteht dieses "und dann noch etwas" darin, nur das Produkt eines bestimmten Anbieters verwenden zu müssen.

2.4. Terminology (Terminologie)

Die Schlüsselwörter "MUST (muss)", "MUST NOT (darf nicht)", "REQUIRED (erforderlich)", "SHALL (soll)", "SHALL NOT (soll nicht)", "SHOULD (sollte)", "SHOULD NOT (sollte nicht)", "RECOMMENDED (empfohlen)", "NOT RECOMMENDED (nicht empfohlen)", "MAY (kann)" und "OPTIONAL (optional)" in diesem Dokument sind zu interpretieren wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

---