1. Introduction
1. Introduction
Molte applicazioni su dispositivi mobili ed embedded richiedono accesso continuo alla rete perché eventi in tempo reale (chiamate, messaggi) siano consegnati (o «in push») tempestivamente. Tali dispositivi hanno spesso riserve energetiche limitate; modi più efficienti di soddisfare le esigenze delle applicazioni beneficiano l'intero ecosistema.
Un contributo significativo al consumo è la radio; le comunicazioni radio assorbono gran parte del budget energetico.
L'uso non coordinato di connessioni o sessioni persistenti da più applicazioni può aumentare l'uso della radio, perché ogni sessione ha overhead. In particolare il traffico keep-alive contro timeout prematuri delle middlebox può sprecare risorse. A lungo termine domina il traffico di manutenzione, essendo gli eventi rari.
Consolidare tutti gli eventi in tempo reale in una singola sessione rende più efficiente rete e radio. Un solo servizio aggrega gli eventi e li distribuisce alle applicazioni. Serve una sola sessione, evitando overhead duplicato.
La Push API del W3C [API] descrive un'API per usare un push service consolidato dalle applicazioni Web. Questo documento estende quel lavoro con un protocollo per:
-
richiedere la consegna di un push message a un user agent,
-
creare nuovi abbonamenti alla consegna push e
-
monitorare nuovi push message.
Un metodo standardizzato è particolarmente importante per la Push API del W3C, dove i server applicativi possono usare più push service. Abbonamento, gestione e monitoraggio sono oggi coperti da protocolli proprietari; sono adeguati ma non offrono i vantaggi della standardizzazione.
Questo documento non descrive intenzionalmente come scoprire un push service; la scoperta è lasciata a lavori futuri. Si presume che gli user agent siano configurati con un URL del push service.
1.1. Conventions and Terminology
Le parole chiave «MUST», «MUST NOT», «REQUIRED», «SHALL», «SHALL NOT», «SHOULD», «SHOULD NOT», «RECOMMENDED», «MAY» e «OPTIONAL» si interpretano come in [RFC2119].
Termini definiti:
application: sia mittente sia consumatore finale dei push message. Molte applicazioni hanno componenti sull'user agent e sui server.
application server: componente che di solito gira su server e richiede la consegna di un push message.
push message subscription: contesto di consegna tra user agent e push service, condiviso col server applicativo. Ogni push message è associato a un abbonamento.
push message subscription set: contesto che raccoglie più abbonamenti in un insieme.
push message: messaggio dal server applicativo all'user agent tramite push service.
push message receipt: conferma di consegna dal push service al server applicativo.
push service: servizio che consegna push message agli user agent.
user agent: dispositivo e software destinatario dei push message.
Gli esempi usano il formato HTTP/1.1 [RFC7230]. Molti scambi possono usare HTTP/1.1: sottoscrizione (sezione 4), richiesta di consegna (5), sostituzione (5.4), acknowledgment (6.2). Quando serve HTTP/2 server push si usa il formato trame di [RFC7540]: ricezione (6), insieme di abbonamenti (6.1), ricevute (6.3).
Tutti gli esempi usano HTTPS sulla porta 443 anziché la porta registrata 1001. Un push service può usare HTTP Alternative Services [RFC7838] (sezione 3); negli esempi ciò può apparire come Alt-Used [RFC7838].
Gli esempi non includono metodi obbligatori di cifratura o autenticazione del server applicativo. [VAPID] e [ENCRYPT] mostrano l'approccio della Push API del W3C [API].