2. Principles and Terminology (Principes et terminologie)

2.1. Goals of This Document (Objectifs de ce document)

L'objectif de la spécification du protocole WebRTC est de spécifier un ensemble de protocoles qui, s'ils sont tous implémentés, permettront à une implémentation de communiquer avec une autre implémentation en utilisant audio, vidéo et données envoyées le long du chemin le plus direct possible entre les participants.

Ce document est destiné à servir de feuille de route (Roadmap) vers les spécifications WebRTC. Il définit les termes utilisés par d'autres parties des spécifications du protocole WebRTC, liste les références à d'autres spécifications qui n'ont pas besoin d'élaboration supplémentaire dans le contexte WebRTC, et donne des pointeurs vers d'autres documents qui font partie de la suite WebRTC.

En lisant ce document et les documents auxquels il fait référence, il devrait être possible d'avoir toutes les informations nécessaires pour implémenter une implémentation compatible WebRTC.

2.2. Relationship between API and Protocol (Relation entre API et protocole)

L'effort WebRTC total se compose de deux parties principales, chacune composée de plusieurs documents :

• Une spécification de protocole (Protocol Specification), réalisée à l'IETF

• Une spécification d'API JavaScript, définie dans une série de documents du W3C [W3C.WD-webrtc] [W3C.WD-mediacapture-streams]

Ensemble, ces deux spécifications visent à fournir un environnement où le JavaScript intégré dans n'importe quelle page, lorsqu'il est dûment autorisé par son utilisateur, est capable d'établir une communication en utilisant audio, vidéo et données auxiliaires, tant que le navigateur prend en charge ces spécifications. L'environnement du navigateur ne contraint pas les types d'applications dans lesquelles cette fonctionnalité peut être utilisée.

La spécification du protocole ne suppose pas que toutes les implémentations implémentent cette API ; il n'est pas prévu qu'il soit nécessaire pour l'interopérabilité de savoir si l'entité avec laquelle on communique est un navigateur ou un autre dispositif implémentant la spécification du protocole.

L'objectif de la coopération entre la spécification du protocole et la spécification de l'API est que pour toutes les options et fonctionnalités de la spécification du protocole, il doit être clair quels appels d'API effectuer pour exercer cette option ou fonctionnalité ; de même, pour toute séquence d'appels d'API, il doit être clair quelles options et fonctionnalités du protocole seront invoquées. Les deux sont bien sûr soumis aux contraintes de l'implémentation.

Les termes suivants sont utilisés dans les documents spécifiant la suite WebRTC, avec les significations spécifiques données ici. Tous les termes ne sont pas utilisés dans ce document. D'autres termes sont utilisés selon leurs significations couramment utilisées.

Agent : Terme non défini. Voir "SDP Agent" et "ICE Agent".

Application Programming Interface (API) (Interface de programmation d'application) : Une spécification d'un ensemble d'appels et d'événements, généralement liés à un langage de programmation ou à une spécification formelle abstraite telle que WebIDL, avec sa sémantique définie.

Browser (Navigateur) : Utilisé comme synonyme de "interactive user agent (agent utilisateur interactif)" tel que défini dans [HTML5]. Voir également la définition "WebRTC Browser (alias "WebRTC User Agent")" ci-dessous.

Data Channel (Canal de données) : Une abstraction qui permet l'envoi de données entre les endpoints WebRTC sous forme de messages. Deux endpoints peuvent avoir plusieurs canaux de données entre eux.

ICE Agent (Agent ICE) : Une implémentation du protocole Interactive Connectivity Establishment (ICE) [RFC8445]. Un agent ICE peut également être un agent SDP, mais il existe des agents ICE qui n'utilisent pas SDP (par exemple, ceux qui utilisent Jingle [XEP-0166]).

Interactive (Interactif) : Communication entre plusieurs parties, où l'attente est qu'une action d'une partie puisse provoquer une réaction d'une autre partie, et que la réaction puisse être observée par la première partie, où le temps total requis pour l'action/réaction/observation est de l'ordre de quelques centaines de millisecondes au maximum.

Media (Média) : Contenu audio et vidéo. À ne pas confondre avec "transmission media (support de transmission)" tels que les fils.

Media Path (Chemin média) : Le chemin que suivent les données média d'un endpoint WebRTC à un autre.

Protocol (Protocole) : Une spécification d'un ensemble d'unités de données, leur représentation et les règles de leur transmission, avec leur sémantique définie. Un protocole est généralement considéré comme allant entre les systèmes.

Real-Time Media (Média temps réel) : Média où la génération et l'affichage du contenu sont destinés à se produire étroitement ensemble dans le temps (de l'ordre de quelques centaines de millisecondes au maximum). Le média temps réel peut être utilisé pour soutenir la communication interactive.

SDP Agent (Agent SDP) : L'implémentation du protocole impliquée dans l'échange offre/réponse du Session Description Protocol (SDP), tel que défini dans [RFC3264], Section 3.

Signaling (Signalisation) : Communication qui se produit afin d'établir, gérer et contrôler les chemins médias et les chemins de données.

