1. Einführung

Die Arbeit an Constrained RESTful Environments (CoRE) zielt darauf ab, die Representational State Transfer (REST)-Architektur in einer geeigneten Form für die am stärksten eingeschränkten Knoten (wie Mikrocontroller mit begrenztem RAM und ROM [RFC7228]) und Netzwerke (wie IPv6 über Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944]) zu realisieren [RFC7252]. Das CoAP-Protokoll soll RESTful [REST]-Dienste bereitstellen, die HTTP [RFC7230] nicht unähnlich sind, während die Komplexität der Implementierung sowie die Größe der ausgetauschten Pakete reduziert werden, um diese Dienste in einem stark eingeschränkten Netzwerk von stark eingeschränkten Knoten nützlich zu machen.

Dieses Ziel erfordert Zurückhaltung in einer Reihe von manchmal widersprüchlichen Wegen:

Reduzierung der Implementierungskomplexität, um die Codegröße zu minimieren,
Reduzierung der Nachrichtengrößen, um die Anzahl der für jede Nachricht erforderlichen Fragmente zu minimieren (um die Wahrscheinlichkeit der Zustellung der Nachricht zu maximieren), die benötigte Sendeleistung und die Belastung des Kanals mit begrenzter Bandbreite zu minimieren,
Reduzierung der Anforderungen an die Umgebung wie stabiler Speicher, gute Zufallsquellen oder Benutzerinteraktionsfähigkeiten.

Da CoAP auf Datagramm-Transporten wie UDP oder Datagram Transport Layer Security (DTLS) basiert, ist die maximale Größe von Ressourcenrepräsentationen, die ohne zu viel Fragmentierung übertragen werden können, begrenzt. Darüber hinaus passen nicht alle Ressourcenrepräsentationen in ein einzelnes Link-Layer-Paket eines eingeschränkten Netzwerks, was zu einer Fragmentierung der Anpassungsschicht führen kann, selbst wenn keine Fragmentierung der IP-Schicht erforderlich ist. Die Verwendung von Fragmentierung (entweder auf der Anpassungsschicht oder auf der IP-Schicht) für den Transport größerer Repräsentationen wäre bis zur maximalen Größe des zugrunde liegenden Datagrammprotokolls (wie UDP) möglich, aber der Fragmentierungs-/Reassemblierungsprozess belastet die unteren Schichten mit einem Konversationszustand, der besser in der Anwendungsschicht verwaltet wird.

Die vorliegende Spezifikation definiert ein Paar von CoAP-Optionen, um einen blockweisen Zugriff auf Ressourcenrepräsentationen zu ermöglichen. Die Block-Optionen bieten eine minimale Möglichkeit, größere Ressourcenrepräsentationen blockweise zu übertragen. Das übergeordnete Ziel ist es, die Notwendigkeit zu vermeiden, einen Konversationszustand auf dem Server für blockweise GET-Anfragen zu erstellen. (Es ist unmöglich, die Erstellung eines Konversationszustands für POST/PUT vollständig zu vermeiden, wenn die Erstellung/Ersetzung von Ressourcen atomar sein soll; wo diese Eigenschaft nicht benötigt wird, muss auch in diesem Fall kein Server-Konversationszustand erstellt werden.)

