2. Principles and Terminology (Principi e terminologia)

2.1. Goals of This Document (Obiettivi di questo documento)

L'obiettivo della specifica del protocollo WebRTC è specificare un insieme di protocolli che, se tutti implementati, consentiranno a un'implementazione di comunicare con un'altra implementazione utilizzando audio, video e dati inviati lungo il percorso più diretto possibile tra i partecipanti.

Questo documento è inteso a fungere da roadmap alle specifiche WebRTC. Definisce i termini utilizzati da altre parti delle specifiche del protocollo WebRTC, elenca riferimenti ad altre specifiche che non richiedono ulteriore elaborazione nel contesto WebRTC e fornisce puntatori ad altri documenti che fanno parte della suite WebRTC.

Leggendo questo documento e i documenti a cui fa riferimento, dovrebbe essere possibile avere tutte le informazioni necessarie per implementare un'implementazione compatibile con WebRTC.

2.2. Relationship between API and Protocol (Relazione tra API e protocollo)

L'intero sforzo WebRTC è composto da due parti principali, ciascuna composta da più documenti:

• Una specifica del protocollo (Protocol Specification), realizzata presso l'IETF

• Una specifica dell'API JavaScript, definita in una serie di documenti del W3C [W3C.WD-webrtc] [W3C.WD-mediacapture-streams]

Insieme, queste due specifiche mirano a fornire un ambiente in cui JavaScript incorporato in qualsiasi pagina, quando debitamente autorizzato dal suo utente, è in grado di stabilire comunicazioni utilizzando audio, video e dati ausiliari, purché il browser supporti queste specifiche. L'ambiente del browser non vincola i tipi di applicazioni in cui questa funzionalità può essere utilizzata.

La specifica del protocollo non presume che tutte le implementazioni implementino questa API; non è previsto che sia necessario per l'interoperabilità sapere se l'entità con cui si sta comunicando è un browser o un altro dispositivo che implementa la specifica del protocollo.

L'obiettivo della cooperazione tra la specifica del protocollo e la specifica dell'API è che per tutte le opzioni e le funzionalità della specifica del protocollo, dovrebbe essere chiaro quali chiamate API effettuare per esercitare tale opzione o funzionalità; allo stesso modo, per qualsiasi sequenza di chiamate API, dovrebbe essere chiaro quali opzioni e funzionalità del protocollo verranno invocate. Entrambe sono ovviamente soggette a vincoli di implementazione.

I seguenti termini sono utilizzati nei documenti che specificano la suite WebRTC, con i significati specifici qui forniti. Non tutti i termini sono utilizzati in questo documento. Altri termini sono utilizzati secondo i loro significati comunemente usati.

Agent: Termine non definito. Vedere "SDP Agent" e "ICE Agent".

