1. Introduction (Einführung)

Die Nutzung von Webdiensten (Web-APIs) im Internet ist in den meisten Anwendungen allgegenwärtig geworden und hängt von der grundlegenden Representational State Transfer [REST] Architektur des Web ab.

Die Arbeit an Constrained RESTful Environments (CoRE) zielt darauf ab, die REST-Architektur in einer geeigneten Form für die am stärksten eingeschränkten Knoten (z.B. 8-Bit-Mikrocontroller mit begrenztem RAM und ROM) und Netzwerke (z.B. 6LoWPAN, [RFC4944]) zu realisieren. Eingeschränkte Netzwerke wie 6LoWPAN unterstützen die Fragmentierung von IPv6-Paketen in kleine Link-Layer-Frames; dies führt jedoch zu einer erheblichen Verringerung der Paketzustellungswahrscheinlichkeit. Eines der Designziele von CoAP bestand darin, den Nachrichten-Overhead klein zu halten und damit die Notwendigkeit einer Fragmentierung zu begrenzen.

Eines der Hauptziele von CoAP ist es, ein generisches Webprotokoll für die speziellen Anforderungen dieser eingeschränkten Umgebung zu entwerfen, insbesondere unter Berücksichtigung von Energie, Gebäudeautomation und anderen Machine-to-Machine (M2M) Anwendungen. Das Ziel von CoAP ist es nicht, HTTP [RFC2616] blind zu komprimieren, sondern vielmehr eine Teilmenge von REST zu realisieren, die mit HTTP gemeinsam ist, aber für M2M-Anwendungen optimiert wurde. Obwohl CoAP verwendet werden könnte, um einfache HTTP-Schnittstellen in ein kompakteres Protokoll umzuwandeln, bietet es darüber hinaus auch Funktionen für M2M wie integrierte Discovery, Multicast-Unterstützung und asynchronen Nachrichtenaustausch.

Dieses Dokument spezifiziert das Constrained Application Protocol (CoAP), das sich leicht in HTTP übersetzen lässt, um mit dem bestehenden Web integriert zu werden, während es spezialisierte Anforderungen wie Multicast-Unterstützung, sehr geringen Overhead und Einfachheit für eingeschränkte Umgebungen und M2M-Anwendungen erfüllt.

1.1. Features (Funktionen)

CoAP hat folgende Hauptfunktionen:

• Webprotokoll, das M2M-Anforderungen in eingeschränkten Umgebungen erfüllt

• UDP [RFC0768] Bindung mit optionaler Zuverlässigkeit, die Unicast- und Multicast-Anfragen unterstützt.

• Asynchroner Nachrichtenaustausch.

• Geringer Header-Overhead und Parsing-Komplexität.

• URI- und Content-Type-Unterstützung.

• Einfache Proxy- und Caching-Fähigkeiten.

• Ein zustandsloses HTTP-Mapping, das es ermöglicht, Proxies zu bauen, die einheitlichen Zugriff auf CoAP-Ressourcen über HTTP bereitstellen, oder einfache HTTP-Schnittstellen alternativ über CoAP zu realisieren.

• Sicherheitsbindung an Datagram Transport Layer Security (DTLS) [RFC6347].

1.2. Terminology (Terminologie)

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", und "OPTIONAL" in diesem Dokument MÜSSEN wie in [RFC2119] beschrieben interpretiert werden, wenn sie in GROSSBUCHSTABEN erscheinen. Diese Wörter können auch in Kleinbuchstaben in diesem Dokument erscheinen, ohne ihre normative Bedeutung.

Diese Spezifikation erfordert, dass die Leser mit allen Begriffen und Konzepten vertraut sind, die in [RFC2616] diskutiert werden, einschließlich "resource" (Ressource), "representation" (Darstellung), "cache" (Cache), und "fresh" (frisch). (Da diese Spezifikation abgeschlossen wurde, bevor der aktualisierte Satz von HTTP RFCs, RFC 7230 bis RFC 7235, verfügbar wurde, referenziert diese Spezifikation speziell die Vorgängerversion -- RFC 2616.) Darüber hinaus definiert diese Spezifikation die folgende Terminologie:

Endpoint (Endpunkt) : Eine Entität, die am CoAP-Protokoll teilnimmt. Umgangssprachlich lebt ein Endpunkt auf einem "Node" (Knoten), obwohl "Host" konsistenter mit der Verwendung von Internet-Standards wäre, und wird weiter identifiziert durch Transport-Layer-Multiplexing-Informationen, die eine UDP-Portnummer und eine Sicherheitsassoziation umfassen können (Section 4.1).

