2. ブロック単位の転送

はじめにで述べたように、制約のあるネットワークでデータグラムのサイズを制限することには正当な理由があります。

• 最大データグラムサイズによる（UDPの場合は約64 KiB）

• IPフラグメンテーションを回避したいという要望による（IPv6の場合は1280のMTU）

• 適応層のフラグメンテーションを回避したいという要望による（6LoWPANの場合は60-80バイト [RFC4919]）

リソース表現が単一のCoAPデータグラムのペイロードで快適に転送できるサイズよりも大きい場合、Blockオプションを使用してブロック単位の転送を示すことができます。ペイロードはリクエストとレスポンスの両方で送信できるため、この仕様では、ペイロード転送の方向ごとに2つの個別のオプションを提供します。これらのオプションに名前を付ける際（ブロック単位の転送およびセクション4でも）、リクエストに関連するリソース表現の転送を指すために番号1（「Block1」、「Size1」）を使用し、レスポンスのリソース表現の転送を指すために番号2（「Block2」、「Size2」）を使用します。

以下では、「ペイロード（payload）」という用語は、単一のCoAPメッセージの実際の内容、つまり転送される単一のブロックに使用され、「ボディ（body）」という用語は、ブロック単位で転送されるリソース表現全体に使用されます。Content-Formatオプションは、ペイロードではなくボディに適用されます。特に、ブロック間の境界は、Content-Formatで使用される構造、エンコーディング、またはコンテンツコーディングの観点から単位全体を区切っていない場所にある可能性があります。（同様に、[RFC7252]のセクション5.10.6で定義されているETagオプションは、リソースの表現全体に適用されるため、レスポンスのボディに適用されます。）

ほとんどの場合、ボディに対して転送されるすべてのブロック（最後のブロックを除く）は同じサイズになります。（最初のリクエストが受信者が好むよりも大きなブロックサイズを使用する場合、後続のリクエストは優先ブロックサイズを使用します。）ブロックサイズはプロトコルによって固定されていません。実装をできるだけ単純にするために、Blockオプションは、2**4（16）から2**10（1024）バイトまでの2の累乗のブロックサイズの小さな範囲のみをサポートします。ボディは選択された2の累乗のブロックサイズで均等に分割されないことが多いため、最後のブロックでサイズに達する必要はありません（ただし、最後のブロックであっても、選択された2の累乗サイズはBlockオプションのブロックサイズフィールドに示されます）。

2.1. Block2およびBlock1オプション

+-----+---+---+---+---+--------+--------+--------+---------+
| No. | C | U | N | R | Name   | Format | Length | Default |
+-----+---+---+---+---+--------+--------+--------+---------+
|  23 | C | U | - | - | Block2 | uint   |    0-3 | (なし)  |
|     |   |   |   |   |        |        |        |         |
|  27 | C | U | - | - | Block1 | uint   |    0-3 | (なし)  |
+-----+---+---+---+---+--------+--------+--------+---------+

                表 1: Blockオプション番号

Block1およびBlock2オプションは、リクエストメッセージとレスポンスメッセージの両方に存在できます。どちらの場合も、Block1オプションはリクエストペイロードに関連し、Block2オプションはレスポンスペイロードに関連します。

したがって、[RFC7252]で定義されているメソッドの場合、Block1はペイロードを持つPOSTおよびPUTリクエストとそのレスポンスで役立ちます。Block2は、GET、POST、およびPUTリクエストとそれらのペイロードを持つレスポンス（2.01、2.02、2.04、および2.05 -- [RFC7252]のセクション5.5を参照）で役立ちます。

Block1がリクエストに存在するか、Block2がレスポンスに存在する場合（つまり、それが関連するペイロードを持つメッセージ内）、それはブロック単位の転送を示し、この特定のブロック単位のペイロードが転送されるボディ全体の一部をどのように形成するかを記述します（「記述的使用法」）。反対方向に存在する場合、それはそのペイロードがどのように形成されるか、または処理されたかに関する追加の制御を提供します（「制御使用法」）。

いずれかのBlockオプションの実装はオプションであることを意図しています。ただし、CoAPメッセージに存在する場合は、処理する必要があります（またはメッセージを拒否する必要があります）。したがって、それはクリティカル（Critical）オプションとして識別されます。いずれのBlockオプションも、単一のメッセージ内で2回以上発生してはなりません（MUST NOT）。

