1. Introduction

1. Introduction

De nombreuses applications sur appareils mobiles et embarqués ont besoin d'un accès continu aux communications réseau afin que des événements en temps réel, tels que des appels entrants ou des messages, puissent être livrés (ou « poussés ») rapidement. Ces appareils disposent généralement de réserves d'énergie limitées ; trouver des moyens plus efficaces de satisfaire les besoins des applications profite donc à tout l'écosystème.

Une contribution importante à la consommation d'énergie est la radio. Les communications radio consomment une part significative du budget énergétique d'un appareil sans fil.

L'utilisation non coordonnée de connexions ou sessions persistantes par plusieurs applications peut contribuer à une utilisation inutile de la radio de l'appareil, car chaque session indépendante peut entraîner ses propres surcoûts. En particulier, le trafic de maintien de session utilisé pour éviter que les middleboxes ne ferment prématurément les sessions peut entraîner un gaspillage important. À long terme, le trafic de maintenance tend à dominer, les événements étant relativement rares.

Regrouper tous les événements temps réel dans une seule session assure une utilisation plus efficace des ressources réseau et radio. Un service unique consolide tous les événements et les distribue aux applications à leur arrivée. Une seule session suffit, ce qui évite des surcoûts dupliqués.

La Push API du W3C [API] décrit une API permettant l'utilisation d'un service push consolidé (consolidated push service) depuis les applications Web. Le présent document complète ce travail en décrivant un protocole permettant de :

• demander la livraison d'un push message (message poussé) à un user agent (agent utilisateur),

• créer de nouveaux abonnements à la livraison de messages poussés, et

• surveiller l'arrivée de nouveaux messages poussés.

Une méthode normalisée de livraison d'événements est particulièrement importante pour la Push API du W3C, où les serveurs d'application peuvent devoir utiliser plusieurs services push. Les fonctions d'abonnement, de gestion et de surveillance sont aujourd'hui assurées par des protocoles propriétaires ; ils sont adéquats mais n'offrent aucun des avantages de la normalisation.

Le présent document ne décrit pas intentionnellement comment découvrir un service push. La découverte est laissée à de futurs travaux, si elle s'avère nécessaire. Les user agents sont censés être configurés avec une URL de service push.

1.1. Conventions and Terminology

Les mots clés « MUST », « MUST NOT », « REQUIRED », « SHALL », « SHALL NOT », « SHOULD », « SHOULD NOT », « RECOMMENDED », « MAY » et « OPTIONAL » dans ce document doivent être interprétés comme décrit dans [RFC2119].

Ce document définit les termes suivants :

application : à la fois l'émetteur et le consommateur final des messages poussés. De nombreuses applications ont des composants exécutés sur le user agent et d'autres sur des serveurs.

application server : le composant d'une application qui s'exécute généralement sur un serveur et demande la livraison d'un message poussé.

push message subscription : un contexte de livraison de messages établi entre le user agent et le push service (service push), partagé avec le serveur d'application. Tous les messages poussés sont associés à un abonnement.

push message subscription set : un contexte de livraison établi entre le user agent et le service push qui regroupe plusieurs abonnements en un ensemble.

push message : un message envoyé du serveur d'application au user agent via le service push.

push message receipt : une confirmation de livraison envoyée du service push au serveur d'application.

push service : un service qui livre des messages poussés aux user agents.

user agent : un appareil et un logiciel qui reçoivent les messages poussés.

Les exemples utilisent le format de messages HTTP/1.1 [RFC7230]. Nombre d'échanges peuvent se faire en HTTP/1.1 :

• Abonnement aux messages poussés (section 4)

• Demande de livraison (section 5)

• Remplacement de messages poussés (section 5.4)

• Accusé de réception (section 6.2)

Lorsqu'un exemple dépend du server push HTTP/2, le format de trames plus verbeux de [RFC7540] est utilisé :

• Réception pour un abonnement (section 6)

• Réception pour un ensemble d'abonnements (section 6.1)

• Réception des accusés de livraison (section 6.3)

Tous les exemples utilisent HTTPS sur le port par défaut (443) plutôt que le port enregistré (1001). Un déploiement peut préférer cette configuration pour maximiser l'accessibilité. Un service push peut utiliser les services alternatifs HTTP pour rediriger vers le port 1001 (voir section 3). Cela n'apparaît dans les exemples que via le champ d'en-tête Alt-Used [RFC7838].

Les exemples n'incluent pas de méthodes spécifiques de chiffrement ou d'authentification du serveur d'application car le protocole n'en impose pas. Les exemples dans [VAPID] et [ENCRYPT] illustrent l'approche de la Push API du W3C [API].