Blockweise Übertragungen werden als Kombinationen von Austauschvorgängen realisiert, von denen jeder gemäß dem CoAP-Basisprotokoll [RFC7252] durchgeführt wird. Jeder Austausch in einer solchen Kombination unterliegt den Spezifikationen in [RFC7252], einschließlich der Überlastungskontrollspezifikationen (Abschnitt 4.7 von [RFC7252]) und der Sicherheitsüberlegungen (Abschnitt 11 von [RFC7252]; zusätzliche Sicherheitsüberlegungen gelten dann für die Übertragungen als Ganzes, siehe Abschnitt 7). Die vorliegende Spezifikation minimiert die Einschränkungen, die sie diesen Basisaustauschen hinzufügt; jedoch sind nicht alle Varianten der Verwendung von CoAP innerhalb einer blockweisen Übertragung sehr nützlich (z. B. würde die Verwendung von nicht bestätigungsfähigen Anfragen innerhalb blockweiser Übertragungen außerhalb des Anwendungsfalls von Abschnitt 2.8 die allgemeine Wahrscheinlichkeit der Nichtzustellung erhöhen). Um ganz klar zu sein, die vorliegende Spezifikation entfernt auch keine der Einschränkungen, die durch die Basisspezifikation gestellt werden, auf der sie streng aufbaut. Beispielsweise sind Back-to-Back-Pakete durch die in Abschnitt 4.7 von [RFC7252] beschriebene Überlastungskontrolle begrenzt (NSTART als Grenze für die Initiierung von Austauschen, PROBING_RATE als Grenze für das Senden ohne Antwort); blockweise Übertragungen können nicht mehr Verkehr senden/anfordern, als ein Client ohne den blockweisen Modus an denselben Server senden / von ihm anfordern könnte.

In einigen Fällen wird die vorliegende Spezifikation EMPFEHLEN (RECOMMEND), dass ein Client eine Sequenz von blockweisen Übertragungen "ohne unangemessene Verzögerung" durchführt. Dies kann nicht als Interoperabilitätsanforderung formuliert werden, ist jedoch eine Erwartung an die Implementierungsqualität. Umgekehrt wird erwartet, dass Server sich nicht übermäßig anstrengen müssen, um Clients entgegenzukommen, die erhebliche Zeit benötigen, um eine blockweise Übertragung abzuschließen. Wenn sich beispielsweise bei einem blockweisen GET die Ressource ändert, während dies fortgesetzt wird, kann das Entity-Tag (ETag) für einen weiteren erhaltenen Block unterschiedlich sein. Um zu vermeiden, dass dies bei einer sich schnell ändernden Ressource ständig passiert, KANN (MAY) ein Server versuchen, einen Cache für einen bestimmten Client für eine kurze Zeit vorzuhalten. Die Erwartung ist hier, dass die Lebensdauer für einen solchen Cache kurz gehalten werden kann, in der Größenordnung von wenigen erwarteten Umlaufzeiten, gezählt ab dem vorherigen übertragenen Block.

Zusammenfassend fügt diese Spezifikation CoAP ein Paar von Block-Optionen hinzu, die für blockweise Übertragungen verwendet werden können. Zu den Vorteilen der Verwendung dieser Optionen gehören:

Übertragungen, die größer sind als das, was in Link-Layer-Paketen eingeschränkter Netzwerke untergebracht werden kann, können in kleineren Blöcken durchgeführt werden.
Auf der Anpassungsschicht oder IP-Schicht wird kein schwer zu verwaltender Konversationszustand für die Fragmentierung erstellt.
Die Übertragung jedes Blocks wird bestätigt, was bei Bedarf eine individuelle erneute Übertragung ermöglicht.
Beide Seiten haben ein Mitspracherecht bei der Blockgröße, die tatsächlich verwendet wird.
Die resultierenden Austauschvorgänge sind mit Paketanalyse-Tools leicht verständlich und daher für das Debugging gut zugänglich.
Bei Bedarf können die Block-Optionen auch (ohne Änderungen) verwendet werden, um einen wahlfreien Zugriff auf Blöcke mit einer Größe von Zweierpotenzen innerhalb einer Ressourcenrepräsentation bereitzustellen.

Eine CoAP-Implementierung, die diese Optionen nicht unterstützt, ist im Allgemeinen in der Größe der Repräsentationen beschränkt, die ausgetauscht werden können, siehe Abschnitt 4.6 von [RFC7252]. Obwohl die Optionen kritisch (Critical) sind, kann ein Server entscheiden, sie unaufgefordert in einer Antwort (Block2) auf eine Anfrage zu verwenden, die keine Block-Option enthielt.