2.2. Blockオプションの構造

Block（Block1またはBlock2）オプションでは、次の3つの情報を転送する必要がある場合があります。

• ブロックのサイズ（SZX）

• 後続のブロックがあるかどうか（M）

• 指定されたサイズのブロックのシーケンス内でのブロックの相対番号（NUM）

Blockオプションの値は、可変サイズ（0〜3バイト）の符号なし整数（uint、[RFC7252]のセクション3.2を参照）です。この整数値はこれら3つのフィールドをエンコードします（図1を参照）。（CoAPのuintエンコーディングルールにより、NUM、M、およびSZXのすべてがゼロの場合、ゼロバイトの整数が送信されます。）

     0
     0 1 2 3 4 5 6 7
    +-+-+-+-+-+-+-+-+
    |  NUM  |M| SZX |
    +-+-+-+-+-+-+-+-+

     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |          NUM          |M| SZX |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   NUM                 |M| SZX |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 図 1: Blockオプション値

ブロックサイズは、3ビットの符号なし整数（2**4バイトの場合は0、2**10バイトの場合は6）を使用してエンコードされます。これを「SZX」（「サイズ指数」）と呼びます。実際のブロックサイズは「2**(SZX + 4)」です。SZXは、オプション値の最下位3ビット（つまり、「val」がオプションの値である「val & 7」）で転送されます。

4番目の最下位ビットであるMまたは「more」ビット（「val & 8」）は、後続のブロックがあるか、現在のブロック単位の転送が転送される最後のブロックであるかを示します。

オプション値を16で割った値（NUMフィールド）は、現在転送されているブロックのシーケンス番号（0から始まる）です。したがって、現在の転送は、バイト「NUM << (SZX + 4)」から始まる「size」バイトに関するものです。

実装上の注意：実装の便宜上、「(val & ~0xF) << (val & 7)」、つまり最後の4ビットをマスクアウトし、SZXの値だけ左にシフトしたオプション値は、転送されるブロックの最初のバイトのバイト位置を示します。

具体的には、Block1またはBlock2オプションのオプション値内で、オプションフィールドの意味は次のように定義されます。

NUM: : ブロック番号。要求または提供されているブロック番号を示します。ブロック番号0は、ボディの最初のブロック（つまり、ボディの最初のバイトから始まる）を示します。

M: : Moreフラグ（「最後のブロックではない」）。記述的使用法の場合、このフラグが設定されていない場合、このメッセージのペイロードがボディの最後のブロックであることを示します。設定されている場合、1つ以上の追加ブロックが利用可能であることを示します。特定のブロック番号を取得するためにリクエストでBlock2オプションを使用する場合（「制御使用法」）、Mビットはゼロとして送信され、受信時に無視されなければなりません（MUST）。（レスポンスのBlock1オプションでは、Mフラグは原子性を示すために使用されます。以下を参照してください。）

SZX: : ブロックサイズ。ブロックサイズは、2の累乗のブロックサイズを示す3ビットの符号なし整数として表されます。したがって、ブロックサイズ = 2**(SZX + 4)です。SZXの許容値は0〜6です。つまり、最小ブロックサイズは2**(0+4) = 16で、最大は2**(6+4) = 1024です。SZXの値7（ブロックサイズ2048を示す）は予約されており、送信してはならず（MUST NOT）、リクエストで受信した場合は4.00 Bad Requestレスポンスコードにつながらなければなりません（MUST）。

Block1およびBlock2オプションにはデフォルト値はありません。これらのオプションのいずれかがないことは、オプションで指定できるNUMおよびMの値に関してオプション値が0であることと同等です。つまり、現在のブロックが転送の最初で唯一のブロック（ブロック番号0、Mビット未設定）であることを示します。ただし、明示的な値0（SZXが0であり、したがってサイズ値が16バイトであることを示す）とは対照的に、オプションの欠如によって特定の明示的なサイズが暗示されることはありません。サイズは指定されません。（他のuintと同様に、明示的な値0はゼロ長のオプションによって効率的に示されます。したがって、これはオプションの欠如とは意味が異なります。）