Sender (Absender) : Der ursprüngliche Endpunkt einer Nachricht. Wenn der Aspekt der Identifizierung des spezifischen Absenders im Fokus steht, auch "source endpoint" (Quellendpunkt) genannt.

Recipient (Empfänger) : Der Zielendpunkt einer Nachricht. Wenn der Aspekt der Identifizierung des spezifischen Empfängers im Fokus steht, auch "destination endpoint" (Zielendpunkt) genannt.

Client : Der ursprüngliche Endpunkt einer Anfrage; der Zielendpunkt einer Antwort.

Server : Der Zielendpunkt einer Anfrage; der ursprüngliche Endpunkt einer Antwort.

Origin Server (Ursprungsserver) : Der Server, auf dem eine bestimmte Ressource existiert oder erstellt werden soll.

Intermediary (Vermittler) : Ein CoAP-Endpunkt, der sowohl als Server als auch als Client in Richtung eines Ursprungsservers agiert (möglicherweise über weitere Vermittler). Eine häufige Form eines Vermittlers ist ein Proxy; mehrere Klassen solcher Proxies werden in dieser Spezifikation diskutiert.

Proxy : Ein Vermittler, der hauptsächlich mit der Weiterleitung von Anfragen und dem Weiterleiten von Antworten befasst ist und dabei möglicherweise Caching, Namespace-Translation oder Protokoll-Translation durchführt. Im Gegensatz zu Vermittlern im allgemeinen Sinne implementieren Proxies im Allgemeinen keine spezifische Anwendungssemantik. Basierend auf der Position in der Gesamtstruktur der Anfragenweiterleitung gibt es zwei gängige Formen von Proxies: Forward-Proxy und Reverse-Proxy. In einigen Fällen kann ein einzelner Endpunkt als Ursprungsserver, Forward-Proxy oder Reverse-Proxy agieren und sein Verhalten je nach Art jeder Anfrage ändern.

Forward-Proxy (Vorwärts-Proxy) : Ein von einem Client ausgewählter Endpunkt, normalerweise über lokale Konfigurationsregeln, um Anfragen im Namen des Clients auszuführen und dabei alle notwendigen Übersetzungen durchzuführen. Einige Übersetzungen sind minimal, wie z.B. für Proxy-Anfragen für "coap"-URIs, während andere Anfragen möglicherweise eine Übersetzung zu und von völlig unterschiedlichen Application-Layer-Protokollen erfordern.

Reverse-Proxy (Rückwärts-Proxy) : Ein Endpunkt, der für einen oder mehrere andere Server steht und Anfragen in deren Namen erfüllt, wobei alle notwendigen Übersetzungen durchgeführt werden. Im Gegensatz zu einem Forward-Proxy ist sich der Client möglicherweise nicht bewusst, dass er mit einem Reverse-Proxy kommuniziert; ein Reverse-Proxy empfängt Anfragen, als wäre er der Ursprungsserver für die Zielressource.

CoAP-to-CoAP Proxy (CoAP-zu-CoAP-Proxy) : Ein Proxy, der von einer CoAP-Anfrage auf eine CoAP-Anfrage abbildet, d.h. das CoAP-Protokoll sowohl auf der Server- als auch auf der Client-Seite verwendet. Im Gegensatz zu Cross-Proxy.

Cross-Proxy (Kreuz-Proxy) : Ein Cross-Protocol-Proxy, oder kurz "Cross-Proxy", ist ein Proxy, der zwischen verschiedenen Protokollen übersetzt, wie z.B. ein CoAP-zu-HTTP-Proxy oder ein HTTP-zu-CoAP-Proxy. Während diese Spezifikation sehr spezifische Anforderungen an CoAP-zu-CoAP-Proxies stellt, ist bei Cross-Proxies mehr Variation möglich.

Confirmable Message (Bestätigbare Nachricht) : Einige Nachrichten erfordern eine Bestätigung. Diese Nachrichten werden "Confirmable" (bestätigbar) genannt. Wenn keine Pakete verloren gehen, löst jede bestätigbare Nachricht genau eine Rückgabenachricht vom Typ Acknowledgement (Bestätigung) oder vom Typ Reset (Zurücksetzen) aus.

Non-confirmable Message (Nicht-bestätigbare Nachricht) : Einige andere Nachrichten erfordern keine Bestätigung. Dies gilt insbesondere für Nachrichten, die aus Anwendungsanforderungen heraus regelmäßig wiederholt werden, wie z.B. wiederholte Ablesungen von einem Sensor.