Signaling Path (Chemin de signalisation) : Les canaux de communication utilisés entre les entités participant à la signalisation pour transférer la signalisation. Il peut y avoir plus d'entités dans le chemin de signalisation que dans le chemin média.

WebRTC Browser (Navigateur WebRTC) (également appelé "WebRTC User Agent" ou "WebRTC UA") : Quelque chose qui est conforme à la fois à la spécification du protocole et à l'API JavaScript citée ci-dessus.

WebRTC Non-Browser (WebRTC non-navigateur) : Quelque chose qui est conforme à la spécification du protocole mais ne prétend pas implémenter l'API JavaScript. Cela peut également être appelé "WebRTC device (dispositif WebRTC)" ou "WebRTC native application (application native WebRTC)".

WebRTC Endpoint (Endpoint WebRTC) : Soit un navigateur WebRTC, soit un WebRTC non-navigateur. Il est conforme à la spécification du protocole.

WebRTC-Compatible Endpoint (Endpoint compatible WebRTC) : Un endpoint qui est capable de communiquer avec succès avec un endpoint WebRTC mais peut ne pas satisfaire certaines exigences d'un endpoint WebRTC. Cela peut limiter où dans le réseau un tel endpoint peut être attaché ou peut limiter les garanties de sécurité qu'il offre aux autres. Il n'est pas contraint par cette spécification ; lorsqu'il est mentionné du tout, c'est pour noter les implications sur les endpoints compatibles WebRTC des exigences imposées aux endpoints WebRTC.

WebRTC Gateway (Passerelle WebRTC) : Un endpoint compatible WebRTC qui médie le trafic média vers des entités non-WebRTC.

Tous les navigateurs WebRTC sont des endpoints WebRTC, donc toute exigence sur un endpoint WebRTC s'applique également à un navigateur WebRTC.

Un WebRTC non-navigateur peut être capable d'héberger des applications d'une manière similaire à la manière dont un navigateur peut héberger des applications JavaScript, typiquement en offrant des API dans d'autres langages. Par exemple, il peut être implémenté comme une bibliothèque qui offre une API C++ destinée à être chargée dans les applications. Dans ce cas, des considérations de sécurité similaires à celles pour JavaScript peuvent être nécessaires ; cependant, puisque de telles API ne sont pas définies ou référencées ici, ce document ne peut donner aucune règle spécifique pour ces interfaces.

Les passerelles WebRTC sont décrites dans un document séparé [WebRTC-Gateways].

2.3. On Interoperability and Innovation (Sur l'interopérabilité et l'innovation)

La "Déclaration de mission de l'IETF" [RFC3935] déclare que "L'avantage d'une norme pour Internet est l'interopérabilité - que plusieurs produits implémentant une norme soient capables de travailler ensemble afin de fournir des fonctions précieuses aux utilisateurs d'Internet."

La communication sur Internet se produit fréquemment en deux phases :

• Deux parties communiquent, par un certain mécanisme, quelle fonctionnalité elles sont toutes deux capables de supporter.

• Elles utilisent cette fonctionnalité communicative partagée pour communiquer ou, ne trouvant rien en commun, renoncent à la communication.

Il existe souvent de nombreux choix qui peuvent être faits pour la fonctionnalité communicative ; l'histoire d'Internet est remplie de la proposition, la normalisation, l'implémentation et le succès ou l'échec de nombreux types d'options, dans toutes sortes de protocoles.

L'objectif d'avoir un ensemble de fonctions obligatoires à implémenter (Mandatory-to-Implement) est d'empêcher l'échec de la négociation, et non de préempter ou d'empêcher la négociation.

La présence d'un ensemble de fonctions obligatoires à implémenter sert de puissant modificateur du marché de déploiement en ce qu'elle donne une garantie que vous pouvez communiquer avec succès tant que (1) vous vous conformez à une spécification et (2) l'autre partie est disposée à accepter la communication au niveau de base de cette spécification.

L'alternative (c'est-à-dire, ne pas avoir de fonction obligatoire à implémenter) ne signifie pas que vous ne pouvez pas communiquer ; cela signifie simplement que pour faire partie du partenariat de communication, vous devez implémenter la norme "et puis quelque chose d'autre". Ce "et puis quelque chose d'autre" est généralement appelé un profil (Profile) de quelque sorte ; dans la version la plus antithétique à l'éthique d'Internet, ce "et puis quelque chose d'autre" consiste à devoir utiliser uniquement le produit d'un fournisseur spécifique.

2.4. Terminology (Terminologie)

Les mots-clés "MUST (doit)", "MUST NOT (ne doit pas)", "REQUIRED (requis)", "SHALL (doit)", "SHALL NOT (ne doit pas)", "SHOULD (devrait)", "SHOULD NOT (ne devrait pas)", "RECOMMENDED (recommandé)", "NOT RECOMMENDED (non recommandé)", "MAY (peut)", et "OPTIONAL (optionnel)" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] quand, et seulement quand, ils apparaissent en majuscules, comme indiqué ici.

---