2.3. リクエストとレスポンスのBlockオプション

Blockオプションは、次の3つの役割のいずれかで使用されます。

• 記述的使用法。つまり、レスポンスのBlock2オプション（GETの2.05レスポンスなど）、またはリクエストのBlock1オプション（PUTまたはPOST）：

  • オプション値のNUMフィールドは、このメッセージのペイロードに含まれるブロック番号を示します。

  • Mビットは、そのボディの転送を完了するためにさらにブロックを転送する必要があるかどうかを示します。

  • Mビットが設定されている場合、SZXによって暗示されるブロックサイズは、ペイロードのサイズ（バイト単位）と一致しなければなりません（MUST）。（Mが設定されていない場合、SZXはペイロードサイズを制御しません）。Block2の場合、リクエストがより大きなSZX値を提案した場合、次のリクエストはSZXをレスポンスで指定されたサイズまで下げなければなりません（MUST）。（その結果、サーバーが（1）優先ブロックサイズと（2）要求されたブロックサイズの小さい方を使用する場合、ボディのすべてのブロックが同じブロックサイズを使用することになります。）

• リクエストの制御使用法でのBlock2オプション（例：GET）：

  • Block2オプションのNUMフィールドは、レスポンスで返されるように要求されているペイロードのブロック番号を示します。

  • この場合、Mビットは機能せず、ゼロに設定しなければなりません（MUST）。

  • 指定されたブロックサイズ（SZX）は、ブロックサイズを提案する（ブロック番号0の場合）か、受信した以前のブロックのブロックサイズを繰り返します（ゼロ以外のブロック番号の場合）。

• レスポンスの制御使用法でのBlock1オプション（例：PUTまたはPOSTリクエストに対する2.xxレスポンス）：

  • Block1オプションのNUMフィールドは、どのブロック番号が確認されているかを示します。

  • リクエストでMビットが設定されていた場合、サーバーは、各ブロックに対して個別にメモリなしで動作するか、ボディ全体のリクエストをアトミックに処理するか、またはその2つの組み合わせを選択できます。

    • レスポンスでもMビットが設定されている場合、このレスポンスがリクエストに対する最終的なレスポンスコードを伝達しないことを示します。つまり、サーバーは同じエンドポイントからさらにブロックを収集し、リクエストをアトミックに実装する予定です（例：ペイロードの最後のブロックを受信したときにのみ動作する）。この場合、レスポンスはBlock2オプションを伝達してはなりません（MUST NOT）。

    • 逆に、リクエストで設定されていたにもかかわらずMビットが設定されていない場合、ブロック単位のリクエストがこのブロックのために特別に制定されたことを示し、レスポンスはこのリクエスト（およびこのブロック単位の転送シーケンスのレスポンスのBlock1オプションでMビットが設定されている以前のリクエスト）に対する最終的なレスポンスを伝達します。クライアントは依然としてさらにブロックを送信し続けることが期待されており、そのリクエストメソッドもブロックごとに制定される場合とされない場合があります。（リソースは部分的に更新された状態になっています。このアプローチは、そのような中間状態を公開することが許容される場合にのみ適切です。クライアントは、リソースの更新をすばやく続行するか、失敗した場合は更新を再開することで、ウィンドウを減らすことができます。）

  • 最後に、制御Block1オプションで指定されたSZXブロックサイズは、最初の交換で使用されたものと同じかそれ以下の、リソースへの転送に対してサーバーが優先する最大ブロックサイズを示します。クライアントは、転送シーケンスのすべての後続のリクエストで、このブロックサイズまたはそれ以下のサイズを使用すべきです（SHOULD）。これには、今後ブロックサイズを変更する（およびそれに応じてブロック番号をスケーリングする）必要がある場合も含まれます。

1つまたは両方のBlockオプションを使用して、単一のREST操作を複数のCoAPメッセージ交換に分割できます。[RFC7252]で指定されているように、これらのメッセージ交換はそれぞれ独自のCoAPメッセージIDを使用します。

