[要約] RFC 9177は、信頼性の高い伝送をサポートするCoAPブロック単位の転送オプションに関するものです。この文書は、ネットワークの帯域幅が限られている環境でのデータ交換の効率化を目的としています。特に、IoTデバイス間の通信や、リソース制約のある環境での使用が想定されています。
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 9177 Orange
Category: Standards Track J. Shallow
ISSN: 2070-1721 March 2022
Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission
ロバスト伝送をサポートする制約付きアプリケーションプロトコル（CoAP）ブロック単位転送オプション
Abstract
概要
This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.
このドキュメントは、代替の制約付きアプリケーションプロトコル（CoAP）ブロック単位転送オプションを指定します.Q-Block1とQ-Block2。
These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission.
これらのオプションは、RFC 7959で定義されているCoAP Block1とBlock2のオプションと似ています。Q-Block1とQ-Block2のオプションは、block1とblock2のオプションを置き換えることを意図していませんが、必ず確認不可能をサポートするという目的をしています。パケット交換が少ない大量のデータの（非）メッセージ。また、Q-Block1とQ-Block2のオプションは、ブロックのどんなブロックが送信中に失われるべきであるより速い回復をサポートします。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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 https://www.rfc-editor.org/info/rfc9177.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9177で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
2. Terminology
3. Alternative CoAP Block-Wise Transfer Options
3.1. CoAP Response Code (4.08) Usage
3.2. Applicability Scope
4. The Q-Block1 and Q-Block2 Options
4.1. Properties of the Q-Block1 and Q-Block2 Options
4.2. Structure of the Q-Block1 and Q-Block2 Options
4.3. Using the Q-Block1 Option
4.4. Using the Q-Block2 Option
4.5. Using the Observe Option
4.6. Using the Size1 and Size2 Options
4.7. Using the Q-Block1 and Q-Block2 Options Together
4.8. Using the Q-Block2 Option with Multicast
5. The Use of the 4.08 (Request Entity Incomplete) Response Code
6. The Use of Tokens
7. Congestion Control for Unreliable Transports
7.1. Confirmable (CON)
7.2. Non-confirmable (NON)
8. Caching Considerations
9. HTTP Mapping Considerations
10. Examples with Non-confirmable Messages
10.1. Q-Block1 Option
10.1.1. A Simple Example
10.1.2. Handling MAX_PAYLOADS Limits
10.1.3. Handling MAX_PAYLOADS with Recovery
10.1.4. Handling Recovery if Failure Occurs
10.2. Q-Block2 Option
10.2.1. A Simple Example
10.2.2. Handling MAX_PAYLOADS Limits
10.2.3. Handling MAX_PAYLOADS with Recovery
10.2.4. Handling Recovery by Setting the M Bit
10.3. Q-Block1 and Q-Block2 Options
10.3.1. A Simple Example
10.3.2. Handling MAX_PAYLOADS Limits
10.3.3. Handling Recovery
11. Security Considerations
12. IANA Considerations
12.1. CoAP Option Numbers Registry
12.2. Media Type Registration
12.3. CoAP Content-Formats Registry
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Examples with Confirmable Messages
A.1. Q-Block1 Option
A.2. Q-Block2 Option
Appendix B. Examples with Reliable Transports
B.1. Q-Block1 Option
B.2. Q-Block2 Option
Acknowledgments
Authors' Addresses
The Constrained Application Protocol (CoAP) [RFC7252], although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. CoAP supports two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and Non-confirmable (NON). Unlike NON messages, every CON message will elicit an acknowledgment or a reset.
HTTPにインスパイアされているが、制約付きアプリケーションプロトコル（COAP）[RFC7252]は、TCPの代わりにUDPを使用するように設計されています。UDPを介したCOAPのメッセージ層には、信頼できる配信、簡単な輻輳制御、およびフロー制御のためのサポートが含まれています。CoAPは2つのメッセージタイプをサポートしています（[RFC7252]のセクション1.2）：確認可能（CON）および確認不可能（非）。メッセージ以外のメッセージとは異なり、すべてのCONメッセージは確認応答またはリセットを誘発します。
The CoAP specification recommends that a CoAP message should fit within a single IP packet (i.e., avoid IP fragmentation). To handle data records that cannot fit in a single IP packet, [RFC7959] introduced the concept of block-wise transfers and the companion CoAP Block1 and Block2 options. However, this concept is designed to work exclusively with Confirmable messages (Section 1 of [RFC7959]). Note that the block-wise transfer was further updated by [RFC8323] for use over TCP, TLS, and WebSockets.
CoAP仕様は、COAPメッセージが単一のIPパケット内に収まるようになることを推奨します（すなわち、IPフラグメンテーションを避ける）。単一のIPパケットに収まらないデータレコードを処理するには、[RFC7959]はブロックごとの転送とコンパニオンCOAP BLOCK1とBLOCK2オプションの概念を導入しました。ただし、この概念は確認可能なメッセージを排他的に動作させるように設計されています（[RFC7959]のセクション1）。ブロックごとの転送は、TCP、TLS、およびWebocketsを介して使用するための[RFC8323]によってさらに更新されました。
The CoAP Block1 and Block2 options work well in environments where there are no, or minimal, packet losses. These options operate synchronously, i.e., each individual block has to be requested. A CoAP endpoint can only ask for (or send) the next block when the transfer of the previous block has completed. The packet transmission rate, and hence the block transmission rate, is controlled by Round-Trip Times (RTTs).
CoAP Block1とBlock2のオプションは、NO、または最小限のパケット損失がある環境でうまく機能します。これらのオプションは同期的に動作し、すなわち各個々のブロックを要求しなければならない。前のブロックの転送が完了したときに、COAPエンドポイントは次のブロックを要求（または送信）できます。パケット伝送速度、したがってブロック伝送速度は、往復時間（RTT）によって制御される。
There is a requirement for blocks of data larger than a single IP datagram to be transmitted under network conditions where there may be asymmetrical transient packet loss (e.g., acknowledgment responses may get dropped). An example is when a network is subject to a Distributed Denial of Service (DDoS) attack and there is a need for DDoS mitigation agents relying upon CoAP to communicate with each other (e.g., [RFC9132] [DOTS-TELEMETRY]). As a reminder, [RFC7959] recommends the use of CON responses to handle potential packet loss. However, such a recommendation does not work with a "flooded pipe" DDoS situation (e.g., [RFC9132]).
非対称の過渡パケット損失があるかもしれないネットワーク条件下で送信されるべき単一のIPデータグラムよりも大きいデータブロックが必要とされている（例えば、確認応答反応がドロップされる可能性がある）。一例は、ネットワークが分散サービス拒否（DDOS）攻撃の影響を受ける場合であり、互いにCOAPに依存するDDOS緩和エージェント（例えば、[RFC9132] [ドット - テレメトリ]）が必要である。リマインダーとして、[RFC7959]は潜在的なパケット損失を処理するためのCON応答を使用することを推奨しています。しかしながら、そのような勧告は「あふれされたパイプ」DDOSの状況（例えば、[RFC9132]）では機能しない。
This document introduces the CoAP Q-Block1 and Q-Block2 options, which allow block-wise transfers to work with a series of Non-confirmable messages instead of lock-stepping using Confirmable messages (Section 3). In other words, this document provides a missing piece of [RFC7959], namely the support of block-wise transfers using Non-confirmable messages where an entire body of data can be transmitted without the requirement that intermediate acknowledgments be received from the peer (but recovery is available should it be needed).
この文書では、COAP Q-Block1とQ-Block2のオプションを紹介します。これにより、確認可能なメッセージを使用してロックステッピングの代わりに一連の確認不可能なメッセージで動作することができます（セクション3）。言い換えれば、この文書は、不足している[RFC7959]、すなわち、中間確認応答を受信する必要なしにデータの全体を送信することができることを確認できない、不可告のメッセージを使用してブロック単位の転送のサポートを提供する（ただし、リカバリが必要です）。
Similar to [RFC7959], this specification does not remove any of the constraints posed by the base CoAP specification [RFC7252] it is strictly layered on top of.
[RFC7959]と同様に、この仕様はベースCOAP仕様で提起された制約のいずれも除去されません[RFC7252]それは厳密に階層化されています。
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Readers should be familiar with the terms and concepts defined in [RFC7252], [RFC7959], and [RFC8132]. Particularly, the document uses the following key concepts:
読者は[RFC7252]、[RFC7959]、[RFC8132]で定義されている用語と概念に精通している必要があります。特に、この文書は次の主な概念を使用しています。
Token: used to match responses to requests independently from the underlying messages (Section 5.3.1 of [RFC7252]).
トークン：基礎となるメッセージから独立して要求に対する応答を一致させるために使用されます（[RFC7252]のセクション5.3.1）。
ETag: used as a resource-local identifier for differentiating between representations of the same resource that vary over time (Section 5.10.6 of [RFC7252]).
ETAG：経時的に異なる同じリソースの表現を区別するためのリソースローカル識別子として使用されます（[RFC7252]のセクション5.10.6）。
The terms "payload" and "body" are defined in [RFC7959]. The term "payload" is thus used for the content of a single CoAP message (i.e., a single block being transferred), while the term "body" is used for the entire resource representation that is being transferred in a block-wise fashion.
「ペイロード」および「本体」という用語は[RFC7959]で定義されています。したがって、「ペイロード」という用語は、単一のCOAPメッセージの内容（すなわち、転送されている単一ブロック）の内容に使用され、一方、「BODY」という用語はブロック単位で転送されている全リソース表現に使用される。
Request-Tag refers to an option that allows a CoAP server to match message fragments belonging to the same request [RFC9175].
request-tagとは、CoAPサーバーが同じ要求[RFC9175]に属するメッセージフラグメントを一致させることを可能にするオプションを指します。
MAX_PAYLOADS is the maximum number of payloads that can be transmitted at any one time.
MAX_PAYLOADSは、一度に送信できるペイロードの最大数です。
MAX_PAYLOADS_SET is the set of blocks identified by block numbers that, when divided by MAX_PAYLOADS, have the same numeric result. For example, if MAX_PAYLOADS is set to 10, a MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. Depending on the overall data size, there could be fewer than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.
MAX_PAYLOADS_SETは、MAX_PAYLOADSで割ったときに同じ数値結果を持つブロック番号で識別されるブロックのセットです。たとえば、MAX_PAYLOADSが10に設定されている場合、MAX_PAYLOADS_SETはブロック＃0~＃9、＃10~＃19などであり得る。全体データサイズに応じて、最終MAX_PAYLOADS_SET内のMAX_PAYLOADSブロックより少ない可能性がある。
This document introduces the CoAP Q-Block1 and Q-Block2 options. These options are designed to work in particular with NON requests and responses.
この文書では、COAP Q-Block1とQ-Block2オプションを紹介します。これらのオプションは、特に要求および応答で機能するように設計されています。
Using NON messages, faster transmissions can occur, as all the blocks can be transmitted serially (akin to fragmented IP packets) without having to wait for a response or next request from the remote CoAP peer. Recovery of missing blocks is faster in that multiple missing blocks can be requested in a single CoAP message. Even if there is asymmetrical packet loss, a body can still be sent and received by the peer whether the body comprises a single payload or multiple payloads, assuming no recovery is required.
非メッセージを使用すると、すべてのブロックをリモートCOAPピアからの応答または次の要求を待つ必要なしにすべてのブロックをシリアル（断片化されたIPパケットにakin）送信することができます。欠けているブロックの回復は、複数のCOAPメッセージで複数の欠けているブロックを要求できるという点で、より速いです。非対称なパケット損失がある場合でも、回復が必要とされていないと仮定して、本体が単一のペイロードまたは複数のペイロードを含むかどうかをピアによって依然として送受信することができる。
A CoAP endpoint can acknowledge all or a subset of the blocks. Concretely, the receiving CoAP endpoint either informs the sending CoAP endpoint of successful reception or reports on all blocks in the body that have not yet been received. The sending CoAP endpoint will then retransmit only the blocks that have been lost in transmission.
COAPエンドポイントは、ブロックのすべてまたはサブセットを確認できます。具体的には、受信用COAPエンドポイントは、まだ受信されていないボディのすべてのブロックについて、受信を成功させるか、またはレポートの送信COAPエンドポイントを通知します。送信されたCOAPエンドポイントは、送信中に失われたブロックのみを再送信します。
Note that similar transmission rate benefits can be applied to Confirmable messages if the value of NSTART is increased from 1 (Section 4.7 of [RFC7252]). However, the use of Confirmable messages will not work effectively if there is asymmetrical packet loss. Some examples with Confirmable messages are provided in Appendix A.
NSTARTの値が1から増加すると、同様の伝送速度の利点を確認可能なメッセージに適用することができます（[RFC7252]のセクション4.7）。ただし、確認可能なメッセージを使用すると、非対称なパケット損失がある場合は効果的には機能しません。確認可能なメッセージを備えたいくつかの例は付録Aに提供されています。
There is little, if any, benefit of using these options with CoAP running over a reliable connection [RFC8323]. In this case, there is no differentiation between CON and NON, as they are not used. Some examples using a reliable transport are provided in Appendix B.
もしあれば、信頼性の高い接続を介してCOAPを実行してこれらのオプションを使用することの利点はほとんどありません[RFC8323]。この場合、使用されていないので、CONとNONの間の区別はありません。信頼できる輸送を使用したいくつかの例は付録Bに提供されています。
The Q-Block1 and Q-Block2 options are similar in operation to the CoAP Block1 and Block2 options, respectively. They are not a replacement for them but have the following benefits:
Q-Block1とQ-Block2のオプションは、それぞれCOAP Block1とBlock2オプションと同様です。彼らはそれらの代わりにはありませんが、次のような利点があります。
* They can operate in environments where packet loss is highly asymmetrical.
* それらはパケット損失が非常に非対称である環境で動作することができます。
* They enable faster transmissions of sets of blocks of data with fewer packet interchanges.
* それらは、より少ないパケット交換を有するデータブロックのセットの高速送信を可能にする。
* They support faster recovery should any of the blocks get lost in transmission.
* それらは、ブロックのいずれかが送信で失われるべきであるより速い回復をサポートします。
* They support sending an entire body using NON messages without requiring that an intermediate response be received from the peer.
* それらは、ピアから中間応答を受信することを必要とせずに、メッセージ以外のメッセージを使用して本体全体を送信します。
The disadvantages of using the CoAP Block1 and Block2 options are as follows:
COAP BLOCK1とBLOCK2オプションを使用するという欠点は次のとおりです。
* There is a loss of lock-stepping, so payloads are not always received in the correct order (blocks in ascending order).
* ロックステッピングが失われるため、ペイロードは必ずしも正しい順序で受信されません（昇順のブロック）。
* Additional congestion control measures need to be put in place for NON messages (Section 7.2).
* メッセージ以外の場合は、追加の輻輳制御措置を講じる必要があります（セクション7.2）。
* To reduce the transmission times for CON transmissions of large bodies, NSTART needs to be increased from 1, but this affects congestion control and incurs a requirement to retune other parameters (Section 4.7 of [RFC7252]). Such tuning is out of scope of this document.
* 大体の伝送の伝送時間を短縮するためには、NSTARTを1から増やす必要がありますが、これは輻輳制御に影響し、その他のパラメータを再実行するための要件を招きます（[RFC7252]のセクション4.7）。このような調整はこの文書の範囲外です。
* Mixing of NON and CON during an exchange of requests/responses using Q-Block options is not supported.
* Qブロックオプションを使用した要求/応答の交換中の非以外のCONのミキシングはサポートされていません。
* The Q-Block options do not support stateless operation/random access.
* Qブロックオプションはステートレス操作/ランダムアクセスをサポートしません。
* Proxying of Q-Block options is limited to caching full representations.
* Qブロックオプションのプロキシは、完全表現をキャッシュすることに限定されています。
* There is no multicast support.
* マルチキャストサポートはありません。
The Q-Block1 and Q-Block2 options can be used instead of the Block1 and Block2 options when the different transmission properties are required. If the new options are not supported by a peer, then transmissions can fall back to using the Block1 and Block2 options (Section 4.1).
異なる送信プロパティが必要な場合は、block1とblock2のオプションの代わりにq-block1とq-block2オプションを使用できます。新しいオプションがピアでサポートされていない場合、送信はBlock1とBlock2のオプションの使用に戻ることができます（セクション4.1）。
The deviations from the Block1 and Block2 options are specified in Section 4. Pointers to the appropriate sections in [RFC7959] are provided.
block1とblock2のオプションからの偏差はセクション4で指定されています。[RFC7959]の適切なセクションへのポインタが提供されています。
The specification refers to the base CoAP methods defined in Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and iPATCH, which are introduced in [RFC8132].
仕様とは、[RFC7252]のセクション5.8で定義されているベースCOAPメソッドと[RFC8132]で導入された新しいCoAPメソッド、フェッチ、パッチ、およびipatchです。
The No-Response option [RFC7967] was considered but was abandoned, as it does not apply to Q-Block2 responses. A unified solution is defined in the document.
無応答オプション[RFC7967]は考慮されましたが、Q-Block2の応答には適用されないため、放棄されました。統一された解決策は文書内で定義されています。
This document adds a media type for the 4.08 (Request Entity Incomplete) response defining an additional message format for reporting on payloads using the Q-Block1 option that are not received by the server.
このドキュメントでは、4.08（要求エンティティ不完全な）応答のメディアタイプを追加します。サーバーによって受信されていないQ-Block1オプションを使用してペイロードを報告するための追加のメッセージフォーマットを定義します。
See Section 5 for more details.
詳細についてはセクション5を参照してください。
The block-wise transfer specified in [RFC7959] covers the general case using Confirmable messages but falls short in situations where packet loss is highly asymmetrical or there is no need for an acknowledgment. In other words, there is a need for Non-confirmable support.
[RFC7959]で指定されているブロックごとの転送は、確認可能なメッセージを使用して一般的なケースをカバーしますが、パケット損失が非常に非対称であるか確認応答を必要としない状況では短くなります。言い換えれば、確認不可能なサポートが必要です。
The mechanism specified in this document provides roughly similar features to the Block1/Block2 options. It provides additional properties that are tailored towards the intended use case of Non-confirmable transmission. Concretely, this mechanism primarily targets applications, such as DDoS Open Threat Signaling (DOTS), that cannot use CON requests/responses because of potential packet loss and that support application-specific mechanisms to assess whether the remote peer is not overloaded and thus is able to process the messages sent by a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC9132]). Other use cases are when an application sends data but has no need for an acknowledgment of receipt and any data transmission loss is not critical.
このドキュメントで指定されているメカニズムは、block1 / block2オプションとほぼ同じ機能を提供します。それは、確認不能な送信の意図されたユースケースに向けて調整された追加の特性を提供します。具体的には、このメカニズムは主にDDOSオープン脅威シグナリング（ドット）などのアプリケーションをターゲットにしており、潜在的なパケット損失のためにCONリクエスト/応答を使用できず、リモートピアが過負荷であるかどうかを評価するためのアプリケーション固有のメカニズムをサポートすることができます。COAPエンドポイントによって送信されたメッセージ（RFC9132のセクション4.7のドットハートビート）を処理する。その他のユースケースは、アプリケーションがデータを送信するが、受信の確認を必要とせず、データ伝送損失は重要ではありません。
The mechanism includes guards to prevent a CoAP agent from overloading the network by adopting an aggressive sending rate. These guards MUST be followed in addition to the existing CoAP congestion control, as specified in Section 4.7 of [RFC7252]. See Section 7 for more details.
このメカニズムには、積極的な送信速度を採用することによって、CoAPエージェントがネットワークを過負荷にするのを防ぐためのガードが含まれています。[RFC7252]のセクション4.7で規定されているように、これらのガードを既存のCAAP輻輳制御に加えて従う必要があります。詳細についてはセクション7を参照してください。
Any usage outside the primary use case of Non-confirmable messages with block transfers should be carefully weighed against the potential loss of interoperability with generic CoAP applications (see the disadvantages listed in Section 3). It is hoped that the experience gained with this mechanism can feed future extensions of the block-wise mechanism that will both be generally applicable and serve this particular use case.
ブロック転送を伴う確認不可能なメッセージの主要な使用例の外部の使用方法は、一般的なCOAPアプリケーションとの相互運用性の喪失に対して慎重に秤量する必要があります（セクション3に記載の欠点を参照）。このメカニズムで得られた経験は、両方とも一般的に適用可能であり、この特定のユースケースを提供するブロック単位のメカニズムの将来の拡張をフィードすることが望まれます。
It is not recommended that these options are used in the "NoSec" security mode (Section 9 of [RFC7252]), as the source endpoint needs to be trusted. Using Object Security for Constrained RESTful Environments (OSCORE) [RFC8613] does provide a security context and hence a trust of the source endpoint that prepared the inner OSCORE content. However, even with OSCORE, using the NoSec mode with these options may still be inadequate, for reasons discussed in Section 11.
ソースエンドポイントを信頼する必要があるため、これらのオプションは「NOSEC」セキュリティモード（[RFC7252]のセクション9）で使用されることはお勧めできません。制約付きRESTful環境のオブジェクトセキュリティの使用（OSCRO）[RFC8613]はセキュリティコンテキスト、したがって内部オスアコンテンツを作成したソースエンドポイントの信頼を提供します。ただし、これらのオプションを使用してNOSECモードを使用すると、セクション11で説明した理由で、NOSECモードを使用しても不十分な場合があります。
The properties of the Q-Block1 and Q-Block2 options are shown in Table 1. The formatting of this table follows the one used in Table 4 of Section 5.10 of [RFC7252]. The C, U, N, and R columns indicate the properties Critical, UnSafe, NoCacheKey, and Repeatable, which are defined in Section 5.4 of [RFC7252]. Only the Critical and UnSafe columns are marked for the Q-Block1 option. The Critical, UnSafe, and Repeatable columns are marked for the Q-Block2 option. As these options are UnSafe, NoCacheKey has no meaning and so is marked with a dash.
Q-Block1とQ-Block2のオプションのプロパティを表1に示します。この表のフォーマットは[RFC7252]のセクション5.10の表4で使用されているものに従います。C、U、N、R列は、[RFC7252]のセクション5.4で定義されているプロパティが重要な、安全でなく、nocachekey、および繰り返し可能なプロパティを示します。Q-Block1オプションには、重要でない列のみがマークされています。クリティカル、危険、および再現可能な列は、Q-Block2オプションのマークが付けられています。これらのオプションは安全ではないので、nocachekeyには意味がありませんのでダッシュでマークされています。
+=====+===+===+===+===+==========+========+========+=========+
| No. | C | U | N | R | Name | Format | Length | Default |
+=====+===+===+===+===+==========+========+========+=========+
| 19 | x | x | - | | Q-Block1 | uint | 0-3 | (none) |
+-----+---+---+---+---+----------+--------+--------+---------+
| 31 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) |
+-----+---+---+---+---+----------+--------+--------+---------+
Table 1: CoAP Q-Block1 and Q-Block2 Option Properties
表1：Q-Block1とQ-Block2オプションのプロパティ
The Q-Block1 and Q-Block2 options can be present in both the request and response messages. The Q-Block1 option pertains to the request payload, and the Q-Block2 option pertains to the response payload. When the Content-Format option is present together with the Q-Block1 or Q-Block2 option, the option applies to the body, not to the payload (i.e., it must be the same for all payloads of the same body).
Q-Block1とQ-Block2オプションは、要求メッセージと応答メッセージの両方に存在できます。Q-Block1オプションはリクエストペイロードに関連し、Q-Block2オプションは応答ペイロードに関するものです。content-formatオプションがQ-Block1またはQ-Block2オプションと一緒に存在する場合、このオプションはペイロードには限らず、そのボディに適用されます（すなわち、同じボディのすべてのペイロードに対して同じでなければなりません）。
The Q-Block1 option is useful with the payload-bearing (e.g., POST, PUT, FETCH, PATCH, and iPATCH) requests and their responses.
Q-Block1オプションは、ペイロードベアリング（例えば、POST、PUT、FETCH、PATCH、およびIPATCH）要求とその応答に役立ちます。
The Q-Block2 option is useful, for example, with GET, POST, PUT, FETCH, PATCH, and iPATCH requests and their payload-bearing responses (response codes 2.01, 2.02, 2.04, and 2.05) (Section 5.5 of [RFC7252]).
Q-Block2オプションは、例えば、GET、POST、PUT、FETCH、パッチ、およびiPatch要求とそのペイロードベアリング応答（応答コード2.01,2.02,2.04、および2.05）を使用して便利です（[RFC7252]のセクション5.5）。
A CoAP endpoint (or proxy) MUST support either both or neither of the Q-Block1 and Q-Block2 options.
COAPエンドポイント（またはプロキシ）は、Q-Block1とQ-Block2オプションの両方でもどちらもサポートしている必要があります。
If the Q-Block1 option is present in a request or the Q-Block2 option is returned in a response, this indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred. If it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed.
q-block1オプションが要求に存在するか、またはq-block2オプションが応答で返された場合、これはブロックごとの転送を示し、この特定のブロックごとのペイロードをどのようにフォーマットしているかを説明します。それが反対方向に存在する場合、そのペイロードがどのように形成されるか処理されたかについての追加の制御を提供します。
To indicate support for Q-Block2 responses, the CoAP client MUST include the Q-Block2 option in a GET or similar request (e.g., FETCH), the Q-Block2 option in a PUT or similar request (e.g., POST), or the Q-Block1 option in a PUT or similar request so that the server knows that the client supports this Q-Block functionality should it need to send back a body that spans multiple payloads. Otherwise, the server would use the Block2 option (if supported) to send back a message body that is too large to fit into a single IP packet [RFC7959].
Q-Block2応答のサポートを示すために、CoAPクライアントは、GETまたは類似の要求（FETCH）、Q-Block2オプション、PUTまたは類似の要求（POSTなど）、またはQ-Block1 PUTまたは類似の要求では、サーバーがこのQブロック機能をサポートしていることを知っているように、複数のペイロードにわたるボディを送り返す必要がある場合は、サーバーがこのQブロック機能を知っています。それ以外の場合、サーバーはBlock2オプション（サポートされている場合）を使用して、単一のIPパケットに収まるように大きすぎるメッセージ本文を送り返します[RFC7959]。
How a client decides whether it needs to include a Q-Block1 or Q-Block2 option can be driven by a local configuration parameter, triggered by an application (e.g., DOTS), etc. Such considerations are out of the scope of this document.
クライアントがQ-Block1またはQ-Block2オプションを含める必要があるかどうかを決定する方法は、アプリケーション（例えば、ドット）などによってトリガされたローカル構成パラメータによって駆動できます。このような考慮事項はこの文書の範囲外です。
Implementation of the Q-Block1 and Q-Block2 options is intended to be optional. However, when a Q-Block1 or Q-Block2 option is present in a CoAP message, it MUST be processed (or the message rejected). Therefore, the Q-Block1 and Q-Block2 options are identified as critical options.
Q-Block1とQ-Block2のオプションの実装はオプションであることを目的としています。ただし、Q-Block1またはQ-Block2オプションがCOAPメッセージに存在する場合は、処理（またはメッセージが拒否された）を処理する必要があります。したがって、Q-Block1とQ-Block2のオプションは重要なオプションとして識別されます。
With CoAP over UDP, the way a request message is rejected for critical options depends on the message type. A Confirmable message with an unrecognized critical option is rejected with a 4.02 (Bad Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable message with an unrecognized critical option is either rejected with a Reset message or just silently ignored (Sections 5.4.1 and 4.3 of [RFC7252]). To reliably get a rejection message, it is therefore REQUIRED that clients use a Confirmable message for determining support for the Q-Block1 and Q-Block2 options. This Confirmable message can be sent under the base CoAP congestion control setup specified in Section 4.7 of [RFC7252] (that is, NSTART does not need to be increased (Section 7.1)).
UDPを介してCOAPを使用すると、要求メッセージが重要なオプションのために拒否される方法は、メッセージの種類によって異なります。認識されなかった重要なオプションを持つ確認可能なメッセージは、4.02（Bad Option）の応答（[RFC7252]のセクション5.4.1）で拒否されます。認識されなかった重要なオプションを持つ確認不可能なメッセージは、リセットメッセージで拒否されるか、または単に無視されます（[RFC7252]のセクション5.4.1と4.3）。したがって、拒否メッセージを確実に取得するためには、クライアントがQ-Block1とQ-Block2オプションのサポートを決定するための確認可能なメッセージを使用する必要があります。この確認可能なメッセージは、[RFC7252]のセクション4.7で指定されたベースCOAP輻輳制御設定で送信できます（つまり、NSTARTは増加する必要はありません（セクション7.1））。
The Q-Block1 and Q-Block2 options are unsafe to forward. That is, a CoAP proxy that does not understand the Q-Block1 (or Q-Block2) option must reject the request or response that uses either option (see Section 5.7.1 of [RFC7252]).
Q-Block1とQ-Block2のオプションは、転送に安全ではありません。つまり、Q-Block1（またはQ-Block2）オプションを理解していないCOAPプロキシは、いずれかのオプションを使用する要求または応答を拒否する必要があります（[RFC7252]のセクション5.7.1を参照）。
The Q-Block2 option is repeatable when requesting retransmission of missing blocks but not otherwise. Except for that case, any request carrying multiple Q-Block1 (or Q-Block2) options MUST be handled following the procedure specified in Section 5.4.5 of [RFC7252].
Q-Block2オプションは、欠落ブロックの再送信を要求するときは繰り返し可能ですが、それ以外の場合は繰り返されません。その場合を除いて、[RFC7252]のセクション5.4.5で指定された手順に従って、複数のQ-Block1（またはQ-Block2）オプションを搭載した要求を処理する必要があります。
The Q-Block1 and Q-Block2 options, like the Block1 and Block2 options, are of both class E and class U for OSCORE processing (Table 2). The Q-Block1 (or Q-Block2) option MAY be an Inner or Outer option (Section 4.1 of [RFC8613]). The Inner and Outer values are therefore independent of each other. The Inner option is encrypted and integrity protected between clients and servers and provides message body identification in case of end-to-end fragmentation of requests. The Outer option is visible to proxies and labels message bodies in case of hop-by-hop fragmentation of requests.
block1とblock2オプションのようなQ-Block1とQ-Block2のオプションは、OSCORE処理用のクラスEとクラスUの両方です（表2）。Q-Block1（またはQ-Block2）オプションは、インナーオプションまたは外部オプションです（RFC8613のセクション4.1）。したがって、内側値と外側値は互いに独立しています。内部オプションは、暗号化され、クライアントとサーバー間で保護されていて、エンドツーエンドの要求の断片化の場合にメッセージ本文の識別を提供します。アウターオプションは、要求のホップバイホップフラグメンテーションの場合、プロキシとラベルメッセージボディに表示されます。
+========+==========+===+===+
| Number | Name | E | U |
+========+==========+===+===+
| 19 | Q-Block1 | x | x |
+--------+----------+---+---+
| 31 | Q-Block2 | x | x |
+--------+----------+---+---+
Table 2: OSCORE Protection of the Q-Block1 and Q-Block2 Options
表2：Q-Block1およびQ-Block2のオプションのオスア保護
Note that, if the Q-Block1 or Q-Block2 options are included in a packet as Inner options, the Block1 or Block2 options MUST NOT be included as Inner options. Similarly, there MUST NOT be a mix of Q-Block and Block options for the Outer options. Messages that do not adhere to this behavior MUST be rejected with a 4.02 (Bad Option). The Q-Block and Block options can be mixed across Inner and Outer options, as these are handled independently of each other. For clarity, if OSCORE is not being used, there MUST NOT be a mix of Q-Block and Block options in the same packet.
Q-Block1またはQ-Block2のオプションが内部オプションとしてパケットに含まれている場合は、Block1またはBlock2オプションを内部オプションとして含めることはできません。同様に、外部オプションのQブロックとブロックオプションの組み合わせがあってはいけません。この動作に従わないメッセージは、4.02（不良オプション）で拒否する必要があります。これらは互いに独立して処理されるため、Qブロックとブロックオプションは内側と外側のオプションを越えて混合できます。明確にするために、OSCOREが使用されていない場合、同じパケット内のQブロックとブロックオプションの組み合わせがなければならない。
The structure of the Q-Block1 and Q-Block2 options follows the structure defined in Section 2.2 of [RFC7959].
Q-Block1とQ-Block2のオプションの構造は、[RFC7959]のセクション2.2で定義されている構造に従います。
There is no default value for the Q-Block1 and Q-Block2 options. The absence of one of these options is equivalent to an option value of 0 with respect to the value of block number (NUM) and more bit (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 is set to 0; M is unset). However, in contrast to the explicit value 0, which would indicate a size of the block (SZX) of 0, and thus a size value of 16 bytes, there is no specific 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; therefore, this is semantically different from the absence of the option.)
Q-Block1とQ-Block2のオプションにはデフォルト値はありません。これらのオプションの1つがないことは、オプションで指定され得るブロック番号（num）およびより多くのビット（m）に関して、すなわち現在のブロックがあることを示す、オプション値0と同等である。最初に、転送のブロックのみがブロック（ブロック番号は0に設定されています。mは設定されていません）。ただし、明示的な値0とは対照的に、ブロック（SZX）のサイズ（SZX）、したがって16バイトのサイズ値を示すであろうと、オプションがないことによって暗黙のサイズはありません - サイズは指定されていないままにした。（任意のUINTに関しては、明示的な値0はゼロ長さのオプションによって効率的に示されます。したがって、これはオプションの欠如とは意味的に異なります。）
The Q-Block1 option is used when the client wants to send a large amount of data to the server using the POST, PUT, FETCH, PATCH, or iPATCH methods where the data and headers do not fit into a single packet.
Q-Block1オプションは、データとヘッダーが単一のパケットに収まらないPOST、PUT、FETCH、PATCH、またはiPatchメソッドを使用して、クライアントが大量のデータをサーバーに送信したい場合に使用されます。
When the Q-Block1 option is used, the client MUST include a Request-Tag option [RFC9175]. The Request-Tag value MUST be the same for all of the requests for the body of data that is being transferred. The Request-Tag is opaque, but the client MUST ensure that it is unique for every different body of transmitted data.
Q-Block1オプションを使用する場合、クライアントには要求タグオプション[RFC9175]を含める必要があります。request-tag値は、転送されているデータの本文のすべての要求に対して同じでなければなりません。request-tagは不透明ですが、クライアントはそれがさまざまな送信されたデータの範囲内で一意であることを確認する必要があります。
Implementation Note: It is suggested that the client treats the Request-Tag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial Request-Tag value should be randomly generated and then subsequently incremented by the client whenever a new body of data is being transmitted between peers.
実装注：クライアントが要求タグを8バイトの符号なし整数として扱うことが示唆されています。実装は、パケットのオーバーヘッドサイズを減らすためにこれを4バイトに制限することを検討したいと思うかもしれません。最初の要求タグ値はランダムに生成され、新しいデータの本体がピア間で送信されているときはいつでもクライアントによって増分されるべきです。
Section 4.6 discusses the use of the Size1 option.
セクション4.6はsize1オプションの使用について説明します。
For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until successful receipt of the body by the server. For Non-confirmable transmission, no response is required until either the successful receipt of the body by the server or a timer expires with some of the payloads having not yet arrived. In the latter case, a "retransmit missing payloads" response is needed. For reliable transports (e.g., [RFC8323]), a response is not required until successful receipt of the body by the server.
確認可能な送信のために、サーバは各パケットを承認し続けているが、サーバによって本体の受信が成功するまで応答は必要ありません（別々またはPIGGYBOBACKにかけるかどうか）。確認不可能な送信の場合、サーバーまたはタイマーが正しく受信されたか、またはまだ到着していないペイロードが期限切れになるまで、応答は必要ありません。後者の場合、「再送のないペイロード」の応答が必要です。信頼できる輸送（例えば、[RFC8323]）の場合、サーバーによって本体の受信が成功するまで応答は必要ありません。
Each individual message that carries a block of the body is treated as a new request (Section 6).
本体のブロックを搬送する個々のメッセージは、新しい要求として扱われます（セクション6）。
The client MUST send the payloads in order of increasing block number, starting from zero, until the body is complete (subject to any congestion control (Section 7)). In addition, any missing payloads requested by the server must be separately transmitted with increasing block numbers.
クライアントは、ボディが完成するまで、ゼロから始まるブロック番号を増やす順にペイロードを送信する必要があります（輻輳制御（セクション7））。さらに、サーバーによって要求された欠陥のあるペイロードは、ブロック番号を増やすと別々に送信されなければなりません。
The following response codes are used:
次の応答コードが使用されます。
2.01 (Created) This response code indicates successful receipt of the entire body and that the resource was created. The token to use MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request, since that will aid any troubleshooting. The client should then release all of the tokens used for this body. Note that the last received payload might not be the one with the highest block number.
2.01 （作成）この応答コードは、本体全体の受信が成功し、リソースが作成されたことを示します。使用するトークンは、このブロック単位の交換の要求で受信されたトークンの1つである必要があります。しかしながら、それがトラブルシューティングを助けるので、最後に受信した要求で使用されているものを提供することが望ましい。その後、クライアントはこのボディに使用されているすべてのトークンを解放する必要があります。最後に受信したペイロードが最も高いブロック番号を持つものではないかもしれないことに注意してください。
2.02 (Deleted) This response code indicates successful receipt of the entire body and that the resource was deleted when using POST (Section 5.8.2 of [RFC7252]). The token to use MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. The client should then release all of the tokens used for this body.
2.02 （削除）この応答コードは、ボディ全体の受信が成功し、POSTを使用しているときにリソースが削除されたことを示します（[RFC7252]のセクション5.8.2）。使用するトークンは、このブロック単位の交換の要求で受信されたトークンの1つである必要があります。しかしながら、最後の受信要求に使用されているものを提供することが望ましい。その後、クライアントはこのボディに使用されているすべてのトークンを解放する必要があります。
2.04 (Changed) This response code indicates successful receipt of the entire body and that the resource was updated. The token to use MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. The client should then release all of the tokens used for this body.
2.04 （変更）この応答コードは、本体全体の受信が成功し、リソースが更新されたことを示します。使用するトークンは、このブロック単位の交換の要求で受信されたトークンの1つである必要があります。しかしながら、最後の受信要求に使用されているものを提供することが望ましい。その後、クライアントはこのボディに使用されているすべてのトークンを解放する必要があります。
2.05 (Content) This response code indicates successful receipt of the entire FETCH request body (Section 2 of [RFC8132]) and that the appropriate representation of the resource is being returned. The token to use MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request.
2.05 （内容）この応答コードは、フェッチ要求本体全体の受信が成功したことを示し（[RFC8132]のセクション2）、リソースの適切な表現が返されていることを示しています。使用するトークンは、このブロック単位の交換の要求で受信されたトークンの1つである必要があります。しかしながら、最後の受信要求に使用されているものを提供することが望ましい。
If the FETCH request includes the Observe option, then the server MUST use the same token as used for the 2.05 (Content) response for returning any triggered Observe responses so that the client can match them up.
フェッチ要求に監視オプションが含まれている場合、サーバーは、クライアントがそれらを一致させることができるように、トリガー監視回答を返すために2.05（コンテンツ）応答に使用されているのと同じトークンを使用する必要があります。
The client should then release all of the tokens used for this body apart from the one used for tracking an observed resource.
その後、クライアントは、観測されたリソースを追跡するために使用されるものとは別に、この本体に使用されるすべてのトークンを解放する必要があります。
2.31 (Continue) This response code can be used to indicate that all of the blocks up to and including the Q-Block1 option block NUM (all having the M bit set) have been successfully received. The token to use MUST be one of the tokens that were received in a request for this latest MAX_PAYLOADS_SET block-wise exchange. However, it is desirable to provide the one used in the last received request.
2.31 （続行）この応答コードを使用して、Q-Block1オプションブロック数（すべてMビットセットを持つ）までのすべてのブロックが正常に受信されたことを示すために使用できます。使用するトークンは、この最新のMAX_PAYLOADS_SETブロック単位交換の要求で受信されたトークンの1つになる必要があります。しかしながら、最後の受信要求に使用されているものを提供することが望ましい。
The client should then release all of the tokens used for this MAX_PAYLOADS_SET.
その後、クライアントはこのMAX_PAYLOADS_SETに使用されるすべてのトークンを解放する必要があります。
A response using this response code MUST NOT be generated for every received Q-Block1 option request. It SHOULD only be generated when all the payload requests are Non-confirmable and a MAX_PAYLOADS_SET has been received by the server. More details about the motivations for this optimization are discussed in Section 7.2.
この応答コードを使用した応答は、受信したQ-Block1オプション要求ごとに生成してはいけません。すべてのペイロード要求が確認不可能で、MAX_PAYLOADS_SETがサーバーによって受信されたときにのみ生成されるべきです。この最適化のための動機に関する詳細は、7.2節で議論されています。
This response code SHOULD NOT be generated for CON, as this may cause duplicated payloads to unnecessarily be sent.
この応答コードは、複製されたペイロードを不必要に送信させる可能性があるため、CONに対して生成されません。
4.00 (Bad Request) This response code MUST be returned if the request does not include a Request-Tag option or a Size1 option but does include a Q-Block1 option.
4.00 （不良要求）要求に要求タグオプションまたはsize1オプションが含まれていないがQ-Block1オプションが含まれている場合、この応答コードを返す必要があります。
4.02 (Bad Option) This response code MUST be returned for a Confirmable request if the server does not support the Q-Block options. Note that a Reset message may be sent in case of a Non-confirmable request.
4.02 （不適切）サーバがQブロックオプションをサポートしていない場合、この応答コードは確認可能な要求に対して返さなければなりません。なお、確認不可の要求の場合には、リセットメッセージを送信することができる。
4.08 (Request Entity Incomplete) As a reminder, this response code returned without content type "application/missing-blocks+cbor-seq" (Section 12.3) is handled as in Section 2.9.2 of [RFC7959].
4.08 （要求不完全な要求の不完全）リマインダーとして、コンテンツタイプの場合に返されたこの応答コードは、[RFC7959]のセクション2.9.2のように処理されます。
This response code returned with content type "application/ missing-blocks+cbor-seq" indicates that some of the payloads are missing and need to be resent. The client then retransmits the individual missing payloads using the same Request-Tag, Size1, and Q-Block1 options to specify the same NUM, SZX, and M bit values as those sent initially in the original (but not received) packets.
コンテンツタイプの「アプリケーション/ Missing-Blocks CBOBOR-SEQ」で返されるこの応答コードは、ペイロードの一部が欠落していることを示し、再送が必要です。次に、クライアントは、同じ要求タグ、size1、およびq-block1オプションを使用して、同じnum、szx、およびmビット値を、元の（未受信）パケットに最初に送信されたものとして指定します。
The Request-Tag value to use is determined by taking the token in the 4.08 (Request Entity Incomplete) response, locating the matching client request, and then using its Request-Tag.
使用する要求タグ値は、4.08（要求エンティティ不完全）応答のトークンを取り、一致するクライアント要求を見つけ、次にその要求タグを使用して決定されます。
The token to use in the 4.08 (Request Entity Incomplete) response MUST be one of the tokens that were received in a request for this block-wise body exchange. However, it is desirable to provide the one used in the last received request. See Section 5 for further information.
4.08（要求エンティティ不完全）の応答で使用するトークンは、このブロックごとの身体交換の要求で受信されたトークンの1つである必要があります。しかしながら、最後の受信要求に使用されているものを提供することが望ましい。詳細についてはセクション5を参照してください。
If the server has not received all the blocks of a body, but one or more NON payloads have been received, it SHOULD wait for NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request Entity Incomplete) response.
サーバーが本体のすべてのブロックを受信していないが、1つ以上のペイロードが受信された場合は、4.08（要求エンティティ不完全）応答を送信する前に、non_receive_timeout（セクション7.2）を待つ必要があります。
4.13 (Request Entity Too Large) This response code can be returned under conditions similar to those discussed in Section 2.9.3 of [RFC7959].
4.13 （リクエストエンティティが大きすぎる）この応答コードは、[RFC7959]のセクション2.9.3で説明されている条件で返すことができます。
This response code can be returned if there is insufficient space to create a response PDU with a block size of 16 bytes (SZX = 0) to send back all the response options as appropriate. In this case, the Size1 option is not included in the response.
必要に応じて、16バイトのブロックサイズ（SZX = 0）の応答PDUを作成するためのスペースが不十分な場合は、この応答コードを返すことができます。この場合、size1オプションは応答に含まれません。
Further considerations related to the transmission timings of the 4.08 (Request Entity Incomplete) and 2.31 (Continue) response codes are discussed in Section 7.2.
4.08（要求エンティティ不完全）および2.31（続行）応答コードの送信タイミングに関するさらなる考慮事項については、セクション7.2で説明されている。
If a server receives payloads with different Request-Tags for the same resource, it should continue to process all the bodies, as it has no way of determining which is the latest version or which body, if any, the client is terminating the transmission for.
サーバーが同じリソースに対して異なるリクエストタグを持つペイロードを受信した場合は、最新バージョンまたはどのボディがどちらかを判断できないか、またはクライアントが送信を終了している場合は、すべてのボディを処理し続ける必要があります。。
If the client elects to stop the transmission of a complete body, then absent any local policy, the client MUST "forget" all tracked tokens associated with the body's Request-Tag so that a Reset message is generated for the invalid token in the 4.08 (Request Entity Incomplete) response. On receipt of the Reset message, the server SHOULD delete the partial body.
クライアントが完全なボディの送信を停止することを選択した場合、ローカルポリシーが存在しない場合、クライアントは、BODYの要求タグに関連付けられているすべての追跡されたトークンを「忘れる」ので、4.08の無効なトークンのリセットメッセージが生成される必要があります（エンティティが不完全な応答を要求します。リセットメッセージを受信すると、サーバーは部分本体を削除する必要があります。
If the server receives a duplicate block with the same Request-Tag, it MUST ignore the payload of the packet but MUST still respond as if the block was received for the first time.
サーバーが同じ要求タグを持つ重複ブロックを受信した場合は、パケットのペイロードを無視する必要がありますが、ブロックが最初に受信されたかのように応答する必要があります。
A server SHOULD maintain a partial body (missing payloads) for NON_PARTIAL_TIMEOUT (Section 7.2).
サーバーは、on_partial_timeout（セクション7.2）の部分的なボディ（ペイロードがない）を維持する必要があります（セクション7.2）。
In a request for any block number, an unset M bit indicates the request is just for that block. If the M bit is set, this has different meanings based on the NUM value:
ブロック番号の要求では、設定されていないMビットは要求がそのブロックのためのものであることを示します。Mビットが設定されている場合、これはNUM値に基づいて異なる意味があります。
NUM is zero: This is a request for the entire body.
numはゼロです。これは全体の要求です。
'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is used to confirm that the current MAX_PAYLOADS_SET (the latest block having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to send the next MAX_PAYLOADS_SET (the first block having block number NUM). This is the 'Continue' Q-Block-2 and conceptually has the same usage (i.e., continue sending the next set of data) as the use of 2.31 (Continue) for Q-Block1.
'num mox_payloads'はゼロです。次のMAX_PAYLOADS_SET（ブロック番号を持つ最初のブロック）を送信し続けます。これは 'Continue' Q Block-2であり、概念的にはQ-Block1の場合は2.31（続く）の使用として同じ使用法（すなわち、次のデータセットの送信を続ける）です。
Any other value of NUM: This is a request for that block and for all of the remaining blocks in the current MAX_PAYLOADS_SET.
その他のnum：これは、現在のMAX_PAYLOADS_SET内のそのブロックおよびすべての残りのブロックに対する要求です。
If the request includes multiple Q-Block2 options and these options overlap (e.g., combination of M being set (this and later blocks) and unset (this individual block)), resulting in an individual block being requested multiple times, the server MUST only send back one instance of that block. This behavior is meant to prevent amplification attacks.
要求に複数のQ-Block2オプションが含まれ、これらのオプションが重なっている場合（たとえば、設定されているMの組み合わせ（この個々のブロック）、（この個々のブロック））、個々のブロックが複数回要求されているため、サーバーのみが必要です。そのブロックのインスタンスを1つ戻ってください。この動作は増幅攻撃を防ぐためのものです。
The payloads sent back from the server as a response MUST all have the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The server MUST NOT use the same ETag value for different representations of a resource.
応答としてサーバーから返送されたペイロードはすべて同じ本文に対して同じETAG（[RFC7252]のセクション5.10.6）を持つ必要があります。サーバーは、リソースの異なる表現に同じETAG値を使用してはいけません。
The ETag is opaque, but the server MUST ensure that it is unique for every different body of transmitted data.
ETAGは不透明ですが、サーバーはそれがさまざまな送信データ本体に対して一意であることを確認する必要があります。
Implementation Note: It is suggested that the server treats the ETag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial ETag value should be randomly generated and then subsequently incremented by the server whenever a new body of data is being transmitted between peers.
実装注：サーバーがETAGを8バイトの符号なし整数として扱うことが示唆されています。実装は、パケットのオーバーヘッドサイズを減らすためにこれを4バイトに制限することを検討したいと思うかもしれません。初期のETAG値はランダムに生成され、その後新しいデータ本体がピア間で送信されているときはいつでもサーバーによって増分されるべきです。
Section 4.6 discusses the use of the Size2 option.
セクション4.6はsize2オプションの使用について説明しています。
The client may elect to request any detected missing blocks or just ignore the partial body. This decision is implementation specific.
クライアントは、検出された欠けているブロックを要求するか、部分本体を無視するだけでよい。この決定は実装固有です。
For NON payloads, the client SHOULD wait for NON_RECEIVE_TIMEOUT (Section 7.2) after the last received payload before requesting retransmission of any missing blocks. Retransmission is requested by issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2 options that define the missing block(s). Generally, the M bit on the Q-Block2 option(s) SHOULD be unset, although the M bit MAY be set to request this and later blocks from this MAX_PAYLOADS_SET; see Section 10.2.4 for an example of this in operation. Further considerations related to the transmission timing for missing requests are discussed in Section 7.2.
ペイロード以外の場合、不足しているブロックの再送信を要求する前に、最後の受信ペイロードの後に、クライアントはNon_Receive_timeout（セクション7.2）を待つ必要があります。再送は、欠落ブロックを定義する1つ以上のQ-Block2オプションを含むGET、POST、PUT、FETCH、PATCH、またはiPatch要求を発行することによって要求されます。一般に、Q-Block2オプションのMビットは設定解除されるべきですが、MビットはこのMAX_PAYLOADS_SETからこの後のブロックを要求するように設定されます。この動作の例については、10.2.4項を参照してください。欠けている要求の送信タイミングに関連するさらなる考慮事項は、セクション7.2で説明されている。
The missing block numbers requested by the client MUST have an increasing block number in each additional Q-Block2 option with no duplicates. The server SHOULD respond with a 4.00 (Bad Request) to requests not adhering to this behavior. Note that the ordering constraint is meant to force the client to check for duplicates and remove them. This also helps with troubleshooting.
クライアントによって要求された欠けているブロック番号は、重複しない追加のQ-Block2オプションごとに増加するブロック番号を持たなければなりません。サーバーは、この動作に付随していない要求を要求するために4.00（悪い要求）で応答する必要があります。注文制約は、クライアントに重複を確認して削除するように強制することを意味します。これはトラブルシューティングにも役立ちます。
If the client receives a duplicate block with the same ETag, it MUST silently ignore the payload.
クライアントが同じETAGを持つ重複ブロックを受信した場合、ペイロードを黙って無視する必要があります。
A client SHOULD maintain a partial body (missing payloads) for NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age option (or its default of 60 seconds (Section 5.6.1 of [RFC7252])), whichever is less. On release of the partial body, the client should then release all of the tokens used for this body apart from the token that is used to track a resource that is being observed.
クライアントは、non_partial_timeout（セクション7.2）またはmax-ageオプション（またはそのデフォルトの60秒の60秒）で定義されている部分的なボディ（ペイロードを欠いていない）を維持する必要があります。部分的な本体の解放時に、クライアントは、この本体に使用されているこの本体に使用されているすべてのトークンを、観察されているリソースを追跡するために使用されるトークンとは別に解除する必要があります。
The ETag option should not be used in the request for missing blocks, as the server could respond with a 2.03 (Valid) response with no payload. It can be used in the request if the client wants to check the freshness of the locally cached body response.
ペイロードなしでサーバーが2.03（有効な）応答で応答できるため、ETAGオプションは不足しているブロックの要求に使用しないでください。クライアントがローカルキャッシュされたボディレスポンスの鮮度をチェックしたい場合は、要求に使用できます。
The server SHOULD maintain a cached copy of the body when using the Q-Block2 option to facilitate retransmission of any missing payloads.
不足しているペイロードの再送信を容易にするために、q-block2オプションを使用するとき、サーバーはボディのキャッシュされたコピーを維持する必要があります。
If the server detects partway through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the old data, then the transmission is terminated. Any subsequent missing block requests MUST be responded to using the latest ETag and Size2 option values with the updated data.
サーバーがリソースデータが変更され、サーバーが古いデータのキャッシュされたコピーを維持していないボディ転送を介して壁を検出した場合、送信は終了します。更新されたデータを使用して、最新のETAGおよびSIZE2オプション値を使用して、後続の欠落しているブロック要求を応答する必要があります。
If the server responds during a body update with a different ETag option value (as the resource representation has changed), then the client should treat the partial body with the old ETag as no longer being fresh. The client may then request all of the new data by specifying Q-Block2 with block number '0' and the M bit set.
サーバーが異なるETAGオプション値を持つボディアップデート中に（リソース表現が変更されたときに）ボディアップデート中に応答した場合、クライアントはもう古いETAGで部分ボディを扱う必要があります。その後、クライアントは、ブロック番号 '0'およびMビットセットでQ-Block2を指定することによってすべての新しいデータを要求することができます。
If the server transmits a new body of data (e.g., a triggered Observe notification) with a new ETag to the same client as an additional response, the client should remove any partially received body held for a previous ETag for that resource, as it is unlikely the missing blocks can be retrieved.
サーバーが新しいEtagを追加の応答と同じクライアントに新しいETagを使用して新しいデータの新しいデータを送信する場合、クライアントはそのリソースの前のETAGに保持されている部分的に受信されたボディを削除する必要があります。欠けているブロックを取得できる可能性があります。
If there is insufficient space to create a response PDU with a block size of 16 bytes (SZX = 0) to send back all the response options as appropriate, a 4.13 (Request Entity Too Large) is returned without the Size1 option.
16バイトのブロックサイズ（SZX = 0）の応答PDUを作成するのに十分なスペースがない場合は、すべての応答オプションを適切に返送するために、4.13（リクエストエンティティが大きすぎます）がsize1オプションなしで返されます。
For Confirmable traffic, the server typically acknowledges the initial request using an Acknowledgment (ACK) with a piggybacked payload and then sends the subsequent payloads of the MAX_PAYLOADS_SET as CON responses. These CON responses are individually ACKed by the client. The server will detect failure to send a packet and SHOULD terminate the body transfer, but the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed.
確認可能なトラフィックの場合、サーバーは通常、PiggyBackedペイロードを使用して確認応答（ACK）を使用して初期要求を確認し、次にMAX_PAYLOADS_SETの後続のペイロードをCON応答として送信します。これらのCON応答は、クライアントによって個別に認識されています。サーバーはパケットの送信に失敗を検出し、ボディ転送を終了するが、クライアントはMAX_TRANSMIT_SPANの遅延後、必要に応じて不足しているブロックに対して別のGET、POST、PUT、FETCH、パッチ、またはiPatchを発行できます。
For a request that uses Q-Block1, the Observe value [RFC7641] MUST be the same for all the payloads of the same body. This includes any missing payloads that are retransmitted.
Qブロック1を使用する要求については、観測値[RFC7641]は同じ本体のすべてのペイロードで同じでなければなりません。これには、再送信された不足しているペイロードが含まれています。
For a response that uses Q-Block2, the Observe value MUST be the same for all the payloads of the same body. This is different from Block2 usage where the Observe value is only present in the first block (Section 3.4 of [RFC7959]). This includes payloads transmitted following receipt of the 'Continue' Q-Block2 option (Section 4.4) by the server. If a missing payload is requested by a client, then both the request and response MUST NOT include the Observe option.
Q-Block2を使用する応答の場合、監視値は同じ本体のすべてのペイロードに対して同じでなければなりません。これは、観測値が最初のブロックにのみ存在する場合のBlock2の使用とは異なります（[RFC7959]のセクション3.4）。これには、サーバーによる '続行' q-block2オプション（セクション4.4）の受信後に送信されたペイロードが含まれます。欠落しているペイロードがクライアントから要求された場合、要求と応答の両方に監視方法を含める必要があります。
Section 4 of [RFC7959] 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.
[RFC7959]のセクション4は、2つのCOAPオプションを定義します.SIZE1は、応答で転送された表現のサイズを示すための要求とサイズ2で転送された表現のサイズを示すためのサイズ1です。
For the Q-Block1 and Q-Block2 options, the Size1 or Size2 option values MUST exactly represent the size of the data on the body so that any missing data can easily be determined.
Q-Block1およびQ-Block2オプションの場合、SIZE1またはSIZE2オプション値は、欠損データが簡単に決定できるように、ボディ上のデータのサイズを正確に表す必要があります。
The Size1 option MUST be used with the Q-Block1 option when used in a request and MUST be present in all payloads of the request, preserving the same value. The Size2 option MUST be used with the Q-Block2 option when used in a response and MUST be present in all payloads of the response, preserving the same value.
size1オプションは、要求に使用されたときにq-block1オプションを使用して使用し、リクエストのすべてのペイロードに存在し、同じ値を保持する必要があります。size2オプションは、応答で使用されたときにq-block2オプションで使用する必要があり、同じ値を保持している応答のすべてのペイロードに存在する必要があります。
The behavior is similar to the one defined in Section 3.3 of [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 substituted for Block2.
この挙動は、Block1とQ-Block 2をブロック2に置き換えたQ-Block 1を除いて、[RFC7959]のセクション3.3で定義されているものと似ています。
Servers MUST ignore multicast requests that contain the Q-Block2 option. As a reminder, the Block2 option can be used as stated in Section 2.8 of [RFC7959].
サーバーは、q-block2オプションを含むマルチキャスト要求を無視する必要があります。リマインダーとして、[RFC7959]のセクション2.8で述べるようにBlock2オプションを使用できます。
The 4.08 (Request Entity Incomplete) response code has a new content type "application/missing-blocks+cbor-seq" used to indicate that the server has not received all of the blocks of the request body that it needs to proceed. Such messages must not be treated by the client as a fatal error.
4.08（要求エンティティ不完全）応答コードには、サーバーが続行する必要がある要求本文のすべてのブロックを受信していないことを示すために使用される新しいコンテンツタイプ「アプリケーション/不足ブロックCBOBOR-SEQ」があります。そのようなメッセージは、致命的なエラーとしてクライアントによって扱われてはいけません。
Likely causes are the client has not sent all blocks, some blocks were dropped during transmission, or the client sent them a long enough time ago that the server has already discarded them.
可能性がある原因が、クライアントがすべてのブロックを送信していない、送信中にいくつかのブロックが削除されたか、またはクライアントはサーバーがすでにそれらを破棄していることを十分に前に長く送信しました。
The new data payload of the 4.08 (Request Entity Incomplete) response with content type "application/missing-blocks+cbor-seq" is encoded as a Concise Binary Object Representation (CBOR) Sequence [RFC8742]. It comprises one or more missing block numbers encoded as CBOR unsigned integers [RFC8949]. The missing block numbers MUST be unique in each 4.08 (Request Entity Incomplete) response when created by the server; the client MUST ignore any duplicates in the same 4.08 (Request Entity Incomplete) response.
コンテンツタイプの「アプリケーション/ Missing-Blocks CBOBOR-SEQ」を使用した4.08（要求エンティティ不完全）応答の新しいデータペイロードは、簡潔なバイナリオブジェクト表現（CBOR）シーケンスとしてエンコードされています[RFC8742]。CBOBOR符号なし整数としてエンコードされている1つ以上の欠けているブロック番号を含みます[RFC8949]。不足しているブロック番号は、サーバーによって作成されたときに各4.08（要求エンティティの不完全）の応答で一意である必要があります。クライアントは、同じ4.08（要求エンティティの不完全な）応答で重複を無視する必要があります。
The Content-Format option (Section 5.10.3 of [RFC7252]) MUST be used in the 4.08 (Request Entity Incomplete) response. It MUST be set to "application/missing-blocks+cbor-seq" (Section 12.3).
4.08（Entity Entity Incomplete）応答では、content-formatオプション（[RFC7252]のセクション5.10.3）を使用する必要があります。「アプリケーション/ Missing-Blocks CBOBOR-SEQ」に設定する必要があります（セクション12.3）。
The Concise Data Definition Language (CDDL) [RFC8610] (and see Section 4.1 of [RFC8742]) for the data describing these missing blocks is as follows:
これらの欠けているブロックを記述するデータについては、簡潔なデータ定義言語（CDDL）[RFC8610]（そして[RFC8742]のセクション4.1）は次のとおりです。
; This defines an array, the elements of which are to be used
; in a CBOR Sequence:
payload = [+ missing-block-number]
; A unique block number not received:
missing-block-number = uint
Figure 1: Structure of the Missing Blocks Payload
図1：不足しているブロックのペイロードの構造
This CDDL syntax MUST be followed.
このCDDL構文に従う必要があります。
It is desirable that the token to use for the response is the token that was used in the last block number received so far with the same Request-Tag value. Note that the use of any received token with the same Request-Tag would be acceptable, but providing the one used in the last received payload will aid any troubleshooting. The client will use the token to determine what was the previously sent request to obtain the Request-Tag value that was used.
応答に使用するトークンは、同じ要求タグ値でこれまでに受信された最後のブロック番号で使用されたトークンであることが望ましいです。同じ要求タグを持つ受信されたトークンの使用は受け入れ可能であることに注意してください。クライアントはトークンを使用して、使用された要求タグ値を取得するために以前に送信された要求が何であるかを決定します。
If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined by Section 4.6 of [RFC7252], then the number of reported missing blocks MUST be limited so that the response can fit into a single packet. If this is the case, then the server can send subsequent 4.08 (Request Entity Incomplete) responses containing those additional missing blocks on receipt of a new request providing a missing payload with the same Request-Tag.
4.08（要求エンティティ不完全）応答パケットのサイズが[RFC7252]のセクション4.6で定義されているものよりも大きい場合、報告された欠落ブロックの数は制限されなければならないため、応答が単一のパケットに収まるようにする必要があります。この場合、サーバーは、同じ要求タグを持つ欠落ペイロードを提供する新しい要求を受信して、それらの追加の欠品ブロックを含む後続の4.08（要求エンティティ不完全）応答を送信できます。
The missing blocks MUST be reported in ascending order without any duplicates. The client SHOULD silently drop 4.08 (Request Entity Incomplete) responses not adhering to this behavior.
欠けているブロックは、重複しない昇順で報告する必要があります。クライアントは、この動作に従わない応答を静かに落として（要求エンティティの不完全な要求）。
Implementation Note: Consider limiting the number of missing payloads to MAX_PAYLOADS to minimize the need for congestion control. The CBOR Sequence does not include any array wrapper.
実装注：輻輳制御の必要性を最小限に抑えるために、MAX_PAYLOADSへの欠落の数を制限することを検討してください。CBORシーケンスにはアレイラッパーは含まれません。
A 4.08 (Request Entity Incomplete) response with content type "application/missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable requests or a reliable connection [RFC8323], as the client will be able to determine that there is a transmission failure of a particular payload and hence that the server is missing that payload.
クライアントが送信があると判断できるように、コンテンツタイプ「アプリケーション/不足ブロックCBOBOR-SEQ」を使用した4.08（アプリケーション/不足ブロックCBOBOR-SEQ "を使用しないでください。クライアントが送信があると判断できます。特定のペイロードの失敗、したがって、サーバーにペイロードがないことがわかります。
Each new request generally uses a new Token (and sometimes must; see Section 4 of [RFC9175]). Additional responses to a request all use the token of the request they respond to.
各新しい要求は一般に新しいトークンを使用しています（時には必要です。[RFC9175]のセクション4を参照）。リクエストに対する追加の応答はすべて応答するリクエストのトークンを使用します。
Implementation Note: By using 8-byte tokens, it is possible to easily minimize the number of tokens that have to be tracked by clients, by keeping the bottom 32 bits the same for the same body and the upper 32 bits containing the current body's request number (incrementing every request, including every retransmit). This alleviates the client's need to keep all the per-request state, e.g., per Section 3 of [RFC8974]. However, if using NoSec, Section 5.2 of [RFC8974] needs to be considered for security implications.
実装注：8バイトのトークンを使用することによって、同じボディのために同じボディで同じボディの要求を含む上位32ビットを同じボディで同じボトムビットを同じにすることで、クライアントによって追跡されなければならないトークンの数を簡単に最小化することができます。番号（すべての再送信を含むすべての要求を増やす）。これにより、クライアントが[RFC8974]のセクション3あたりのすべての要求期間を保持する必要がある必要性を軽減します。ただし、NOSECを使用する場合は、[RFC8974]のセクション5.2をセキュリティの影響について考慮する必要があります。
The transmission of all the blocks of a single body over an unreliable transport MUST either all be Confirmable or all be Non-confirmable. This is meant to simplify the congestion control procedure.
信頼できない輸送にわたる単一の本体のすべてのブロックの送信は、すべて確認可能であるか、またはすべて確認不可能です。これは、輻輳制御手順を単純化するためのものです。
As a reminder, there is no need for CoAP-specific congestion control for reliable transports [RFC8323].
リマインダーとして、信頼できる輸送のためのCOAP固有の輻輳制御は必要ありません[RFC8323]。
Congestion control for CON requests and responses is specified in Section 4.7 of [RFC7252]. In order to benefit from faster transmission rates, NSTART will need to be increased from 1. However, the other CON congestion control parameters will need to be tuned to cover this change. This tuning is not specified in this document, given that the applicability scope of the current specification assumes that all requests and responses using Q-Block1 and Q-Block2 will be Non-confirmable (Section 3.2) apart from the initial Q-Block functionality negotiation.
CON要求と応答の輻輳制御は[RFC7252]のセクション4.7で指定されています。高速伝送速度から恩恵を受けるためには、NSTARTは1から増やす必要があります。ただし、この変更をカバーするように他のCON輻輳制御パラメータを調整する必要があります。現在の仕様の適用可能性範囲がQ-Block1とQ-Block2を使用したすべての要求と応答が最初のQブロック機能ネゴシエーションとは別に確定できないと仮定して、この文書では指定されていません。。
Following the failure to transmit a packet due to packet loss after MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is implementation specific as to whether there should be any further requests for missing data.
MAX_TRANSMIT_SPAN時間後のパケット損失のためにパケットを送信しなかった後（[RFC7252]のセクション4.8.2）は、欠落データに対してさらに要求があるかどうかに関する実装です。
This document introduces the new parameters MAX_PAYLOADS, NON_TIMEOUT, NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
このドキュメントでは、新しいパラメータMAX_PAYLOADS、NON_TIMEOUT、NON_TIMEOUT_RANDOM、NON_RECEIVE_TIMEOUT、NON_MAX_RETRANSMIT、NON_PROBING_WAIT、およびNON_PARTIAL_TIMEOUT、および非パスワット_TIMEOUT（表3）を紹介します（表3）。
Note: Randomness may naturally be provided based on the traffic profile, how PROBING_RATE is computed (as this is an average), and when the peer responds. Randomness is explicitly added for some of the congestion control parameters to handle situations where everything is in sync when retrying.
注：ランダム性は、トラフィックプロファイル、Probing_Rateがどのように計算されているか（これが平均的なので）、およびピアが応答するときに自然に提供されることがあります。ランダム性は、リトライのときにすべてが同期している状況を処理するために、いくつかの輻輳制御パラメータのために明示的に追加されます。
MAX_PAYLOADS should be configurable with a default value of 10. Both CoAP endpoints MUST have the same value (otherwise, there will be transmission delays in one direction), and the value MAY be negotiated between the endpoints to a common value by using a higher-level protocol (out of scope of this document). This is the maximum number of payloads that can be transmitted at any one time.
MAX_PAYLOADSはデフォルト値10で構成可能である必要があります.COAPエンドポイントの両方が同じ値を持つ必要があります（そうでなければ、一方向に送信遅延があることがあります）、そして値は、より高い値を使用してエンドポイント間の値の間で値をネゴシエートさせることができます。レベルプロトコル（この文書の範囲外）。これは一度に送信できるペイロードの最大数です。
Note: The default value of 10 is chosen for reasons similar to those discussed in Section 5 of [RFC6928], especially given the target application discussed in Section 3.2.
注：デフォルト値は、[RFC6928]のセクション5で説明されているものと同様の理由で、特にセクション3.2で説明されているターゲットアプリケーションと同様の理由で選択されます。
NON_TIMEOUT is used to compute the delay between sending MAX_PAYLOADS_SET for the same body. By default, NON_TIMEOUT has the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]).
non_timeoutは、同じボディのMAX_PAYLOADS_SETの送信間の遅延を計算するために使用されます。デフォルトでは、non_timeoutにはack_timeoutと同じ値があります（[RFC7252]のセクション4.8）。
NON_TIMEOUT_RANDOM is the initial actual delay between sending the first two MAX_PAYLOADS_SETs of the same body. The same delay is then used between the subsequent MAX_PAYLOADS_SETs. It is a random duration (not an integral number of seconds) between NON_TIMEOUT and (NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to 1.5, as discussed in Section 4.8 of [RFC7252].
non_timeout_randomは、同じボディの最初の2つのmax_payloads_setsを送信する間の実際の実際の遅延です。次に、次のMAX_PAYLOADS_SETSの間で同じ遅延が使用されます。これは、non_timeoutと（non_timeout * ack_random_factor）の間のランダムな期間（整数秒数秒）です。[RFC7252]のセクション4.8で説明したように、ACK_RANDOM_FACTORは1.5に設定されています。
NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload before requesting retransmission for the first time. Every time the missing payload is re-requested, the Time-to-Wait value doubles. The time to wait is calculated as:
Non_Receive_Timeoutは、初めて再送信を要求する前に、欠落ペイロードを待つ初期時刻です。欠落ペイロードが再要求されるたびに、待機時間値は2倍になります。待機する時間は次のように計算されます。
Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))
NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT. NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT_RANDOM by at least one second so that the sender of the payloads has the opportunity to start sending the next MAX_PAYLOADS_SET before the receiver times out.
non_receive_timeoutには、デフォルト値が2倍以内です。非RECEIVE_TIMEOUTは常に少なくとも1秒ずつ常に大きくなければならず、ペイロードの送信者は、受信者がタイムアウトする前に次のMAX_PAYLOADS_SETの送信を開始する機会を持っている必要があります。
NON_MAX_RETRANSMIT is the maximum number of times a request for the retransmission of missing payloads can occur without a response from the remote peer. After this occurs, the local endpoint SHOULD consider the body stale, remove any body, and release the tokens and Request-Tag on the client (or the ETag on the server). By default, NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8 of [RFC7252]).
non_max_retransmitは、リモートピアからの応答なしに、欠落ペイロードの再送信要求が発生する可能性があります。これが発生した後、ローカルエンドポイントはボディストールを考慮して、任意のボディを削除し、クライアント（またはサーバー上のetag）のトークンと要求タグを解放する必要があります。デフォルトでは、non_max_retransmitにはmax_retransmitと同じ値があります（[RFC7252]のセクション4.8）。
NON_PROBING_WAIT is used to limit the potential wait needed when using PROBING_RATE. By default, NON_PROBING_WAIT is computed in a way similar to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with ACK_TIMEOUT, MAX_RETRANSMIT, and PROCESSING_DELAY substituted with NON_TIMEOUT, NON_MAX_RETRANSMIT, and NON_TIMEOUT_RANDOM, respectively:
on_probing_waitは、probing_rateを使用するときに必要な潜在的な待機を制限するために使用されます。デフォルトでは、non_probing_waitは、ack_timeout、max_retransmit、およびprocessing_delayがそれぞれnon_timeout、non_max_retransmit、およびnon_timeout_randomで置き換えられた方法で算出されます。
NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) *
ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT_RANDOM
NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. By default, NON_PARTIAL_TIMEOUT is computed in the same way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and NON_MAX_RETRANSMIT, respectively:
Non_Partial_Timeoutは、部分的に受信したボディの期限切れに使用されます。デフォルトでは、non_partial_timeoutはExchange_lifetime（[RFC7252]のセクション4.8.2）と同じ方法で計算されますが、それぞれnon_timeoutとnon_max_retransmitでack_timeoutとmax_retransmitを使用して、それぞれack_timeoutとmax_retransmitを使用しています。
NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) -
1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT
+=====================+===================+
| Parameter Name | Default Value |
+=====================+===================+
| MAX_PAYLOADS | 10 |
+---------------------+-------------------+
| NON_MAX_RETRANSMIT | 4 |
+---------------------+-------------------+
| NON_TIMEOUT | 2 s |
+---------------------+-------------------+
| NON_TIMEOUT_RANDOM | between 2-3 s |
+---------------------+-------------------+
| NON_RECEIVE_TIMEOUT | 4 s |
+---------------------+-------------------+
| NON_PROBING_WAIT | between 247-248 s |
+---------------------+-------------------+
| NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+-------------------+
Table 3: Congestion Control Parameters
表3：輻輳制御パラメータ
The PROBING_RATE parameter in CoAP indicates the average data rate that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. A single body will be subjected to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. If the wait time between sending bodies that are not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time is limited to NON_PROBING_WAIT.
COAPのprobing_rateパラメータは、応答しないピアエンドポイントに送信する際のCOAPエンドポイントによって超えてはいけない平均データレートを示します。単一の本体は、個々のパケットではなく、probing_rate（[RFC7252]のセクション4.7）を受ける。probing_rateに基づいて応答していない送信体間の待機時間がnon_probing_waitを超えている場合、待機時間はnon_probing_waitに制限されます。
Note: For the particular DOTS application, PROBING_RATE and other transmission parameters are negotiated between peers. Even when not negotiated, the DOTS application uses customized defaults, as discussed in Section 4.5.2 of [RFC9132]. Note that MAX_PAYLOADS, NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as per [DOTS-QUICK-BLOCKS]. When explicit values are configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these values are used without applying any jitter.
注：特定のドットアプリケーションの場合、Probing_Rateおよび他の送信パラメータはピア間でネゴシエートされます。ネゴシエートされていない場合でも、[RFC9132]のセクション4.5.2で説明したように、ドットアプリケーションはカスタマイズされたデフォルトを使用します。MAX_PAYLOADS、NON_MAX_RETRANSMIT、NON_TIMEOUT、NON_TIMEOUT、NON_PROBING_WAIT、およびNON_PARTIAL_TIMEOUTは、例えばドットピア間で交渉することができます。明示的な値がnon_probing_waitとnon_partial_timeoutに設定されている場合、これらの値はジッタを適用せずに使用されます。
Each NON 4.08 (Request Entity Incomplete) response is subject to PROBING_RATE.
各4.08以外の（要求エンティティ不完全）応答はprobing_rateの対象となります。
Each NON GET or FETCH request using a Q-Block2 option is subject to PROBING_RATE.
Q-Block2オプションを使用している各非取得またはフェッチ要求はprobing_rateの対象となります。
As the sending of many payloads of a single body may itself cause congestion, after transmission of every MAX_PAYLOADS_SET of a single body, a delay of NON_TIMEOUT_RANDOM MUST be introduced before sending the next MAX_PAYLOADS_SET, unless a 'Continue' is received from the peer for the current MAX_PAYLOADS_SET, in which case the next MAX_PAYLOADS_SET MAY start transmission immediately.
単一のボディの多数のペイロードの送信が輻輳を引き起こす可能性があるため、単一の本体のMAX_PAYLOADS_SETの送信後、「続行」がピアから受信されない限り、次のMAX_PAYLOADS_SETを送信する前にnon_timeout_randomの遅延を導入する必要があります。現在のMAX_PAYLOADS_SET。その場合、次のMAX_PAYLOADS_SETはすぐに送信を開始することがあります。
Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having 10 payloads, this corresponds to 1500 * 10 * 8 = 120 kbits. With a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates an average speed requirement of 60 kbps for a single body should there be no responses. This transmission rate is further reduced by being subject to PROBING_RATE.
注：1500バイトのパケットと10ペイロードを持つMAX_PAYLOADS_SETを仮定すると、これは1500 * 10 * 8 = 120キットに対応します。MAX_PAYLOADS_SETの間で2秒の遅延で、これは応答がない場合は単一のボディに対して60kbpsの平均速度要件を示します。この伝送速度は、プロービングを受けることによってさらに低減される。
The sending of a set of missing blocks of a body is restricted to those in a MAX_PAYLOADS_SET at a time. In other words, a NON_TIMEOUT_RANDOM delay is still observed between each MAX_PAYLOADS_SET.
本体の欠けているブロックのセットの送信は、一度にMAX_PAYLOADS_SET内のものに制限されています。言い換えれば、各MAX_PAYLOADS_SETの間で除外されていない遅延は依然として存在しています。
For the Q-Block1 option, if the server responds with a 2.31 (Continue) response code for the latest payload sent, then the client can continue to send the next MAX_PAYLOADS_SET without any further delay. If the server responds with a 4.08 (Request Entity Incomplete) response code, then the missing payloads SHOULD be retransmitted before going into another NON_TIMEOUT_RANDOM delay prior to sending the next set of payloads.
Q-Block1オプションの場合、サーバーが2.31（続行）されている場合（続き）送信された最新のペイロードの応答コードが、その後、クライアントはさらに遅延なしで次のMAX_PAYLOADS_SETを送信し続けることができます。サーバーが4.08（要求エンティティ不完全）応答コードで応答すると、次のペイロードのセットを送信する前に、不足しているペイロードを再送信する必要があります。
For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) response code on receipt of all of the MAX_PAYLOADS_SET to prevent the client unnecessarily delaying the transfer of remaining blocks. If not all of the MAX_PAYLOADS_SET were received, the server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload) before sending the 4.08 (Request Entity Incomplete) response code for the missing payload(s). If all of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) response code had been sent, but no more payloads were received for NON_RECEIVE_TIMEOUT (exponentially scaled), the server SHOULD send a 4.08 (Request Entity Incomplete) response detailing the missing payloads after the block number that was indicated in the sent 2.31 (Continue) response code. If the repeat response count of the 4.08 (Request Entity Incomplete) exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and stop requesting the missing payloads.
Q-Block1以外の要求を受信したサーバーの場合、クライアントが残りのブロックの転送を不必要に遅らせるのを防ぐために、すべてのMAX_PAYLOADS_SETを受信して2.31（続行）応答コードを送り返します。すべてのMAX_PAYLOADS_SETが受信されなかった場合は、4.08（Request Entity Incomplete）の応答コードがないペイロードを送信する前に、non_receive_timeout（ペイロードのリピート要求数に基づいて指数関数的にスケーリングされた）を遅らせる必要があります。 MAX_PAYLOADS_SETのすべてが受信され、2.31（続行）応答コードが送信されていましたが、以外のペイロードが受信されていない（指数関数的に拡大縮小されています）、サーバーは4.08（要求エンティティ不完全）応答をディテールした後に4.08（要求エンティティ不完全）応答を送信する必要があります。送信された2.31（続行）応答コードに示されたブロック番号。 4.08（要求エンティティ不完全）の繰り返し応答カウントがon_max_retransmitを超えると、サーバーは部分的な本文を破棄し、欠落ペイロードを要求するのをやめます。
It is likely that the client will start transmitting the next MAX_PAYLOADS_SET before the server times out on waiting for the last block of the previous MAX_PAYLOADS_SET. On receipt of a payload from the next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity Incomplete) response code indicating any missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity Incomplete) response code, the client SHOULD send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay prior to sending the next MAX_PAYLOADS_SET.
前のMAX_PAYLOADS_SETの最後のブロックを待って、サーバーがタイムアウトする前にクライアントが次のMAX_PAYLOADS_SETの送信を開始する可能性があります。次のMAX_PAYLOADS_SETからのペイロードを受信すると、サーバーは4.08（要求エンティティ不完全）応答コードを、以前のMAX_PAYLOADS_SETからの欠損ペイロードを示す応答コードを送信する必要があります。4.08（要求エンティティ不完全）応答コードを受信すると、クライアントは、MAX_PAYLOADS_SETの残りの部分を送信し続ける前に欠落ペイロードを送信し、次のMAX_PAYLOADS_SETを送信する前に別のnon_timeout_random遅延に入ります。
For the client receiving NON Q-Block2 responses, it SHOULD send a 'Continue' Q-Block2 request (Section 4.4) for the next MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET to prevent the server unnecessarily delaying the transfer of remaining blocks. Otherwise, the client SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload) before sending the request for the missing payload(s). If the repeat request count for a missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the partial body and stop requesting the missing payloads.
クライアントが非Q-Block2レスポンスを受信するには、すべてのMAX_PAYLOADS_SETを受信した次のMAX_PAYLOADS_SETの場合は、次のMAX_PAYLOADS_SETの場合は、残りのブロックの転送を不必要に遅らせるのを防ぐ必要があります。それ以外の場合、不足ペイロードの要求を送信する前に、クライアントはNon_Receive_timeout（ペイロードの繰り返し要求数に基づいて指数関数的に拡大縮小されます）を遅らせる必要があります。欠落ペイロードの繰り返し要求カウントがon_max_retransmitを超えると、クライアントは部分的な本文を破棄し、欠落ペイロードの要求を停止する必要があります。
The server SHOULD recognize the 'Continue' Q-Block2 request per the definition in Section 4.4 and just continue the transmission of the body (including the Observe option, if appropriate for an unsolicited response) rather than treat 'Continue' as a request for the remaining missing blocks.
サーバーはセクション4.4の定義ごとに「続く」Q-Block2要求を認識する必要があります。欠けているブロックの残り
It is likely that the server will start transmitting the next MAX_PAYLOADS_SET before the client times out on waiting for the last block of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of such a request, the server SHOULD send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay prior to sending the next MAX_PAYLOADS_SET.
サーバーは、前回のMAX_PAYLOADS_SETの最後のブロックを待つ前に、クライアントがタイムアウトする前に次のMAX_PAYLOADS_SETを送信し始める可能性があります。新しいMAX_PAYLOADS_SETからペイロードを受信すると、クライアントは、以前のMAX_PAYLOADS_SETから不足しているペイロードを示す要求を送信する必要があります。そのような要求を受信すると、サーバは、MAX_PAYLOADS_SETの残りを送信し続ける前に不足のペイロードを送信し、次のMAX_PAYLOADS_SETを送信する前に別のnon_timeout_random遅延に入ります。
The client does not need to acknowledge the receipt of the entire body.
クライアントは全身の受信を認識する必要はありません。
Note: If there is asymmetric traffic loss causing responses to never get received, a delay of NON_TIMEOUT_RANDOM after every transmission of MAX_PAYLOADS_SET will be observed. The endpoint receiving the body is still likely to receive the entire body.
注：非対称なトラフィック損失がある場合は、受信したことがないという応答が発生しない場合は、MAX_PAYLOADS_SETの送信後のNon_timeout_randomの遅延が観察されます。本体を受け取るエンドポイントはまだ体全体を受け取る可能性があります。
Caching block-based information is not straightforward in a proxy. For the Q-Block1 and Q-Block2 options, for simplicity, it is expected that the proxy will reassemble the body (using any appropriate recovery options for packet loss) before passing the body onward to the appropriate CoAP endpoint. This does not preclude an implementation doing a more complex per-payload caching, but how to do this is out of the scope of this document. The onward transmission of the body does not require the use of the Q-Block1 or Q-Block2 options, as these options may not be supported in that link. This means that the proxy must fully support the Q-Block1 and Q-Block2 options.
キャッシングブロックベースの情報は、プロキシでは簡単ではありません。Q-Block1およびQ-Block2のオプションの場合、単純さのために、プロキシはボディを適切なCOAPエンドポイントに渡す前に（パケット損失の適切な回復オプションを使用して）本体を再組み立てます。これは、ペイロードキャッシングごとにより複雑な実装を実行するのを妨げませんが、これを行う方法はこの文書の範囲外です。これらのオプションがそのリンクでサポートされていない可能性があるため、本体の順方向の送信はQ-Block1またはQ-Block2オプションの使用を必要としません。つまり、プロキシはQ-Block1とQ-Block2オプションを完全にサポートしている必要があります。
How the body is cached in the CoAP client (for Q-Block1 transmissions) or the CoAP server (for Q-Block2 transmissions) is implementation specific.
CoAPクライアント（Q-Block1トランスミッションの場合）またはCoAPサーバー（Q-Block2トランスミッションの場合）に本体がどのようにキャッシュされているか（Q-Block2送信用）は実装固有です。
As the entire body is being cached in the proxy, the Q-Block1 and Q-Block2 options are removed as part of the block assembly and thus do not reach the cache.
全体がプロキシにキャッシュされているので、Qブロック1とQ-Block2のオプションはブロックアセンブリの一部として削除され、したがってキャッシュに到達しません。
For Q-Block2 responses, the ETag option value is associated with the data (and transmitted onward to the CoAP client) but is not part of the cache key.
Q-Block2応答の場合、ETAGオプションの値はデータに関連付けられています（およびCoAPクライアントには進みます）がキャッシュキーの一部ではありません。
For requests with the Q-Block1 option, the Request-Tag option is associated with building the body from successive payloads but is not part of the cache key. For the onward transmission of the body using CoAP, a new Request-Tag SHOULD be generated and used. Ideally, this new Request-Tag should replace the Request-Tag used by the client.
q-block1オプションを指定した要求の場合、request-tagオプションは連続するペイロードから本体の構築に関連付けられていますが、キャッシュキーの一部ではありません。COAPを使用している本体の前方への送信のために、新しい要求タグを生成して使用する必要があります。理想的には、この新しい要求タグはクライアントによって使用される要求タグを置き換える必要があります。
It is possible that two or more CoAP clients are concurrently updating the same resource through a common proxy to the same CoAP server using the Q-Block1 (or Block1) option. If this is the case, the first client to complete building the body causes that body to start transmitting to the CoAP server with an appropriate Request-Tag value. When the next client completes building the body, any existing partial body transmission to the CoAP server is terminated, and the transmission of the new body representation starts with a new Request-Tag value. Note that it cannot be assumed that the proxy will always receive a complete body from a client.
2つ以上のCOAPクライアントが、Q-Block1（またはBlock1）オプションを使用して同じCOAPサーバーへの共通のプロキシを介して同じリソースを同時に更新している可能性があります。この場合、本体の構築を完了する最初のクライアントは、そのボディが適切な要求タグ値を持つCoApサーバーへの送信を開始します。次のクライアントが本体の構築を完了すると、CoAPサーバーへの既存の部分ボディ送信が終了し、新しいボディ表現の送信は新しい要求タグ値で始まります。プロキシが常にクライアントから完全な本文を受信すると想定することはできません。
A proxy that supports the Q-Block2 option MUST be prepared to receive a GET or similar request indicating one or more missing blocks. From its cache, the proxy will serve the missing blocks that are available in its cache in the same way a server would send all the appropriate Q-Block2 responses. If a body matching the cache key is not available in the cache, the proxy MUST request the entire body from the CoAP server using the information in the cache key.
q-block2オプションをサポートするプロキシは、1つ以上の欠けているブロックを示すGETまたは類似の要求を受信するように準備する必要があります。そのキャッシュから、プロキシは、サーバーがすべての適切なQ-Block2レスポンスを送信するのと同じ方法で、キャッシュ内で利用可能な不足ブロックを提供します。キャッシュキーと一致するボディがキャッシュ内で利用できない場合、プロキシはキャッシュキーの情報を使用してCoAPサーバーから本体全体を要求する必要があります。
How long a CoAP endpoint (or proxy) keeps the body in its cache is implementation specific (e.g., it may be based on Max-Age).
COAAエンドポイント（またはプロキシ）がそのキャッシュ内で本体をどのくらい保持しているか（例えば、最大年齢に基づいている可能性があります）。
As a reminder, the basic normative requirements on HTTP/CoAP mappings are defined in Section 10 of [RFC7252]. The implementation guidelines for HTTP/CoAP mappings are elaborated in [RFC8075].
リマインダーとして、HTTP / COAPマッピングの基本的な規範要件は[RFC7252]のセクション10で定義されています。HTTP / COAPマッピングの実装ガイドラインは[RFC8075]で詳しく説明されています。
The rules defined in Section 5 of [RFC7959] are to be followed.
[RFC7959]のセクション5で定義されている規則に従うべきです。
This section provides some sample flows to illustrate the use of the Q-Block1 and Q-Block2 options with NON. Examples with CON are provided in Appendix A.
このセクションでは、Q-Block1とQ-Block2オプションの使用を非表示にするためのサンプルフローをいくつか説明します。conの例は付録Aに提供されています。
The examples in the following subsections assume MAX_PAYLOADS is set to 10 and NON_MAX_RETRANSMIT is set to 4.
次のサブセクションの例では、max_payloadsが10に設定され、non_max_retransmitが4に設定されています。
The list below contains the conventions that are used in the figures in the following subsections.
以下のリストには、次のサブセクションの図で使用されている規則が含まれています。
T: Token value
t：トークン値
O: Observe option value
O：オプション値を守ってください
M: Message ID
M：メッセージID
RT: Request-Tag
RT：request-tag.
ET: ETag
ET：Etag
QB1: Q-Block1 option values NUM/More/Size
QB2: Q-Block2 option values NUM/More/Size
Size: Actual block size encoded in SZX
サイズ：SZXでエンコードされた実際のブロックサイズ
\: Trimming long lines
\:長い線をトリミングする
[[]]: Comments
[[]]：コメント
-->X: Message loss (request)
- > X：メッセージ損失（リクエスト）
X<--: Message loss (response)
X < - ：メッセージ損失（応答）
...: Passage of time
...： 時間の経過
Payload N: Corresponds to the CoAP message that conveys a block number (N-1) of a given block-wise exchange.
ペイロードN：与えられたブロック単位の交換のブロック番号（N-1）を伝えるCOAPメッセージに対応します。
Figure 2 depicts an example of a NON PUT request conveying the Q-Block1 option. All the blocks are received by the server.
図2は、Q-Block1オプションを伝える非PUTリクエストの例を示しています。すべてのブロックはサーバーによって受信されます。
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x81 T:0xc0 RT=9 QB1:0/1/1024
+--------->| NON PUT /path M:0x82 T:0xc1 RT=9 QB1:1/1/1024
+--------->| NON PUT /path M:0x83 T:0xc2 RT=9 QB1:2/1/1024
+--------->| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024
|<---------+ NON 2.04 M:0xf1 T:0xc3
| ... |
Figure 2: Example of a NON Request with the Q-Block1 option (without Loss)
図2：q-block1オプション（損失なし）を使用した非要求の例
Figure 3 depicts an example of a NON PUT request conveying the Q-Block1 option. The number of payloads exceeds MAX_PAYLOADS. All the blocks are received by the server.
図3は、Q-Block1オプションを伝達していない非PUTリクエストの例を示しています。ペイロードの数はmax_payloadsを超えています。すべてのブロックはサーバーによって受信されます。
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024
+--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024
[[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET receipt acknowledged by server]]
|<---------+ NON 2.31 M:0x81 T:0xfa
+--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024
|<---------+ NON 2.04 M:0x82 T:0xfb
| ... |
Figure 3: Example of a MAX_PAYLOADS NON Request with the Q-Block1 Option (without Loss)
図3：MAX_PAYLOADSの例q-block1オプション（損失なし）を使用した要求
Consider now a scenario where a new body of data is to be sent by the client, but some blocks are dropped in transmission, as illustrated in Figure 4.
図4に示すように、新しいデータの本体がクライアントによって送信されることになるシナリオであることを考慮してください。
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024
+--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024
+--------->| [[Payloads 3 - 8 not detailed]]
+--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024
+--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024
[[Some of the MAX_PAYLOADS_SET has been received]]
| ... |
[[NON_TIMEOUT_RANDOM (client) delay expires]]
| [[Client starts sending next MAX_PAYLOADS_SET]]
+--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024
+--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024
| |
Figure 4: Example of a MAX_PAYLOADS NON Request with the Q-Block1 Option (with Loss)
図4：MAX_PAYLOADSの例q-block1オプション（損失付き）
On seeing a payload from the next MAX_PAYLOADS_SET, the server realizes that some blocks are missing from the previous MAX_PAYLOADS_SET and asks for the missing blocks in one go (Figure 5). It does so by indicating which blocks from the previous MAX_PAYLOADS_SET have not been received in the data portion of the response (Section 5). The token used in the response should be the token that was used in the last received payload. The client can then derive the Request-Tag by matching the token with the sent request.
次のMAX_PAYLOADS_SETからペイロードを見て、サーバーは前のMAX_PAYLOADS_SETからいくつかのブロックが見つからないことを認識し、欠けているブロックを1行に依頼します（図5）。これは、前のMAX_PAYLOADS_SETからのブロックが応答のデータ部分で受信されていないことを示すことができる（セクション5）。応答で使用されているトークンは、最後の受信ペイロードで使用されたトークンです。その後、クライアントは、トークンを送信要求と一致させることによって要求タグを導出することができます。
CoAP CoAP
Client Server
| |
|<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9]
| [[Client responds with missing payloads]]
+--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024
+--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024
| [[Client continues sending next MAX_PAYLOADS_SET]]
+--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks
| for the missing one]]
|<---------+ NON 4.08 M:0x92 T:0xef [Missing 10]
+--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024
|<---------+ NON 2.04 M:0x93 T:0xf0
| ... |
Figure 5: Example of a NON Request with the Q-Block1 Option (Block Recovery)
図5：Q-Block1オプションを使用した要求の例（ブロックリカバリ）
Figure 6 depicts an example of a NON PUT request conveying the Q-Block1 option where recovery takes place but eventually fails.
図6は、リカバリが行われるが、最終的に失敗するQ-Block1オプションを伝達する非PUTリクエストの例を示しています。
CoAP CoAP
Client Server
| |
+--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024
+--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024
+--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is missing and asks
| for the missing one. Retry #1]]
|<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1]
| ... |
[[2 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks
| for the missing one. Retry #2]]
|<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1]
| ... |
[[4 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks
| for the missing one. Retry #3]]
|<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1]
| ... |
[[8 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks
| for the missing one. Retry #4]]
|<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1]
| ... |
[[16 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[NON_MAX_RETRANSMIT exceeded. Server stops requesting
| the missing blocks and releases partial body]]
| ... |
Figure 6: Example of a NON Request with the Q-Block1 Option (with Eventual Failure)
図6：q-block1オプションを使用した非要求の例（最終的な失敗を伴う）
These examples include the Observe option to demonstrate how that option is used. Note that the Observe option is not required for Q-Block2.
これらの例には、そのオプションがどのように使用されるかを示す観察オプションが含まれます。Q-Block 2には監視オプションは必要ありません。
Figure 7 illustrates an example of the Q-Block2 option. The client sends a NON GET carrying the Observe and Q-Block2 options. The Q-Block2 option indicates a block size hint (1024 bytes). The server replies to this request using four (4) blocks that are transmitted to the client without any loss. Each of these blocks carries a Q-Block2 option. The same process is repeated when an Observe is triggered, but no loss is experienced by any of the notification blocks.
図7は、q-block2オプションの例を示しています。クライアントは、観察者とQ-Block2のオプションを持ち運ぶ非取得を送信します。q-block2オプションは、ブロックサイズのヒント（1024バイト）を示します。サーバーは、損失なしでクライアントに送信される4つのブロックを使用してこの要求に応答します。これらのブロックのそれぞれはQ-Block2オプションを搭載しています。観察がトリガされると同じプロセスが繰り返されますが、どんな通知ブロックによっても損失はありません。
CoAP CoAP
Client Server
| |
+--------->| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf2 T:0xc0 O:1220 ET=19 QB2:1/1/1024
|<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024
|<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024
|<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024
|<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024
| ... |
Figure 7: Example of NON Notifications with the Q-Block2 Option (without Loss)
図7：q-block2オプションを使用した非通知の例（損失なし）
Figure 8 illustrates the same scenario as Figure 7, but this time with eleven (11) payloads, which exceeds MAX_PAYLOADS. There is no loss experienced.
図8は、図7と同じシナリオを示していますが、今回はMAX_PAYLOADSを超える11個のペイロードと同じです。紛失はありません。
CoAP CoAP
Client Server
| |
+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
|<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024
|<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024
|<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024
[[Body has been received]]
| ... |
Figure 8: Example of NON Notifications with the Q-Block2 Option (without Loss)
図8：q-block2オプションを使用した非通知の例（損失なし）
Figure 9 shows an example of an Observe that is triggered but for which some notification blocks are lost. The client detects the missing blocks and requests their retransmission. It does so by indicating the blocks that are missing as one or more Q-Block2 options.
図9は、トリガーされるがいくつかの通知ブロックが失われるという観察の例を示しています。クライアントは欠けているブロックを検出し、それらの再送信を要求します。それは、1つ以上のQ-Block2オプションとして欠落しているブロックを示すことによってそうします。
CoAP CoAP
Client Server
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
| X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024
[[Some of the MAX_PAYLOADS_SET has been received]]
| ... |
[[NON_TIMEOUT_RANDOM (server) delay expires]]
| [[Server sends next MAX_PAYLOADS_SET]]
|<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024
| [[On seeing a payload from the next MAX_PAYLOADS_SET,
| client realizes blocks are missing and asks for the
| missing ones in one go]]
+--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
| | QB2:9/0/1024
| X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024
| ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for
| missing block]]
+--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024
|<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024
[[Body has been received]]
| ... |
Figure 9: Example of NON Notifications with the Q-Block2 Option (Block Recovery)
図9：q-block2オプションを使用した非通知の例（ブロックリカバリ）
Figure 10 shows an example where an Observe is triggered but only the first two notification blocks reach the client. In order to retrieve the missing blocks, the client sends a request with a single Q-Block2 option with the M bit set.
図10は、観察がトリガされる例を示していますが、最初の2つの通知ブロックのみがクライアントに到達します。欠落しているブロックを取得するために、クライアントはMビットセットを使用して単一のQ-Block2オプションを持つ要求を送信します。
CoAP CoAP
Client Server
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024
|<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024
| X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024
| X<---+ [[Payloads 4 - 9 not detailed]]
| X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024
[[Some of the MAX_PAYLOADS_SET has been received]]
| ... |
[[NON_TIMEOUT_RANDOM (server) delay expires]]
| [[Server sends next MAX_PAYLOADS_SET]]
| X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes blocks are missing and asks for the
| missing ones in one go by setting the M bit]]
+--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024
|<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using 'Continue'
| Q-Block2]]
+--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024
|<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024
[[Body has been received]]
| ... |
Figure 10: Example of NON Notifications with the Q-Block2 Option (Block Recovery with the M Bit Set)
図10：q-block2オプションを使用した非通知の例（Mビットセットによるブロックリカバリ）
Figure 11 illustrates an example of a FETCH using both the Q-Block1 and Q-Block2 options along with an Observe option. No loss is experienced.
図11は、Q-Block1とQ-Block2の両方のオプションを使用した例を監視オプションとともに示します。損失はありません。
CoAP CoAP
Client Server
| |
+--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024
+--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024
+--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024
|<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024
|<---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024
|<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024
|<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024
|<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024
|<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024
|<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024
| ... |
Figure 11: Example of a NON FETCH with the Q-Block1 and Q-Block2 Options (without Loss)
図11：Q-Block1とQ-Block2のオプションを使用した非フェッチの例（損失なし）
Figure 12 illustrates the same scenario as Figure 11, but this time with eleven (11) payloads in both directions, which exceeds MAX_PAYLOADS. There is no loss experienced.
図12は、図11と同じシナリオを示していますが、この時間はMAX_PAYLOADSを超える双方向のPayloadsと同じです。紛失はありません。
CoAP CoAP
Client Server
| |
+--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024
+--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024
[[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by server]]
|<---------+ NON 2.31 M:0x80 T:0xa9
+--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024
|<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024
|<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]]
+--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024
|<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024
|<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]]
+--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024
|<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024
[[Body has been received]]
| ... |
Figure 12: Example of a NON FETCH with the Q-Block1 and Q-Block2 Options (without Loss)
図12：Q-Block1とQ-Block2のオプションを使用した非フェッチの例（損失なし）
Note that, as 'Continue' was used, the server continues to use the same token (0xaa), since the 'Continue' is not being used as a request for a new set of packets but rather is being used to instruct the server to continue its transmission (Section 7.2).
'continue'が使用されているように、 'continue'は新しいパケットのセットの要求として使用されていないが、サーバにサーバを指示するために使用されているので、サーバは同じトークン（0xAA）を使用し続けていることに注意してください。その伝送を続けます（7.2項）。
Consider now a scenario where some blocks are lost in transmission, as illustrated in Figure 13.
図13に示すように、いくつかのブロックが送信中に失われるシナリオであることを検討してください。
CoAP CoAP
Client Server
| |
+--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024
+--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024
+--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024
+--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]]
Figure 13: Example of a NON FETCH with the Q-Block1 and Q-Block2 Options (with Loss)
図13：Q-Block1とQ-Block2オプションを使用したフェッチの例（損失）
The server realizes that some blocks are missing and asks for the missing blocks in one go (Figure 14). It does so by indicating which blocks have not been received in the data portion of the response. The token used in the response is the token that was used in the last received payload. The client can then derive the Request-Tag by matching the token with the sent request.
サーバーは、いくつかのブロックが見つからないことを認識し、欠けているブロックを1つのGOに依頼します（図14）。応答のデータ部分にどのブロックが受信されていないかを示すことによってそうします。応答で使用されているトークンは、最後の受信ペイロードで使用されたトークンです。その後、クライアントは、トークンを送信要求と一致させることによって要求タグを導出することができます。
CoAP CoAP
Client Server
| |
|<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2]
| [[Client responds with missing payloads]]
+--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024
+--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024
| [[Server received FETCH body,
| starts transmitting response body]]
|<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024
| X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| |
Figure 14: Example of a NON Request with the Q-Block1 Option (Server Recovery)
図14：q-block1オプション（サーバーリカバリ）を使用した要求の例
The client realizes that not all the payloads of the response have been returned. The client then asks for the missing blocks in one go (Figure 15). Note that, following Section 2.7 of [RFC7959], the FETCH request does not include the Q-Block1 or any payload.
クライアントは、応答のすべてのペイロードが返されたわけではないことを認識しています。その後、クライアントは1つのGOに欠けているブロックを要求します（図15）。なお、[RFC7959]の[2.7]の下にある[RFC7959]に、Q-Block1またはペイロードは含まれていません。
CoAP CoAP
Client Server
| |
+--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\
| | QB2:3/0/1024
| [[Server receives FETCH request for missing payloads,
| starts transmitting missing blocks]]
| X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for
| missing block]]
+--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024
| [[Server receives FETCH request for missing payload,
| starts transmitting missing block]]
|<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024
[[Body has been received]]
| ... |
| [[Observe triggered]]
|<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024
|<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for
| missing block]]
+--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024
| [[Server receives FETCH request for missing payload,
| starts transmitting missing block]]
|<---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024
[[Body has been received]]
| ... |
Figure 15: Example of a NON Request with the Q-Block1 Option (Client Recovery)
図15：q-block1オプション（クライアントリカバリ）を使用した非要求の例
Security considerations discussed in Section 7 of [RFC7959] should be taken into account.
セキュリティ上の考慮事項[RFC7959]のセクション7で説明する必要があります。
Security considerations discussed in Sections 11.3 and 11.4 of [RFC7252] should also be taken into account.
セキュリティ上の考慮事項は、[RFC7252]のセクション11.3および11.4で説明したセキュリティ上の考慮事項も考慮に入れるべきです。
OSCORE provides end-to-end protection of all information that is not required for proxy operations and requires that a security context is set up (Section 3.1 of [RFC8613]). It can be trusted that the source endpoint is legitimate even if the NoSec mode is used. However, an intermediary node can modify the unprotected Outer Q-Block1 and/or Q-Block2 options to cause a Q-Block transfer to fail or keep requesting all the blocks by setting the M bit and thus causing attack amplification. As discussed in Section 12.1 of [RFC8613], applications need to consider that certain message fields and message types are not protected end to end and may be spoofed or manipulated. Therefore, it is NOT RECOMMENDED to use the NoSec mode if either the Q-Block1 or Q-Block2 option is used.
OSCOREは、プロキシ操作に必要ではないすべての情報を終了し、セキュリティコンテキストが設定されている必要がある（[RFC8613]のセクション3.1）。NOSECモードが使用されていても、ソースエンドポイントが正当なものであると信頼できます。ただし、中間ノードは、保護されていない外側Q-Block1および/またはQ-Block2オプションを変更して、Qブロック転送が失敗したり、Mビットを設定したりしてすべてのブロックを要求したりして攻撃増幅を引き起こしたりすることができます。[RFC8613]のセクション12.1で説明したように、アプリケーションは、特定のメッセージフィールドとメッセージタイプが保護されていないことを考慮する必要があり、スプーフィングまたは操作される可能性があります。したがって、Q-Block1またはQ-Block2オプションが使用されている場合は、NOSECモードを使用することはお勧めできません。
If OSCORE is not used, it is also NOT RECOMMENDED to use the NoSec mode if either the Q-Block1 or Q-Block2 option is used.
OSCOREが使用されていない場合は、Q-Block1またはQ-Block2オプションが使用されている場合は、NOSECモードを使用することもお勧めできません。
If NoSec is being used, Appendix D.5 of [RFC8613] discusses the security analysis and considerations for unprotected message fields even if OSCORE is not being used.
NOSECが使用されている場合、[RFC8613]の付録D.5は、OSCOREが使用されていない場合でも、保護されていないメッセージフィールドに対するセキュリティ分析と考慮事項について説明しています。
Security considerations related to the use of Request-Tag are discussed in Section 5 of [RFC9175].
Request-Tagの使用に関連するセキュリティ上の考慮事項は、[RFC9175]のセクション5で説明されています。
IANA has added the following entries to the "CoAP Option Numbers" subregistry [IANA-Options] defined in [RFC7252] within the "Constrained RESTful Environments (CoRE) Parameters" registry:
IANAは、[制約されたRESTFUL環境（コア）パラメータ]レジストリ内で[RFC7252]で定義されている[CoAPオプション番号]サブレジスト[IANAオプション]に次のようなエントリを追加しました。
+========+==========+===========+
| Number | Name | Reference |
+========+==========+===========+
| 19 | Q-Block1 | RFC 9177 |
+--------+----------+-----------+
| 31 | Q-Block2 | RFC 9177 |
+--------+----------+-----------+
Table 4: Additions to CoAP Option Numbers Registry
表4：COAPオプション番号レジストリの追加
IANA has registered the "application/missing-blocks+cbor-seq" media type in the "Media Types" registry [IANA-MediaTypes]. This registration follows the procedures specified in [RFC6838].
IANAは、「メディアタイプ」レジストリ[IANA-MEDIATYPES]に「アプリケーション/不足ブロックCBOR-SEQ」メディアタイプを登録しました。この登録は[RFC6838]で指定された手順に従います。
Type name: application
タイプ名：アプリケーション
Subtype name: missing-blocks+cbor-seq
サブタイプ名：Missing-Blocks CBOBOR-SEQ.
Required parameters: N/A
必要なパラメータ：N / A.
Optional parameters: N/A
オプションのパラメータ：n / A.
Encoding considerations: Must be encoded as a CBOR Sequence [RFC8742], as defined in Section 5 of RFC 9177.
符号化の考慮事項：RFC 9177のセクション5で定義されているように、CBORシーケンス[RFC8742]としてエンコードする必要があります。
Security considerations: See Section 11 of RFC 9177.
セキュリティ上の考慮事項：RFC 9177のセクション11を参照してください。
Interoperability considerations: N/A
相互運用性の考慮事項：N / A.
Published specification: RFC 9177
公開仕様：RFC 9177
Applications that use this media type: Data serialization and deserialization. In particular, the type is used by applications relying upon block-wise transfers, allowing a server to specify non-received blocks and request their retransmission, as defined in Section 4 of RFC 9177.
このメディアタイプを使用するアプリケーションデータの直列化と逆シリアライゼーション。特に、タイプはブロックごとの転送に依存しているアプリケーションによって使用され、サーバーはRFC 9177のセクション4で定義されているように、受信しないブロックを指定し、それらの再送信を要求します。
Fragment identifier considerations: N/A
フラグメント識別子の考慮事項：N / A.
Additional information: N/A
追加情報：N / A.
Person & email address to contact for further information: IETF, iesg@ietf.org
詳細については、連絡先のある人とEメールアドレス：IETF、iesg@ietf.org
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: none
使用法の制限：なし
Author: See Authors' Addresses section of RFC 9177.
著者：RFC 9177の「作者の住所」セクションを参照してください。
Change controller: IESG
変更コントローラ：IESG
Provisional registration? No
暫定登録？番号
IANA has registered the following CoAP Content-Format for the "application/missing-blocks+cbor-seq" media type in the "CoAP Content-Formats" registry [IANA-Format] defined in [RFC7252] within the "Constrained RESTful Environments (CoRE) Parameters" registry:
IANAは、[RFC7252]で定義されている[RFC7252]で定義されている[CoAP Content-Format]の「アプリケーション/不足ブロックCBOBOR-SEQ」メディアタイプに次のCOAAコンテンツ形式を登録しました。）パラメータ "レジストリ：
+=====================================+==========+=====+===========+
| Media Type | Encoding | ID | Reference |
+=====================================+==========+=====+===========+
| application/missing-blocks+cbor-seq | - | 272 | RFC 9177 |
+-------------------------------------+----------+-----+-----------+
Table 5: Addition to CoAP Content-Format Registry
表5：COAPコンテンツフォーマットレジストリの追加
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J.、およびT.Hansen、「メディア型仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：///www.rfc-editor.org/info/rfc6838>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K.、およびC. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-編集者。ORG / INFO / RFC7252>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<https：//www.rfc-editor.org/info/rfc7641>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann、C.およびZ. Shelby、ED。、「制約付きアプリケーションプロトコル（COAP）」、RFC 7959、DOI 10.17487 / RFC7959、<https：///www.rfc-editor.org/info/rfc7959>。
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)", RFC 8075, DOI 10.17487/RFC8075, February 2017, <https://www.rfc-editor.org/info/rfc8075>.
[RFC8075] Castellani、A.、Loreto、S.、Rahman、A.、Fossati、T.、およびE. Dijk、「マッピング実装のためのガイドライン：HTTPへのガイドライン：HTTP宛てのアプリケーションプロトコル（CoAP）」、RFC 8075、DOI 10.17487/ RFC8075、2017年2月、<https：//www.rfc-editor.org/info/rfc8075>。
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, <https://www.rfc-editor.org/info/rfc8132>.
[RFC8132] Van Der Stok、P.、Bormann、C.、およびA.Sehgal、「制約付きアプリケーションプロトコル（CoAP）」、RFC 8132、DOI 10.17487 / RFC8132、2017年4月、<HTTPS：//ww.rfc-editor.org/info/rfc8132>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B.、RFC 2119キーワードの「大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
[RFC8323] Bormann、C、LeMay、S.、Tschofenig、H.、Hartke、K.、Silverajan、B.、およびB.Raymor、Ed。、TCP、TLS、およびWebocketsの上のCOAP（制約付きアプリケーションプロトコル）"、RFC 8323、DOI 10.17487 / RFC8323、2018年2月、<https：//www.rfc-editor.org/info/rfc8323>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C. Bormann、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）とJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/ RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.
[RFC8613] Selander、G.、Mattsson、J.、Palombini、F.、およびL. Seitz、「制約のある安らかな環境のためのオブジェクトセキュリティ（OSCORE）」、RFC 8613、DOI 10.17487 / RFC8613、2019年7月、<https：//www.rfc-editor.org/info/rfc8613>。
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, <https://www.rfc-editor.org/info/rfc8742>.
[RFC8742] Bormann、C.、「CBOR）シーケンス」、RFC 8742、DOI 10.17487 / RFC8742、2020年2月、<https：//www.rfc-editor.org/info/rfc8742>。
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
[RFC8949] Bormann、C.およびP.HOFFMAN、「簡潔なバイナリオブジェクト表現（CBOR）」、STD 94、RFC 8949、DOI 10.17487 / RFC8949、2020年12月、<https：//www.rfc-editor.org/info/ RFC8949>。
[RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander, "Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing", RFC 9175, DOI 10.17487/RFC9175, February 2022, <https://www.rfc-editor.org/info/rfc9175>.
[RFC9175]Amsüss、C、PreußMattsson、J.、およびG. Selander、「制約付きアプリケーションプロトコル（CoAP）：エコー、要求タグ、およびトークン処理」、RFC 9175、DOI 10.17487 / RFC9175、2022年2月、<https://www.rfc-editor.org/info/rfc9175>。
[DOTS-QUICK-BLOCKS] Boucadair, M. and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission", Work in Progress, Internet-Draft, draft-bosh-dots-quick-blocks-03, 29 June 2021, <https://datatracker.ietf.org/doc/html/draft-bosh-dots-quick-blocks-03>.
[ドットクイックブロック] Boucadair、M.およびJ.Shallow、 "Robust Block Transmissionのための配布拒否オープン脅威シグナリング（ドット）信号チャネル構成属性"、進行中の作業、インターネットドラフト、ドラフトBOSH-dots-quick-03,03,29 6月29日、<https：//datatracker.ietf.org/doc/html/draft-bosh-dots-quick-blocks-03>
[DOTS-TELEMETRY] Boucadair, M., Ed., Reddy.K, T., Ed., Doron, E., Chen, M., and J. Shallow, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry", Work in Progress, Internet-Draft, draft-ietf-dots-telemetry-19, 4 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-19>.
[ドット - 遠隔測定] Boucadair、M.、Ed。、Reddy.K、T.、ED。、DORON、E.、CHEN、M.、J.Shallow、 "分散サービス拒否オープン脅威シグナリング（ドット）テレメトリ "）、進行中の作業、インターネットドラフト、ドラフト - IETF-DOTF-Telemetry-19,11月4日、<https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-19>。
[IANA-Format] IANA, "CoAP Content-Formats", <https://www.iana.org/assignments/core-parameters/>.
[IANA-FORMAT] IANA、「coap content-formats」、<https：//www.iana.org/assignments/core-parameters/>。
[IANA-MediaTypes] IANA, "Media Types", <https://www.iana.org/assignments/media-types/>.
[IANA-MEDIATYPES] IANA、「メディアタイプ」、<https：//www.iana.org/assignments/media-types/>。
[IANA-Options] IANA, "CoAP Option Numbers", <https://www.iana.org/assignments/core-parameters/>.
[IANA-OPTIONS] IANA、「COAPオプション番号」、<https：//www.iana.org/assignments/core-parameters/>。
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing TCP's Initial Window", RFC 6928, DOI 10.17487/RFC6928, April 2013, <https://www.rfc-editor.org/info/rfc6928>.
[RFC6928] Chu、J.、Dukkipati、N.、Cheng、Y.、およびM Mathis、「TCPの初期ウィンドウの増加」、RFC 6928、DOI 10.17487 / RFC6928、2013年4月、<https：///www.rfc-editor.org/info/rfc6928>。
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC7967] Bhattacharyya、A.、Bandyopadhyay、S.、Pal、A.、およびT. Bose、RFC 7967、DOI 10.17487 / RFC7967、2016年8月、<https//www.rfc-editor.org/info/rfc7967>。
[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, <https://www.rfc-editor.org/info/rfc8974>.
[RFC8974] Hartke、K.およびM. Richardson、「制約付きアプリケーションプロトコル（COAAP）」、RFC 8974、DOI 10.17487 / RFC8974、<https：///www.rfc-編集者の拡張トークンおよびステートレスクライアント。ORG / INFO / RFC8974>。
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K, "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification", RFC 9132, DOI 10.17487/RFC9132, September 2021, <https://www.rfc-editor.org/info/rfc9132>.
[RFC9132] Boucadair、M.、Ed。、浅い、J.、およびT.Reddy.k、「分散サービス拒否オープン脅威シグナリング（ドット）信号チャネル仕様」、RFC 9132、DOI 10.17487 / RFC9132、9月2021、<https://www.rfc-editor.org/info/rfc9132>。
The following examples assume NSTART has been increased to 3.
以下の実施例は、NSTARTが3に増加されたと仮定する。
The conventions provided in Section 10 are used in the following subsections.
第10節で提供されている規約は以下のサブセクションで使用されています。
Let's now consider the use of the Q-Block1 option with a CON request, as shown in Figure 16. All the blocks are acknowledged (as noted with "ACK").
図16に示すように、Q-Block1オプションの使用をCON要求で使用することを検討しましょう。すべてのブロックは確認されます（ "ACK"で説明されているように）。
CoAP CoAP
Client Server
| |
+--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024
+--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024
+--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
[[NSTART(3) limit reached]]
|<---------+ ACK 0.00 M:0x01
+--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
|<---------+ ACK 0.00 M:0x02
|<---------+ ACK 0.00 M:0x03
|<---------+ ACK 2.04 M:0x04
| |
Figure 16: Example of a CON Request with the Q-Block1 Option (without Loss)
図16：Q-Block1オプションを使用したCON要求の例（損失なし）
Now, suppose that a new body of data is to be sent but with some blocks dropped in transmission, as illustrated in Figure 17. The client will retry sending blocks for which no ACK was received.
さて、図17に示すように、新しいデータボディが送信されるべきであると仮定します。クライアントは、ACKが受信されなかったブロックを送信します。
CoAP CoAP
Client Server
| |
+--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024
+--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
[[NSTART(3) limit reached]]
|<---------+ ACK 0.00 M:0x05
+--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024
|<---------+ ACK 0.00 M:0x08
| ... |
[[ACK TIMEOUT (client) for M:0x06 delay expires]]
| [[Client retransmits packet]]
+--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
[[ACK TIMEOUT (client) for M:0x07 delay expires]]
| [[Client retransmits packet]]
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
|<---------+ ACK 0.00 M:0x06
| ... |
[[ACK TIMEOUT exponential backoff (client) delay expires]]
| [[Client retransmits packet]]
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
| ... |
[[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted]]
Figure 17: Example of a CON Request with the Q-Block1 Option (Block Recovery)
図17：q-block1オプションを使用したcon要求の例（ブロックリカバリ）
It is up to the implementation as to whether the application process stops trying to send this particular body of data on reaching MAX_RETRANSMIT for any payload or separately tries to initiate the new transmission of the payloads that have not been acknowledged under these adverse traffic conditions.
アプリケーションプロセスが、任意のペイロードのためにMAX_RETRANSMITに到達する上でこの特定のデータを送信しようとしているかどうかに関して実装次第で、または別途これらの有害トラフィック条件下で認識されていないペイロードの新しい送信を開始しようとします。
If transient network losses are possible, then the use of NON should be considered.
一時的なネットワーク損失が可能な場合は、非以外の使用を考慮する必要があります。
An example of the use of the Q-Block2 option with Confirmable messages is shown in Figure 18.
確認可能なメッセージを持つQ-Block2オプションの使用例を図18に示します。
Client Server
| |
+--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
|<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ CON 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ CON 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024
|<---------+ CON 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xe1
|--------->+ ACK 0.00 M:0xe2
|--------->+ ACK 0.00 M:0xe3
| ... |
| [[Observe triggered]]
|<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024
[[NSTART(3) limit reached]]
|--------->+ ACK 0.00 M:0xe4
|<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xe5
|--------->+ ACK 0.00 M:0xe6
|--------->+ ACK 0.00 M:0xe7
| ... |
| [[Observe triggered]]
|<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
[[NSTART(3) limit reached]]
|--------->+ ACK 0.00 M:0xe8
|<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xeb
| ... |
[[ACK TIMEOUT (server) for M:0xe9 delay expires]]
| [[Server retransmits packet]]
|<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
[[ACK TIMEOUT (server) for M:0xea delay expires]]
| [[Server retransmits packet]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
|--------->+ ACK 0.00 M:0xe9
| ... |
[[ACK TIMEOUT exponential backoff (server) delay expires]]
| [[Server retransmits packet]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
| ... |
[[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted]]
Figure 18: Example of CON Notifications with the Q-Block2 Option
図18：q-block2オプションを使用したCon通知の例
It is up to the implementation as to whether the application process stops trying to send this particular body of data on reaching MAX_RETRANSMIT for any payload or separately tries to initiate the new transmission of the payloads that have not been acknowledged under these adverse traffic conditions.
アプリケーションプロセスが、任意のペイロードのためにMAX_RETRANSMITに到達する上でこの特定のデータを送信しようとしているかどうかに関して実装次第で、または別途これらの有害トラフィック条件下で認識されていないペイロードの新しい送信を開始しようとします。
If transient network losses are possible, then the use of NON should be considered.
一時的なネットワーク損失が可能な場合は、非以外の使用を考慮する必要があります。
The conventions provided in Section 10 are used in the following subsections.
第10節で提供されている規約は以下のサブセクションで使用されています。
Let's now consider the use of the Q-Block1 option with a reliable transport, as shown in Figure 19. There is no acknowledgment of packets at the CoAP layer, just the final result.
図19に示すように、信頼できるトランスポートでQ-Block1オプションの使用を検討しましょう。CoAp層にパケットの確認応答はありません。最終結果だけです。
CoAP CoAP
Client Server
| |
+--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024
+--------->| PUT /path T:0xf1 RT=10 QB1:1/1/1024
+--------->| PUT /path T:0xf2 RT=10 QB1:2/1/1024
+--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024
|<---------+ 2.04
| |
Figure 19: Example of a Reliable Request with the Q-Block1 Option
図19：Q-Block1オプションを使用した信頼できる要求の例
If transient network losses are possible, then the use of unreliable transport with NON should be considered.
一時的なネットワーク損失が可能な場合は、非信頼性の低い輸送の使用を考慮する必要があります。
An example of the use of the Q-Block2 option with a reliable transport is shown in Figure 20.
信頼できる輸送を備えたQ-Block2オプションの使用例を図20に示します。
Client Server
| |
+--------->| GET /path T:0xf0 O:0 QB2:0/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:2/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024
| ... |
| [[Observe triggered]]
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:2/1/1024
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:3/0/1024
| ... |
Figure 20: Example of Notifications with the Q-Block2 Option
図20：Q-Block2オプションを使用した通知の例
If transient network losses are possible, then the use of unreliable transport with NON should be considered.
一時的なネットワーク損失が可能な場合は、非信頼性の低い輸送の使用を考慮する必要があります。
Acknowledgments
謝辞
Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their comments.
Achim Kraus、Jim Schaad、およびMichael Richardsonのコメントに感謝します。
Special thanks to Christian Amsüss, Carsten Bormann, and Marco Tiloca for their suggestions and several reviews, which improved this specification significantly. Thanks to Francesca Palombini for the AD review. Thanks to Pete Resnick for the Gen-ART review, Colin Perkins for the TSVART review, and Emmanuel Baccelli for the IOT-DIR review. Thanks to Martin Duke, Éric Vyncke, Benjamin Kaduk, Roman Danyliw, John Scudder, and Lars Eggert for the IESG review.
彼らの提案といくつかのレビューのために、クリスチャンアムスセス、Carsten Bormann、およびMarco Tilocaに感謝します。広告レビューのためのFrancesca Palombiniに感謝します。Gen-Art ReviewのためのPete Resnick、Tsvart Review用Colin Perkins、およびIoT-Dir Reviewのためのエマニュエルバッケリのおかげで。Martin Duke、Eric Vyncke、Benjamin Kaduk、Roman Danyylw、John Scudder、およびLARSのIESGレビューに感謝します。
Some text from [RFC7959] is reused for the readers' convenience.
[RFC7959]からのいくつかのテキストは読者の利便性に再利用されます。
Authors' Addresses
著者の住所
Mohamed Boucadair Orange 35000 Rennes France Email: mohamed.boucadair@orange.com
Mohamed Boucadair Orange 35000 Rennes Franceメール：Mohamed.boucadair@orange.com
Jon Shallow United Kingdom Email: supjps-ietf@jpshallow.com
Jon Shallow United Kingdom Eメール：supjps-ietf@jpshallow.com