1. はじめに

制約のあるRESTful環境（CoRE）に関する作業は、最も制約のあるノード（RAMとROMが制限されたマイクロコントローラー[RFC7228]など）およびネットワーク（IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944]など）に適した形式で、Representational State Transfer（REST）アーキテクチャを実現することを目的としています[RFC7252]。CoAPプロトコルは、HTTP [RFC7230]と同様のRESTful [REST]サービスを提供することを目的としていますが、実装の複雑さと交換されるパケットのサイズを削減して、高度に制約されたノードの高度に制約されたネットワークでこれらのサービスを有用なものにします。

この目的には、いくつかの相反する方法での抑制が必要です。

コードサイズを最小限に抑えるために実装の複雑さを軽減する。
各メッセージに必要なフラグメントの数を最小限に抑え（メッセージの配信確率を最大化するため）、必要な送信電力と制限された帯域幅チャネルの負荷を最小限に抑えるために、メッセージサイズを縮小する。
安定したストレージ、優れたランダム性のソース、またはユーザーインタラクション機能などの環境に対する要件を軽減する。

CoAPはUDPやDatagram Transport Layer Security（DTLS）などのデータグラムトランスポートに基づいているため、フラグメンテーションがあまり発生せずに転送できるリソース表現の最大サイズは制限されています。さらに、すべてのリソース表現が制約のあるネットワークの単一のリンク層パケットに収まるわけではなく、IP層のフラグメンテーションが必要ない場合でも、適応層のフラグメンテーションが発生する可能性があります。より大きな表現のトランスポートにフラグメンテーション（適応層またはIP層のいずれか）を使用することは、基になるデータグラムプロトコル（UDPなど）の最大サイズまでは可能ですが、フラグメンテーション/再構成プロセスは、アプリケーション層で管理する方が適切な会話状態で下位層に負担をかけます。

本仕様では、リソース表現へのブロック単位のアクセスを可能にするCoAPオプションのペアを定義しています。Blockオプションは、より大きなリソース表現をブロック単位で転送するための最小限の方法を提供します。最優先の目的は、ブロック単位のGETリクエストに対してサーバーで会話状態を作成する必要を回避することです。（リソースの作成/置換をアトミックにする場合、POST/PUTの会話状態の作成を完全に回避することは不可能です。そのプロパティが必要ない場合は、この場合もサーバーの会話状態を作成する必要はありません。）

ブロック単位の転送は交換の組み合わせとして実現され、それぞれがCoAP基本プロトコル[RFC7252]に従って実行されます。このような組み合わせの各交換は、輻輳制御仕様（[RFC7252]のセクション4.7）およびセキュリティの考慮事項（[RFC7252]のセクション11、追加のセキュリティの考慮事項は転送全体に適用されます。セクション7を参照）を含む、[RFC7252]の仕様によって管理されます。本仕様は、これらの基本交換に追加する制約を最小限に抑えます。ただし、CoAPを使用するすべてのバリエーションがブロック単位の転送内で非常に役立つわけではありません（たとえば、セクション2.8のユースケース以外でブロック単位の転送内で確認不能リクエストを使用すると、全体的な不達確率が上昇します）。明確にするために、本仕様は、厳密に階層化されている基本仕様によって課される制約のいずれも削除しません。たとえば、バックツーバックパケットは、[RFC7252]のセクション4.7で説明されている輻輳制御によって制限されます（交換を開始するための制限としてのNSTART、応答なしで送信するための制限としてのPROBING_RATE）。ブロック単位の転送は、クライアントがブロック単位モードなしで同じサーバーに送信/要求できるよりも多くのトラフィックを送信/要求することはできません。

場合によっては、本仕様は、クライアントが一連のブロック単位転送を「不当な遅延なしに」実行することを推奨（RECOMMEND）します。これは相互運用性の要件として表現することはできませんが、実装品質への期待です。逆に、サーバーは、ブロック単位の転送を完了するのにかなりの時間がかかるクライアントに対応するためにわざわざ努力する必要はないと予想されます。たとえば、ブロック単位のGETの場合、これが進行中にリソースが変更されると、取得された後続のブロックのエンティティタグ（ETag）が異なる場合があります。急速に変化するリソースでこれが常に発生しないようにするために、サーバーは特定のクライアントのキャッシュを短期間保持しようとする場合があります（MAY）。ここでの期待は、そのようなキャッシュの寿命を短く保つことができ、前のブロックが転送されてから数回の予想往復時間のオーダーであるということです。

要約すると、この仕様は、ブロック単位の転送に使用できるBlockオプションのペアをCoAPに追加します。これらのオプションを使用する利点は次のとおりです。

制約のあるネットワークのリンク層パケットに収容できるものよりも大きな転送を、より小さなブロックで実行できます。
フラグメンテーションのために適応層またはIP層で管理が難しい会話状態が作成されることはありません。
各ブロックの転送が確認され、必要に応じて個別の再送信が可能になります。
双方が実際に使用されるブロックサイズについて発言権を持っています。
結果として得られる交換は、パケットアナライザーツールを使用して簡単に理解できるため、デバッグに非常にアクセスしやすくなります。
必要に応じて、Blockオプションを使用して（変更なしで）、リソース表現内の2の累乗サイズのブロックへのランダムアクセスを提供することもできます。

これらのオプションをサポートしていないCoAP実装は、通常、交換できる表現のサイズが制限されています。[RFC7252]のセクション4.6を参照してください。オプションはクリティカル（Critical）ですが、サーバーは、Blockオプションが含まれていないリクエストへの応答（Block2）で、要請されていない方法でそれらの使用を開始することを決定する場合があります。