リクエストまたはレスポンスとともに送信されるContent-Formatオプションは、ボディ全体のContent-Formatを反映しなければなりません（MUST）。レスポンスボディのブロックが異なるContent-Formatオプションで到着した場合、このエラーをどのように処理するかはクライアント次第です（通常、進行中のブロック単位の転送を中止します）。リクエストのブロックが不一致のContent-Formatオプションでサーバーに到着した場合、サーバーはそれらを単一のリクエストに組み立ててはなりません（MUST NOT）。これは通常、不一致のブロックに対する4.08（Request Entity Incomplete、セクション2.9.2）エラーレスポンスにつながります。

2.4. Block2オプションの使用

リクエストがMビットが設定されたBlock2オプションを伝達するレスポンスで応答された場合、リクエスターは、初期リクエストと同じオプションと、目的のブロック番号およびブロックサイズを指定するBlock2オプションを使用して、さらにリクエストを送信することにより、リソース表現の追加ブロックを取得できます。リクエストでは、クライアントはBlock2オプションのMビットをゼロに設定しなければならず（MUST）、サーバーは受信時にそれを無視しなければなりません（MUST）。

レスポンスで使用されるブロックサイズに影響を与えるために、リクエスターは初期リクエストでBlock2オプションを使用し、目的のサイズ、ブロック番号ゼロ、Mビットゼロを指定することもできます（MAY）。サーバーは、示されたブロックサイズまたはそれ以下のサイズを使用しなければなりません（MUST）。最初のブロックを超えるブロックに対するそれ以上のブロック単位のリクエストは、Block2オプションを使用して目的のサイズを指定した最初のリクエストのレスポンスでサーバーが使用したのと同じブロックサイズを示さなければなりません（MUST）。

リクエスターによってBlock2オプションが使用され、調整された可能性のあるブロックサイズで最初のレスポンスが受信されると、単一のブロック単位の転送におけるそれ以上のすべてのリクエストは、最終的に同じサイズを使用することに収束します。ただし、最後のブロック（Mビットが設定されずに返されたもの）を埋めるのに十分なコンテンツがない場合は除きます。（Block2オプションのない最初のリクエストがレスポンスでBlock2オプションになった後、クライアントが2番目のリクエストでBlock2オプションの使用を開始する場合があることに注意してください。）サーバーはリクエストオプションで示されたブロックサイズまたはそれ以下のサイズを使用しますが、リクエスターは初期リクエストに対するレスポンスで実際に使用されたブロックサイズに注意し、後続のリクエストでそれを使用し続けなければなりません（MUST）。サーバーの動作は、このクライアントの動作が、シーケンス内のすべてのレスポンスに対して同じブロックサイズになるようにしなければなりません（MUST）（Mビットが設定されていない最後のレスポンス、および初期リクエストにBlock2オプションが含まれていなかった場合は最初のレスポンスを除く）。

ブロック単位の転送は、表現が完全に静的（デバイスを記述するスキーマなど、時間の経過とともにまったく変化しない）なリソースをGETするため、または動的に変化するリソースのために使用できます。後者の場合、Block2オプションはETagオプション（[RFC7252]、セクション5.10.6）と組み合わせて使用すべきです（SHOULD）。これにより、再構成されるブロックが表現の同じバージョンからのものであることが保証されます。サーバーは各レスポンスにETagオプションを含めるべきです（SHOULD）。ETagオプションが利用可能な場合、クライアントは交換されているブロックから表現を再構成する際にETagオプションを比較しなければなりません（MUST）。GET転送でETagオプションが一致しない場合、リクエスターは最初に取得したブロックの新しい値を再取得しようとするオプションがあります。結果として生じる非効率性を最小限に抑えるために、サーバーは進行中のリクエストシーケンスのために表現の現在の値をキャッシュしてもかまいません（MAY）。（サーバーは、各ブロック単位のリクエストでリクエストエンドポイントとURIが同じであるという組み合わせによってシーケンスを識別できます。）この仕様では、サーバーがいかなる状態も確立することを要求していないことに十分注意してください。ただし、急速に変化するリソースを提供するサーバーは、それによってクライアントが一貫したブロックセットを取得することを不可能にする可能性があります。リソースのすべてのブロックを取得したいクライアントは、不当な遅延なしにそうするように努めるべきです（SHOULD）。サーバーは、状態への最後のアクセス後、EXCHANGE_LIFETIME（[RFC7252]、セクション4.8.2）の期間後にキャッシュされた状態を自由に破棄できると完全に期待できますが、常にそれだけ長く状態を保持するという要件はありません。

