[要約] RFC 7959は、制約のあるアプリケーションプロトコル（CoAP）でのブロック単位の転送に関する仕様です。このRFCの目的は、CoAPを使用して大きなデータを効率的に転送するためのメカニズムを提供することです。
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 7959 Universitaet Bremen TZI
Updates: 7252 Z. Shelby, Ed.
Category: Standards Track ARM
ISSN: 2070-1721 August 2016
Block-Wise Transfers in the Constrained Application Protocol (CoAP)
制約付きアプリケーションプロトコル（CoAP）でのブロック単位の転送
Abstract
概要
The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred.
制約付きアプリケーションプロトコル（CoAP）は、制約付きノードおよびネットワーク用のRESTful転送プロトコルです。基本的なCoAPメッセージは、センサーやアクチュエーターからの小さなペイロードに適しています。ただし、アプリケーションは、たとえばファームウェアの更新のために、時々大きなペイロードを転送する必要があります。 HTTPとは対照的に、TCPはセグメント化と再シーケンスの大まかな作業を行いますが、CoAPはUDPやデータグラムトランスポート層セキュリティ（DTLS）などのデータグラムトランスポートに基づいています。これらのトランスポートは断片化のみを提供します。これは制約されたノードとネットワークではさらに問題であり、実際に転送できるリソース表現の最大サイズを制限します。
Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.
IPフラグメンテーションに依存する代わりに、この仕様は、複数の要求と応答のペアのリソース表現から情報の複数のブロックを転送するための「ブロック」オプションのペアで基本的なCoAPを拡張します。多くの重要なケースで、ブロックオプションはサーバーを真にステートレスにすることができます。サーバーは各ブロック転送を個別に処理でき、以前のブロック転送の接続設定や他のサーバー側メモリは必要ありません。基本的に、[ブロック]オプションは、大きな表現をブロックごとに転送する最小限の方法を提供します。
A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.
これらのオプションをサポートしないCoAP実装は、通常、交換できる表現のサイズに制限があるため、ブロックオプションがCoAP実装で広く使用されることが期待されています。したがって、この仕様はRFC 7252を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7959.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7959で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Block-Wise Transfers . . . . . . . . . . . . . . . . . . . . 6
2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 7
2.2. Structure of a Block Option . . . . . . . . . . . . . . . 8
2.3. Block Options in Requests and Responses . . . . . . . . . 10
2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 12
2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 14
2.6. Combining Block-Wise Transfers with the Observe Option . 15
2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 16
2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 16
2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 17
2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 17
2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 17
2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 17
2.10. Caching Considerations . . . . . . . . . . . . . . . . . 18
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 19
3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 23
3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 25
3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 26
4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 29
5. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 31
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 33
7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 34
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. Normative References . . . . . . . . . . . . . . . . . . 34
8.2. Informative References . . . . . . . . . . . . . . . . . 35
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
The work on Constrained RESTful Environments (CoRE) aims at realizing the Representational State Transfer (REST) architecture in a suitable form for the most constrained nodes (such as microcontrollers with limited RAM and ROM [RFC7228]) and networks (such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC4944]) [RFC7252]. The CoAP protocol is intended to provide RESTful [REST] services not unlike HTTP [RFC7230], while reducing the complexity of implementation as well as the size of packets exchanged in order to make these services useful in a highly constrained network of highly constrained nodes.
制約付きRESTful環境（CoRE）に関する作業は、Representational State Transfer（REST）アーキテクチャを最も制約されたノード（RAMおよびROMが制限されたマイクロコントローラー[RFC7228]など）およびネットワーク（IPv6 over Lowなど）に適した形式で実現することを目的としています-Powerワイヤレスパーソナルエリアネットワーク（6LoWPAN）[RFC4944]）[RFC7252]。 CoAPプロトコルは、HTTP [RFC7230]とは異なり、RESTful [REST]サービスを提供することを目的としています。同時に、制約の厳しいノードの非常に制約されたネットワークでこれらのサービスを有用にするために、実装の複雑さと交換されるパケットのサイズを削減します。
This objective requires restraint in a number of sometimes conflicting ways:
この目的は、いくつかの時々相反する方法での抑制を必要とします：
o reducing implementation complexity in order to minimize code size,
o コードサイズを最小化するために実装の複雑さを軽減し、
o reducing message sizes in order to minimize the number of fragments needed for each message (to maximize the probability of delivery of the message), the amount of transmission power needed, and the loading of the limited-bandwidth channel,
o 各メッセージに必要なフラグメントの数を最小化する（メッセージの配信の確率を最大化する）ためにメッセージサイズを縮小する、必要な送信電力の量、および制限された帯域幅チャネルの負荷
o reducing requirements on the environment such as stable storage, good sources of randomness, or user-interaction capabilities.
o 安定したストレージ、ランダム性の優れたソース、ユーザーインタラクション機能など、環境に対する要件を減らす。
Because CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS), the maximum size of resource representations that can be transferred without too much fragmentation is limited. In addition, not all resource representations will fit into a single link-layer packet of a constrained network, which may cause adaptation layer fragmentation even if IP-layer fragmentation is not required. Using fragmentation (either at the adaptation layer or at the IP layer) for the transport of larger representations would be possible up to the maximum size of the underlying datagram protocol (such as UDP), but the fragmentation/reassembly process burdens the lower layers with conversation state that is better managed in the application layer.
CoAPは、UDPやデータグラムトランスポート層セキュリティ（DTLS）などのデータグラムトランスポートに基づいているため、断片化しすぎずに転送できるリソース表現の最大サイズは制限されています。さらに、すべてのリソース表現が制約付きネットワークの単一のリンク層パケットに収まるとは限らないため、IP層の断片化が必要ない場合でも、適応層の断片化が発生する可能性があります。より大きな表現を転送するために（アダプテーションレイヤーまたはIPレイヤーのいずれかで）フラグメンテーションを使用することは、基になるデータグラムプロトコル（UDPなど）の最大サイズまで可能ですが、フラグメンテーション/再構成プロセスは、以下のレイヤーに負担をかけます。アプリケーション層でより適切に管理される会話状態。
The present specification defines a pair of CoAP options to enable block-wise access to resource representations. The Block options provide a minimal way to transfer larger resource representations in a block-wise fashion. The overriding objective is to avoid the need for creating conversation state at the server for block-wise GET requests. (It is impossible to fully avoid creating conversation state for POST/PUT, if the creation/replacement of resources is to be atomic; where that property is not needed, there is no need to create server conversation state in this case, either.) Block-wise transfers are realized as combinations of exchanges, each of which is performed according to the CoAP base protocol [RFC7252]. Each exchange in such a combination is governed by the specifications in [RFC7252], including the congestion control specifications (Section 4.7 of [RFC7252]) and the security considerations (Section 11 of [RFC7252]; additional security considerations then apply to the transfers as a whole, see Section 7). The present specification minimizes the constraints it adds to those base exchanges; however, not all variants of using CoAP are very useful inside a block-wise transfer (e.g., using Non-confirmable requests within block-wise transfers outside the use case of Section 2.8 would escalate the overall non-delivery probability). To be perfectly clear, the present specification also does not remove any of the constraints posed by the base specification it is strictly layered on top of. For example, back-to-back packets are limited by the congestion control described in Section 4.7 of [RFC7252] (NSTART as a limit for initiating exchanges, PROBING_RATE as a limit for sending with no response); block-wise transfers cannot send/solicit more traffic than a client could be sending to / soliciting from the same server without the block-wise mode.
本仕様では、リソース表現へのブロック単位のアクセスを可能にするCoAPオプションのペアを定義します。ブロックオプションは、ブロック単位でより大きなリソース表現を転送する最小限の方法を提供します。オーバーライドの目的は、ブロック単位のGET要求のためにサーバーで会話状態を作成する必要を回避することです。 （リソースの作成/置換がアトミックである場合、POST / PUTの会話状態の作成を完全に回避することは不可能です。そのプロパティが必要ない場合、この場合もサーバー会話状態を作成する必要はありません。）ブロック単位の転送は、CoAPベースプロトコル[RFC7252]に従って実行される交換の組み合わせとして実現されます。このような組み合わせでの各交換は、輻輳制御仕様（[RFC7252]のセクション4.7）およびセキュリティに関する考慮事項（[RFC7252]のセクション11）を含む[RFC7252]の仕様によって管理されます。追加のセキュリティに関する考慮事項が転送に適用されます。全体、セクション7を参照）。現在の仕様は、それらのベース交換に追加する制約を最小化します。ただし、CoAPを使用するすべてのバリアントがブロック単位の転送内で非常に役立つわけではありません（たとえば、セクション2.8のユースケース外のブロック単位の転送内で確認不可能なリクエストを使用すると、全体的な配信不能確率が増加します）。完全に明確にするために、本仕様は、厳密にその上に階層化されている基本仕様によって課された制約も削除していません。たとえば、バックツーバックパケットは、[RFC7252]のセクション4.7で説明されている輻輳制御によって制限されます（NSTARTは交換を開始するための制限として、PROBING_RATEは応答なしで送信するための制限として）。ブロック単位の転送では、クライアントがブロック単位のモードなしで同じサーバーに送信したり、同じサーバーから要求したりするよりも多くのトラフィックを送信/請求できません。
In some cases, the present specification will RECOMMEND that a client perform a sequence of block-wise transfers "without undue delay". This cannot be phrased as an interoperability requirement, but is an expectation on implementation quality. Conversely, the expectation is that servers will not have to go out of their way to accommodate clients that take considerable time to finish a block-wise transfer. For example, for a block-wise GET, if the resource changes while this proceeds, the entity-tag (ETag) for a further block obtained may be different. To avoid this happening all the time for a fast-changing resource, a server MAY try to keep a cache around for a specific client for a short amount of time. The expectation here is that the lifetime for such a cache can be kept short, on the order of a few expected round-trip times, counting from the previous block transferred.
場合によっては、本仕様は、クライアントが「過度の遅延なしに」一連のブロック単位の転送を実行することを推奨します。これは相互運用性の要件とは言えませんが、実装の品質に対する期待です。逆に、ブロック単位の転送を完了するのにかなりの時間がかかるクライアントに対応するために、サーバーが邪魔になる必要がないことが期待されます。たとえば、ブロック単位のGETの場合、これが進行中にリソースが変更されると、取得される次のブロックのエンティティタグ（ETag）が異なる場合があります。変化の速いリソースでこれが常に発生するのを回避するために、サーバーは、特定のクライアントのキャッシュを短時間保持するように試みる場合があります。ここでの期待は、転送された前のブロックから数えて、数回の予想往復時間のオーダーで、そのようなキャッシュの寿命を短く保つことができるということです。
In summary, this specification adds a pair of Block options to CoAP that can be used for block-wise transfers. Benefits of using these options include:
要約すると、この仕様は、ブロック単位の転送に使用できるCoAPにブロックオプションのペアを追加します。これらのオプションを使用する利点は次のとおりです。
o Transfers larger than what can be accommodated in constrained-network link-layer packets can be performed in smaller blocks.
o 制約付きネットワークのリンク層パケットに対応できる転送よりも大きい転送は、より小さなブロックで実行できます。
o No hard-to-manage conversation state is created at the adaptation layer or IP layer for fragmentation.
o 断片化のために、適応層またはIP層で管理が難しい会話状態は作成されません。
o The transfer of each block is acknowledged, enabling individual retransmission if required.
o 各ブロックの転送が確認され、必要に応じて個々の再送信が可能になります。
o Both sides have a say in the block size that actually will be used.
o 両側には、実際に使用されるブロックサイズに発言権があります。
o The resulting exchanges are easy to understand using packet analyzer tools, and thus quite accessible to debugging.
o 結果の交換は、パケットアナライザツールを使用して簡単に理解できるため、デバッグに非常にアクセスしやすくなっています。
o If needed, the Block options can also be used (without changes) to provide random access to power-of-two sized blocks within a resource representation.
o 必要に応じて、ブロックオプションを（変更なしで）使用して、リソース表現内の2のべき乗サイズのブロックへのランダムアクセスを提供することもできます。
A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, see Section 4.6 of [RFC7252]. Even though the options are Critical, a server may decide to start using them in an unsolicited way in a response. No effort was expended to provide a capability indication mechanism supporting that decision: since the block-wise transfer mechanisms are so fundamental to the use of CoAP for representations larger than about a kilobyte, there is an expectation that they are very widely implemented.
これらのオプションをサポートしないCoAP実装は、交換できる表現のサイズに制限があります。[RFC7252]のセクション4.6を参照してください。これらのオプションは重要ですが、サーバーは、応答で一方的な方法でオプションの使用を開始する場合があります。その決定をサポートする機能表示メカニズムを提供するための労力は費やされませんでした。ブロック単位の転送メカニズムは、約1キロバイトを超える表現でCoAPを使用するうえで非常に基本的であるため、非常に広く実装されることが期待されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant CoAP implementations.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントでは、RFC 2119、BCP 14 [RFC2119]で説明されているように解釈され、準拠するCoAP実装の要件レベルを示します。
In this document, the term "byte" is used in its now customary sense as a synonym for "octet".
このドキュメントでは、「バイト」という用語は「オクテット」の同義語として現在慣習的な意味で使用されています。
Where bit arithmetic is explained, this document uses the notation familiar from the programming language C, except that the operator "**" stands for exponentiation.
ビット演算について説明する場合、このドキュメントでは、演算子「**」が指数を表すことを除いて、プログラミング言語Cでよく知られている表記法を使用しています。
As discussed in the introduction, there are good reasons to limit the size of datagrams in constrained networks:
はじめに説明したように、制約付きネットワークでデータグラムのサイズを制限するのには十分な理由があります。
o by the maximum datagram size (~ 64 KiB for UDP)
o 最大データグラムサイズ（UDPの場合は〜64 KiB）
o by the desire to avoid IP fragmentation (MTU of 1280 for IPv6)
o IPフラグメンテーションを回避したいという願望（IPv6のMTUは1280）
o by the desire to avoid adaptation-layer fragmentation (60-80 bytes for 6LoWPAN [RFC4919])
o アダプテーションレイヤーの断片化を回避したいという要望による（6LoWPANの場合は60〜80バイト[RFC4919]）
When a resource representation is larger than can be comfortably transferred in the payload of a single CoAP datagram, a Block option can be used to indicate a block-wise transfer. As payloads can be sent both with requests and with responses, this specification provides two separate options for each direction of payload transfer. In naming these options (for block-wise transfers as well as in Section 4), we use the number 1 ("Block1", "Size1") to refer to the transfer of the resource representation that pertains to the request, and the number 2 ("Block2", "Size2") to refer to the transfer of the resource representation for the response.
リソース表現が単一のCoAPデータグラムのペイロードで快適に転送できるよりも大きい場合、ブロックオプションを使用してブロック単位の転送を示すことができます。ペイロードはリクエストとレスポンスの両方で送信できるため、この仕様では、ペイロード転送の方向ごとに2つの個別のオプションが提供されています。これらのオプションに名前を付ける際（ブロック単位の転送とセクション4の場合）、番号1（ "Block1"、 "Size1"）を使用して、要求に関連するリソース表現の転送と番号を表します2（ "Block2"、 "Size2"）は、応答のリソース表現の転送を指します。
In the following, the term "payload" will be used for the actual content of a single CoAP message, i.e., a single block being transferred, while the term "body" will be used for the entire resource representation that is being transferred in a block-wise fashion. The Content-Format Option applies to the body, not to the payload; in particular, the boundaries between the blocks may be in places that are not separating whole units in terms of the structure, encoding, or content-coding used by the Content-Format. (Similarly, the ETag Option defined in Section 5.10.6 of [RFC7252] applies to the whole representation of the resource, and thus to the body of the response.)
以下では、「ペイロード」という用語は、単一のCoAPメッセージの実際のコンテンツ、つまり転送される単一のブロックに使用され、「本体」という用語は、転送されるリソース表現全体に使用されます。ブロックごとのファッション。 Content-Formatオプションは、ペイロードではなく本文に適用されます。特に、ブロック間の境界は、Content-Formatで使用される構造、エンコーディング、またはコンテンツコーディングの観点から、ユニット全体を分離していない場所にある可能性があります。 （同様に、[RFC7252]のセクション5.10.6で定義されたETagオプションは、リソースの表現全体に、したがって応答の本文に適用されます。）
In most cases, all blocks being transferred for a body (except for the last one) will be of the same size. (If the first request uses a bigger block size than the receiver prefers, subsequent requests will use the preferred block size.) The block size is not fixed by the protocol. To keep the implementation as simple as possible, the Block options support only a small range of power-of-two block sizes, from 2**4 (16) to 2**10 (1024) bytes. As bodies often will not evenly divide into the power-of-two block size chosen, the size need not be reached in the final block (but even for the final block, the chosen power-of-two size will still be indicated in the block size field of the Block option).
ほとんどの場合、ボディに転送されるすべてのブロック（最後のブロックを除く）は同じサイズになります。 （最初の要求が受信側の希望よりも大きいブロックサイズを使用する場合、後続の要求は優先ブロックサイズを使用します。）ブロックサイズはプロトコルによって固定されていません。実装を可能な限り単純にするために、ブロックオプションは2 ** 4（16）から2 ** 10（1024）バイトまでの2のべき乗のブロックサイズの狭い範囲のみをサポートします。ボディは選択された2のべき乗のブロックサイズに均等に分割されないことが多いため、最終ブロックでサイズに到達する必要はありません（ただし、最終ブロックの場合でも、選択された2のべき乗サイズは引き続きブロックオプションのブロックサイズフィールド）。
+-----+---+---+---+---+--------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+--------+--------+--------+---------+
| 23 | C | U | - | - | Block2 | uint | 0-3 | (none) |
| | | | | | | | | |
| 27 | C | U | - | - | Block1 | uint | 0-3 | (none) |
+-----+---+---+---+---+--------+--------+--------+---------+
Table 1: Block Option Numbers
表1：ブロックオプション番号
Both Block1 and Block2 Options can be present in both the request and response messages. In either case, the Block1 Option pertains to the request payload, and the Block2 Option pertains to the response payload.
Block1オプションとBlock2オプションの両方を、要求メッセージと応答メッセージの両方に含めることができます。どちらの場合も、Block1オプションは要求ペイロードに関係し、Block2オプションは応答ペイロードに関係します。
Hence, for the methods defined in [RFC7252], Block1 is useful with the payload-bearing POST and PUT requests and their responses. Block2 is useful with GET, POST, and PUT requests and their payload-bearing responses (2.01, 2.02, 2.04, and 2.05 -- see Section 5.5 of [RFC7252]).
したがって、[RFC7252]で定義されているメソッドの場合、Block1は、ペイロードを伴うPOSTおよびPUTリクエストとそれらのレスポンスで役立ちます。 Block2は、GET、POST、PUTリクエストとそれらのペイロードを含むレスポンス（2.01、2.02、2.04、および2.05-[RFC7252]のセクション5.5を参照）で役立ちます。
Where Block1 is present in a request or Block2 in a response (i.e., in that message to the payload of which it pertains) it indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred ("descriptive usage"). Where it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed ("control usage").
Block1がリクエストにあるか、Block2がレスポンスにある場合（つまり、それが関係するペイロードへのメッセージにある場合）、ブロック単位の転送を示し、この特定のブロック単位のペイロードが転送される本文全体の一部を形成する方法を説明します（「説明的な使用法」）。それが反対方向に存在する場合、そのペイロードがどのように形成または処理されるかについての追加の制御を提供します（「制御の使用法」）。
Implementation of either Block option is intended to be optional. However, when it is present in a CoAP message, it MUST be processed (or the message rejected); therefore, it is identified as a Critical option. Either Block option MUST NOT occur more than once in a single message.
いずれかのBlockオプションの実装はオプションであることを意図しています。ただし、CoAPメッセージに存在する場合は、処理する必要があります（またはメッセージを拒否します）。したがって、重要なオプションとして識別されます。どちらのブロックオプションも、1つのメッセージで複数回発生してはなりません。
Three items of information may need to be transferred in a Block (Block1 or Block2) option:
ブロック（ブロック1またはブロック2）オプションで3つの情報項目を転送する必要がある場合があります。
o the size of the block (SZX);
o ブロックのサイズ（SZX）;
o whether more blocks are following (M);
o より多くのブロックが続くかどうか（M）;
o the relative number of the block (NUM) within a sequence of blocks with the given size.
o 指定されたサイズの一連のブロック内のブロックの相対番号（NUM）。
The value of the Block option is a variable-size (0 to 3 byte) unsigned integer (uint, see Section 3.2 of [RFC7252]). This integer value encodes these three fields, see Figure 1. (Due to the CoAP uint-encoding rules, when all of NUM, M, and SZX happen to be zero, a zero-byte integer will be sent.)
[ブロック]オプションの値は、可変サイズ（0〜3バイト）の符号なし整数（uint、[RFC7252]のセクション3.2を参照）です。この整数値はこれらの3つのフィールドをエンコードします（図1を参照）（CoAP uint-encodingルールにより、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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Block Option Value
図1：ブロックオプション値
The block size is encoded using a three-bit unsigned integer (0 for 2**4 bytes to 6 for 2**10 bytes), which we call the "SZX" ("size exponent"); the actual block size is then "2**(SZX + 4)". SZX is transferred in the three least significant bits of the option value (i.e., "val & 7" where "val" is the value of the option).
ブロックサイズは、3ビットの符号なし整数（2 ** 4バイトの場合は0から2 ** 10バイトの場合は6）を使用してエンコードされます。これを「SZX」（「サイズ指数」）と呼びます。その場合、実際のブロックサイズは「2 **（SZX + 4）」になります。 SZXは、オプション値の最下位3ビットで転送されます（つまり、「val＆7」。ここで、「val」はオプションの値です）。
The fourth least significant bit, the M or "more" bit ("val & 8"), indicates whether more blocks are following or if the current block-wise transfer is the last block being transferred.
4番目の最下位ビットであるMビットまたは「more」ビット（「val＆8」）は、さらにブロックが続くか、現在のブロック単位の転送が転送される最後のブロックであるかを示します。
The option value divided by sixteen (the NUM field) is the sequence number of the block currently being transferred, starting from zero. The current transfer is, therefore, about the "size" bytes starting at byte "NUM << (SZX + 4)".
オプション値を16で割った値（NUMフィールド）は、現在転送中のブロックのシーケンス番号であり、ゼロから始まります。したがって、現在の転送は、バイト「NUM <<（SZX + 4）」から始まる「サイズ」バイト程度です。
Implementation note: As an implementation convenience, "(val & ~0xF) << (val & 7)", i.e., the option value with the last 4 bits masked out, shifted to the left by the value of SZX, gives the byte position of the first byte of the block being transferred.
実装に関する注記：実装の便宜上、「（val＆〜0xF）<<（val＆7）」、つまり、最後の4ビットがマスクされ、SZXの値だけ左にシフトされたオプション値は、バイトを示します。転送されるブロックの最初のバイトの位置。
More specifically, within the option value of a Block1 or Block2 Option, the meaning of the option fields is defined as follows:
より具体的には、Block1またはBlock2オプションのオプション値内で、オプションフィールドの意味は次のように定義されます。
NUM: Block Number, indicating the block number being requested or provided. Block number 0 indicates the first block of a body (i.e., starting with the first byte of the body).
NUM：ブロック番号。要求または提供されているブロック番号を示します。ブロック番号0は、ボディの最初のブロックを示します（つまり、ボディの最初のバイトから始まります）。
M: More Flag ("not last block"). For descriptive usage, this flag, if unset, indicates that the payload in this message is the last block in the body; when set, it indicates that there are one or more additional blocks available. When a Block2 Option is used in a request to retrieve a specific block number ("control usage"), the M bit MUST be sent as zero and ignored on reception. (In a Block1 Option in a response, the M flag is used to indicate atomicity, see below.)
M：その他のフラグ（「最後のブロックではない」）。説明的な使用の場合、このフラグは、設定されていない場合、このメッセージのペイロードが本文の最後のブロックであることを示します。設定されると、1つ以上の追加のブロックが利用可能であることを示します。特定のブロック番号を取得するための要求でBlock2オプションが使用される場合（「制御使用法」）、Mビットはゼロとして送信され、受信時には無視される必要があります。 （応答のBlock1オプションでは、Mフラグを使用して原子性を示します。以下を参照してください。）
SZX: Block Size. The block size is represented as a three-bit unsigned integer indicating the size of a block to the power of two. Thus, block size = 2**(SZX + 4). The allowed values of SZX are 0 to 6, i.e., the minimum block size is 2**(0+4) = 16 and the maximum is 2**(6+4) = 1024. The value 7 for SZX (which would indicate a block size of 2048) is reserved, i.e., MUST NOT be sent and MUST lead to a 4.00 Bad Request response code upon reception in a request.
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レスポンスコードにつながる必要があります。
There is no default value for the Block1 and Block2 Options. Absence of one of these options is equivalent to an option value of 0 with respect to the value of NUM and M that could be given in the option, i.e., it indicates that the current block is the first and only block of the transfer (block number 0, M bit not set). However, in contrast to the explicit value 0, which would indicate an SZX of 0 and thus a size value of 16 bytes, there is no specific explicit size implied by the absence of the option -- the size is left unspecified. (As for any uint, the explicit value 0 is efficiently indicated by a zero-length option; this, therefore, is different in semantics from the absence of the option.)
Block1およびBlock2オプションのデフォルト値はありません。これらのオプションのいずれかがない場合、オプションで指定できるNUMおよびMの値に関してオプション値0と同等です。つまり、現在のブロックが転送の最初で唯一のブロックであることを示します（ブロック番号0、Mビットは設定されていません）。ただし、SZXが0、したがってサイズ値が16バイトであることを示す明示的な値0とは対照的に、オプションがないことによって暗黙的に指定される明示的なサイズはありません。サイズは指定されません。 （どのuintについても、明示的な値0は長さゼロのオプションによって効率的に示されます。したがって、これはオプションがないこととは意味が異なります。）
The Block options are used in one of three roles:
ブロックオプションは、次の3つの役割のいずれかで使用されます。
o In descriptive usage, i.e., a Block2 Option in a response (such as a 2.05 response for GET), or a Block1 Option in a request (a PUT or POST):
o 説明的な使用法、つまり、応答のBlock2オプション（GETの2.05応答など）、または要求のBlock1オプション（PUTまたはPOST）：
* The NUM field in the option value describes what block number is contained in the payload of this message.
* オプション値のNUMフィールドは、このメッセージのペイロードに含まれるブロック番号を示します。
* The M bit indicates whether further blocks need to be transferred to complete the transfer of that body.
* Mビットは、その本体の転送を完了するためにさらにブロックを転送する必要があるかどうかを示します。
* The block size implied by SZX MUST match the size of the payload in bytes, if the M bit is set. (SZX does not govern the payload size if M is unset). For Block2, if the request suggested a larger value of SZX, the next request MUST move SZX down to the size given in the response. (The effect is that, if the server uses the smaller of (1) its preferred block size and (2) the block size requested, all blocks for a body use the same block size.)
* Mビットが設定されている場合、SZXによって暗示されるブロックサイズは、ペイロードのサイズ（バイト単位）と一致する必要があります。 （Mが設定されていない場合、SZXはペイロードサイズを制御しません）。 Block2の場合、リクエストがSZXのより大きな値を提案した場合、次のリクエストはSZXを応答で指定されたサイズに移動する必要があります。 （効果は、サーバーが（1）優先ブロックサイズと（2）要求されたブロックサイズの小さい方を使用する場合、本文のすべてのブロックが同じブロックサイズを使用することです。）
o A Block2 Option in control usage in a request (e.g., GET):
o リクエストでのコントロールの使用におけるBlock2オプション（GETなど）：
* The NUM field in the Block2 Option gives the block number of the payload that is being requested to be returned in the response.
* Block2オプションのNUMフィールドは、応答で返されるように要求されているペイロードのブロック番号を示します。
* In this case, the M bit has no function and MUST be set to zero.
* この場合、Mビットには機能がなく、ゼロに設定する必要があります。
* The block size given (SZX) suggests a block size (in the case of block number 0) or repeats the block size of previous blocks received (in the case of a non-zero block number).
* 指定されたブロックサイズ（SZX）は、ブロックサイズ（ブロック番号0の場合）を示唆するか、受信した以前のブロックのブロックサイズを繰り返します（ゼロ以外のブロック番号の場合）。
o A Block1 Option in control usage in a response (e.g., a 2.xx response for a PUT or POST request):
o 応答の制御使用におけるBlock1オプション（たとえば、PUTまたはPOST要求の2.xx応答）：
* The NUM field of the Block1 Option indicates what block number is being acknowledged.
* Block1オプションのNUMフィールドは、どのブロック番号が確認されているかを示します。
* If the M bit was set in the request, the server can choose whether to act on each block separately, with no memory, or whether to handle the request for the entire body atomically, or any mix of the two.
* リクエストでMビットが設定されている場合、サーバーは、メモリなしで各ブロックを個別に処理するか、ボディ全体のリクエストをアトミックに処理するか、またはこの2つの組み合わせを処理するかを選択できます。
+ If the M bit is also set in the response, it indicates that this response does not carry the final response code to the request, i.e., the server collects further blocks from the same endpoint and plans to implement the request atomically (e.g., acts only upon reception of the last block of payload). In this case, the response MUST NOT carry a Block2 Option.
+ 応答でMビットも設定されている場合、この応答は最終応答コードを要求に伝えないことを示します。つまり、サーバーは同じエンドポイントからさらにブロックを収集し、要求をアトミックに実装することを計画します（たとえば、ペイロードの最後のブロックを受信したとき）。この場合、応答にはBlock2オプションを含めてはなりません（MUST NOT）。
+ Conversely, if the M bit is unset even though it was set in the request, it indicates the block-wise request was enacted now specifically for this block, and the response carries the final response to this request (and to any previous ones with the M bit set in the response's Block1 Option in this sequence of block-wise transfers); the client is still expected to continue sending further blocks, the request method for which may or may not also be enacted per-block. (Note that the resource is now in a partially updated state; this approach is only appropriate where exposing such an intermediate state is acceptable. The client can reduce the window by quickly continuing to update the resource, or, in case of failure, restarting the update.)
+逆に、リクエストで設定されていてもMビットが設定されていない場合は、ブロック単位のリクエストがこのブロック専用に制定されたことを示し、レスポンスにはこのリクエスト（および以前のリクエストに対する最終レスポンス）が含まれますこのブロック単位の転送シーケンスの応答のBlock1オプションで設定されたMビット）;クライアントはさらにブロックを送信し続けることが期待されており、その要求メソッドはブロックごとに制定される場合と制定されない場合があります。 （リソースが部分的に更新された状態になっていることに注意してください。このアプローチは、このような中間状態の公開が許容される場合にのみ適切です。クライアントは、リソースの更新をすばやく続行することでウィンドウを縮小できます。失敗した場合は、更新。）
* Finally, the SZX block size given in a control Block1 Option indicates the largest block size preferred by the server for transfers toward the resource that is the same or smaller than the one used in the initial exchange; the client SHOULD use this block size or a smaller one in all further requests in the transfer sequence, even if that means changing the block size (and possibly scaling the block number accordingly) from now on.
* 最後に、制御Block1オプションで指定されたSZXブロックサイズは、最初の交換で使用されたものと同じかそれよりも小さいリソースへの転送のためにサーバーが優先する最大ブロックサイズを示します。クライアントは、これからブロックサイズを変更すること（およびそれに応じてブロック番号をスケーリングすること）を意味する場合でも、転送シーケンスの以降のすべての要求でこのブロックサイズまたはより小さいブロックを使用する必要があります（SHOULD）。
Using one or both Block options, a single REST operation can be split into multiple CoAP message exchanges. As specified in [RFC7252], each of these message exchanges uses their own CoAP Message ID.
1つまたは両方のブロックオプションを使用して、1つのREST操作を複数のCoAPメッセージ交換に分割できます。 [RFC7252]で指定されているように、これらのメッセージ交換はそれぞれ独自のCoAPメッセージIDを使用します。
The Content-Format Option sent with the requests or responses MUST reflect the Content-Format of the entire body. If blocks of a response body arrive with different Content-Format Options, it is up to the client how to handle this error (it will typically abort any ongoing block-wise transfer). If blocks of a request arrive at a server with mismatching Content-Format Options, the server MUST NOT assemble them into a single request; this usually leads to a 4.08 (Request Entity Incomplete, Section 2.9.2) error response on the mismatching block.
要求または応答とともに送信されるContent-Formatオプションは、本文全体のContent-Formatを反映する必要があります。応答本文のブロックが異なるContent-Formatオプションとともに到着した場合、クライアントがこのエラーを処理する方法を決定します（通常、進行中のブロック単位の転送は中止されます）。リクエストのブロックが一致しないContent-Formatオプションでサーバーに到着した場合、サーバーはそれらを単一のリクエストにアセンブルしてはなりません（MUST NOT）。これは通常、不一致ブロックで4.08（Request Entity Incomplete、Section 2.9.2）エラー応答を引き起こします。
When a request is answered with a response carrying a Block2 Option with the M bit set, the requester may retrieve additional blocks of the resource representation by sending further requests with the same options as the initial request and a Block2 Option giving the block number and block size desired. In a request, the client MUST set the M bit of a Block2 Option to zero and the server MUST ignore it on reception.
Mビットが設定されたBlock2オプションを含む応答で要求に応答すると、要求者は、最初の要求と同じオプションとブロック番号とブロックを指定するBlock2オプションを含む要求をさらに送信することにより、リソース表現の追加のブロックを取得できます。希望のサイズ。リクエストでは、クライアントはBlock2オプションのMビットをゼロに設定しなければならず（MUST）、サーバーは受信時にそれを無視しなければなりません（MUST）。
To influence the block size used in a response, the requester MAY also use the Block2 Option on the initial request, giving the desired size, a block number of zero and an M bit of zero. A server MUST use the block size indicated or a smaller size. Any further block-wise requests for blocks beyond the first one MUST indicate the same block size that was used by the server in the response for the first request that gave a desired size using a Block2 Option.
応答で使用されるブロックサイズに影響を与えるために、リクエスタは最初の要求でBlock2オプションも使用して、必要なサイズ、ゼロのブロック番号、およびゼロのMビットを指定できます。サーバーは、指定されたブロックサイズ以下のサイズを使用する必要があります。最初のブロックを超えるブロックに対するブロックごとの要求は、Block2オプションを使用して目的のサイズを与えた最初の要求に対する応答でサーバーが使用したのと同じブロックサイズを示す必要があります。
Once the Block2 Option is used by the requester and a first response has been received with a possibly adjusted block size, all further requests in a single block-wise transfer will ultimately converge on using the same size, except that there may not be enough content to fill the last block (the one returned with the M bit not set). (Note that the client may start using the Block2 Option in a second request after a first request without a Block2 Option resulted in a Block2 Option in the response.) The server uses the block size indicated in the request option or a smaller size, but the requester MUST take note of the actual block size used in the response it receives to its initial request and proceed to use it in subsequent requests. The server behavior MUST ensure that this client behavior results in the same block size for all responses in a sequence (except for the last one with the M bit not set, and possibly the first one if the initial request did not contain a Block2 Option).
要求者がBlock2オプションを使用し、調整されたブロックサイズで最初の応答を受信すると、単一のブロック単位の転送での以降のすべての要求は、十分なコンテンツがない場合を除いて、最終的に同じサイズを使用して収束します。最後のブロック（Mビットが設定されていない状態で返されたブロック）を埋めます。 （クライアントは、Block2 Optionのない最初のリクエストが応答にBlock2 Optionをもたらした後、2番目のリクエストでBlock2 Optionの使用を開始する場合があることに注意してください。）サーバーはリクエストオプションで指定されたブロックサイズまたはそれより小さいサイズを使用しますが、リクエスタは、最初のリクエストに対して受け取った応答で使用されている実際のブロックサイズに注意し、後続のリクエストでそれを使用する必要があります。サーバーの動作は、このクライアントの動作がシーケンス内のすべての応答に対して同じブロックサイズになることを保証する必要があります（Mビットが設定されていない最後の応答と、最初の要求にBlock2オプションが含まれていない場合は最初の応答を除く）。 。
Block-wise transfers can be used to GET resources whose representations are entirely static (not changing over time at all, such as in a schema describing a device), or for dynamically changing resources. In the latter case, the Block2 Option SHOULD be used in conjunction with the ETag Option ([RFC7252], Section 5.10.6), to ensure that the blocks being reassembled are from the same version of the representation: The server SHOULD include an ETag Option in each response. If an ETag Option is available, the client, when reassembling the representation from the blocks being exchanged, MUST compare ETag Options. If the ETag Options do not match in a GET transfer, the requester has the option of attempting to retrieve fresh values for the blocks it retrieved first. To minimize the resulting inefficiency, the server MAY cache the current value of a representation for an ongoing sequence of requests. (The server may identify the sequence by the combination of the requesting endpoint and the URI being the same in each block-wise request.) Note well that this specification makes no requirement for the server to establish any state; however, servers that offer quickly changing resources may thereby make it impossible for a client to ever retrieve a consistent set of blocks. Clients that want to retrieve all blocks of a resource SHOULD strive to do so without undue delay. Servers can fully expect to be free to discard any cached state after a period of EXCHANGE_LIFETIME ([RFC7252], Section 4.8.2) after the last access to the state, however, there is no requirement to always keep the state for as long.
ブロック単位の転送を使用して、表現が完全に静的であるリソースを取得する（デバイスを記述するスキーマなど、時間の経過とともにまったく変化しない）か、リソースを動的に変更することができます。後者の場合、Block2オプションはETagオプション（[RFC7252]、セクション5.10.6）と組み合わせて使用する必要があり（SHOULD）、再構築されるブロックが同じバージョンの表現からのものであることを確認します。サーバーはETagを含む必要があります（SHOULD）各応答のオプション。 ETagオプションが利用可能な場合、クライアントは、交換されるブロックから表現を再構築するときに、ETagオプションを比較する必要があります。 ETagオプションがGET転送で一致しない場合、リクエスターには、最初に取得したブロックの新しい値を取得するオプションがあります。結果として生じる非効率性を最小限に抑えるために、サーバーは、要求の進行中のシーケンスの表現の現在の値をキャッシュしてもよい（MAY）。 （サーバーは、要求するエンドポイントとURIの組み合わせによってシーケンスを識別できます。各ブロック単位の要求で同じです。）この仕様では、サーバーが状態を確立する必要がないことに注意してください。ただし、リソースが急速に変化するサーバーでは、クライアントが一貫したブロックのセットを取得することが不可能になる場合があります。リソースのすべてのブロックを取得したいクライアントは、過度の遅延なしに取得するよう努めるべきです（SHOULD）。サーバーは、状態への最後のアクセスからEXCHANGE_LIFETIME（[RFC7252]、セクション4.8.2）の期間が経過した後、キャッシュされた状態を自由に破棄できることを完全に期待できますが、常にその状態を長期間維持する必要はありません。
The Block2 Option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise response payload transfer (e.g., GET) operations to the same resource. This is rarely a requirement, but as a workaround, a client may vary the cache key (e.g., by using one of several URIs accessing resources with the same semantics, or by varying a proxy-safe elective option).
Block2オプションは、単一のエンドポイントが同じリソースに対して複数の並行して進行するブロック単位の応答ペイロード転送（GETなど）操作を実行する方法を提供しません。これが必要になることはめったにありませんが、回避策として、クライアントがキャッシュキーを変更する場合があります（たとえば、同じセマンティクスでリソースにアクセスする複数のURIの1つを使用するか、プロキシセーフの選択オプションを変更する）。
In a request with a request payload (e.g., PUT or POST), the Block1 Option refers to the payload in the request (descriptive usage).
リクエストペイロード（PUTやPOSTなど）を含むリクエストでは、Block1オプションはリクエスト内のペイロードを参照します（説明的な使用法）。
In response to a request with a payload (e.g., a PUT or POST transfer), the block size given in the Block1 Option indicates the block size preference of the server for this resource (control usage). Obviously, at this point the first block has already been transferred by the client without benefit of this knowledge. Still, the client SHOULD heed the preference indicated and, for all further blocks, use the block size preferred by the server or a smaller one. Note that any reduction in the block size may mean that the second request starts with a block number larger than one, as the first request already transferred multiple blocks as counted in the smaller size.
ペイロードを含むリクエスト（PUTやPOST転送など）に応答して、Block1オプションで指定されたブロックサイズは、このリソース（制御使用）に対するサーバーのブロックサイズ設定を示します。明らかに、この時点で最初のブロックはすでにこの知識の恩恵を受けることなくクライアントによって転送されています。それでも、クライアントは示された設定に注意する必要があり、それ以降のすべてのブロックについては、サーバーまたはより小さなブロックが優先するブロックサイズを使用します。最初の要求はすでに複数のブロックを転送しているため、ブロックサイズを小さくすると、2番目の要求が1より大きいブロック番号で始まる場合があることに注意してください。
To counter the effects of adaptation-layer fragmentation on packet-delivery probability, a client may want to give up retransmitting a request with a relatively large payload even before MAX_RETRANSMIT has been reached, and try restating the request as a block-wise transfer with a smaller payload. Note that this new attempt is then a new message-layer transaction and requires a new Message ID. (Because of the uncertainty about whether the request or the acknowledgement was lost, this strategy is useful mostly for idempotent requests.)
パケット配信の確率に対するアダプテーションレイヤーの断片化の影響に対抗するために、クライアントは、MAX_RETRANSMITに到達する前であっても、比較的大きなペイロードを含むリクエストの再送をあきらめ、リクエストをペイロードが小さい。この新しい試みは新しいメッセージ層トランザクションであり、新しいメッセージIDが必要になることに注意してください。 （要求または確認応答が失われたかどうかの不確実性のため、この戦略は主にべき等の要求に役立ちます。）
In a block-wise transfer of a request payload (e.g., a PUT or POST) that is intended to be implemented in an atomic fashion at the server, the actual creation/replacement takes place at the time the final block, i.e., a block with the M bit unset in the Block1 Option, is received. In this case, all success responses to non-final blocks carry the response code 2.31 (Continue, Section 2.9.1). If not all previous blocks are available at the server at the time of processing the final block, the transfer fails and error code 4.08 (Request Entity Incomplete, Section 2.9.2) MUST be returned. A server MAY also return a 4.08 error code for any (final or non-final) Block1 transfer that is not in sequence; therefore, clients that do not have specific mechanisms to handle this case SHOULD always start with block zero and send the following blocks in order.
サーバーでアトミックな方法で実装することを目的としたリクエストペイロード（PUTやPOSTなど）のブロック単位の転送では、実際の作成/置換は最終ブロック、つまりブロックの時点で行われます。 Block1オプションでMビットが設定されていない状態で受信されます。この場合、非最終ブロックに対するすべての成功応答には、応答コード2.31が含まれます（続行、セクション2.9.1）。最後のブロックの処理時にすべての以前のブロックがサーバーで利用できない場合、転送は失敗し、エラーコード4.08（エンティティのリクエストが不完全、セクション2.9.2）が返されます。サーバーは、シーケンスにない（最終または非最終の）Block1転送に対しても4.08エラーコードを返す場合があります。したがって、このケースを処理する特定のメカニズムを持たないクライアントは、常にブロック0から開始し、次のブロックを順番に送信する必要があります（SHOULD）。
One reason that a client might encounter a 4.08 error code is that the server has already timed out and discarded the partial request body being assembled. Clients SHOULD strive to send all blocks of a request without undue delay. Servers can fully expect to be free to discard any partial request body when a period of EXCHANGE_LIFETIME ([RFC7252], Section 4.8.2) has elapsed after the most recent block was transferred; however, there is no requirement on a server to always keep the partial request body for as long.
クライアントが4.08エラーコードに遭遇する可能性のある1つの理由は、サーバーがすでにタイムアウトし、アセンブルされている部分的なリクエスト本文を破棄したことです。クライアントは、過度の遅延なしにリクエストのすべてのブロックを送信するよう努めるべきです。最新のブロックが転送されてからEXCHANGE_LIFETIME（[RFC7252]、セクション4.8.2）の期間が経過した場合、サーバーはリクエスト本文の一部を自由に破棄できることを完全に期待できます。ただし、サーバーが部分的なリクエストの本文を常に長く保持する必要はありません。
The error code 4.13 (Request Entity Too Large) can be returned at any time by a server that does not currently have the resources to store blocks for a block-wise request payload transfer that it would intend to implement in an atomic fashion. (Note that a 4.13 response to a request that does not employ Block1 is a hint for the client to try sending Block1, and a 4.13 response with a smaller SZX in its Block1 Option than requested is a hint to try a smaller SZX.)
エラーコード4.13（リクエストエンティティが大きすぎる）は、アトミックな方法で実装しようとしているブロック単位のリクエストペイロード転送用のブロックを格納するリソースを現在備えていないサーバーからいつでも返すことができます。 （Block1を使用しない要求に対する4.13応答は、クライアントがBlock1を送信しようとするヒントであり、要求されたものよりも小さいSZXを含む4.13応答は、より小さいSZXを試行するヒントであることに注意してください。）
A block-wise transfer of a request payload that is implemented in a stateless fashion at the server is likely to leave the resource being operated on in an inconsistent state while the transfer is still ongoing or when the client does not complete the transfer. This characteristic is closer to that of remote file systems than to that of HTTP, where state is always kept on the server during a transfer. Techniques well known from shared file access (e.g., client-specific temporary resources) can be used to mitigate this difference from HTTP.
サーバーでステートレスな方法で実装されたリクエストペイロードのブロック単位の転送では、転送がまだ進行中の間、またはクライアントが転送を完了しないときに、操作されているリソースが不整合な状態のままになる可能性があります。この特性は、転送中は常にサーバー上で状態が保持されるHTTPの特性よりも、リモートファイルシステムの特性に近いものです。共有ファイルアクセスでよく知られている手法（クライアント固有の一時リソースなど）を使用して、HTTPとのこの違いを緩和できます。
The Block1 Option provides no way for a single endpoint to perform multiple concurrently proceeding block-wise request payload transfer (e.g., PUT or POST) operations to the same resource. Starting a new block-wise sequence of requests to the same resource (before an old sequence from the same endpoint was finished) simply overwrites the context the server may still be keeping. (This is probably exactly what one wants in this case -- the client may simply have restarted and lost its knowledge of the previous sequence.)
Block1オプションは、単一のエンドポイントが同じリソースに対して複数の並行して進行するブロック単位のリクエストペイロード転送（たとえば、PUTまたはPOST）操作を実行する方法を提供しません。 （同じエンドポイントからの古いシーケンスが完了する前に）同じリソースへの新しいブロック単位のリクエストシーケンスを開始すると、サーバーが保持しているコンテキストが上書きされるだけです。 （これはおそらく、この場合に必要なものです-クライアントが単に再起動し、前のシーケンスの知識を失っただけかもしれません。）
The Observe option provides a way for a client to be notified about changes over time of a resource [RFC7641]. Resources observed by clients may be larger than can be comfortably processed or transferred in one CoAP message. The following rules apply to the combination of block-wise transfers with notifications.
監視オプションは、リソースの経時変化についてクライアントに通知する方法を提供します[RFC7641]。クライアントが監視するリソースは、1つのCoAPメッセージで快適に処理または転送できるリソースよりも大きい場合があります。次のルールは、ブロック単位の転送と通知の組み合わせに適用されます。
Observation relationships always apply to an entire resource; the Block2 Option does not provide a way to observe a single block of a resource.
監視関係は常にリソース全体に適用されます。 Block2オプションは、リソースの単一のブロックを監視する方法を提供しません。
As with basic GET transfers, the client can indicate its desired block size in a Block2 Option in the GET request establishing or renewing the observation relationship. If the server supports block-wise transfers, it SHOULD take note of the block size and apply it as a maximum size to all notifications/responses resulting from the GET request (until the client is removed from the list of observers or the entry in that list is updated by the server receiving a new GET request for the resource from the client).
基本的なGET転送と同様に、クライアントは、監視関係を確立または更新するGETリクエストのBlock2オプションで、希望するブロックサイズを示すことができます。サーバーがブロック単位の転送をサポートしている場合、サーバーはブロックサイズに注意し、GETリクエストからのすべての通知/応答に最大サイズとして適用する必要があります（オブザーバーのリストまたはそのエントリからクライアントが削除されるまで）リストは、サーバーがクライアントからリソースの新しいGETリクエストを受信することで更新されます。
When sending a 2.05 (Content) notification, the server only sends the first block of the representation. The client retrieves the rest of the representation as if it had caused this first response by a GET request, i.e., by using additional GET requests with Block2 Options containing NUM values greater than zero. (This results in the transfer of the entire representation, even if only some of the blocks have changed with respect to a previous notification.)
2.05（コンテンツ）通知を送信する場合、サーバーは表現の最初のブロックのみを送信します。クライアントは、GETリクエストによってこの最初の応答を引き起こしたかのように、残りの表現を取得します。つまり、ゼロより大きいNUM値を含むBlock2オプションで追加のGETリクエストを使用します。 （これにより、以前の通知に対して一部のブロックのみが変更された場合でも、表現全体が転送されます。）
As with other dynamically changing resources, to ensure that the blocks being reassembled are from the same version of the representation, the server SHOULD include an ETag Option in each response, and the reassembling client MUST compare the ETag Options (Section 2.4). Even more so than for the general case of Block2, clients that want to retrieve all blocks of a resource they have been notified about with a first block SHOULD strive to do so without undue delay.
他の動的に変化するリソースと同様に、再構築されるブロックが同じバージョンの表現からのものであることを保証するために、サーバーは各応答にETagオプションを含める必要があり、再構築クライアントはETagオプションを比較する必要があります（セクション2.4）。ブロック2の一般的なケースよりもさらに、最初のブロックで通知されたリソースのすべてのブロックを取得したいクライアントは、過度の遅延なしに取得するよう努めるべきです（SHOULD）。
See Section 3.4 for examples.
例については、セクション3.4を参照してください。
In PUT and particularly in POST exchanges, both the request body and the response body may be large enough to require the use of block-wise transfers. First, the Block1 transfer of the request body proceeds as usual. In the exchange of the last slice of this block-wise transfer, the response carries the first slice of the Block2 transfer (NUM is zero). To continue this Block2 transfer, the client continues to send requests similar to the requests in the Block1 phase, but leaves out the Block1 Options and includes a Block2 request option with non-zero NUM.
PUT、特にPOST交換では、リクエストボディとレスポンスボディの両方が、ブロック単位の転送の使用を必要とするほど大きくなる場合があります。まず、リクエストボディのBlock1転送が通常どおり続行されます。このブロック単位の転送の最後のスライスの交換では、応答はBlock2転送の最初のスライスを伝送します（NUMはゼロです）。このBlock2転送を続行するために、クライアントはBlock1フェーズのリクエストと同様のリクエストを送信し続けますが、Block1オプションを省略し、ゼロ以外のNUMを持つBlock2リクエストオプションを含めます。
Block2 transfers that retrieve the response body for a request that used Block1 MUST be performed in sequential order.
Block1を使用した要求の応答本文を取得するBlock2転送は、順番に実行する必要があります。
A client can use the Block2 Option in a multicast GET request with NUM = 0 to aid in limiting the size of the response.
クライアントは、NUM = 0のマルチキャストGETリクエストでBlock2オプションを使用して、応答のサイズを制限することができます。
Similarly, a response to a multicast GET request can use a Block2 Option with NUM = 0 if the representation is large, or to further limit the size of the response.
同様に、マルチキャストGET要求への応答は、表現が大きい場合、または応答のサイズをさらに制限する場合、NUM = 0のBlock2オプションを使用できます。
In both cases, the client retrieves any further blocks using unicast exchanges; in the unicast requests, the client SHOULD heed any block size preferences indicated by the server in the response to the multicast request.
どちらの場合も、クライアントはユニキャスト交換を使用してそれ以上のブロックを取得します。ユニキャスト要求では、クライアントは、マルチキャスト要求への応答でサーバーによって示されるブロックサイズの設定に注意する必要があります（SHOULD）。
Other uses of the Block options in conjunction with multicast messages are for further study.
マルチキャストメッセージと併せてブロックオプションを使用する他の方法については、さらに検討する必要があります。
Beyond the response codes defined in [RFC7252], this specification defines two response codes and extends the meaning of one.
[RFC7252]で定義されている応答コードを超えて、この仕様では2つの応答コードを定義し、1つの意味を拡張しています。
This new success status code indicates that the transfer of this block of the request body was successful and that the server encourages sending further blocks, but that a final outcome of the whole block-wise request cannot yet be determined. No payload is returned with this response code.
この新しい成功ステータスコードは、リクエストボディのこのブロックの転送が成功し、サーバーがさらにブロックを送信することを推奨しているが、ブロック単位のリクエスト全体の最終結果がまだ決定されていないことを示しています。この応答コードではペイロードは返されません。
This new client error status code indicates that the server has not received the blocks of the request body that it needs to proceed. The client has not sent all blocks, not sent them in the order required by the server, or has sent them long enough ago that the server has already discarded them.
この新しいクライアントエラーステータスコードは、サーバーが続行する必要のあるリクエストボディのブロックを受信していないことを示します。クライアントがすべてのブロックを送信していない、サーバーが必要とする順序で送信していない、またはサーバーがすでにブロックを破棄するのに十分前にそれらを送信している
(Note that one reason for not having the necessary blocks at hand may be a Content-Format mismatch, see Section 2.3. Implementation note: A server can reject a Block1 transfer with this code when NUM != 0 and a different Content-Format is indicated than expected from the current state of the resource. If it implements the transfer in a stateless fashion, it can match up the Content-Format of the block against that of the existing resource. If it implements the transfer in an atomic fashion, it can match up the block against the partially reassembled piece of representation that is going to replace the state of the resource.)
（必要なブロックが手元にない理由の1つは、Content-Formatの不一致である可能性があることに注意してください。セクション2.3を参照してください。実装上の注意：NUM！= 0で、異なるContent-Formatがリソースの現在の状態から予想以上に示されます。ステートレスな方法で転送を実装する場合、ブロックのContent-Formatを既存のリソースのコンテンツフォーマットと照合できます。転送をアトミックな方法で実装する場合、ブロックを、リソースの状態を置き換える部分的に再構成された表現と照合することができます。）
In Section 5.9.2.9 of [RFC7252], the response code 4.13 (Request Entity Too Large) is defined to be like HTTP 413 "Request Entity Too Large". [RFC7252] also recommends that this response SHOULD include a Size1 Option (Section 4) to indicate the maximum size of request entity the server is able and willing to handle, unless the server is not in a position to make this information available.
[RFC7252]のセクション5.9.2.9で、レスポンスコード4.13（リクエストエンティティが大きすぎる）は、HTTP 413「リクエストエンティティが大きすぎます」のように定義されています。 [RFC7252]は、サーバーがこの情報を利用できる位置にない限り、サーバーが処理でき、処理できる要求エンティティの最大サイズを示すために、この応答にサイズ1オプション（セクション4）を含める必要があることも推奨しています。
The present specification allows the server to return this response code at any time during a Block1 transfer to indicate that it does not currently have the resources to store blocks for a transfer that it would intend to implement in an atomic fashion. It also allows the server to return a 4.13 response to a request that does not employ Block1 as a hint for the client to try sending Block1. Finally, a 4.13 response to a request with a Block1 Option (control usage, see Section 2.3) where the response carries a smaller SZX in its Block1 Option is a hint to try that smaller SZX.
現在の仕様では、サーバーがBlock1転送中にいつでもこの応答コードを返し、アトミックな方法で実装しようとしている転送用のブロックを格納するリソースが現在ないことを示しています。また、クライアントがBlock1を送信しようとするヒントとしてBlock1を使用しないリクエストに対して、サーバーが4.13応答を返すこともできます。最後に、Block1オプション（制御の使用法、セクション2.3を参照）を含む要求に対する4.13応答は、応答がそのBlock1オプションで小さいSZXを運ぶ場合、その小さいSZXを試すヒントになります。
This specification attempts to leave a variety of implementation strategies open for caches, in particular those in caching proxies. For example, a cache is free to cache blocks individually, but also could wait to obtain the complete representation before it serves parts of it. Partial caching may be more efficient in a cross-proxy (equivalent to a streaming HTTP proxy). A cached block (partial cached response) can be used in place of a complete response to satisfy a block-wise request that is presented to a cache. Note that different blocks can have different Max-Age values, as they are transferred at different times. A response with a block updates the freshness of the complete representation. Individual blocks can be validated, and validating a single block validates the complete representation. A response with a Block1 Option in control usage with the M bit set invalidates cached responses for the target URI.
この仕様では、さまざまな実装戦略、特にキャッシュプロキシの実装戦略をキャッシュに残しておきます。たとえば、キャッシュはブロックを個別にキャッシュできますが、完全な表現を取得してから、その一部を提供することもできます。部分プロキシは、クロスプロキシ（ストリーミングHTTPプロキシと同等）でより効率的です。キャッシュされたブロック（部分的にキャッシュされた応答）を完全な応答の代わりに使用して、キャッシュに提示されるブロック単位の要求を満たすことができます。異なるブロックは異なる時間に転送されるため、異なるMax-Age値を持つ可能性があることに注意してください。ブロック付きの応答は、完全な表現の鮮度を更新します。個々のブロックを検証でき、単一のブロックを検証すると完全な表現が検証されます。 Mビットが設定されたコントロールの用途でBlock1オプションを使用した応答は、ターゲットURIのキャッシュされた応答を無効にします。
A cache or proxy that combines responses (e.g., to split blocks in a request or increase the block size in a response, or a cross-proxy) may need to combine 2.31 and 2.01/2.04 responses; a stateless server may be responding with 2.01 only on the first Block1 block transferred, which dominates any 2.04 responses for later blocks.
応答を組み合わせるキャッシュまたはプロキシー（例えば、要求内のブロックを分割したり、応答内のブロックサイズを増やしたりするため、またはクロスプロキシー）は、2.31と2.01 / 2.04応答を組み合わせる必要がある場合があります。ステートレスサーバーは、転送された最初のBlock1ブロックでのみ2.01で応答している可能性があります。
If-None-Match only works correctly on Block1 requests with (NUM=0) and MUST NOT be used on Block1 requests with NUM != 0.
If-None-Matchは（NUM = 0）のBlock1リクエストでのみ正しく機能し、NUM！= 0のBlock1リクエストでは使用しないでください。
This section gives a number of short examples with message flows for a block-wise GET, and for a PUT or POST. These examples demonstrate the basic operation, the operation in the presence of retransmissions, and examples for the operation of the block size negotiation.
このセクションでは、ブロック単位のGET、およびPUTまたはPOSTのメッセージフローの短い例をいくつか示します。これらの例は、基本的な操作、再送信がある場合の操作、およびブロックサイズネゴシエーションの操作の例を示しています。
In all these examples, a Block option is shown in a decomposed way indicating the kind of Block option (1 or 2) followed by a colon, and then the block number (NUM), more bit (M), and block size exponent (2**(SZX+4)) separated by slashes. For example, a Block2 Option value of 33 would be shown as 2:2/0/32) and a Block1 Option value of 59 would be shown as 1:3/1/128.
これらすべての例で、ブロックオプションは、ブロックオプションの種類（1または2）の後にコロン、ブロック番号（NUM）、ビット数（M）、ブロックサイズの指数（ 2 **（SZX + 4））はスラッシュで区切られます。たとえば、33のBlock2 Option値は2：2/0/32として表示され、59のBlock1 Option値は1：3/1/128として表示されます。
As in [RFC7252], "MID" is used as an abbreviation for "Message ID".
[RFC7252]と同様に、「MID」は「メッセージID」の省略形として使用されます。
The first example (Figure 2) shows a GET request that is split into three blocks. The server proposes a block size of 128, and the client agrees. The first two ACKs contain a payload of 128 bytes each, and the third ACK contains a payload between 1 and 128 bytes.
最初の例（図2）は、3つのブロックに分割されたGET要求を示しています。サーバーは128のブロックサイズを提案し、クライアントは同意します。最初の2つのACKにはそれぞれ128バイトのペイロードが含まれ、3番目のACKには1〜128バイトのペイロードが含まれます。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:1/0/128 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 |
| |
| CON [MID=1236], GET, /status, 2:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.05 Content, 2:2/0/128 |
Figure 2: Simple Block-Wise GET
図2：単純なブロック単位のGET
In the second example (Figure 3), the client anticipates the block-wise transfer (e.g., because of a size indication in the link-format description [RFC6690]) and sends a block size proposal. All ACK messages except for the last carry 64 bytes of payload; the last one carries between 1 and 64 bytes.
2番目の例（図3）では、クライアントはブロック単位の転送を予期し（たとえば、リンク形式の説明[RFC6690]のサイズ表示のため）、ブロックサイズの提案を送信します。最後を除くすべてのACKメッセージは64バイトのペイロードを伝送します。最後の1つは1〜64バイトを伝送します。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/64 |
| |
| CON [MID=1235], GET, /status, 2:1/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:4/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:4/1/64 |
| |
| CON [MID=1239], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1239], 2.05 Content, 2:5/0/64 |
Figure 3: Block-Wise GET with Early Negotiation
図3：アーリーネゴシエーションを使用したブロック単位のGET
In the third example (Figure 4), the client is surprised by the need for a block-wise transfer, and unhappy with the size chosen unilaterally by the server. As it did not send a size proposal initially, the negotiation only influences the size from the second message exchange onward. Since the client already obtained both the first and second 64-byte block in the first 128-byte exchange, it goes on requesting the third 64-byte block ("2/0/64"). None of this is (or needs to be) understood by the server, which simply responds to the requests as it best can.
3番目の例（図4）では、クライアントはブロック単位の転送の必要性に驚いており、サーバーが一方的に選択したサイズに不満を持っています。最初はサイズ提案を送信しなかったため、ネゴシエーションは2番目のメッセージ交換以降のサイズにのみ影響します。クライアントは最初の128バイト交換で最初と2番目の64バイトブロックの両方をすでに取得しているため、3番目の64バイトブロック（ "2/0/64"）を要求し続けます。これはサーバーによって理解されていません（または理解する必要はありません）。サーバーは、可能な限り要求に応答します。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
| |
| CON [MID=1236], GET, /status, 2:3/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.05 Content, 2:3/1/64 |
| |
| CON [MID=1237], GET, /status, 2:4/0/64 ------> |
| |
| <------ ACK [MID=1237], 2.05 Content, 2:4/1/64 |
| |
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 4: Block-Wise GET with Late Negotiation
図4：レイトネゴシエーションを使用したブロック単位のGET
In all these (and the following) cases, retransmissions are handled by the CoAP message exchange layer, so they don't influence the block operations (Figures 5 and 6).
これらすべて（および以下）のケースでは、再送信はCoAPメッセージ交換層によって処理されるため、ブロック操作には影響しません（図5および6）。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GE///////////////////////// |
| |
| (timeout) |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 5: Block-Wise GET with Late Negotiation and Lost CON
図5：レイトネゴシエーションと失われたCONを使用したブロック単位のGET
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| //////////////////////////////////tent, 2:2/1/64 |
| |
| (timeout) |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
Figure 6: Block-Wise GET with Late Negotiation and Lost ACK
図6：レイトネゴシエーションとロストACKを使用したブロック単位のGET
The following examples demonstrate a PUT exchange; a POST exchange looks the same, with different requirements on atomicity/idempotence. Note that, similar to GET, the responses to the requests that have a more bit in the request Block1 Option are provisional and carry the response code 2.31 (Continue); only the final response tells the client that the PUT succeeded.
次の例は、PUT交換を示しています。 POST交換は同じように見えますが、原子性/べき等に関する要件は異なります。 GETと同様に、リクエストのBlock1オプションにビットが多いリクエストへのレスポンスは暫定的なものであり、レスポンスコード2.31（Continue）を含むことに注意してください。最後の応答だけがクライアントにPUTが成功したことを伝えます。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
Figure 7: Simple Atomic Block-Wise PUT
図7：シンプルなアトミックブロック単位のPUT
A stateless server that simply builds/updates the resource in place (statelessly) may indicate this by not setting the more bit in the response (Figure 8); in this case, the response codes are valid separately for each block being updated. This is of course only an acceptable behavior of the server if the potential inconsistency present during the run of the message exchange sequence does not lead to problems, e.g., because the resource being created or changed is not yet or not currently in use.
（ステートレスで）リソースを単に構築/更新するステートレスサーバーは、応答でより多くのビットを設定しないことによってこれを示す場合があります（図8）。この場合、応答コードは更新されるブロックごとに個別に有効です。もちろん、これは、メッセージ交換シーケンスの実行中に存在する潜在的な不整合が問題を引き起こさない場合（たとえば、作成または変更されるリソースがまだ使用されていないか現在使用されていないため）の場合のサーバーの許容可能な動作にすぎません。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.04 Changed, 1:0/0/128 |
| |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.04 Changed, 1:1/0/128 |
| |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
Figure 8: Simple Stateless Block-Wise PUT
図8：単純なステートレスブロックごとのPUT
Finally, a server receiving a block-wise PUT or POST may want to indicate a smaller block size preference (Figure 9). In this case, the client SHOULD continue with a smaller block size; if it does, it MUST adjust the block number to properly count in that smaller size.
最後に、ブロック単位のPUTまたはPOSTを受信するサーバーは、より小さなブロックサイズの設定を示す必要がある場合があります（図9）。この場合、クライアントはより小さいブロックサイズで続行する必要があります（SHOULD）。もしそうなら、それはその小さいサイズで適切に数えるためにブロック番号を調整しなければなりません。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/32 |
| |
| CON [MID=1235], PUT, /options, 1:4/1/32 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:4/1/32 |
| |
| CON [MID=1236], PUT, /options, 1:5/1/32 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:5/1/32 |
| |
| CON [MID=1237], PUT, /options, 1:6/0/32 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:6/0/32 |
Figure 9: Simple Atomic Block-Wise PUT with Negotiation
図9：ネゴシエーションを使用した単純なAtomicブロック単位のPUT
Block options may be used in both directions of a single exchange. The following example demonstrates a block-wise POST request, resulting in a separate block-wise response.
ブロックオプションは、単一の交換の両方向で使用できます。次の例は、ブロック単位のPOSTリクエストを示し、個別のブロック単位の応答になります。
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 2:0/1/128, 1:2/0/128 |
| |
| CON [MID=1237], POST, /soap, 2:1/0/128 ------> |
| (no payload for requests with Block2 with NUM != 0) |
| (could also do late negotiation by requesting, |
| e.g., 2:2/0/64) |
| |
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/128 |
| |
| CON [MID=1238], POST, /soap, 2:2/0/128 ------> |
| |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/128 |
| |
| CON [MID=1239], POST, /soap, 2:3/0/128 ------> |
| |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/128 |
Figure 10: Atomic Block-Wise POST with Block-Wise Response
図10：ブロック単位の応答を伴うアトミックブロック単位のPOST
This model does provide for early negotiation input to the Block2 block-wise transfer, as shown below.
このモデルは、以下に示すように、Block2ブロック単位の転送への早期ネゴシエーション入力を提供します。
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128, 2:0/1/64 |
| |
| CON [MID=1237], POST, /soap, 2:1/0/64 ------> |
| (no payload for requests with Block2 with NUM != 0) |
| |
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/64 |
| |
| CON [MID=1238], POST, /soap, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/64 |
| |
| CON [MID=1239], POST, /soap, 2:3/0/64 ------> |
| |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/64 |
Figure 11: Atomic Block-Wise POST with Block-Wise Response, Early Negotiation
図11：アトミックなブロック単位のPOST、ブロック単位の応答、早期交渉
In the following example, the server first sends a direct response (Observe sequence number 62350) to the initial GET request (the resulting block-wise transfer is as in Figure 4 and has therefore been left out). The second transfer is started by a 2.05 notification that contains just the first block (Observe sequence number 62354); the client then goes on to obtain the rest of the blocks.
次の例では、サーバーは最初に最初のGET要求に直接応答（Observeシーケンス番号62350）を送信します（結果のブロック単位の転送は図4のとおりなので、省略されています）。 2番目の転送は、最初のブロック（シーケンス番号62354を監視）のみを含む2.05通知によって開始されます。その後、クライアントは残りのブロックを取得します。
CLIENT SERVER
| |
+----->| Header: GET 0x41011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: (empty)
| |
|<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62350
| | ETag: 6f00f38e
| | Payload: [128 bytes]
| |
| | (Usual GET transfer left out)
...
| | (Notification of first block)
| |
|<-----+ Header: 2.05 0x4145af9c
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62354
| | ETag: 6f00f392
| | Payload: [128 bytes]
| |
+- - ->| Header: 0x6000af9c
| |
| | (Retrieval of remaining blocks)
| |
+----->| Header: GET 0x41011637
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 1/0/128
| |
|<-----+ Header: 2.05 0x61451637
| 2.05 | Token: 0xfc
| | Block2: 1/1/128
| | ETag: 6f00f392
| | Payload: [128 bytes]
| |
+----->| Header: GET 0x41011638
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 2/0/128
| |
|<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc
| | Block2: 2/0/128
| | ETag: 6f00f392
| | Payload: [53 bytes]
Figure 12: Observe Sequence with Block-Wise Response
図12：ブロック単位の応答でシーケンスを観察する
(Note that the choice of token 0xfc in this example is arbitrary; tokens are just shown in this example to illustrate that the requests for additional blocks cannot make use of the token of the Observation relationship. As a general comment on tokens, there is no other mention of tokens in this document, as block-wise transfers handle tokens like any other CoAP exchange. As usual, the client is free to choose tokens for each exchange as it likes.)
（この例でのトークン0xfcの選択は任意であることに注意してください。追加のブロックの要求が観測関係のトークンを利用できないことを示すために、トークンはこの例に示されているだけです。トークンに関する一般的なコメントとして、このドキュメントでは、ブロック単位の転送が他のCoAP交換と同様にトークンを処理するため、トークンに関する他の記述があります。通常どおり、クライアントは各交換のトークンを自由に選択できます。）
In the following example, the client also uses early negotiation to limit the block size to 64 bytes.
次の例では、クライアントも早期ネゴシエーションを使用してブロックサイズを64バイトに制限しています。
CLIENT SERVER
| |
+----->| Header: GET 0x41011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: (empty)
| | Block2: 0/0/64
| |
|<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/64
| | Observe: 62350
| | ETag: 6f00f38e
| | Max-Age: 60
| | Payload: [64 bytes]
| |
| | (Usual GET transfer left out)
...
| | (Notification of first block)
| |
|<-----+ Header: 2.05 0x4145af9c
| 2.05 | Token: 0xfb
| | Block2: 0/1/64
| | Observe: 62354
| | ETag: 6f00f392
| | Payload: [64 bytes]
| |
+- - ->| Header: 0x6000af9c
| |
| | (Retrieval of remaining blocks)
| |
+----->| Header: GET 0x41011637
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 1/0/64
| |
|<-----+ Header: 2.05 0x61451637
| 2.05 | Token: 0xfc
| | Block2: 1/1/64
| | ETag: 6f00f392
| | Payload: [64 bytes]
....
| |
+----->| Header: GET 0x41011638
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 4/0/64
| |
|<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc
| | Block2: 4/0/64
| | ETag: 6f00f392
| | Payload: [53 bytes]
Figure 13: Observe Sequence with Early Negotiation
図13：早期交渉でシーケンスを観察する
In many cases when transferring a large resource representation block by block, it is advantageous to know the total size early in the process. Some indication may be available from the maximum size estimate attribute "sz" provided in a resource description [RFC6690]. However, the size may vary dynamically, so a more up-to-date indication may be useful.
大きなリソース表現をブロックごとに転送する場合、多くの場合、プロセスの早い段階で合計サイズを知っておくと便利です。リソースの説明[RFC6690]で提供される最大サイズ推定属性「sz」から、いくつかの指標が利用できる場合があります。ただし、サイズは動的に変化する可能性があるため、より最新の指標が役立つ場合があります。
This specification defines two CoAP options, Size1 for indicating the size of the representation transferred in requests, and Size2 for indicating the size of the representation transferred in responses. (Size1 has already been defined in Section 5.10.9 of [RFC7252] to provide "size information about the resource representation in a request"; however, that section only details the narrow case of indicating in 4.13 responses the maximum size of request payload that the server is able and willing to handle. The present specification provides details about its use as a request option as well.) The Size2 Option may be used for two purposes:
この仕様では、2つのCoAPオプションが定義されています。Size1は、要求で転送される表現のサイズを示し、Size2は、応答で転送される表現のサイズを示します。 （Size1は[RFC7252]のセクション5.10.9ですでに定義されており、「リクエスト内のリソース表現に関するサイズ情報」を提供しています。ただし、そのセクションでは、4.13レスポンスでリクエストペイロードの最大サイズを示すサーバーは処理可能であり、喜んで処理します。この仕様では、リクエストオプションとしてのサーバーの使用についても詳細を説明しています。Size2オプションは、次の2つの目的で使用できます。
o In a request, to ask the server to provide a size estimate along with the usual response ("size request"). For this usage, the value MUST be set to 0.
o リクエストで、通常のレスポンスと一緒にサイズの見積もりを提供するようサーバーに要求する（「サイズリクエスト」）。この使用法では、値を0に設定する必要があります。
o In a response carrying a Block2 Option, to indicate the current estimate the server has of the total size of the resource representation, measured in bytes ("size indication").
o Block2オプションを含む応答で、バイト単位で測定されたリソース表現の合計サイズに関するサーバーの現在の見積もりを示す（「サイズ表示」）。
Similarly, the Size1 Option may be used for two purposes:
同様に、Size1オプションは次の2つの目的で使用できます。
o In a request carrying a Block1 Option, to indicate the current estimate the client has of the total size of the resource representation, measured in bytes ("size indication").
o Block1オプションを含むリクエストで、バイト単位で測定されたリソース表現の合計サイズに対するクライアントの現在の見積もりを示す（「サイズ表示」）。
o In a 4.13 response, to indicate the maximum size that would have been acceptable [RFC7252], measured in bytes.
o 4.13応答では、許容される最大サイズ[RFC7252]をバイト単位で示すため。
Apart from conveying/asking for size information, the Size options have no other effect on the processing of the request or response. If the client wants to minimize the size of the payload in the resulting response, it should add a Block2 Option to the request with a small block size (e.g., setting SZX=0).
サイズ情報の伝達/要求以外に、サイズオプションは、要求または応答の処理に他の影響を与えません。クライアントが結果の応答のペイロードのサイズを最小化したい場合は、ブロックサイズの小さいリクエストにBlock2オプションを追加する必要があります（例：SZX = 0の設定）。
The Size options are "elective", i.e., a client MUST be prepared for the server to ignore the size estimate request. Either Size option MUST NOT occur more than once in a single message.
サイズオプションは「選択的」です。つまり、クライアントがサーバーがサイズ見積もり要求を無視できるように準備する必要があります。どちらのサイズオプションも、単一のメッセージで複数回発生してはなりません。
+-----+---+---+---+---+-------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+-----+---+---+---+---+-------+--------+--------+---------+
| 60 | | | x | | Size1 | uint | 0-4 | (none) |
| | | | | | | | | |
| 28 | | | x | | Size2 | uint | 0-4 | (none) |
+-----+---+---+---+---+-------+--------+--------+---------+
Table 2: Size Option Numbers
表2：サイズオプション番号
Implementation Notes:
実装上の注意：
o As a quality of implementation consideration, block-wise transfers for which the total size considerably exceeds the size of one block are expected to include size indications, whenever those can be provided without undue effort (preferably with the first block exchanged). If the size estimate does not change, the indication does not need to be repeated for every block.
o 実装の品質に関する考慮事項として、合計サイズが1ブロックのサイズを大幅に超えるブロック単位の転送には、サイズの指示が含まれていることが予想されます。サイズの見積もりが変わらない場合は、すべてのブロックについて表示を繰り返す必要はありません。
o The end of a block-wise transfer is governed by the M bits in the Block options, _not_ by exhausting the size estimates exchanged.
o ブロック単位の転送の終了は、交換されたサイズの見積もりを使い果たすことによって、ブロックオプションのMビットによって制御されます。
o As usual for an option of type uint, the value 0 is best expressed as an empty option (0 bytes). There is no default value for either Size option.
o タイプuintのオプションの場合と同様に、値0は空のオプション（0バイト）として最もよく表現されます。どちらのサイズオプションにもデフォルト値はありません。
o The Size options are neither critical nor unsafe, and are marked as No-Cache-Key.
o サイズオプションは重要でも安全でもないため、キャッシュなしキーとしてマークされています。
In this subsection, we give some brief examples of the influence that the Block options might have on intermediaries that map between CoAP and HTTP.
このサブセクションでは、ブロックオプションがCoAPとHTTPをマッピングする仲介者に与える影響のいくつかの簡単な例を示します。
For mapping CoAP requests to HTTP, the intermediary may want to map the sequence of block-wise transfers into a single HTTP transfer. For example, for a GET request, the intermediary could perform the HTTP request once the first block has been requested and could then fulfill all further block requests out of its cache. A constrained implementation may not be able to cache the entire object and may use a combination of TCP flow control and (in particular if timeouts occur) HTTP range requests to obtain the information necessary for the next block transfer at the right time.
CoAP要求をHTTPにマッピングするために、仲介者は、ブロック単位の転送のシーケンスを単一のHTTP転送にマッピングする必要がある場合があります。たとえば、GETリクエストの場合、最初のブロックがリクエストされると、仲介者はHTTPリクエストを実行し、その後、キャッシュからすべてのブロックリクエストを実行できます。制約のある実装では、オブジェクト全体をキャッシュできず、TCPフロー制御と（特にタイムアウトが発生した場合）HTTP範囲要求の組み合わせを使用して、適切なタイミングで次のブロック転送に必要な情報を取得できます。
For PUT or POST requests, historically there was more variation in how HTTP servers might implement ranges; recently, [RFC7233] has defined that Range header fields received with a request method other than GET are not to be interpreted. So, in general, the CoAP-to-HTTP intermediary will have to try sending the payload of all the blocks of a block-wise transfer for these other methods within one HTTP request. If enough buffering is available, this request can be started when the last CoAP block is received. A constrained implementation may want to relieve its buffering by already starting to send the HTTP request at the time the first CoAP block is received; any HTTP 408 status code that indicates that the HTTP server became impatient with the resulting transfer can then be mapped into a CoAP 4.08 response code (similarly, 413 maps to 4.13).
PUTまたはPOSTリクエストの場合、これまでは、HTTPサーバーが範囲を実装する方法にさらに多くのバリエーションがありました。最近、[RFC7233]は、GET以外のリクエストメソッドで受信されたRangeヘッダーフィールドは解釈されないことを定義しています。したがって、一般に、CoAPからHTTPへの仲介者は、1つのHTTP要求内でこれらの他のメソッドのブロック単位の転送のすべてのブロックのペイロードを送信する必要があります。十分なバッファリングが利用可能な場合、この要求は、最後のCoAPブロックが受信されたときに開始できます。制約のある実装では、最初のCoAPブロックを受信した時点でHTTP要求の送信をすでに開始しているため、バッファリングを緩和したい場合があります。 HTTPサーバーが結果の転送に焦り始めたことを示すHTTP 408ステータスコードは、CoAP 4.08応答コードにマッピングできます（同様に、413は4.13にマッピングされます）。
For mapping HTTP to CoAP, the intermediary may want to map a single HTTP transfer into a sequence of block-wise transfers. If the HTTP client is too slow delivering a request body on a PUT or POST, the CoAP server might time out and return a 4.08 response code, which in turn maps well to an HTTP 408 status code (again, 4.13 maps to 413). HTTP range requests received on the HTTP side may be served out of a cache and/or mapped to GET requests that request a sequence of blocks that cover the range.
HTTPをCoAPにマッピングするために、仲介者は、単一のHTTP転送を一連のブロック単位の転送にマッピングする必要がある場合があります。 HTTPクライアントがPUTまたはPOSTでのリクエスト本文の配信が遅すぎる場合、CoAPサーバーがタイムアウトして4.08応答コードを返し、HTTP 408ステータスコード（4.13は413にマッピングされる）に適切にマッピングされます。 HTTP側で受信されたHTTP範囲要求は、キャッシュから提供されるか、範囲をカバーする一連のブロックを要求するGET要求にマップされます。
(Note that, while the semantics of CoAP 4.08 and HTTP 408 differ, this difference is largely due to the different way the two protocols are mapped to transport. HTTP has an underlying TCP connection, which supplies connection state, so an HTTP 408 status code can immediately be used to indicate that a timeout occurred during transmitting a request through that active TCP connection. The CoAP 4.08 response code indicates one or more missing blocks, which may be due to timeouts or resource constraints; as there is no connection state, there is no way to deliver such a response immediately; instead, it is delivered on the next block transfer. Still, HTTP 408 is probably the best mapping back to HTTP, as the timeout is the most likely cause for a CoAP 4.08. Note that there is no way to distinguish a timeout from a missing block for a server without creating additional state, the need for which we want to avoid.)
（CoAP 4.08とHTTP 408のセマンティクスは異なりますが、この違いは主に、2つのプロトコルがトランスポートにマップされる方法が異なるためです。HTTPには、接続状態を提供する基本的なTCP接続があるため、HTTP 408ステータスコードそのアクティブなTCP接続を介して要求を送信中にタイムアウトが発生したことを示すためにすぐに使用できます。CoAP4.08応答コードは、タイムアウトまたはリソースの制約が原因である可能性がある1つ以上の欠落ブロックを示します。接続状態がないため、は、そのような応答をすぐに配信する方法ではありません。代わりに、次のブロック転送で配信されます。それでも、タイムアウトがCoAP 4.08の原因である可能性が最も高いため、HTTP 408がおそらくHTTPへの最適なマッピングです。追加の状態を作成せずに、タイムアウトをサーバーの欠落ブロックと区別する方法はありません。この必要性は避けたいものです。）
This document adds the following option numbers to the "CoAP Option Numbers" registry defined by [RFC7252]:
このドキュメントでは、[RFC7252]で定義されている「CoAP Option Numbers」レジストリに次のオプション番号を追加しています。
+--------+--------+-----------+
| Number | Name | Reference |
+--------+--------+-----------+
| 23 | Block2 | RFC 7959 |
| | | |
| 27 | Block1 | RFC 7959 |
| | | |
| 28 | Size2 | RFC 7959 |
+--------+--------+-----------+
Table 3: CoAP Option Numbers
表3：CoAPオプション番号
This document adds the following response codes to the "CoAP Response Codes" registry defined by [RFC7252]:
このドキュメントでは、[RFC7252]で定義されている「CoAP Response Codes」レジストリに次の応答コードを追加します。
+------+---------------------------+-----------+
| Code | Description | Reference |
+------+---------------------------+-----------+
| 2.31 | Continue | RFC 7959 |
| | | |
| 4.08 | Request Entity Incomplete | RFC 7959 |
+------+---------------------------+-----------+
Table 4: CoAP Response Codes
表4：CoAP応答コード
Providing access to blocks within a resource may lead to surprising vulnerabilities. Where requests are not implemented atomically, an attacker may be able to exploit a race condition or confuse a server by inducing it to use a partially updated resource representation. Partial transfers may also make certain problematic data invisible to Intrusion Detection Systems (IDSs); it is RECOMMENDED that an IDS that analyzes resource representations transferred by CoAP implement the Block options to gain access to entire resource representations. Still, approaches such as transferring even-numbered blocks on one path and odd-numbered blocks on another path, or even transferring blocks multiple times with different content and obtaining a different interpretation of temporal order at the IDS than at the server, may prevent an IDS from seeing the whole picture. These kinds of attacks are well understood from IP fragmentation and TCP segmentation; CoAP does not add fundamentally new considerations.
リソース内のブロックへのアクセスを提供すると、驚くべき脆弱性につながる可能性があります。リクエストがアトミックに実装されていない場合、攻撃者は競合状態を悪用したり、部分的に更新されたリソース表現を使用するようにサーバーを誘導したりして、サーバーを混乱させる可能性があります。部分的な転送によって、特定の問題のあるデータが侵入検知システム（IDS）から見えなくなることもあります。 CoAPによって転送されたリソース表現を分析するIDSがブロックオプションを実装して、リソース表現全体にアクセスできるようにすることをお勧めします。それでも、1つのパスで偶数番号のブロックと別のパスで奇数番号のブロックを転送したり、異なるコンテンツで複数回ブロックを転送したり、IDSでサーバーとは異なる時間順序の解釈を取得したりするなどのアプローチでは、 IDSは全体像を見てから。これらの種類の攻撃は、IPフラグメンテーションとTCPセグメンテーションからよく理解されています。 CoAPは基本的に新しい考慮事項を追加しません。
Where access to a resource is only granted to clients making use of specific security associations, all blocks of that resource MUST be subject to the same security checks; it MUST NOT be possible for unprotected exchanges to influence blocks of an otherwise protected resource. As a related consideration, where object security is employed, PUT/POST should be implemented in the atomic fashion, unless the object security operation is performed on each access and the creation of unusable resources can be tolerated. Future end-to-end security mechanisms that may be added to CoAP itself may have related security considerations, this includes considerations about caching of blocks in clients and in proxies (see Sections 2.10 and 5 for different strategies in performing this caching); these security considerations will need to be described in the specifications of those mechanisms.
リソースへのアクセスが特定のセキュリティアソシエーションを利用するクライアントにのみ許可される場合、そのリソースのすべてのブロックは同じセキュリティチェックの対象でなければなりません。保護されていない交換が、他の方法で保護されているリソースのブロックに影響を与えることは可能ではありません。関連する考慮事項として、オブジェクトセキュリティが採用されている場合、PUT / POSTはアトミックな方法で実装する必要があります。ただし、オブジェクトセキュリティ操作が各アクセスで実行され、使用できないリソースの作成が許容できる場合を除きます。 CoAP自体に追加される可能性がある将来のエンドツーエンドのセキュリティメカニズムには、関連するセキュリティの考慮事項が含まれる可能性があります。これには、クライアントおよびプロキシでのブロックのキャッシングに関する考慮事項が含まれます（このキャッシングを実行するさまざまな戦略については、セクション2.10および5を参照）。これらのセキュリティに関する考慮事項は、これらのメカニズムの仕様で説明する必要があります。
A stateless server might be susceptible to an attack where the adversary sends a Block1 (e.g., PUT) block with a high block number: A naive implementation might exhaust its resources by creating a huge resource representation.
ステートレスサーバーは、攻撃者がブロック番号の大きいBlock1（PUTなど）ブロックを送信する攻撃を受けやすい可能性があります。単純な実装では、巨大なリソース表現を作成してリソースを使い果たす可能性があります。
Misleading size indications may be used by an attacker to induce buffer overflows in poor implementations, for which the usual considerations apply.
攻撃者は、誤解を招くサイズの指示を使用して、通常の考慮事項が適用される不適切な実装でバッファオーバーフローを引き起こす可能性があります。
Certain block-wise requests may induce the server to create state, e.g., to create a snapshot for the block-wise GET of a fast-changing resource to enable consistent access to the same version of a resource for all blocks, or to create temporary resource representations that are collected until pressed into service by a final PUT or POST with the more bit unset. All mechanisms that induce a server to create state that cannot simply be cleaned up create opportunities for denial-of-service attacks. Servers SHOULD avoid being subject to resource exhaustion based on state created by untrusted sources. But even if this is done, the mitigation may cause a denial-of-service to a legitimate request when it is drowned out by other state-creating requests. Wherever possible, servers should therefore minimize the opportunities to create state for untrusted sources, e.g., by using stateless approaches.
特定のブロック単位の要求は、サーバーに状態を作成するように誘導する場合があります。たとえば、高速で変化するリソースのブロック単位のGETのスナップショットを作成して、すべてのブロックで同じバージョンのリソースに一貫してアクセスできるようにするか、一時的に作成します。より多くのビットが設定されていない最後のPUTまたはPOSTによってサービスにプッシュされるまで収集されるリソース表現。サーバーが単純にクリーンアップできない状態を作成するように誘導するすべてのメカニズムは、サービス拒否攻撃の機会を生み出します。サーバーは、信頼できないソースによって作成された状態に基づくリソースの枯渇の影響を受けないようにする必要があります。ただし、これが実行された場合でも、緩和策により、正当な要求が他の状態作成要求によって溺死されたときに、サービス拒否が発生する可能性があります。したがって、サーバーは可能な限り、たとえばステートレスアプローチを使用するなどして、信頼できないソースの状態を作成する機会を最小限に抑える必要があります。
Performing segmentation at the application layer is almost always better in this respect than at the transport layer or lower (IP fragmentation, adaptation-layer fragmentation), for instance, because there are application-layer semantics that can be used for mitigation or because lower layers provide security associations that can prevent attacks. However, it is less common to apply timeouts and keepalive mechanisms at the application layer than at lower layers. Servers MAY want to clean up accumulated state by timing it out (cf. response code 4.08), and clients SHOULD be prepared to run block-wise transfers in an expedient way to minimize the likelihood of running into such a timeout.
アプリケーション層でのセグメンテーションの実行は、ほとんどの場合、この点でトランスポート層以下（IPフラグメンテーション、アダプテーションレイヤーフラグメンテーション）よりも優れています。たとえば、緩和に使用できるアプリケーションレイヤーのセマンティクスが存在するため、攻撃を防止できるセキュリティアソシエーションを提供します。ただし、アプリケーション層でタイムアウトとキープアライブメカニズムを適用することは、下位層よりも一般的ではありません。サーバーは蓄積された状態をタイムアウトすることでクリーンアップしたい場合があり（応答コード4.08を参照）、クライアントは、そのようなタイムアウトに陥る可能性を最小限に抑えるために、適切な方法でブロック単位の転送を実行する準備をする必要があります。
[RFC7252] discusses the susceptibility of CoAP endpoints for use in amplification attacks.
[RFC7252]は、増幅攻撃で使用するCoAPエンドポイントの脆弱性について説明しています。
A CoAP server can reduce the amount of amplification it provides to an attacker by offering large resource representations only in relatively small blocks. With this, e.g., for a 1000-byte resource, a 10-byte request might result in an 80-byte response (with a 64-byte block) instead of a 1016-byte response, considerably reducing the amplification provided.
CoAPサーバーは、比較的小さなブロックでのみ大きなリソース表現を提供することにより、攻撃者に提供する増幅の量を減らすことができます。これにより、たとえば、1000バイトのリソースの場合、10バイトのリクエストでは、1016バイトのレスポンスではなく、80バイトのレスポンス（64バイトのブロック）が発生し、提供される増幅が大幅に減少します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<http：//www.rfc-editor。 org / info / rfc7252>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <http://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「Observing Resources in the Constrained Application Protocol（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<http://www.rfc-editor.org/info/rfc7641>。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST] Fielding、R。、「Architectural Styles and the Design of Network-based Software Architectures」、Ph.D。カリフォルニア大学アーバイン校の論文、2000年、<http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf>。
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <http://www.rfc-editor.org/info/rfc4919>.
[RFC4919] Kushalnagar、N。、モンテネグロ、G。、およびC. Schumacher、「IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）：Overview、Assumptions、Problem Statement、and Goals」、RFC 4919、DOI 10.17487 / RFC4919 、2007年8月、<http://www.rfc-editor.org/info/rfc4919>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」、RFC 4944、DOI 10.17487 / RFC4944、2007年9月、<http： //www.rfc-editor.org/info/rfc4944>。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <http://www.rfc-editor.org/info/rfc6690>.
[RFC6690] Shelby、Z。、「Constrained RESTful Environments（CoRE）Link Format」、RFC 6690、DOI 10.17487 / RFC6690、2012年8月、<http://www.rfc-editor.org/info/rfc6690>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、DOI 10.17487 / RFC7228、May 2014、<http://www.rfc-editor.org / info / rfc7228>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.
[RFC7233] Fielding、R.、Ed。、Lafon、Y.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Range Requests"、RFC 7233、DOI 10.17487 / RFC7233、June 2014、<http://www.rfc-editor.org/info/rfc7233>。
Acknowledgements
謝辞
Much of the content of this document is the result of discussions with the [RFC7252] authors, and via many CoRE WG discussions.
このドキュメントの内容の多くは、[RFC7252]の作者との議論の結果であり、多くのCoRE WGの議論によるものです。
Charles Palmer provided extensive editorial comments to a previous draft version of this document, some of which have been covered in this document. Esko Dijk reviewed a more recent version, leading to a number of further editorial improvements, a solution to the 4.13 ambiguity problem, and the section about combining Block and multicast (Section 2.8). Markus Becker proposed getting rid of an ill-conceived default value for the Block2 and Block1 Options. Peter Bigot insisted on a more systematic coverage of the options and response code. Qin Wu provided a review for the IETF Operations directorate, and Goeran Selander commented on the security considerations.
Charles Palmerは、このドキュメントの以前のドラフトバージョンに広範な編集コメントを提供しており、その一部はこのドキュメントでカバーされています。 Esko Dijkがより新しいバージョンをレビューし、編集上の改善、4.13のあいまいさの問題の解決、およびブロックとマルチキャストの組み合わせに関するセクション（セクション2.8）につながりました。 Markus Beckerは、Block2およびBlock1オプションの誤った考えのデフォルト値を取り除くことを提案しました。 Peter Bigotは、オプションと応答コードのより体系的な適用範囲を主張しました。 Qin WuがIETFオペレーションディレクターにレビューを提供し、Goeran Selanderがセキュリティの考慮事項についてコメントしました。
Kepeng Li, Linyi Tian, and Barry Leiba wrote up an early version of the Size option, which is described in this document. Klaus Hartke wrote some of the text describing the interaction of Block2 with Observe. Matthias Kovatsch provided a number of significant simplifications of the protocol.
Kepeng Li、Linyi Tian、Barry Leibaは、このドキュメントで説明されている初期サイズのサイズオプションを作成しました。 Klaus Hartkeは、Block2とObserveの相互作用を説明するテキストの一部を書きました。 Matthias Kovatschは、プロトコルを大幅に簡素化しました。
The IESG reviewers provided very useful comments. Spencer Dawkins even suggested new text. He and Mirja Kuehlewind insisted on more explicit information about the layering of block-wise transfers on top of the base protocol. Ben Campbell helped untangle some MUST/ SHOULD soup. Comments by Alexey Melnikov, as well as the Gen-ART review by Jouni Korhonen, resulted in further improvements to the text.
IESGレビューアは非常に有用なコメントを提供しました。スペンサー・ドーキンスは新しいテキストさえ提案しました。彼とMirja Kuehlewindは、基本プロトコルの上にブロック単位の転送を階層化することについて、より明確な情報を要求しました。ベンキャンベルは、スープをほぐす手助けをしました。 Alexey MelnikovによるコメントとJouni KorhonenによるGen-ARTレビューにより、テキストがさらに改善されました。
Authors' Addresses
著者のアドレス
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
Carsten Bormann Universitaet Bremen TZI PO Box 330440ブレーメンD-28359ドイツ
Phone: +49-421-218-63921
Email: cabo@tzi.org
Zach Shelby (editor) ARM 150 Rose Orchard San Jose, CA 95134 United States of America
Zach Shelby（editor）ARM 150 Rose Orchard San Jose、CA 95134アメリカ合衆国
Phone: +1-408-203-9434
Email: zach.shelby@arm.com