Acknowledgement Message (Bestätigungsnachricht) : Eine Bestätigungsnachricht bestätigt, dass eine bestimmte bestätigbare Nachricht angekommen ist. Eine Bestätigungsnachricht allein zeigt nicht den Erfolg oder Misserfolg einer in der bestätigbaren Nachricht gekapselten Anfrage an, aber die Bestätigungsnachricht kann auch eine Piggybacked Response (Huckepack-Antwort) tragen (siehe unten).

Reset Message (Zurücksetzungsnachricht) : Eine Zurücksetzungsnachricht zeigt an, dass eine bestimmte Nachricht (bestätigbar oder nicht-bestätigbar) empfangen wurde, aber ein gewisser Kontext fehlt, um sie ordnungsgemäß zu verarbeiten. Dieser Zustand wird normalerweise verursacht, wenn der empfangende Knoten neu gestartet wurde und einen bestimmten Zustand vergessen hat, der erforderlich wäre, um die Nachricht zu interpretieren. Das Provozieren einer Zurücksetzungsnachricht (z.B. durch Senden einer leeren bestätigbaren Nachricht) ist auch nützlich als kostengünstige Überprüfung der Lebendigkeit eines Endpunkts ("CoAP-Ping").

Piggybacked Response (Huckepack-Antwort) : Eine Huckepack-Antwort ist direkt in einer CoAP-Acknowledgement (ACK) Nachricht enthalten, die gesendet wird, um den Empfang der Anfrage für diese Antwort zu bestätigen (Section 5.2.1).

Separate Response (Separate Antwort) : Wenn eine bestätigbare Nachricht, die eine Anfrage trägt, mit einer leeren Nachricht bestätigt wird (z.B. weil der Server die Antwort nicht sofort hat), wird eine separate Antwort in einem separaten Nachrichtenaustausch gesendet (Section 5.2.2).

Empty Message (Leere Nachricht) : Eine Nachricht mit einem Code von 0.00; weder eine Anfrage noch eine Antwort. Eine leere Nachricht enthält nur den 4-Byte-Header.

Critical Option (Kritische Option) : Eine Option, die vom Endpunkt, der die Nachricht letztendlich empfängt, verstanden werden müsste, um die Nachricht ordnungsgemäß zu verarbeiten (Section 5.4.1). Beachten Sie, dass die Implementierung kritischer Optionen, wie der Name "Option" impliziert, im Allgemeinen optional ist: nicht unterstützte kritische Optionen führen zu einer Fehlerantwort oder zur zusammenfassenden Ablehnung der Nachricht.

Elective Option (Wahlweise Option) : Eine Option, die von einem Endpunkt, der sie nicht versteht, ignoriert werden soll. Die Verarbeitung der Nachricht, auch ohne die Option zu verstehen, ist akzeptabel (Section 5.4.1).

Unsafe Option (Unsichere Option) : Eine Option, die von einem Proxy, der die Nachricht empfängt, verstanden werden müsste, um die Nachricht sicher weiterzuleiten (Section 5.4.2). Nicht jede kritische Option ist eine unsichere Option.

Safe-to-Forward Option (Sicher-weiterzuleitende Option) : Eine Option, die für die Weiterleitung durch einen Proxy, der sie nicht versteht, als sicher vorgesehen ist. Die Weiterleitung der Nachricht, auch ohne die Option zu verstehen, ist akzeptabel (Section 5.4.2).

Resource Discovery (Ressourcenentdeckung) : Der Prozess, bei dem ein CoAP-Client einen Server nach seiner Liste der gehosteten Ressourcen abfragt (d.h. Links, wie in Section 7 definiert).

Content-Format (Inhaltsformat) : Die Kombination eines Internet-Medientyps, möglicherweise mit spezifischen angegebenen Parametern, und einer Content-Codierung (die oft die Identitäts-Content-Codierung ist), identifiziert durch eine numerische Kennung, die durch das "CoAP Content-Formats" Register definiert wird. Wenn der Fokus weniger auf der numerischen Kennung als auf der Kombination dieser Merkmale einer Ressourcendarstellung liegt, wird dies auch als "representation format" (Darstellungsformat) bezeichnet.

Zusätzliche Terminologie für eingeschränkte Knoten und Netzwerke eingeschränkter Knoten finden Sie in [RFC7228].

In dieser Spezifikation wird der Begriff "byte" (Byte) in seinem jetzt üblichen Sinn als Synonym für "octet" (Oktett) verwendet.

Alle Mehrbyte-Ganzzahlen in diesem Protokoll werden in Netzwerk-Byte-Reihenfolge interpretiert.