Block2オプションは、単一のエンドポイントが同じリソースに対して複数の並行して進行するブロック単位のレスポンスペイロード転送（GETなど）操作を実行する方法を提供しません。これが要件になることはめったにありませんが、回避策として、クライアントはキャッシュキーを変更できます（たとえば、同じセマンティクスを持つリソースにアクセスする複数のURIのいずれかを使用するか、プロキシセーフな選択的オプションを変更することによって）。

2.5. Block1オプションの使用

リクエストペイロードを持つリクエスト（PUTまたはPOSTなど）では、Block1オプションはリクエスト内のペイロードを指します（記述的使用法）。

ペイロードを持つリクエスト（PUTまたはPOST転送など）へのレスポンスでは、Block1オプションで指定されたブロックサイズは、このリソースに対するサーバーのブロックサイズ設定を示します（制御使用法）。明らかに、この時点で、最初のブロックはすでにこの知識の恩恵を受けずにクライアントによって転送されています。それでも、クライアントは示された設定に注意し、それ以降のすべてのブロックについて、サーバーが優先するブロックサイズまたはそれ以下のサイズを使用すべきです（SHOULD）。ブロックサイズを小さくすると、最初の要求ですでに小さいサイズでカウントされた複数のブロックが転送されているため、2番目の要求が1より大きいブロック番号で始まる可能性があることに注意してください。

パケット配信確率に対する適応層フラグメンテーションの影響に対抗するために、クライアントは、MAX_RETRANSMITに達する前であっても、比較的大きなペイロードを持つリクエストの再送信をあきらめ、より小さなペイロードを持つブロック単位の転送としてリクエストを再表明しようとする場合があります。この新しい試みは新しいメッセージ層トランザクションであり、新しいメッセージIDが必要であることに注意してください。（リクエストが失われたのか確認応答が失われたのかが不確実なため、この戦略は主にべき等なリクエストに役立ちます。）

サーバーでアトミックに実装されることを意図したリクエストペイロード（PUTまたはPOSTなど）のブロック単位の転送では、実際の作成/置換は、最後のブロック（つまり、Block1オプションでMビットが設定されていないブロック）が受信されたときに行われます。この場合、非最終ブロックに対するすべての成功レスポンスは、レスポンスコード2.31（Continue、セクション2.9.1）を伝達します。最終ブロックの処理時に以前のすべてのブロックがサーバーで利用できない場合、転送は失敗し、エラーコード4.08（Request Entity Incomplete、セクション2.9.2）を返さなければなりません（MUST）。サーバーは、順序が正しくない（最終または非最終）Block1転送に対して4.08エラーコードを返すこともできます（MAY）。したがって、このケースを処理する特定のメカニズムを持たないクライアントは、常にブロックゼロから開始し、次のブロックを順番に送信すべきです（SHOULD）。

クライアントが4.08エラーコードに遭遇する理由の1つは、サーバーがすでにタイムアウトし、組み立て中の部分的なリクエストボディを破棄したことです。クライアントは、不当な遅延なしにリクエストのすべてのブロックを送信するように努めるべきです（SHOULD）。最新のブロックが転送されてからEXCHANGE_LIFETIME（[RFC7252]、セクション4.8.2）の期間が経過すると、サーバーは部分的なリクエストボディを自由に破棄できると完全に期待できます。ただし、サーバーに常に部分的なリクエストボディをそれだけ長く保持するという要件はありません。

エラーコード4.13（Request Entity Too Large）は、アトミックに実装しようとしている転送のためのブロックを保存するためのリソースが現在ないことを示すために、Block1転送中のいつでもサーバーによって返される可能性があります。（Block1を使用しないリクエストに対する4.13レスポンスは、クライアントがBlock1の送信を試みるためのヒントであり、要求されたよりもBlock1オプションで小さいSZXを持つ4.13レスポンスは、より小さいSZXを試みるためのヒントであることに注意してください。）

サーバーでステートレスに実装されるリクエストペイロードのブロック単位の転送は、転送がまだ進行中であるか、クライアントが転送を完了しない場合、操作対象のリソースを不整合な状態のままにする可能性があります。この特性は、転送中にサーバーに常に状態が保持されるHTTPの特性よりも、リモートファイルシステムの特性に近いです。共有ファイルアクセスでよく知られている手法（クライアント固有の一時リソースなど）を使用して、HTTPとのこの違いを軽減できます。

