1. Introduction
L'utilisation de services Web (API Web) sur Internet est devenue omniprésente dans la plupart des applications et dépend de l'architecture fondamentale REST (Representational State Transfer) du Web.
Les travaux sur les environnements RESTful contraints (CoRE) visent à réaliser l'architecture REST sous une forme adaptée aux nœuds les plus contraints (par exemple, des microcontrôleurs 8 bits avec une RAM et une ROM limitées) et aux réseaux (par exemple, 6LoWPAN, [RFC4944]). Les réseaux contraints tels que 6LoWPAN prennent en charge la fragmentation des paquets IPv6 en petites trames de couche de liaison ; cependant, cela entraîne une réduction significative de la probabilité de livraison des paquets. L'un des objectifs de conception de CoAP a été de maintenir une surcharge de message faible, limitant ainsi le besoin de fragmentation.
L'un des principaux objectifs de CoAP est de concevoir un protocole Web générique pour les exigences particulières de cet environnement contraint, en tenant compte notamment de l'énergie, de l'automatisation des bâtiments et d'autres applications machine à machine (M2M). L'objectif de CoAP n'est pas de compresser aveuglément HTTP [RFC2616], mais plutôt de réaliser un sous-ensemble de REST commun avec HTTP mais optimisé pour les applications M2M. Bien que CoAP puisse être utilisé pour remodeler des interfaces HTTP simples en un protocole plus compact, il offre surtout des fonctionnalités pour le M2M telles que la découverte intégrée, la prise en charge de la multidiffusion et les échanges de messages asynchrones.
Ce document spécifie le protocole d'application contraint (CoAP), qui se traduit facilement en HTTP pour l'intégration avec le Web existant tout en répondant à des exigences spécialisées telles que la prise en charge de la multidiffusion, une très faible surcharge et la simplicité pour les environnements contraints et les applications M2M.
1.1. Fonctionnalités
CoAP possède les principales fonctionnalités suivantes :
o Protocole Web répondant aux exigences M2M dans les environnements contraints
o Liaison UDP [RFC0768] avec fiabilité optionnelle prenant en charge les requêtes unicast et multicast.
o Échanges de messages asynchrones.
o Faible surcharge d'en-tête et complexité d'analyse.
o Prise en charge des URI et des types de contenu.
o Capacités simples de proxy et de mise en cache.
o Un mappage HTTP sans état, permettant de construire des proxys fournissant un accès aux ressources CoAP via HTTP de manière uniforme ou permettant de réaliser des interfaces simples HTTP alternativement sur CoAP.
o Liaison de sécurité avec DTLS (Datagram Transport Layer Security) [RFC6347].
1.2. Terminologie
Les mots clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans [RFC2119] lorsqu'ils apparaissent EN MAJUSCULES. Ces mots peuvent également apparaître dans ce document en minuscules, sans leur signification normative.
Cette spécification exige que les lecteurs soient familiarisés avec tous les termes et concepts abordés dans [RFC2616], y compris "ressource", "représentation", "cache" et "frais". (Ayant été achevée avant que l'ensemble mis à jour des RFC HTTP, RFC 7230 à RFC 7235, ne soit disponible, cette spécification fait spécifiquement référence à la version précédente -- RFC 2616.) De plus, cette spécification définit la terminologie suivante :
Endpoint (Point de terminaison) Une entité participant au protocole CoAP. Familièrement, un point de terminaison vit sur un "Nœud", bien que "Hôte" soit plus cohérent avec l'usage des normes Internet, et est identifié en outre par des informations de multiplexage de la couche transport qui peuvent inclure un numéro de port UDP et une association de sécurité (Section 4.1).
Sender (Expéditeur) Le point de terminaison d'origine d'un message. Lorsque l'aspect de l'identification de l'expéditeur spécifique est au centre de l'attention, on parle aussi de "point de terminaison source".
Recipient (Destinataire) Le point de terminaison de destination d'un message. Lorsque l'aspect de l'identification du destinataire spécifique est au centre de l'attention, on parle aussi de "point de terminaison de destination".
Client Le point de terminaison d'origine d'une requête ; le point de terminaison de destination d'une réponse.
Server (Serveur) Le point de terminaison de destination d'une requête ; le point de terminaison d'origine d'une réponse.
Origin Server (Serveur d'origine) Le serveur sur lequel une ressource donnée réside ou doit être créée.
Intermediary (Intermédiaire) Un point de terminaison CoAP qui agit à la fois comme un serveur et comme un client envers un serveur d'origine (éventuellement via d'autres intermédiaires). Une forme courante d'intermédiaire est un proxy ; plusieurs classes de tels proxys sont discutées dans cette spécification.
Proxy Un intermédiaire qui s'occupe principalement de transmettre les requêtes et de relayer les réponses, effectuant éventuellement une mise en cache, une traduction d'espace de noms ou une traduction de protocole dans le processus. Contrairement aux intermédiaires au sens général, les proxys n'implémentent généralement pas de sémantique d'application spécifique. En fonction de la position dans la structure globale de transfert des requêtes, il existe deux formes courantes de proxy : le proxy direct (forward-proxy) et le proxy inverse (reverse-proxy). Dans certains cas, un seul point de terminaison peut agir comme un serveur d'origine, un proxy direct ou un proxy inverse, changeant de comportement en fonction de la nature de chaque requête.
Forward-Proxy (Proxy direct) Un point de terminaison sélectionné par un client, généralement via des règles de configuration locales, pour effectuer des requêtes au nom du client, en effectuant toutes les traductions nécessaires. Certaines traductions sont minimes, comme pour les requêtes de proxy pour les URI "coap", tandis que d'autres requêtes peuvent nécessiter une traduction vers et depuis des protocoles de couche d'application entièrement différents.
Reverse-Proxy (Proxy inverse) Un point de terminaison qui remplace un ou plusieurs autres serveur(s) et satisfait les requêtes au nom de ceux-ci, en effectuant toutes les traductions nécessaires. Contrairement à un proxy direct, le client peut ne pas être conscient qu'il communique avec un proxy inverse ; un proxy inverse reçoit les requêtes comme s'il était le serveur d'origine pour la ressource cible.
CoAP-to-CoAP Proxy (Proxy CoAP vers CoAP) Un proxy qui mappe une requête CoAP vers une requête CoAP, c'est-à-dire qu'il utilise le protocole CoAP à la fois côté serveur et côté client. À opposer au cross-proxy.
Cross-Proxy (Proxy croisé) Un proxy inter-protocole, ou "cross-proxy" en abrégé, est un proxy qui traduit entre différents protocoles, tel qu'un proxy CoAP vers HTTP ou un proxy HTTP vers CoAP. Bien que cette spécification formule des exigences très spécifiques pour les proxys CoAP vers CoAP, il existe plus de variations possibles dans les proxys croisés.
Confirmable Message (Message confirmable) Certains messages nécessitent un accusé de réception. Ces messages sont appelés "Confirmable". Lorsqu'aucun paquet n'est perdu, chaque message Confirmable suscite exactement un message de retour de type Acknowledgement (Accusé de réception) ou de type Reset (Réinitialisation).
Non-confirmable Message (Message non confirmable) D'autres messages ne nécessitent pas d'accusé de réception. C'est particulièrement vrai pour les messages qui sont répétés régulièrement pour les besoins de l'application, tels que les lectures répétées d'un capteur.
Acknowledgement Message (Message d'accusé de réception) Un message d'accusé de réception reconnaît qu'un message Confirmable spécifique est arrivé. En soi, un message d'accusé de réception n'indique pas le succès ou l'échec d'une requête encapsulée dans le message Confirmable, mais le message d'accusé de réception peut également transporter une réponse superposée (Piggybacked Response) (voir ci-dessous).
Reset Message (Message de réinitialisation) Un message de réinitialisation indique qu'un message spécifique (Confirmable ou Non-confirmable) a été reçu, mais qu'il manque un certain contexte pour le traiter correctement. Cette condition est généralement causée lorsque le nœud récepteur a redémarré et a oublié un certain état qui serait nécessaire pour interpréter le message. Provoquer un message de réinitialisation (par exemple, en envoyant un message Confirmable vide) est également utile comme vérification peu coûteuse de la vivacité d'un point de terminaison ("CoAP ping").
Piggybacked Response (Réponse superposée) Une réponse superposée est incluse directement dans un message d'accusé de réception (ACK) CoAP qui est envoyé pour accuser réception de la requête pour cette réponse (Section 5.2.1).
Separate Response (Réponse séparée) Lorsqu'un message Confirmable transportant une requête est acquitté par un message vide (par exemple, parce que le serveur n'a pas la réponse tout de suite), une réponse séparée est envoyée dans un échange de messages séparé (Section 5.2.2).
Empty Message (Message vide) Un message avec un code de 0.00 ; ni une requête ni une réponse. Un message vide contient uniquement l'en-tête de 4 octets.
Critical Option (Option critique) Une option qui devrait être comprise par le point de terminaison recevant finalement le message afin de traiter correctement le message (Section 5.4.1). Notez que l'implémentation des options critiques est, comme le nom "Option" l'indique, généralement optionnelle : les options critiques non prises en charge entraînent une réponse d'erreur ou un rejet sommaire du message.
Elective Option (Option élective) Une option qui est destinée à être ignorée par un point de terminaison qui ne la comprend pas. Le traitement du message même sans comprendre l'option est acceptable (Section 5.4.1).
Unsafe Option (Option non sûre) Une option qui devrait être comprise par un proxy recevant le message afin de transmettre le message en toute sécurité (Section 5.4.2). Toutes les options critiques ne sont pas des options non sûres.
Safe-to-Forward Option (Option sûre à transmettre) Une option qui est destinée à être sûre pour la transmission par un proxy qui ne la comprend pas. La transmission du message même sans comprendre l'option est acceptable (Section 5.4.2).
Resource Discovery (Découverte de ressources) Le processus par lequel un client CoAP interroge un serveur pour sa liste de ressources hébergées (c'est-à-dire, des liens tels que définis dans la Section 7).
Content-Format (Format de contenu) La combinaison d'un type de média Internet, éventuellement avec des paramètres spécifiques donnés, et d'un codage de contenu (qui est souvent le codage de contenu d'identité), identifié par un identifiant numérique défini par le registre "CoAP Content-Formats". Lorsque l'accent est moins mis sur l'identifiant numérique que sur la combinaison de ces caractéristiques d'une représentation de ressource, cela est également appelé "format de représentation".
Une terminologie supplémentaire pour les nœuds contraints et les réseaux de nœuds contraints peut être trouvée dans [RFC7228].
Dans cette spécification, le terme "byte" est utilisé dans son sens désormais coutumier comme synonyme d'"octet".
Tous les entiers multi-octets dans ce protocole sont interprétés dans l'ordre des octets du réseau.
Là où l'arithmétique est utilisée, cette spécification utilise la notation familière du langage de programmation C, sauf que l'opérateur "**" représente l'exponentiation.