Application Programming Interface (API) (Interfaccia di programmazione dell'applicazione): Una specifica di un insieme di chiamate ed eventi, di solito legati a un linguaggio di programmazione o a una specifica formale astratta come WebIDL, con la sua semantica definita.

Browser: Usato come sinonimo di "interactive user agent (agente utente interattivo)" come definito in [HTML5]. Vedere anche la definizione "WebRTC Browser (alias "WebRTC User Agent")" di seguito.

Data Channel (Canale dati): Un'astrazione che consente l'invio di dati tra gli endpoint WebRTC sotto forma di messaggi. Due endpoint possono avere più canali dati tra loro.

ICE Agent (Agente ICE): Un'implementazione del protocollo Interactive Connectivity Establishment (ICE) [RFC8445]. Un agente ICE può anche essere un agente SDP, ma esistono agenti ICE che non usano SDP (ad esempio, quelli che usano Jingle [XEP-0166]).

Interactive (Interattivo): Comunicazione tra più parti, dove l'aspettativa è che un'azione di una parte possa causare una reazione di un'altra parte e che la reazione possa essere osservata dalla prima parte, dove il tempo totale richiesto per l'azione/reazione/osservazione è dell'ordine di poche centinaia di millisecondi al massimo.

Media: Contenuto audio e video. Da non confondere con "transmission media (supporti di trasmissione)" come i fili.

Media Path (Percorso media): Il percorso che i dati media seguono da un endpoint WebRTC a un altro.

Protocol (Protocollo): Una specifica di un insieme di unità di dati, la loro rappresentazione e le loro regole di trasmissione, con la loro semantica definita. Un protocollo è solitamente considerato come qualcosa che va tra i sistemi.

Real-Time Media (Media tempo reale): Media in cui la generazione e la visualizzazione del contenuto sono destinate a verificarsi strettamente vicine nel tempo (dell'ordine di poche centinaia di millisecondi al massimo). Il media tempo reale può essere utilizzato per supportare la comunicazione interattiva.

SDP Agent (Agente SDP): L'implementazione del protocollo coinvolta nello scambio offerta/risposta del Session Description Protocol (SDP), come definito in [RFC3264], Sezione 3.

Signaling (Segnalazione): Comunicazione che si verifica al fine di stabilire, gestire e controllare i percorsi media e i percorsi dati.

Signaling Path (Percorso di segnalazione): I canali di comunicazione utilizzati tra le entità che partecipano alla segnalazione per trasferire la segnalazione. Possono esserci più entità nel percorso di segnalazione che nel percorso media.

WebRTC Browser (Browser WebRTC) (alias "WebRTC User Agent" o "WebRTC UA"): Qualcosa che è conforme sia alla specifica del protocollo che all'API JavaScript citate sopra.

WebRTC Non-Browser (WebRTC non-browser): Qualcosa che è conforme alla specifica del protocollo ma non dichiara di implementare l'API JavaScript. Questo può anche essere chiamato "WebRTC device (dispositivo WebRTC)" o "WebRTC native application (applicazione nativa WebRTC)".

WebRTC Endpoint (Endpoint WebRTC): Sia un browser WebRTC che un WebRTC non-browser. È conforme alla specifica del protocollo.

WebRTC-Compatible Endpoint (Endpoint compatibile WebRTC): Un endpoint che è in grado di comunicare con successo con un endpoint WebRTC ma potrebbe non soddisfare alcuni requisiti di un endpoint WebRTC. Questo può limitare dove nella rete tale endpoint può essere collegato o può limitare le garanzie di sicurezza che offre agli altri. Non è vincolato da questa specifica; quando è menzionato del tutto, è per notare le implicazioni sugli endpoint compatibili WebRTC dei requisiti imposti sugli endpoint WebRTC.

WebRTC Gateway (Gateway WebRTC): Un endpoint compatibile WebRTC che media il traffico media verso entità non-WebRTC.

Tutti i browser WebRTC sono endpoint WebRTC, quindi qualsiasi requisito su un endpoint WebRTC si applica anche a un browser WebRTC.

Un WebRTC non-browser può essere in grado di ospitare applicazioni in modo simile a come un browser può ospitare applicazioni JavaScript, tipicamente offrendo API in altri linguaggi. Ad esempio, può essere implementato come una libreria che offre un'API C++ destinata a essere caricata nelle applicazioni. In questo caso, potrebbero essere necessarie considerazioni di sicurezza simili a quelle per JavaScript; tuttavia, poiché tali API non sono definite o referenziate qui, questo documento non può fornire regole specifiche per queste interfacce.

I gateway WebRTC sono descritti in un documento separato [WebRTC-Gateways].

2.3. On Interoperability and Innovation (Sull'interoperabilità e l'innovazione)

La "Dichiarazione di missione dell'IETF" [RFC3935] afferma che "Il vantaggio di uno standard per Internet è nell'interoperabilità -- che più prodotti che implementano uno standard siano in grado di lavorare insieme in modo da fornire funzioni preziose agli utenti di Internet."

La comunicazione su Internet si verifica spesso in due fasi:

• Due parti comunicano, attraverso qualche meccanismo, quale funzionalità sono entrambe in grado di supportare.

• Utilizzano quella funzionalità comunicativa condivisa per comunicare o, non trovando nulla in comune, abbandonano la comunicazione.

Ci sono spesso molte scelte che possono essere fatte per la funzionalità comunicativa; la storia di Internet è piena della proposta, standardizzazione, implementazione e successo o fallimento di molti tipi di opzioni, in tutti i tipi di protocolli.

L'obiettivo di avere un insieme di funzioni obbligatorie da implementare (Mandatory-to-Implement) è impedire il fallimento della negoziazione, non prevenire o impedire la negoziazione.

La presenza di un insieme di funzioni obbligatorie da implementare serve come potente modificatore del mercato di distribuzione in quanto fornisce una garanzia che è possibile comunicare con successo purché (1) si sia conformi a una specifica e (2) l'altra parte sia disposta ad accettare la comunicazione al livello di base di quella specifica.

L'alternativa (cioè, non avere una funzione obbligatoria da implementare) non significa che non è possibile comunicare; significa semplicemente che per far parte del partenariato di comunicazione, è necessario implementare lo standard "e poi qualcos'altro". Questo "e poi qualcos'altro" è solitamente chiamato un profilo (Profile) di qualche tipo; nella versione più antitetica all'etica di Internet, questo "e poi qualcos'altro" consiste nel dover utilizzare solo il prodotto di un fornitore specifico.

2.4. Terminology (Terminologia)

Le parole chiave "MUST (deve)", "MUST NOT (non deve)", "REQUIRED (richiesto)", "SHALL (dovrà)", "SHALL NOT (non dovrà)", "SHOULD (dovrebbe)", "SHOULD NOT (non dovrebbe)", "RECOMMENDED (raccomandato)", "NOT RECOMMENDED (non raccomandato)", "MAY (può)" e "OPTIONAL (opzionale)" in questo documento devono essere interpretate come descritto in BCP 14 [RFC2119] [RFC8174] quando, e solo quando, appaiono in maiuscolo, come mostrato qui.

---