Block1オプションは、単一のエンドポイントが同じリソースに対して複数の並行して進行するブロック単位のリクエストペイロード転送（PUTまたはPOSTなど）操作を実行する方法を提供しません。同じリソースへの新しいブロック単位のリクエストシーケンスを開始すると（同じエンドポイントからの古いシーケンスが終了する前に）、サーバーがまだ保持している可能性のあるコンテキストが単に上書きされます。（これはおそらく、この場合にまさに望まれることです。クライアントは単に再起動し、以前のシーケンスの知識を失った可能性があります。）

2.6. ブロック単位の転送とObserveオプションの組み合わせ

Observeオプションは、リソースの経時変化についてクライアントに通知する方法を提供します[RFC7641]。クライアントによって観察されるリソースは、1つのCoAPメッセージで快適に処理または転送できるよりも大きい場合があります。次のルールは、ブロック単位の転送と通知の組み合わせに適用されます。

観察関係は常にリソース全体に適用されます。Block2オプションは、リソースの単一のブロックを観察する方法を提供しません。

基本的なGET転送と同様に、クライアントは、観察関係を確立または更新するGETリクエストのBlock2オプションで、希望するブロックサイズを示すことができます。サーバーがブロック単位の転送をサポートしている場合、ブロックサイズに注意し、GETリクエストから生じるすべての通知/レスポンスに最大サイズとして適用すべきです（SHOULD）（クライアントがオブザーバーのリストから削除されるか、クライアントからのリソースの新しいGETリクエストをサーバーが受信してそのリストのエントリが更新されるまで）。

2.05（Content）通知を送信する場合、サーバーは表現の最初のブロックのみを送信します。クライアントは、GETリクエストによってこの最初のレスポンスが発生したかのように、つまりゼロより大きいNUM値を含むBlock2オプションを持つ追加のGETリクエストを使用することによって、表現の残りを取得します。（これにより、以前の通知に関して一部のブロックのみが変更された場合でも、表現全体の転送が行われます。）

他の動的に変化するリソースと同様に、再構成されるブロックが表現の同じバージョンからのものであることを保証するために、サーバーは各レスポンスにETagオプションを含めるべきであり（SHOULD）、再構成するクライアントはETagオプションを比較しなければなりません（MUST）（セクション2.4）。Block2の一般的なケースよりもさらに、最初のブロックで通知されたリソースのすべてのブロックを取得したいクライアントは、不当な遅延なしにそうするように努めるべきです（SHOULD）。

例については、セクション3.4を参照してください。

2.7. Block1とBlock2の組み合わせ

PUT、特にPOST交換では、リクエストボディとレスポンスボディの両方が、ブロック単位の転送の使用を必要とするほど大きくなる場合があります。まず、リクエストボディのBlock1転送は通常どおり進行します。このブロック単位の転送の最後のスライスの交換では、レスポンスはBlock2転送の最初のスライスを伝達します（NUMはゼロ）。このBlock2転送を続行するために、クライアントはBlock1フェーズのリクエストと同様のリクエストを送信し続けますが、Block1オプションを省略し、ゼロ以外のNUMを持つBlock2リクエストオプションを含めます。

Block1を使用したリクエストのレスポンスボディを取得するBlock2転送は、順次実行しなければなりません（MUST）。

2.8. Block2とマルチキャストの組み合わせ

クライアントは、マルチキャストGETリクエストでNUM = 0のBlock2オプションを使用して、レスポンスのサイズを制限するのに役立てることができます。

同様に、マルチキャストGETリクエストへのレスポンスは、表現が大きい場合、またはレスポンスのサイズをさらに制限するために、NUM = 0のBlock2オプションを使用できます。

どちらの場合も、クライアントはユニキャスト交換を使用してそれ以降のブロックを取得します。ユニキャストリクエストでは、クライアントは、マルチキャストリクエストへのレスポンスでサーバーによって示されたブロックサイズ設定に注意すべきです（SHOULD）。

マルチキャストメッセージと組み合わせたBlockオプションの他の使用法は、今後の研究課題です。

