1. Introduction

L'utilisation des services web (APIs web) sur Internet est devenue omniprésente dans la plupart des applications et dépend de l'architecture fondamentale Representational State Transfer [REST] du Web.

Les travaux sur les Constrained RESTful Environments (CoRE) visent à réaliser l'architecture REST sous une forme adaptée aux nœuds les plus contraints (par exemple, les microcontrôleurs 8 bits avec des quantités limitées de RAM et ROM) 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 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 la surcharge des messages 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 spéciales de cet environnement contraint, en tenant particulièrement compte de l'énergie, de l'automatisation des bâtiments et d'autres applications machine-à-machine (M2M). L'objectif de CoAP n'est pas de comprimer 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 refaçonner des interfaces HTTP simples en un protocole plus compact, plus important encore, il offre également des fonctionnalités pour M2M telles que la découverte intégrée, le support multicast et les échanges de messages asynchrones.

Ce document spécifie le Constrained Application Protocol (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 le support multicast, une très faible surcharge et la simplicité pour les environnements contraints et les applications M2M.

1.1. Features (Fonctionnalités)

CoAP possède les principales fonctionnalités suivantes:

• Protocole web répondant aux exigences M2M dans des environnements contraints

• Liaison UDP [RFC0768] avec fiabilité optionnelle prenant en charge les requêtes unicast et multicast.

• Échanges de messages asynchrones.

• Faible surcharge d'en-tête et complexité d'analyse.

• Support des URI et du type de contenu.

• Capacités simples de proxy et de mise en cache.

• Un mappage HTTP sans état, permettant de construire des proxies fournissant un accès aux ressources CoAP via HTTP de manière uniforme ou pour que les interfaces simples HTTP soient réalisées alternativement sur CoAP.

• Liaison de sécurité à Datagram Transport Layer Security (DTLS) [RFC6347].

1.2. Terminology (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 familiers avec tous les termes et concepts qui sont discutés dans [RFC2616], y compris "resource" (ressource), "representation" (représentation), "cache" (cache), et "fresh" (frais). (Ayant été complétée avant que l'ensemble mis à jour des RFC HTTP, RFC 7230 à RFC 7235, ne devienne disponible, cette spécification fait spécifiquement référence à la version prédécesseur -- 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 "Node" (nœud), bien que "Host" (hôte) soit plus cohérent avec l'usage des standards Internet, et est en outre identifié par des informations de multiplexage de couche transport qui peuvent inclure un numéro de port UDP et une association de sécurité (Section 4.1).

Sender (Émetteur) : Le point de terminaison d'origine d'un message. Lorsque l'aspect d'identification de l'émetteur spécifique est au centre, également appelé "source endpoint" (point de terminaison source).

Recipient (Destinataire) : Le point de terminaison de destination d'un message. Lorsque l'aspect d'identification du destinataire spécifique est au centre, également appelé "destination endpoint" (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 vers un serveur d'origine (éventuellement via d'autres intermédiaires). Une forme courante d'intermédiaire est un proxy; plusieurs classes de tels proxies sont discutées dans cette spécification.

Proxy : Un intermédiaire qui est principalement concerné par le transfert de requêtes et le relais de réponses, effectuant éventuellement la mise en cache, la traduction d'espace de noms ou la traduction de protocole dans le processus. Contrairement aux intermédiaires au sens général, les proxies n'implémentent généralement pas de sémantique d'application spécifique. En fonction de la position dans la structure globale du transfert de requête, il existe deux formes courantes de proxy: forward-proxy (proxy direct) et reverse-proxy (proxy inverse). Dans certains cas, un seul point de terminaison peut agir comme un serveur d'origine, un proxy direct ou un proxy inverse, en 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 les traductions nécessaires. Certaines traductions sont minimales, comme pour les requêtes proxy pour les URI "coap", tandis que d'autres requêtes peuvent nécessiter une traduction vers et depuis des protocoles de couche application entièrement différents.

Reverse-Proxy (Proxy inverse) : Un point de terminaison qui représente un ou plusieurs autres serveurs et satisfait les requêtes en leur nom, en effectuant 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 des 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 d'une requête CoAP à une requête CoAP, c'est-à-dire utilise le protocole CoAP à la fois côté serveur et côté client. À contraster avec cross-proxy.

Cross-Proxy (Proxy inter-protocoles) : Un proxy inter-protocoles, ou "cross-proxy" en abrégé, est un proxy qui traduit entre différents protocoles, tels qu'un proxy CoAP vers HTTP ou un proxy HTTP vers CoAP. Alors que cette spécification fait des demandes très spécifiques aux proxies CoAP vers CoAP, il y a plus de variation possible dans les cross-proxies.

Confirmable Message (Message confirmable) : Certains messages nécessitent un accusé de réception. Ces messages sont appelés "Confirmable" (confirmables). 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) : Certains autres messages ne nécessitent pas d'accusé de réception. Cela est particulièrement vrai pour les messages qui sont répétés régulièrement pour des exigences d'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 de toute requête encapsulée dans le message confirmable, mais le message d'accusé de réception peut également porter une Piggybacked Response (réponse embarquée) (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'un certain contexte manque 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 embarquée) : Une réponse embarquée est incluse directement dans un message CoAP Acknowledgement (ACK) 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 portant une requête est accusé de réception avec 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 doit ê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'implique, généralement optionnelle: les options critiques non prises en charge conduisent à une réponse d'erreur ou au 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. Traiter le message même sans comprendre l'option est acceptable (Section 5.4.1).

Unsafe Option (Option non sûre) : Une option qui doit être comprise par un proxy recevant le message afin de transférer 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 à transférer) : Une option qui est destinée à être sûre pour le transfert par un proxy qui ne la comprend pas. Transférer le 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, les liens tels que définis dans la Section 7).

Content-Format (Format de contenu) : La combinaison d'un type de média Internet, potentiellement avec des paramètres spécifiques donnés, et d'un codage de contenu (qui est souvent le codage de contenu 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é "representation format" (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" (octet) est utilisé dans son sens désormais coutumier comme synonyme de "octet".

Tous les entiers multi-octets dans ce protocole sont interprétés en ordre des octets réseau.