2.9. レスポンスコード

[RFC7252]で定義されているレスポンスコードに加えて、この仕様では2つのレスポンスコードを定義し、1つの意味を拡張します。

2.9.1. 2.31 Continue

この新しい成功ステータスコードは、リクエストボディのこのブロックの転送が成功し、サーバーがさらにブロックを送信することを推奨しているが、ブロック単位のリクエスト全体の最終的な結果はまだ決定できないことを示します。このレスポンスコードではペイロードは返されません。

2.9.2. 4.08 Request Entity Incomplete

この新しいクライアントエラーステータスコードは、サーバーが続行するために必要なリクエストボディのブロックを受信していないことを示します。クライアントがすべてのブロックを送信していないか、サーバーが必要とする順序で送信していないか、サーバーがすでに破棄しているほど前に送信しました。

（手元に必要なブロックがない理由の1つは、Content-Formatの不一致である可能性があることに注意してください。セクション2.3を参照してください。実装上の注意：NUM != 0で、リソースの現在の状態から予想されるものとは異なるContent-Formatが示されている場合、サーバーはこのコードでBlock1転送を拒否できます。ステートレスな方法で転送を実装する場合、ブロックのContent-Formatを既存のリソースのContent-Formatと照合できます。アトミックな方法で転送を実装する場合、ブロックを、リソースの状態を置き換えようとしている部分的に再構成された表現の一部と照合できます。）

2.9.3. 4.13 Request Entity Too Large

[RFC7252]のセクション5.9.2.9では、レスポンスコード4.13（Request Entity Too Large）は、HTTP 413 "Request Entity Too Large"のように定義されています。[RFC7252]はまた、サーバーがこの情報を利用可能にする立場にない場合を除き、サーバーが処理できる（かつ処理する意思がある）リクエストエンティティの最大サイズを示すために、このレスポンスにSize1オプション（セクション4）を含めるべきである（SHOULD）と推奨しています。

本仕様では、サーバーがBlock1転送中のいつでもこのレスポンスコードを返して、アトミックに実装しようとしている転送のブロックを保存するためのリソースが現在ないことを示すことを許可しています。また、サーバーがBlock1を使用しないリクエストに対して4.13レスポンスを返すことを、クライアントがBlock1の送信を試みるためのヒントとして許可しています。最後に、Block1オプション（制御使用法、セクション2.3を参照）を持つリクエストに対する4.13レスポンスで、レスポンスがBlock1オプションでより小さいSZXを伝達する場合、それはそのより小さいSZXを試みるためのヒントです。

2.10. キャッシュに関する考慮事項

この仕様では、キャッシュ、特にキャッシュプロキシ内のキャッシュに対して、さまざまな実装戦略を開いたままにしようとしています。たとえば、キャッシュはブロックを個別に自由にキャッシュできますが、完全な表現を取得してからその一部を提供するのを待つこともできます。部分的なキャッシュは、クロスプロキシ（ストリーミングHTTPプロキシに相当）でより効率的である場合があります。キャッシュされたブロック（部分的にキャッシュされたレスポンス）は、完全なレスポンスの代わりに使用して、キャッシュに提示されたブロック単位のリクエストを満たすことができます。ブロックが異なれば、転送される時間が異なるため、Max-Age値も異なる可能性があることに注意してください。ブロックを含むレスポンスは、完全な表現の鮮度を更新します。個々のブロックを検証でき、単一のブロックを検証すると、完全な表現が検証されます。Mビットが設定された制御使用法のBlock1オプションを含むレスポンスは、ターゲットURIのキャッシュされたレスポンスを無効にします。

レスポンスを結合するキャッシュまたはプロキシ（たとえば、リクエスト内のブロックを分割したり、レスポンス内のブロックサイズを増やしたり、クロスプロキシ）は、2.31および2.01/2.04レスポンスを結合する必要がある場合があります。ステートレスサーバーは、転送された最初のBlock1ブロックでのみ2.01で応答する可能性があり、これは後のブロックに対する2.04レスポンスを支配します。

If-None-Matchは、(NUM=0)のBlock1リクエストでのみ正しく機能し、NUM != 0のBlock1リクエストでは使用してはなりません（MUST NOT）。