rfc9177.txt   draft-ietf-core-new-block.txt 
Internet Engineering Task Force (IETF) M. Boucadair CoRE Working Group M. Boucadair
Request for Comments: 9177 Orange Internet-Draft Orange
Category: Standards Track J. Shallow Intended status: Standards Track J. Shallow
ISSN: 2070-1721 March 2022 Expires: November 26, 2021 May 25, 2021
Constrained Application Protocol (CoAP) Block-Wise Transfer Options Constrained Application Protocol (CoAP) Block-Wise Transfer Options
Supporting Robust Transmission Supporting Robust Transmission
draft-ietf-core-new-block-latest
Abstract Abstract
This document specifies alternative Constrained Application Protocol This document specifies alternative Constrained Application Protocol
(CoAP) block-wise transfer options: Q-Block1 and Q-Block2. (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.
These options are similar to, but distinct from, the CoAP Block1 and These options are similar to, but distinct from, the CoAP Block1 and
Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options
options are not intended to replace the Block1 and Block2 options but are not intended to replace Block1 and Block2 Options, but rather
rather have the goal of supporting Non-confirmable (NON) messages for have the goal of supporting Non-confirmable messages for large
large amounts of data with fewer packet interchanges. Also, the amounts of data with fewer packet interchanges. Also, the Q-Block1
Q-Block1 and Q-Block2 options support faster recovery should any of and Q-Block2 Options support faster recovery should any of the blocks
the blocks get lost in transmission. get lost in transmission.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is a product of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF). It represents the consensus of the IETF community. It has Task Force (IETF). Note that other groups may also distribute
received public review and has been approved for publication by the working documents as Internet-Drafts. The list of current Internet-
Internet Engineering Steering Group (IESG). Further information on Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Internet-Drafts are draft documents valid for a maximum of six months
and how to provide feedback on it may be obtained at and may be updated, replaced, or obsoleted by other documents at any
https://www.rfc-editor.org/info/rfc9177. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 26, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Simplified BSD License text as described in Section 4.e of
Trust Legal Provisions and are provided without warranty as described the Trust Legal Provisions and are provided without warranty as
in the Revised BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Alternative CoAP Block-Wise Transfer Options 3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 5
3.1. CoAP Response Code (4.08) Usage 3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 7
3.2. Applicability Scope 3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 7
4. The Q-Block1 and Q-Block2 Options 4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 8
4.1. Properties of the Q-Block1 and Q-Block2 Options 4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 8
4.2. Structure of the Q-Block1 and Q-Block2 Options 4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 10
4.3. Using the Q-Block1 Option 4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 11
4.4. Using the Q-Block2 Option 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 15
4.5. Using the Observe Option 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 17
4.6. Using the Size1 and Size2 Options 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 17
4.7. Using the Q-Block1 and Q-Block2 Options Together 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 18
4.8. Using the Q-Block2 Option with Multicast 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 18
5. The Use of the 4.08 (Request Entity Incomplete) Response Code 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 18
6. The Use of Tokens 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 19
7. Congestion Control for Unreliable Transports 7. Congestion Control for Unreliable Transports . . . . . . . . 20
7.1. Confirmable (CON) 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 20
7.2. Non-confirmable (NON) 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 20
8. Caching Considerations 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 25
9. HTTP Mapping Considerations 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 26
10. Examples with Non-confirmable Messages 10. Examples with Non-confirmable Messages . . . . . . . . . . . 26
10.1. Q-Block1 Option 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 27
10.1.1. A Simple Example 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 27
10.1.2. Handling MAX_PAYLOADS Limits 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 27
10.1.3. Handling MAX_PAYLOADS with Recovery 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 27
10.1.4. Handling Recovery if Failure Occurs 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 29
10.2. Q-Block2 Option 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 30
10.2.1. A Simple Example 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 30
10.2.2. Handling MAX_PAYLOADS Limits 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 31
10.2.3. Handling MAX_PAYLOADS with Recovery 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 32
10.2.4. Handling Recovery by Setting the M Bit 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 33
10.3. Q-Block1 and Q-Block2 Options 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 34
10.3.1. A Simple Example 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 34
10.3.2. Handling MAX_PAYLOADS Limits 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 35
10.3.3. Handling Recovery 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 36
11. Security Considerations 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12. IANA Considerations 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
12.1. CoAP Option Numbers Registry 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 39
12.2. Media Type Registration 12.2. Media Type Registration . . . . . . . . . . . . . . . . 39
12.3. CoAP Content-Formats Registry 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 40
13. References 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
13.1. Normative References 13.1. Normative References . . . . . . . . . . . . . . . . . . 41
13.2. Informative References 13.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Examples with Confirmable Messages Appendix A. Examples with Confirmable Messages . . . . . . . . . 43
A.1. Q-Block1 Option A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 43
A.2. Q-Block2 Option A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 45
Appendix B. Examples with Reliable Transports Appendix B. Examples with Reliable Transports . . . . . . . . . 47
B.1. Q-Block1 Option B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 47
B.2. Q-Block2 Option B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 47
Acknowledgments Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252], although The Constrained Application Protocol (CoAP) [RFC7252], although
inspired by HTTP, was designed to use UDP instead of TCP. The inspired by HTTP, was designed to use UDP instead of TCP. The
message layer of CoAP over UDP includes support for reliable message layer of CoAP over UDP includes support for reliable
delivery, simple congestion control, and flow control. CoAP supports delivery, simple congestion control, and flow control. CoAP supports
two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and two message types (Section 1.2 of [RFC7252]): Confirmable (CON) and
Non-confirmable (NON). Unlike NON messages, every CON message will Non-confirmable (NON) messages. Unlike NON messages, every CON
elicit an acknowledgment or a reset. message will elicit an acknowledgement or a reset.
The CoAP specification recommends that a CoAP message should fit The CoAP specification recommends that a CoAP message should fit
within a single IP packet (i.e., avoid IP fragmentation). To handle within a single IP packet (i.e., avoid IP fragmentation). To handle
data records that cannot fit in a single IP packet, [RFC7959] data records that cannot fit in a single IP packet, [RFC7959]
introduced the concept of block-wise transfers and the companion CoAP introduced the concept of block-wise transfer and the companion CoAP
Block1 and Block2 options. However, this concept is designed to work Block1 and Block2 Options. However, this concept is designed to work
exclusively with Confirmable messages (Section 1 of [RFC7959]). Note exclusively with Confirmable messages (Section 1 of [RFC7959]). Note
that the block-wise transfer was further updated by [RFC8323] for use that the block-wise transfer was further updated by [RFC8323] for use
over TCP, TLS, and WebSockets. over TCP, TLS, and WebSockets.
The CoAP Block1 and Block2 options work well in environments where The CoAP Block1 and Block2 Options work well in environments where
there are no, or minimal, packet losses. These options operate there are no, or minimal, packet losses. These options operate
synchronously, i.e., each individual block has to be requested. A synchronously, i.e., each individual block has to be requested. A
CoAP endpoint can only ask for (or send) the next block when the CoAP endpoint can only ask for (or send) the next block when the
transfer of the previous block has completed. The packet transfer of the previous block has completed. Packet transmission
transmission rate, and hence the block transmission rate, is rate, and hence block transmission rate, is controlled by Round Trip
controlled by Round-Trip Times (RTTs). Times (RTTs).
There is a requirement for blocks of data larger than a single IP There is a requirement for blocks of data larger than a single IP
datagram to be transmitted under network conditions where there may datagram to be transmitted under network conditions where there may
be asymmetrical transient packet loss (e.g., acknowledgment responses be asymmetrical transient packet loss (e.g., acknowledgment responses
may get dropped). An example is when a network is subject to a 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 Distributed Denial of Service (DDoS) attack and there is a need for
DDoS mitigation agents relying upon CoAP to communicate with each DDoS mitigation agents relying upon CoAP to communicate with each
other (e.g., [RFC9132] [DOTS-TELEMETRY]). As a reminder, [RFC7959] other (e.g., [RFC8782][I-D.ietf-dots-telemetry]). As a reminder,
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]).
This document introduces the CoAP Q-Block1 and Q-Block2 options, [RFC7959] recommends the use of CON responses to handle potential
which allow block-wise transfers to work with a series of Non- packet loss. However, such a recommendation does not work with a
confirmable messages instead of lock-stepping using Confirmable flooded pipe DDoS situation (e.g., [RFC8782]).
messages (Section 3). In other words, this document provides a
missing piece of [RFC7959], namely the support of block-wise This document introduces the CoAP Q-Block1 and Q-Block2 Options which
transfers using Non-confirmable messages where an entire body of data allow block-wise transfer to work with series of Non-confirmable
can be transmitted without the requirement that intermediate messages, instead of lock-stepping using Confirmable messages
acknowledgments be received from the peer (but recovery is available (Section 3). In other words, this document provides a missing piece
should it be needed). of [RFC7959], namely the support of block-wise transfer using Non-
confirmable 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).
Similar to [RFC7959], this specification does not remove any of the Similar to [RFC7959], this specification does not remove any of the
constraints posed by the base CoAP specification [RFC7252] it is constraints posed by the base CoAP specification [RFC7252] it is
strictly layered on top of. strictly layered on top of.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Readers should be familiar with the terms and concepts defined in Readers should be familiar with the terms and concepts defined in
[RFC7252], [RFC7959], and [RFC8132]. Particularly, the document uses [RFC7252], [RFC7959], and [RFC8132]. Particularly, the document uses
the following key concepts: the following key concepts:
Token: used to match responses to requests independently from the Token: is used to match responses to requests independently from the
underlying messages (Section 5.3.1 of [RFC7252]). underlying messages (Section 5.3.1 of [RFC7252]).
ETag: used as a resource-local identifier for differentiating ETag: is used as a resource-local identifier for differentiating
between representations of the same resource that vary over time between representations of the same resource that vary over time
(Section 5.10.6 of [RFC7252]). (Section 5.10.6 of [RFC7252]).
The terms "payload" and "body" are defined in [RFC7959]. The term The terms "payload" and "body" are defined in [RFC7959]. The term
"payload" is thus used for the content of a single CoAP message "payload" is thus used for the content of a single CoAP message
(i.e., a single block being transferred), while the term "body" is (i.e., a single block being transferred), while the term "body" is
used for the entire resource representation that is being transferred used for the entire resource representation that is being transferred
in a block-wise fashion. in a block-wise fashion.
Request-Tag refers to an option that allows a CoAP server to match Request-Tag refers to an option that allows a CoAP server to match
message fragments belonging to the same request [RFC9175]. message fragments belonging to the same request
[I-D.ietf-core-echo-request-tag].
MAX_PAYLOADS is the maximum number of payloads that can be MAX_PAYLOADS is the maximum number of payloads that can be
transmitted at any one time. transmitted at any one time.
MAX_PAYLOADS_SET is the set of blocks identified by block numbers MAX_PAYLOADS_SET is the set of blocks identified by block numbers
that, when divided by MAX_PAYLOADS, have the same numeric result. 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 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 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 size, there could be fewer than MAX_PAYLOADS blocks in the final
MAX_PAYLOADS_SET. MAX_PAYLOADS_SET.
3. Alternative CoAP Block-Wise Transfer Options 3. Alternative CoAP Block-Wise Transfer Options
This document introduces the CoAP Q-Block1 and Q-Block2 options. This document introduces the CoAP Q-Block1 and Q-Block2 Options.
These options are designed to work in particular with NON requests These options are designed to work in particular with NON requests
and responses. and responses.
Using NON messages, faster transmissions can occur, as all the blocks Using NON messages, faster transmissions can occur as all the blocks
can be transmitted serially (akin to fragmented IP packets) without can be transmitted serially (akin to fragmented IP packets) without
having to wait for a response or next request from the remote CoAP having to wait for a response or next request from the remote CoAP
peer. Recovery of missing blocks is faster in that multiple missing peer. Recovery of missing blocks is faster in that multiple missing
blocks can be requested in a single CoAP message. Even if there is 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 asymmetrical packet loss, a body can still be sent and received by
the peer whether the body comprises a single payload or multiple the peer whether the body comprises a single or multiple payloads,
payloads, assuming no recovery is required. assuming no recovery is required.
A CoAP endpoint can acknowledge all or a subset of the blocks. A CoAP endpoint can acknowledge all or a subset of the blocks.
Concretely, the receiving CoAP endpoint either informs the sending Concretely, the receiving CoAP endpoint either informs the CoAP
CoAP endpoint of successful reception or reports on all blocks in the sender endpoint of successful reception or reports on all blocks in
body that have not yet been received. The sending CoAP endpoint will the body that have not yet been received. The CoAP sender endpoint
then retransmit only the blocks that have been lost in transmission. will then retransmit only the blocks that have been lost in
transmission.
Note that similar transmission rate benefits can be applied to Note that similar transmission rate benefits can be applied to
Confirmable messages if the value of NSTART is increased from 1 Confirmable messages if the value of NSTART is increased from 1
(Section 4.7 of [RFC7252]). However, the use of Confirmable messages (Section 4.7 of [RFC7252]). However, the use of Confirmable messages
will not work effectively if there is asymmetrical packet loss. Some will not work effectively if there is asymmetrical packet loss. Some
examples with Confirmable messages are provided in Appendix A. examples with Confirmable messages are provided in Appendix A.
There is little, if any, benefit of using these options with CoAP There is little, if any, benefit of using these options with CoAP
running over a reliable connection [RFC8323]. In this case, there is running over a reliable connection [RFC8323]. In this case, there is
no differentiation between CON and NON, as they are not used. Some no differentiation between CON and NON as they are not used. Some
examples using a reliable transport are provided in Appendix B. examples using a reliable transport are provided in Appendix B.
The Q-Block1 and Q-Block2 options are similar in operation to the Q-Block1 and Q-Block2 Options are similar in operation to the CoAP
CoAP Block1 and Block2 options, respectively. They are not a Block1 and Block2 Options, respectively. They are not a replacement
replacement for them but have the following benefits: for them, but have the following benefits:
* They can operate in environments where packet loss is highly o They can operate in environments where packet loss is highly
asymmetrical. asymmetrical.
* They enable faster transmissions of sets of blocks of data with o They enable faster transmissions of sets of blocks of data with
fewer packet interchanges. fewer packet interchanges.
* They support faster recovery should any of the blocks get lost in o They support faster recovery should any of the blocks get lost in
transmission. transmission.
* They support sending an entire body using NON messages without o They support sending an entire body using NON messages without
requiring that an intermediate response be received from the peer. requiring that an intermediate response be received from the peer.
The disadvantages of using the CoAP Block1 and Block2 options are as There are the following disadvantages over using CoAP Block1 and
follows: Block2 Options:
* There is a loss of lock-stepping, so payloads are not always o Loss of lock-stepping so payloads are not always received in the
received in the correct order (blocks in ascending order). correct (block ascending) order.
* Additional congestion control measures need to be put in place for o Additional congestion control measures need to be put in place for
NON messages (Section 7.2). NON messages (Section 7.2).
* To reduce the transmission times for CON transmissions of large o To reduce the transmission times for CON transmission of large
bodies, NSTART needs to be increased from 1, but this affects bodies, NSTART needs to be increased from 1, but this affects
congestion control and incurs a requirement to retune other congestion control and incurs a requirement to re-tune other
parameters (Section 4.7 of [RFC7252]). Such tuning is out of parameters (Section 4.7 of [RFC7252]). Such tuning is out of
scope of this document. scope of this document.
* Mixing of NON and CON during an exchange of requests/responses o Mixing of NON and CON during requests/responses using Q-Block is
using Q-Block options is not supported. not supported.
* The Q-Block options do not support stateless operation/random o The Q-Block Options do not support stateless operation/random
access. access.
* Proxying of Q-Block options is limited to caching full o Proxying of Q-Block is limited to caching full representations.
representations.
* There is no multicast support. o There is no multicast support.
The Q-Block1 and Q-Block2 options can be used instead of the Block1 Q-Block1 and Q-Block2 Options can be used instead of Block1 and
and Block2 options when the different transmission properties are Block2 Options when the different transmission properties are
required. If the new options are not supported by a peer, then required. If the new options are not supported by a peer, then
transmissions can fall back to using the Block1 and Block2 options transmissions can fall back to using Block1 and Block2 Options
(Section 4.1). (Section 4.1).
The deviations from the Block1 and Block2 options are specified in The deviations from Block1 and Block2 Options are specified in
Section 4. Pointers to the appropriate sections in [RFC7959] are Section 4. Pointers to appropriate [RFC7959] sections are provided.
provided.
The specification refers to the base CoAP methods defined in The specification refers to the base CoAP methods defined in
Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and
iPATCH, which are introduced in [RFC8132]. iPATCH introduced in [RFC8132].
The No-Response option [RFC7967] was considered but was abandoned, as The No-Response Option [RFC7967] was considered but was abandoned as
it does not apply to Q-Block2 responses. A unified solution is it does not apply to Q-Block2 responses. A unified solution is
defined in the document. defined in the document.
3.1. CoAP Response Code (4.08) Usage 3.1. CoAP Response Code (4.08) Usage
This document adds a media type for the 4.08 (Request Entity This document adds a media type for the 4.08 (Request Entity
Incomplete) response defining an additional message format for Incomplete) response defining an additional message format for
reporting on payloads using the Q-Block1 option that are not received reporting on payloads using the Q-Block1 Option that are not received
by the server. by the server.
See Section 5 for more details. See Section 5 for more details.
3.2. Applicability Scope 3.2. Applicability Scope
The block-wise transfer specified in [RFC7959] covers the general The block-wise transfer specified in [RFC7959] covers the general
case using Confirmable messages but falls short in situations where case using Confirmable messages, but falls short in situations where
packet loss is highly asymmetrical or there is no need for an packet loss is highly asymmetrical or there is no need for an
acknowledgment. In other words, there is a need for Non-confirmable acknowledgement. In other words, there is a need for Non-confirmable
support. support.
The mechanism specified in this document provides roughly similar The mechanism specified in this document provides roughly similar
features to the Block1/Block2 options. It provides additional features to the Block1/Block2 Options. It provides additional
properties that are tailored towards the intended use case of Non- properties that are tailored towards the intended use case of Non-
confirmable transmission. Concretely, this mechanism primarily confirmable transmission. Concretely, this mechanism primarily
targets applications, such as DDoS Open Threat Signaling (DOTS), that targets applications such as DDoS Open Threat Signaling (DOTS) that
cannot use CON requests/responses because of potential packet loss cannot use CON requests/responses because of potential packet loss
and that support application-specific mechanisms to assess whether and that support application-specific mechanisms to assess whether
the remote peer is not overloaded and thus is able to process the the remote peer is not overloaded and thus is able to process the
messages sent by a CoAP endpoint (e.g., DOTS heartbeats in messages sent by a CoAP endpoint (e.g., DOTS heartbeats in
Section 4.7 of [RFC9132]). Other use cases are when an application Section 4.7 of [RFC8782]). Other use cases are when an application
sends data but has no need for an acknowledgment of receipt and any sends data but has no need for an acknowledgement of receipt and, any
data transmission loss is not critical. data transmission loss is not critical.
The mechanism includes guards to prevent a CoAP agent from The mechanism includes guards to prevent a CoAP agent from
overloading the network by adopting an aggressive sending rate. overloading the network by adopting an aggressive sending rate.
These guards MUST be followed in addition to the existing CoAP These guards MUST be followed in addition to the existing CoAP
congestion control, as specified in Section 4.7 of [RFC7252]. See congestion control as specified in Section 4.7 of [RFC7252]. See
Section 7 for more details. Section 7 for more details.
Any usage outside the primary use case of Non-confirmable messages Any usage outside the primary use case of Non-confirmable with block
with block transfers should be carefully weighed against the transfers should be carefully weighed against the potential loss of
potential loss of interoperability with generic CoAP applications interoperability with generic CoAP applications (See the
(see the disadvantages listed in Section 3). It is hoped that the disadvantages listed in Section 3). It is hoped that the experience
experience gained with this mechanism can feed future extensions of gained with this mechanism can feed future extensions of the block-
the block-wise mechanism that will both be generally applicable and wise mechanism that will both be generally applicable and serve this
serve this particular use case. particular use case.
It is not recommended that these options are used in the "NoSec" It is not recommended that these options are used in a NoSec security
security mode (Section 9 of [RFC7252]), as the source endpoint needs mode (Section 9 of [RFC7252]) as the source endpoint needs to be
to be trusted. Using Object Security for Constrained RESTful trusted. Using OSCORE [RFC8613] does provide a security context and,
Environments (OSCORE) [RFC8613] does provide a security context and hence, a trust of the source endpoint that prepared the inner OSCORE
hence a trust of the source endpoint that prepared the inner OSCORE content. However, even with OSCORE, using a NoSec security mode with
content. However, even with OSCORE, using the NoSec mode with these these options may still be inadequate, for reasons discussed in
options may still be inadequate, for reasons discussed in Section 11. Section 11.
4. The Q-Block1 and Q-Block2 Options 4. The Q-Block1 and Q-Block2 Options
4.1. Properties of the Q-Block1 and Q-Block2 Options 4.1. Properties of Q-Block1 and Q-Block2 Options
The properties of the Q-Block1 and Q-Block2 options are shown in 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 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 Table 4 of [RFC7252] (Section 5.10). The C, U, N, and R columns
indicate the properties Critical, UnSafe, NoCacheKey, and Repeatable, indicate the properties Critical, UnSafe, NoCacheKey, and Repeatable
which are defined in Section 5.4 of [RFC7252]. Only the Critical and defined in Section 5.4 of [RFC7252]. Only Critical and UnSafe
UnSafe columns are marked for the Q-Block1 option. The Critical, columns are marked for the Q-Block1 Option. Critical, UnSafe, and
UnSafe, and Repeatable columns are marked for the Q-Block2 option. Repeatable columns are marked for the Q-Block2 Option. As these
As these options are UnSafe, NoCacheKey has no meaning and so is options are UnSafe, NoCacheKey has no meaning and so is marked with a
marked with a dash. dash.
+=====+===+===+===+===+==========+========+========+=========+ +--------+---+---+---+---+--------------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default | | Number | C | U | N | R | Name | Format | Length | Default |
+=====+===+===+===+===+==========+========+========+=========+ +========+===+===+===+===+==============+========+========+=========+
| 19 | x | x | - | | Q-Block1 | uint | 0-3 | (none) | | TBA1 | x | x | - | | Q-Block1 | uint | 0-3 | (none) |
+-----+---+---+---+---+----------+--------+--------+---------+ | TBA2 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) |
| 31 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) | +--------+---+---+---+---+--------------+--------+--------+---------+
+-----+---+---+---+---+----------+--------+--------+---------+
Table 1: CoAP Q-Block1 and Q-Block2 Option Properties Table 1: CoAP Q-Block1 and Q-Block2 Option Properties
The Q-Block1 and Q-Block2 options can be present in both the request 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 and response messages. The Q-Block1 Option pertains to the request
payload, and the Q-Block2 option pertains to the response payload. payload and the Q-Block2 Option pertains to the response payload.
When the Content-Format option is present together with the Q-Block1 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 or Q-Block2 Option, the option applies to the body not to the payload
payload (i.e., it must be the same for all payloads of the same (i.e., it must be the same for all payloads of the same body).
body).
The Q-Block1 option is useful with the payload-bearing (e.g., POST, The Q-Block1 Option is useful with the payload-bearing, e.g., POST,
PUT, FETCH, PATCH, and iPATCH) requests and their responses. PUT, FETCH, PATCH, and iPATCH requests and their responses.
The Q-Block2 option is useful, for example, with GET, POST, PUT, The Q-Block2 Option is useful, e.g., with GET, POST, PUT, FETCH,
FETCH, PATCH, and iPATCH requests and their payload-bearing responses PATCH, and iPATCH requests and their payload-bearing responses
(response codes 2.01, 2.02, 2.04, and 2.05) (Section 5.5 of (response codes 2.01, 2.02, 2.04, and 2.05) (Section 5.5 of
[RFC7252]). [RFC7252]).
A CoAP endpoint (or proxy) MUST support either both or neither of the A CoAP endpoint (or proxy) MUST support either both or neither of the
Q-Block1 and Q-Block2 options. Q-Block1 and Q-Block2 Options.
If the Q-Block1 option is present in a request or the Q-Block2 option 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 is returned in a response, this indicates a block-wise transfer and
describes how this specific block-wise payload forms part of the describes how this specific block-wise payload forms part of the
entire body being transferred. If it is present in the opposite entire body being transferred. If it is present in the opposite
direction, it provides additional control on how that payload will be direction, it provides additional control on how that payload will be
formed or was processed. formed or was processed.
To indicate support for Q-Block2 responses, the CoAP client MUST To indicate support for Q-Block2 responses, the CoAP client MUST
include the Q-Block2 option in a GET or similar request (e.g., include the Q-Block2 Option in a GET or similar request (FETCH, for
FETCH), the Q-Block2 option in a PUT or similar request (e.g., POST), example), the Q-Block2 Option in a PUT or similar request (POST, for
or the Q-Block1 option in a PUT or similar request so that the server example), or the Q-Block1 Option in a PUT or similar request so that
knows that the client supports this Q-Block functionality should it the server knows that the client supports this Q-Block functionality
need to send back a body that spans multiple payloads. Otherwise, should it need to send back a body that spans multiple payloads.
the server would use the Block2 option (if supported) to send back a Otherwise, the server would use the Block2 Option (if supported) to
message body that is too large to fit into a single IP packet send back a message body that is too large to fit into a single IP
[RFC7959]. packet [RFC7959].
How a client decides whether it needs to include a Q-Block1 or How a client decides whether it needs to include a Q-Block1 or
Q-Block2 option can be driven by a local configuration parameter, Q-Block2 Option can be driven by a local configuration parameter,
triggered by an application (e.g., DOTS), etc. Such considerations triggered by an application (DOTS, for example), etc. Such
are out of the scope of this document. considerations are out of the scope of the document.
Implementation of the Q-Block1 and Q-Block2 options is intended to be 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 optional. However, when it is present in a CoAP message, it MUST be
a CoAP message, it MUST be processed (or the message rejected). processed (or the message rejected). Therefore, Q-Block1 and
Therefore, the Q-Block1 and Q-Block2 options are identified as Q-Block2 Options are identified as Critical options.
critical options.
With CoAP over UDP, the way a request message is rejected for With CoAP over UDP, the way a request message is rejected for
critical options depends on the message type. A Confirmable message critical options depends on the message type. A Confirmable message
with an unrecognized critical option is rejected with a 4.02 (Bad with an unrecognized critical option is rejected with a 4.02 (Bad
Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable
message with an unrecognized critical option is either rejected with 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 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 [RFC7252]). To reliably get a rejection message, it is therefore
REQUIRED that clients use a Confirmable message for determining REQUIRED that clients use a Confirmable message for determining
support for the Q-Block1 and Q-Block2 options. This Confirmable support for Q-Block1 and Q-Block2 Options. This CON message can be
message can be sent under the base CoAP congestion control setup sent under the base CoAP congestion control setup specified in
specified in Section 4.7 of [RFC7252] (that is, NSTART does not need Section 4.7 of [RFC7252] (that is, NSTART does not need to be
to be increased (Section 7.1)). increased (Section 7.1)).
The Q-Block1 and Q-Block2 options are unsafe to forward. That is, a 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 CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option
must reject the request or response that uses either option (see must reject the request or response that uses either option (See
Section 5.7.1 of [RFC7252]). Section 5.7.1 of [RFC7252]).
The Q-Block2 option is repeatable when requesting retransmission of The Q-Block2 Option is repeatable when requesting retransmission of
missing blocks but not otherwise. Except for that case, any request missing blocks, but not otherwise. Except that case, any request
carrying multiple Q-Block1 (or Q-Block2) options MUST be handled carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled
following the procedure specified in Section 5.4.5 of [RFC7252]. following the procedure specified in Section 5.4.5 of [RFC7252].
The Q-Block1 and Q-Block2 options, like the Block1 and 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 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 (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 Outer option (Section 4.1 of [RFC8613]). The Inner and Outer values
are therefore independent of each other. The Inner option is are therefore independent of each other. The Inner option is
encrypted and integrity protected between clients and servers and encrypted and integrity protected between clients and servers, and
provides message body identification in case of end-to-end provides message body identification in case of end-to-end
fragmentation of requests. The Outer option is visible to proxies fragmentation of requests. The Outer option is visible to proxies
and labels message bodies in case of hop-by-hop fragmentation of and labels message bodies in case of hop-by-hop fragmentation of
requests. requests.
+========+==========+===+===+ +--------+-----------------+---+---+
| Number | Name | E | U | | Number | Name | E | U |
+========+==========+===+===+ +========+=================+===+===+
| 19 | Q-Block1 | x | x | | TBA1 | Q-Block1 | x | x |
+--------+----------+---+---+ | TBA2 | Q-Block2 | x | x |
| 31 | Q-Block2 | x | x | +--------+-----------------+---+---+
+--------+----------+---+---+ Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options
Table 2: OSCORE
Protection of the
Q-Block1 and Q-Block2
Options
Note that, if the Q-Block1 or Q-Block2 options are included in a Note that if Q-Block1 or Q-Block2 Options are included in a packet as
packet as Inner options, the Block1 or Block2 options MUST NOT be Inner options, Block1 or Block2 Options MUST NOT be included as Inner
included as Inner options. Similarly, there MUST NOT be a mix of options. Similarly, there MUST NOT be a mix of Q-Block and Block for
Q-Block and Block options for the Outer options. Messages that do the Outer options. Messages that do not adhere with this behavior
not adhere to this behavior MUST be rejected with a 4.02 (Bad MUST be rejected with 4.02 (Bad Option). Q-Block and Block Options
Option). The Q-Block and Block options can be mixed across Inner and can be mixed across Inner and Outer options as these are handled
Outer options, as these are handled independently of each other. For independently of each other. For clarity, if OSCORE is not being
clarity, if OSCORE is not being used, there MUST NOT be a mix of used, there MUST NOT be a mix of Q-Block and Block Options in the
Q-Block and Block options in the same packet. same packet.
4.2. Structure of the Q-Block1 and Q-Block2 Options 4.2. Structure of Q-Block1 and Q-Block2 Options
The structure of the Q-Block1 and Q-Block2 options follows the The structure of Q-Block1 and Q-Block2 Options follows the structure
structure defined in Section 2.2 of [RFC7959]. defined in Section 2.2 of [RFC7959].
There is no default value for the Q-Block1 and Q-Block2 options. The There is no default value for the Q-Block1 and Q-Block2 Options.
absence of one of these options is equivalent to an option value of 0 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 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 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 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, 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 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 value of 16 bytes, there is no specific explicit size implied by the
of the option -- the size is left unspecified. (As for any uint, the absence of the option -- the size is left unspecified. (As for any
explicit value 0 is efficiently indicated by a zero-length option; uint, the explicit value 0 is efficiently indicated by a zero-length
therefore, this is semantically different from the absence of the option; this, therefore, is different in semantics from the absence
option.) of the option).
4.3. Using the Q-Block1 Option 4.3. Using the Q-Block1 Option
The Q-Block1 option is used when the client wants to send a large 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 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 iPATCH methods where the data and headers do not fit into a single
packet. packet.
When the Q-Block1 option is used, the client MUST include a Request- When Q-Block1 Option is used, the client MUST include a Request-Tag
Tag option [RFC9175]. The Request-Tag value MUST be the same for all Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST
of the requests for the body of data that is being transferred. The be the same for all of the requests for the body of data that is
Request-Tag is opaque, but the client MUST ensure that it is unique being transferred. The Request-Tag is opaque, but the client MUST
for every different body of transmitted data. ensure that it is unique for every different body of transmitted
data.
Implementation Note: It is suggested that the client treats the Implementation Note: It is suggested that the client treats the
Request-Tag as an unsigned integer of 8 bytes in length. An Request-Tag as an unsigned integer of 8 bytes in length. An
implementation may want to consider limiting this to 4 bytes to implementation may want to consider limiting this to 4 bytes to
reduce packet overhead size. The initial Request-Tag value should reduce packet overhead size. The initial Request-Tag value should
be randomly generated and then subsequently incremented by the be randomly generated and then subsequently incremented by the
client whenever a new body of data is being transmitted between client whenever a new body of data is being transmitted between
peers. peers.
Section 4.6 discusses the use of the Size1 option. Section 4.6 discusses the use of Size1 Option.
For Confirmable transmission, the server continues to acknowledge For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or each packet, but a response is not required (whether separate or
piggybacked) until successful receipt of the body by the server. For piggybacked) until successful receipt of the body by the server. For
Non-confirmable transmission, no response is required until either Non-confirmable transmission, no response is required until either
the successful receipt of the body by the server or a timer expires 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 with some of the payloads having not yet arrived. In the latter
case, a "retransmit missing payloads" response is needed. For case, a "retransmit missing payloads" response is needed. For
reliable transports (e.g., [RFC8323]), a response is not required reliable transports (e.g., [RFC8323]), a response is not required
until successful receipt of the body by the server. until successful receipt of the body by the server.
Each individual message that carries a block of the body is treated Each individual message that carries a block of the body is treated
as a new request (Section 6). as a new request (Section 6).
The client MUST send the payloads in order of increasing block The client MUST send the payloads in order of increasing block
number, starting from zero, until the body is complete (subject to number, starting from zero, until the body is complete (subject to
any congestion control (Section 7)). In addition, any missing any congestion control (Section 7)). Any missing payloads requested
payloads requested by the server must be separately transmitted with by the server must in addition be separately transmitted with
increasing block numbers. increasing block numbers.
The following response codes are used: The following Response Codes are used:
2.01 (Created) 2.01 (Created)
This response code indicates successful receipt of the entire body
This Response Code indicates successful receipt of the entire body
and that the resource was created. The token to use MUST be one 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 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 exchange. However, it is desirable to provide the one used in the
last received request, since that will aid any troubleshooting. last received request, since that will aid any troubleshooting.
The client should then release all of the tokens used for this The client should then release all of the tokens used for this
body. Note that the last received payload might not be the one body. Note that the last received payload might not be the one
with the highest block number. with the highest block number.
2.02 (Deleted) 2.02 (Deleted)
This response code indicates successful receipt of the entire body
This Response Code indicates successful receipt of the entire body
and that the resource was deleted when using POST (Section 5.8.2 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 [RFC7252]). The token to use MUST be one of the tokens that were
were received in a request for this block-wise exchange. However, received in a request for this block-wise exchange. However, it
it is desirable to provide the one used in the last received is desirable to provide the one used in the last received request.
request. The client should then release all of the tokens used The client should then release all of the tokens used for this
for this body. body.
2.04 (Changed) 2.04 (Changed)
This response code indicates successful receipt of the entire body
This Response Code indicates successful receipt of the entire body
and that the resource was updated. The token to use MUST be one 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 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 exchange. However, it is desirable to provide the one used in the
last received request. The client should then release all of the last received request. The client should then release all of the
tokens used for this body. tokens used for this body.
2.05 (Content) 2.05 (Content)
This response code indicates successful receipt of the entire
This Response Code indicates successful receipt of the entire
FETCH request body (Section 2 of [RFC8132]) and that the FETCH request body (Section 2 of [RFC8132]) and that the
appropriate representation of the resource is being returned. The appropriate representation of the resource is being returned. The
token to use MUST be one of the tokens that were received in a 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 request for this block-wise exchange. However, it is desirable to
provide the one used in the last received request. provide the one used in the last received request.
If the FETCH request includes the Observe option, then the server If the FETCH request includes the Observe Option, then the server
MUST use the same token as used for the 2.05 (Content) response MUST use the same token as used for the 2.05 (Content) response
for returning any triggered Observe responses so that the client for returning any Observe triggered responses so that the client
can match them up. can match them up.
The client should then release all of the tokens used for this The client should then release all of the tokens used for this
body apart from the one used for tracking an observed resource. body apart from the one used for tracking an observed resource.
2.31 (Continue) 2.31 (Continue)
This response code can be used to indicate that all of the blocks 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 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 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 be one of the tokens that were received in a request for this
latest MAX_PAYLOADS_SET block-wise exchange. However, it is latest MAX_PAYLOADS_SET block-wise exchange. However, it is
desirable to provide the one used in the last received request. desirable to provide the one used in the last received request.
The client should then release all of the tokens used for this 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 A response using this Response Code MUST NOT be generated for
every received Q-Block1 option request. It SHOULD only be every received Q-Block1 Option request. It SHOULD only be
generated when all the payload requests are Non-confirmable and a generated when all the payload requests are Non-confirmable and a
MAX_PAYLOADS_SET has been received by the server. More details MAX_PAYLOADS_SET has been received by the server. More details
about the motivations for this optimization are discussed in about the motivations for this optimization are discussed in
Section 7.2. Section 7.2.
This response code SHOULD NOT be generated for CON, as this may This Response Code SHOULD NOT be generated for CON as this may
cause duplicated payloads to unnecessarily be sent. cause duplicated payloads to unnecessarily be sent.
4.00 (Bad Request) 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 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. Q-Block1 option.
4.02 (Bad Option) 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 This Response Code MUST be returned for a Confirmable request if
Reset message may be sent in case of a Non-confirmable request. the server does not support the Q-Block Options. Note that a
reset message may be sent in case of Non-confirmable request.
4.08 (Request Entity Incomplete) 4.08 (Request Entity Incomplete)
As a reminder, this response code returned without content type
As a reminder, this Response Code returned without Content-Type
"application/missing-blocks+cbor-seq" (Section 12.3) is handled as "application/missing-blocks+cbor-seq" (Section 12.3) is handled as
in Section 2.9.2 of [RFC7959]. in Section 2.9.2 [RFC7959].
This response code returned with content type "application/ This Response Code returned with Content-Type "application/
missing-blocks+cbor-seq" indicates that some of the payloads are missing-blocks+cbor-seq" indicates that some of the payloads are
missing and need to be resent. The client then retransmits the missing and need to be resent. The client then retransmits the
individual missing payloads using the same Request-Tag, Size1, and individual missing payloads using the same Request-Tag, Size1,
Q-Block1 options to specify the same NUM, SZX, and M bit values as and, Q-Block1 Option to specify the same NUM, SZX, and M bit as
those sent initially in the original (but not received) packets. sent initially in the original, but not received, packet.
The Request-Tag value to use is determined by taking the token in The Request-Tag value to use is determined by taking the token in
the 4.08 (Request Entity Incomplete) response, locating the the 4.08 (Request Entity Incomplete) response, locating the
matching client request, and then using its Request-Tag. matching client request, and then using its Request-Tag.
The token to use in the 4.08 (Request Entity Incomplete) response 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 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 block-wise body exchange. However, it is desirable to provide the
one used in the last received request. See Section 5 for further one used in the last received request. See Section 5 for further
information. information.
If the server has not received all the blocks of a body, but one 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 or more NON payloads have been received, it SHOULD wait for
NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request NON_RECEIVE_TIMEOUT (Section 7.2) before sending a 4.08 (Request
Entity Incomplete) response. Entity Incomplete) response.
4.13 (Request Entity Too Large) 4.13 (Request Entity Too Large)
This response code can be returned under conditions similar to
This Response Code can be returned under similar conditions to
those discussed in Section 2.9.3 of [RFC7959]. those discussed in Section 2.9.3 of [RFC7959].
This response code can be returned if there is insufficient space 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 create a response PDU with a block size of 16 bytes (SZX = 0)
to send back all the response options as appropriate. In this to send back all the response options as appropriate. In this
case, the Size1 option is not included in the response. case, the Size1 Option is not included in the response.
Further considerations related to the transmission timings of the Further considerations related to the transmission timings of 4.08
4.08 (Request Entity Incomplete) and 2.31 (Continue) response codes (Request Entity Incomplete) and 2.31 (Continue) Response Codes are
are discussed in Section 7.2. discussed in Section 7.2.
If a server receives payloads with different Request-Tags for the If a server receives payloads with different Request-Tags for the
same resource, it should continue to process all the bodies, as it same resource, it should continue to process all the bodies as it has
has no way of determining which is the latest version or which body, no way of determining which is the latest version, or which body, if
if any, the client is terminating the transmission for. any, the client is terminating the transmission for.
If the client elects to stop the transmission of a complete body, If the client elects to stop the transmission of a complete body, and
then absent any local policy, the client MUST "forget" all tracked absent any local policy, the client MUST "forget" all tracked tokens
tokens associated with the body's Request-Tag so that a Reset message associated with the body's Request-Tag so that a reset message is
is generated for the invalid token in the 4.08 (Request Entity generated for the invalid token in the 4.08 (Request Entity
Incomplete) response. On receipt of the Reset message, the server Incomplete) response. The server on receipt of the reset message
SHOULD delete the partial body. SHOULD delete the partial body.
If the server receives a duplicate block with the same Request-Tag, 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 it MUST ignore the payload of the packet, but MUST still respond as
the block was received for the first time. if the block was received for the first time.
A server SHOULD maintain a partial body (missing payloads) for A server SHOULD maintain a partial body (missing payloads) for
NON_PARTIAL_TIMEOUT (Section 7.2). NON_PARTIAL_TIMEOUT (Section 7.2).
4.4. Using the Q-Block2 Option 4.4. Using the Q-Block2 Option
In a request for any block number, an unset M bit indicates the In a request for any block number, the M bit unset indicates the
request is just for that block. If the M bit is set, this has request is just for that block. If the M bit is set, this has
different meanings based on the NUM value: different meanings based on the NUM value:
NUM is zero: This is a request for the entire body. NUM is zero: This is a request for the entire body.
'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is 'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is
used to confirm that the current MAX_PAYLOADS_SET (the latest used to confirm that the current MAX_PAYLOADS_SET (the latest
block having block number NUM-1) has been successfully received block having block number NUM-1) has been successfully received
and that, upon receipt of this request, the server can continue to and that, upon receipt of this request, the server can continue to
send the next MAX_PAYLOADS_SET (the first block having block send the next MAX_PAYLOADS_SET (the first block having block
number NUM). This is the 'Continue' Q-Block-2 and conceptually number NUM). This is the 'Continue' Q-Block-2 and conceptually
has the same usage (i.e., continue sending the next set of data) has the same usage (i.e., continue sending the next set of data)
as the use of 2.31 (Continue) for Q-Block1. as the use of 2.31 (Continue) for Q-Block1.
Any other value of NUM: This is a request for that block and for all 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. of the remaining blocks in the current MAX_PAYLOADS_SET.
If the request includes multiple Q-Block2 options and these options If the request includes multiple Q-Block2 Options and these options
overlap (e.g., combination of M being set (this and later blocks) and overlap (e.g., combination of M being set (this and later blocks) and
unset (this individual block)), resulting in an individual block being unset (this individual block)) resulting in an individual block
being requested multiple times, the server MUST only send back one being requested multiple times, the server MUST only send back one
instance of that block. This behavior is meant to prevent instance of that block. This behavior is meant to prevent
amplification attacks. amplification attacks.
The payloads sent back from the server as a response MUST all have 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 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 server MUST NOT use the same ETag value for different representations
of a resource. of a resource.
The ETag is opaque, but the server MUST ensure that it is unique for The ETag is opaque, but the server MUST ensure that it is unique for
every different body of transmitted data. every different body of transmitted data.
Implementation Note: It is suggested that the server treats the Implementation Note: It is suggested that the server treats the
ETag as an unsigned integer of 8 bytes in length. An ETag as an unsigned integer of 8 bytes in length. An
implementation may want to consider limiting this to 4 bytes to implementation may want to consider limiting this to 4 bytes to
reduce packet overhead size. The initial ETag value should be reduce packet overhead size. The initial ETag value should be
randomly generated and then subsequently incremented by the server randomly generated and then subsequently incremented by the server
whenever a new body of data is being transmitted between peers. whenever a new body of data is being transmitted between peers.
Section 4.6 discusses the use of the Size2 option. Section 4.6 discusses the use of Size2 Option.
The client may elect to request any detected missing blocks or just The client may elect to request any detected missing blocks or just
ignore the partial body. This decision is implementation specific. ignore the partial body. This decision is implementation specific.
For NON payloads, the client SHOULD wait for NON_RECEIVE_TIMEOUT For NON payloads, the client SHOULD wait NON_RECEIVE_TIMEOUT
(Section 7.2) after the last received payload before requesting (Section 7.2) after the last received payload before requesting
retransmission of any missing blocks. Retransmission is requested by retransmission of any missing blocks. Retransmission is requested by
issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that
contains one or more Q-Block2 options that define the missing 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 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 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 from this MAX_PAYLOADS_SET, see Section 10.2.4 for an example of this
in operation. Further considerations related to the transmission in operation. Further considerations related to the transmission
timing for missing requests are discussed in Section 7.2. timing for missing requests are discussed in Section 7.2.
The missing block numbers requested by the client MUST have an The missing block numbers requested by the client MUST have an
increasing block number in each additional Q-Block2 option with no increasing block number in each additional Q-Block2 Option with no
duplicates. The server SHOULD respond with a 4.00 (Bad Request) to duplicates. The server SHOULD respond with a 4.00 (Bad Request) to
requests not adhering to this behavior. Note that the ordering requests not adhering to this behavior. Note that the ordering
constraint is meant to force the client to check for duplicates and constraint is meant to force the client to check for duplicates and
remove them. This also helps with troubleshooting. remove them. This also helps with troubleshooting.
If the client receives a duplicate block with the same ETag, it MUST If the client receives a duplicate block with the same ETag, it MUST
silently ignore the payload. silently ignore the payload.
A client SHOULD maintain a partial body (missing payloads) for A client SHOULD maintain a partial body (missing payloads) for
NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age option 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])), (or its default of 60 seconds (Section 5.6.1 of [RFC7252])),
whichever is less. On release of the partial body, the client should whichever is the less. On release of the partial body, the client
then release all of the tokens used for this body apart from the should then release all of the tokens used for this body apart from
token that is used to track a resource that is being observed. the token that is used to track a resource that is being observed.
The ETag option should not be used in the request for missing blocks, 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 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 payload. It can be used in the request if the client wants to check
the freshness of the locally cached body response. the freshness of the locally cached body response.
The server SHOULD maintain a cached copy of the body when using the 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 Option to facilitate retransmission of any missing payloads.
If the server detects partway through a body transfer that the If the server detects part way through a body transfer that the
resource data has changed and the server is not maintaining a cached resource data has changed and the server is not maintaining a cached
copy of the old data, then the transmission is terminated. Any copy of the old data, then the transmission is terminated. Any
subsequent missing block requests MUST be responded to using the subsequent missing block requests MUST be responded to using the
latest ETag and Size2 option values with the updated data. latest ETag and Size2 Option values with the updated data.
If the server responds during a body update with a different ETag If the server responds during a body update with a different ETag
option value (as the resource representation has changed), then the Option value (as the resource representation has changed), then the
client should treat the partial body with the old ETag as no longer 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 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. specifying Q-Block2 with block number '0' and the M bit set.
If the server transmits a new body of data (e.g., a triggered Observe 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 notification) with a new ETag to the same client as an additional
response, the client should remove any partially received body held response, the client should remove any partially received body held
for a previous ETag for that resource, as it is unlikely the missing for a previous ETag for that resource as it is unlikely the missing
blocks can be retrieved. blocks can be retrieved.
If there is insufficient space to create a response PDU with a block 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 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 appropriate, a 4.13 (Request Entity Too Large) is returned without
the Size1 option. the Size1 Option.
For Confirmable traffic, the server typically acknowledges the For Confirmable traffic, the server typically acknowledges the
initial request using an Acknowledgment (ACK) with a piggybacked initial request using an ACK with a piggybacked payload, and then
payload and then sends the subsequent payloads of the sends the subsequent payloads of the MAX_PAYLOADS_SET as CON
MAX_PAYLOADS_SET as CON responses. These CON responses are responses. These CON responses are individually ACKed by the client.
individually ACKed by the client. The server will detect failure to The server will detect failure to send a packet and SHOULD terminate
send a packet and SHOULD terminate the body transfer, but the client the body transfer, but the client can issue, after a
can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, POST, MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or
PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed. iPATCH for any missing blocks as needed.
4.5. Using the Observe Option 4.5. Using Observe Option
For a request that uses Q-Block1, the Observe value [RFC7641] MUST be 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 the same for all the payloads of the same body. This includes any
missing payloads that are retransmitted. missing payloads that are retransmitted.
For a response that uses Q-Block2, the Observe value MUST be the same 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 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 usage where the Observe value is only present in the first block
(Section 3.4 of [RFC7959]). This includes payloads transmitted (Section 3.4 of [RFC7959]). This includes payloads transmitted
following receipt of the 'Continue' Q-Block2 option (Section 4.4) by 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 server. If a missing payload is requested by a client, then both
the request and response MUST NOT include the Observe option. the request and response MUST NOT include the Observe Option.
4.6. Using the Size1 and Size2 Options 4.6. Using Size1 and Size2 Options
Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating
the size of the representation transferred in requests and Size2 for the size of the representation transferred in requests and Size2 for
indicating the size of the representation transferred in responses. indicating the size of the representation transferred in responses.
For the Q-Block1 and Q-Block2 options, the Size1 or Size2 option For Q-Block1 and Q-Block2 Options, the Size1 or Size2 Option values
values MUST exactly represent the size of the data on the body so MUST exactly represent the size of the data on the body so that any
that any missing data can easily be determined. missing data can easily be determined.
The Size1 option MUST be used with the Q-Block1 option when used in a 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, request and MUST be present in all payloads of the request,
preserving the same value. The Size2 option MUST be used with the 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 Q-Block2 Option when used in a response and MUST be present in all
payloads of the response, preserving the same value. payloads of the response, preserving the same value.
4.7. Using the Q-Block1 and Q-Block2 Options Together 4.7. Using Q-Block1 and Q-Block2 Options Together
The behavior is similar to the one defined in Section 3.3 of The behavior is similar to the one defined in Section 3.3 of
[RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for
substituted for Block2. Block2.
4.8. Using the Q-Block2 Option with Multicast 4.8. Using Q-Block2 Option With Multicast
Servers MUST ignore multicast requests that contain the Q-Block2 Servers MUST ignore multicast requests that contain the Q-Block2
option. As a reminder, the Block2 option can be used as stated in Option. As a reminder, Block2 Option can be used as stated in
Section 2.8 of [RFC7959]. Section 2.8 of [RFC7959].
5. The Use of the 4.08 (Request Entity Incomplete) Response Code 5. The Use of 4.08 (Request Entity Incomplete) Response Code
The 4.08 (Request Entity Incomplete) response code has a new content 4.08 (Request Entity Incomplete) Response Code has a new Content-Type
type "application/missing-blocks+cbor-seq" used to indicate that the "application/missing-blocks+cbor-seq" used to indicate that the
server has not received all of the blocks of the request body that it 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 needs to proceed. Such messages must not be treated by the client as
a fatal error. a fatal error.
Likely causes are the client has not sent all blocks, some blocks Likely causes are the client has not sent all blocks, some blocks
were dropped during transmission, or the client sent them a long were dropped during transmission, or the client has sent them
enough time ago that the server has already discarded them. sufficiently long ago that the server has already discarded them.
The new data payload of the 4.08 (Request Entity Incomplete) response The new data payload of the 4.08 (Request Entity Incomplete) response
with content type "application/missing-blocks+cbor-seq" is encoded as with Content-Type set to "application/missing-blocks+cbor-seq" is
a Concise Binary Object Representation (CBOR) Sequence [RFC8742]. It encoded as a CBOR Sequence [RFC8742]. It comprises one or more
comprises one or more missing block numbers encoded as CBOR unsigned missing block numbers encoded as CBOR unsigned integers [RFC8949].
integers [RFC8949]. The missing block numbers MUST be unique in each The missing block numbers MUST be unique in each 4.08 (Request Entity
4.08 (Request Entity Incomplete) response when created by the server; Incomplete) response when created by the server; the client MUST
the client MUST ignore any duplicates in the same 4.08 (Request ignore any duplicates in the same 4.08 (Request Entity Incomplete)
Entity Incomplete) response. response.
The Content-Format option (Section 5.10.3 of [RFC7252]) MUST be used 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 in the 4.08 (Request Entity Incomplete) response. It MUST be set to
"application/missing-blocks+cbor-seq" (Section 12.3). "application/missing-blocks+cbor-seq" (Section 12.3).
The Concise Data Definition Language (CDDL) [RFC8610] (and see The Concise Data Definition Language [RFC8610] (and see Section 4.1
Section 4.1 of [RFC8742]) for the data describing these missing [RFC8742]) for the data describing these missing blocks is as
blocks is as follows: follows:
; This defines an array, the elements of which are to be used ; This defines an array, the elements of which are to be used
; in a CBOR Sequence: ; in a CBOR Sequence:
payload = [+ missing-block-number] payload = [+ missing-block-number]
; A unique block number not received: ; A unique block number not received:
missing-block-number = uint missing-block-number = uint
Figure 1: Structure of the Missing Blocks Payload Figure 1: Structure of the Missing Blocks Payload
This CDDL syntax MUST be followed. This CDDL syntax MUST be followed.
It is desirable that the token to use for the response is the token 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 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 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 same Request-Tag would be acceptable, but providing the one used in
the last received payload will aid any troubleshooting. The client the last received payload will aid any troubleshooting. The client
will use the token to determine what was the previously sent request will use the token to determine what was the previously sent request
to obtain the Request-Tag value that was used. to obtain the Request-Tag value that was used.
If the size of the 4.08 (Request Entity Incomplete) response packet 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 is larger than that defined by Section 4.6 [RFC7252], then the number
number of reported missing blocks MUST be limited so that the of reported missing blocks MUST be limited so that the response can
response can fit into a single packet. If this is the case, then the fit into a single packet. If this is the case, then the server can
server can send subsequent 4.08 (Request Entity Incomplete) responses send subsequent 4.08 (Request Entity Incomplete) responses containing
containing those additional missing blocks on receipt of a new the missing other blocks on receipt of a new request providing a
request providing a missing payload with the same Request-Tag. missing payload with the same Request-Tag.
The missing blocks MUST be reported in ascending order without any The missing blocks MUST be reported in ascending order without any
duplicates. The client SHOULD silently drop 4.08 (Request Entity duplicates. The client SHOULD silently drop 4.08 (Request Entity
Incomplete) responses not adhering to this behavior. Incomplete) responses not adhering with this behavior.
Implementation Note: Consider limiting the number of missing Implementation Note: Consider limiting the number of missing
payloads to MAX_PAYLOADS to minimize the need for congestion payloads to MAX_PAYLOADS to minimize congestion control being
control. The CBOR Sequence does not include any array wrapper. needed. The CBOR sequence does not include any array wrapper.
A 4.08 (Request Entity Incomplete) response with content type The 4.08 (Request Entity Incomplete) with Content-Type "application/
"application/missing-blocks+cbor-seq" SHOULD NOT be used when using missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable
Confirmable requests or a reliable connection [RFC8323], as the requests or a reliable connection [RFC8323] as the client will be
client will be able to determine that there is a transmission failure able to determine that there is a transmission failure of a
of a particular payload and hence that the server is missing that particular payload and hence that the server is missing that payload.
payload.
6. The Use of Tokens 6. The Use of Tokens
Each new request generally uses a new Token (and sometimes must; see Each new request generally uses a new Token (and sometimes must, see
Section 4 of [RFC9175]). Additional responses to a request all use Section 4 of [I-D.ietf-core-echo-request-tag]). Additional responses
the token of the request they respond to. to a request all use the token of the request they respond to.
Implementation Note: By using 8-byte tokens, it is possible to Implementation Note: By using 8-byte tokens, it is possible to
easily minimize the number of tokens that have to be tracked by 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 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 and the upper 32 bits containing the current body's request number
(incrementing every request, including every retransmit). This (incrementing every request, including every re-transmit). This
alleviates the client's need to keep all the per-request state, allows the client to be alleviated from keeping all the per-
e.g., per Section 3 of [RFC8974]. However, if using NoSec, request-state, e.g., in Section 3 of [RFC8974]. However, if using
Section 5.2 of [RFC8974] needs to be considered for security NoSec, Section 5.2 of [RFC8974] needs to be considered for
implications. security implications.
7. Congestion Control for Unreliable Transports 7. Congestion Control for Unreliable Transports
The transmission of all the blocks of a single body over an The transmission of all the blocks of a single body over an
unreliable transport MUST either all be Confirmable or all be Non- unreliable transport MUST either all be Confirmable or all be Non-
confirmable. This is meant to simplify the congestion control confirmable. This is meant to simplify the congestion control
procedure. procedure.
As a reminder, there is no need for CoAP-specific congestion control As a reminder, there is no need for CoAP-specific congestion control
for reliable transports [RFC8323]. for reliable transports [RFC8323].
skipping to change at line 936 skipping to change at page 20, line 41
and Q-Block2 will be Non-confirmable (Section 3.2) apart from the and Q-Block2 will be Non-confirmable (Section 3.2) apart from the
initial Q-Block functionality negotiation. initial Q-Block functionality negotiation.
Following the failure to transmit a packet due to packet loss after Following the failure to transmit a packet due to packet loss after
MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is MAX_TRANSMIT_SPAN time (Section 4.8.2 of [RFC7252]), it is
implementation specific as to whether there should be any further implementation specific as to whether there should be any further
requests for missing data. requests for missing data.
7.2. Non-confirmable (NON) 7.2. Non-confirmable (NON)
This document introduces the new parameters MAX_PAYLOADS, This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_TIMEOUT, NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT,
NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON
primarily for use with NON (Table 3). (Table 3).
Note: Randomness may naturally be provided based on the traffic Note: Randomness may naturally be provided based on the traffic
profile, how PROBING_RATE is computed (as this is an average), and profile, how probing-rate is computed (as this is an average), and
when the peer responds. Randomness is explicitly added for some when the peer responds. Randomness is explicitly added for some
of the congestion control parameters to handle situations where of the congestion control parameters to handle situations where
everything is in sync when retrying. every thing is in sync when retrying.
MAX_PAYLOADS should be configurable with a default value of 10. Both MAX_PAYLOADS should be configurable with a default value of 10. Both
CoAP endpoints MUST have the same value (otherwise, there will be CoAP endpoints MUST have the same value (otherwise there will be
transmission delays in one direction), and the value MAY be transmission delays in one direction) and the value MAY be negotiated
negotiated between the endpoints to a common value by using a higher- between the endpoints to a common value by using a higher level
level protocol (out of scope of this document). This is the maximum protocol (out of scope of this document). This is the maximum number
number of payloads that can be transmitted at any one time. of payloads that can be transmitted at any one time.
Note: The default value of 10 is chosen for reasons similar to Note: The default value of 10 is chosen for reasons similar to
those discussed in Section 5 of [RFC6928], especially given the those discussed in Section 5 of [RFC6928], especially given the
target application discussed in Section 3.2. target application discussed in Section 3.2.
NON_TIMEOUT is used to compute the delay between sending NON_TIMEOUT is used to compute the delay between sending
MAX_PAYLOADS_SET for the same body. By default, NON_TIMEOUT has the MAX_PAYLOADS_SET for the same body. By default, NON_TIMEOUT has the
same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]). same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]).
NON_TIMEOUT_RANDOM is the initial actual delay between sending the 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 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 used between the subsequent MAX_PAYLOADS_SETs. It is a random
duration (not an integral number of seconds) between NON_TIMEOUT and duration (not an integral number of seconds) between NON_TIMEOUT and
(NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to 1.5, (NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to 1.5
as discussed in Section 4.8 of [RFC7252]. as discussed in Section 4.8 of [RFC7252].
NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload
before requesting retransmission for the first time. Every time the before requesting retransmission for the first time. Every time the
missing payload is re-requested, the Time-to-Wait value doubles. The missing payload is re-requested, the time to wait value doubles. The
time to wait is calculated as: time to wait is calculated as:
Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1)) 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 has a default value of twice NON_TIMEOUT.
NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT_RANDOM by 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 at least one second so that the sender of the payloads has the
opportunity to start sending the next MAX_PAYLOADS_SET before the opportunity to start sending the next MAX_PAYLOADS_SET before the
receiver times out. receiver times out.
NON_MAX_RETRANSMIT is the maximum number of times a request for the NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from retransmission of missing payloads can occur without a response from
the remote peer. After this occurs, the local endpoint SHOULD the remote peer. After this occurs, the local endpoint SHOULD
consider the body stale, remove any body, and release the tokens and consider the body stale, remove any body, and release Tokens and
Request-Tag on the client (or the ETag on the server). By default, 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 NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
of [RFC7252]). of [RFC7252]).
NON_PROBING_WAIT is used to limit the potential wait needed when NON_PROBING_WAIT is used to limit the potential wait needed when
using PROBING_RATE. By default, NON_PROBING_WAIT is computed in a using PROBING_RATE. By default, NON_PROBING_WAIT is computed in a
way similar to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but similar way as EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but
with ACK_TIMEOUT, MAX_RETRANSMIT, and PROCESSING_DELAY substituted with ACK_TIMEOUT, MAX_RETRANSMIT, and PROCESSING_DELAY substituted
with NON_TIMEOUT, NON_MAX_RETRANSMIT, and NON_TIMEOUT_RANDOM, with NON_TIMEOUT, NON_MAX_RETRANSMIT, and NON_TIMEOUT_RANDOM,
respectively: respectively:
NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) * NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) *
ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT_RANDOM ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT_RANDOM
NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
By default, NON_PARTIAL_TIMEOUT is computed in the same way as By default, NON_PARTIAL_TIMEOUT is computed in the same way as
EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with ACK_TIMEOUT EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) but with ACK_TIMEOUT
and MAX_RETRANSMIT substituted with NON_TIMEOUT and and MAX_RETRANSMIT substituted with NON_TIMEOUT and
NON_MAX_RETRANSMIT, respectively: NON_MAX_RETRANSMIT, respectively:
NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) -
1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT 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 |
+---------------------+-------------------+ +---------------------+-------------------+
| 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_PROBING_WAIT | between 247-248 s |
+---------------------+-------------------+ | NON_PARTIAL_TIMEOUT | 247 s |
| NON_PARTIAL_TIMEOUT | 247 s |
+---------------------+-------------------+ +---------------------+-------------------+
Table 3: Congestion Control Parameters Table 3: Congestion Control Parameters
The PROBING_RATE parameter in CoAP indicates the average data rate 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 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 endpoint that does not respond. A single body will be subjected to
PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets. PROBING_RATE (Section 4.7 of [RFC7252]), not the individual packets.
If the wait time between sending bodies that are not being responded 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 to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time
is limited to NON_PROBING_WAIT. is limited to NON_PROBING_WAIT.
| Note: For the particular DOTS application, PROBING_RATE and Note: For the particular DOTS application, PROBING_RATE and other
| other transmission parameters are negotiated between peers. transmission parameters are negotiated between peers. Even when
| Even when not negotiated, the DOTS application uses customized not negotiated, the DOTS application uses customized defaults as
| defaults, as discussed in Section 4.5.2 of [RFC9132]. Note discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS,
| that MAX_PAYLOADS, NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and
| NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT can be negotiated NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as
| between DOTS peers, e.g., as per [DOTS-QUICK-BLOCKS]. When per [I-D.bosh-dots-quick-blocks]. When explicit values are
| explicit values are configured for NON_PROBING_WAIT and configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
| NON_PARTIAL_TIMEOUT, these values are used without applying any values are used without applying any jitter.
| jitter.
Each NON 4.08 (Request Entity Incomplete) response is subject to Each NON 4.08 (Request Entity Incomplete) response is subject to
PROBING_RATE. PROBING_RATE.
Each NON GET or FETCH request using a Q-Block2 option is subject to Each NON GET or FETCH request using a Q-Block2 Option is subject to
PROBING_RATE. PROBING_RATE.
As the sending of many payloads of a single body may itself cause As the sending of many payloads of a single body may itself cause
congestion, after transmission of every MAX_PAYLOADS_SET of a single congestion, after transmission of every MAX_PAYLOADS_SET of a single
body, a delay of NON_TIMEOUT_RANDOM MUST be introduced before sending body, a delay MUST be introduced of NON_TIMEOUT_RANDOM before sending
the next MAX_PAYLOADS_SET, unless a 'Continue' is received from the the next MAX_PAYLOADS_SET unless a 'Continue' is received from the
peer for the current MAX_PAYLOADS_SET, in which case the next peer for the current MAX_PAYLOADS_SET, in which case the next
MAX_PAYLOADS_SET MAY start transmission immediately. MAX_PAYLOADS_SET MAY start transmission immediately.
Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having
10 payloads, this corresponds to 1500 * 10 * 8 = 120 kbits. With 10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits. With
a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates an a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates an
average speed requirement of 60 kbps for a single body should average speed requirement of 60 Kbps for a single body should
there be no responses. This transmission rate is further reduced there be no responses. This transmission rate is further reduced
by being subject to PROBING_RATE. by being subject to PROBING_RATE.
The sending of a set of missing blocks of a body is restricted to 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 those in a MAX_PAYLOADS_SET at a time. In other words, a
NON_TIMEOUT_RANDOM delay is still observed between each NON_TIMEOUT_RANDOM delay is still observed between each
MAX_PAYLOADS_SET. MAX_PAYLOAD_SET.
For the Q-Block1 option, if the server responds with a 2.31 For Q-Block1 Option, if the server responds with a 2.31 (Continue)
(Continue) response code for the latest payload sent, then the client Response Code for the latest payload sent, then the client can
can continue to send the next MAX_PAYLOADS_SET without any further continue to send the next MAX_PAYLOADS_SET without any further delay.
delay. If the server responds with a 4.08 (Request Entity If the server responds with a 4.08 (Request Entity Incomplete)
Incomplete) response code, then the missing payloads SHOULD be Response Code, then the missing payloads SHOULD be retransmitted
retransmitted before going into another NON_TIMEOUT_RANDOM delay before going into another NON_TIMEOUT_RANDOM delay prior to sending
prior to sending the next set of payloads. the next set of payloads.
For the server receiving NON Q-Block1 requests, it SHOULD send back a For the server receiving NON Q-Block1 requests, it SHOULD send back a
2.31 (Continue) response code on receipt of all of the 2.31 (Continue) Response Code on receipt of all of the
MAX_PAYLOADS_SET to prevent the client unnecessarily delaying the MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If
transfer of remaining blocks. If not all of the MAX_PAYLOADS_SET not all of the MAX_PAYLOADS_SET were received, the server SHOULD
were received, the server SHOULD delay for NON_RECEIVE_TIMEOUT delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the
(exponentially scaled based on the repeat request count for a repeat request count for a payload) before sending the 4.08 (Request
payload) before sending the 4.08 (Request Entity Incomplete) response Entity Incomplete) Response Code for the missing payload(s). If all
code for the missing payload(s). If all of the MAX_PAYLOADS_SET were of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been
received and a 2.31 (Continue) response code had been sent, but no sent, but no more payloads were received for NON_RECEIVE_TIMEOUT
more payloads were received for NON_RECEIVE_TIMEOUT (exponentially (exponentially scaled), the server SHOULD send a 4.08 (Request Entity
scaled), the server SHOULD send a 4.08 (Request Entity Incomplete) Incomplete) response detailing the missing payloads after the block
response detailing the missing payloads after the block number that number that was indicated in the sent 2.31 (Continue). If the
was indicated in the sent 2.31 (Continue) response code. If the repeated response count of the 4.08 (Request Entity Incomplete)
repeat response count of the 4.08 (Request Entity Incomplete) exceeds exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial
NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and body and stop requesting the missing payloads.
stop requesting the missing payloads.
It is likely that the client will start transmitting the next It is likely that the client will start transmitting the next
MAX_PAYLOADS_SET before the server times out on waiting for the last 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 of the previous MAX_PAYLOADS_SET. On receipt of a payload from the
the next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity
Entity Incomplete) response code indicating any missing payloads from Incomplete) Response Code indicating any missing payloads from any
any previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity
Entity Incomplete) response code, the client SHOULD send the missing Incomplete) Response Code, the client SHOULD send the missing
payloads before continuing to send the remainder of the payloads before continuing to send the remainder of the
MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay
prior to sending the next MAX_PAYLOADS_SET. prior to sending the next MAX_PAYLOADS_SET.
For the client receiving NON Q-Block2 responses, it SHOULD send a For the client receiving NON Q-Block2 responses, it SHOULD send a
'Continue' Q-Block2 request (Section 4.4) for the next 'Continue' Q-Block2 request (Section 4.4) for the next
MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET to prevent MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET, to
the server unnecessarily delaying the transfer of remaining blocks. prevent the server unnecessarily delaying. Otherwise the client
Otherwise, the client SHOULD delay for NON_RECEIVE_TIMEOUT SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on
(exponentially scaled based on the repeat request count for a the repeat request count for a payload), before sending the request
payload) before sending the request for the missing payload(s). If for the missing payload(s). If the repeat request count for a
the repeat request count for a missing payload exceeds missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard
NON_MAX_RETRANSMIT, the client SHOULD discard the partial body and the partial body and stop requesting the missing payloads.
stop requesting the missing payloads.
The server SHOULD recognize the 'Continue' Q-Block2 request per the The server SHOULD recognize the 'Continue' Q-Block2 request as a
definition in Section 4.4 and just continue the transmission of the continue request and just continue the transmission of the body
body (including the Observe option, if appropriate for an unsolicited (including Observe Option, if appropriate for an unsolicited
response) rather than treat 'Continue' as a request for the remaining response) rather than as a request for the remaining missing blocks.
missing blocks.
It is likely that the server will start transmitting the next It is likely that the server will start transmitting the next
MAX_PAYLOADS_SET before the client times out on waiting for the last 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 of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the
from the new MAX_PAYLOADS_SET, the client SHOULD send a request new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any
indicating any missing payloads from any previous MAX_PAYLOADS_SET. missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of
Upon receipt of such a request, the server SHOULD send the missing such request, the server SHOULD send the missing payloads before
payloads before continuing to send the remainder of the continuing to send the remainder of the MAX_PAYLOADS_SET and then go
MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay into another NON_TIMEOUT_RANDOM delay prior to sending the next
prior to sending the next MAX_PAYLOADS_SET. MAX_PAYLOADS_SET.
The client does not need to acknowledge the receipt of the entire The client does not need to acknowledge the receipt of the entire
body. body.
Note: If there is asymmetric traffic loss causing responses to Note: If there is asymmetric traffic loss causing responses to
never get received, a delay of NON_TIMEOUT_RANDOM after every never get received, a delay of NON_TIMEOUT_RANDOM after every
transmission of MAX_PAYLOADS_SET will be observed. The endpoint transmission of MAX_PAYLOADS_SET will be observed. The endpoint
receiving the body is still likely to receive the entire body. receiving the body is still likely to receive the entire body.
8. Caching Considerations 8. Caching Considerations
Caching block-based information is not straightforward in a proxy. Caching block based information is not straight forward in a proxy.
For the Q-Block1 and Q-Block2 options, for simplicity, it is expected For Q-Block1 and Q-Block2 Options, for simplicity it is expected that
that the proxy will reassemble the body (using any appropriate the proxy will reassemble the body (using any appropriate recovery
recovery options for packet loss) before passing the body onward to options for packet loss) before passing on the body to the
the appropriate CoAP endpoint. This does not preclude an appropriate CoAP endpoint. This does not preclude an implementation
implementation doing a more complex per-payload caching, but how to doing a more complex per payload caching, but how to do this is out
do this is out of the scope of this document. The onward of the scope of this document. The onward transmission of the body
transmission of the body does not require the use of the Q-Block1 or does not require the use of the Q-Block1 or Q-Block2 Options as these
Q-Block2 options, as these options may not be supported in that link. options may not be supported in that link. This means that the proxy
This means that the proxy must fully support the Q-Block1 and must fully support the Q-Block1 and Q-Block2 Options.
Q-Block2 options.
How the body is cached in the CoAP client (for Q-Block1 How the body is cached in the CoAP client (for Q-Block1
transmissions) or the CoAP server (for Q-Block2 transmissions) is transmissions) or the CoAP server (for Q-Block2 transmissions) is
implementation specific. implementation specific.
As the entire body is being cached in the proxy, the Q-Block1 and 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 Q-Block2 Options are removed as part of the block assembly and thus
do not reach the cache. do not reach the cache.
For Q-Block2 responses, the ETag option value is associated with the 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 data (and onward transmitted to the CoAP client), but is not part of
the cache key. the cache key.
For requests with the Q-Block1 option, the Request-Tag option is For requests with Q-Block1 Option, the Request-Tag Option is
associated with building the body from successive payloads but is not associated with the build up of the body from successive payloads,
part of the cache key. For the onward transmission of the body using but is not part of the cache key. For the onward transmission of the
CoAP, a new Request-Tag SHOULD be generated and used. Ideally, this body using CoAP, a new Request-Tag SHOULD be generated and used.
new Request-Tag should replace the Request-Tag used by the client. Ideally this new Request-Tag should replace the client's request
Request-Tag.
It is possible that two or more CoAP clients are concurrently It is possible that two or more CoAP clients are concurrently
updating the same resource through a common proxy to the same CoAP 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, server using Q-Block1 (or Block1) Option. If this is the case, the
the first client to complete building the body causes that body to first client to complete building the body causes that body to start
start transmitting to the CoAP server with an appropriate Request-Tag transmitting to the CoAP server with an appropriate Request-Tag
value. When the next client completes building the body, any value. When the next client completes building the body, any
existing partial body transmission to the CoAP server is terminated, existing partial body transmission to the CoAP server is terminated
and the transmission of the new body representation starts with a new and the new body representation transmission starts with a new
Request-Tag value. Note that it cannot be assumed that the proxy Request-Tag value. Note that it cannot be assumed that the proxy
will always receive a complete body from a client. will always receive a complete body from a client.
A proxy that supports the Q-Block2 option MUST be prepared to receive A proxy that supports Q-Block2 Option MUST be prepared to receive a
a GET or similar request indicating one or more missing blocks. From GET or similar request indicating one or more missing blocks. The
its cache, the proxy will serve the missing blocks that are available proxy will serve from its cache the missing blocks that are available
in its cache in the same way a server would send all the appropriate 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 Q-Block2 responses. If a body matching the cache key is not
available in the cache, the proxy MUST request the entire body from available in the cache, the proxy MUST request the entire body from
the CoAP server using the information in the cache key. the CoAP server using the information in the cache key.
How long a CoAP endpoint (or proxy) keeps the body in its cache is 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). implementation specific (e.g., it may be based on Max-Age).
9. HTTP Mapping Considerations 9. HTTP-Mapping Considerations
As a reminder, the basic normative requirements on HTTP/CoAP mappings As a reminder, the basic normative requirements on HTTP/CoAP mappings
are defined in Section 10 of [RFC7252]. The implementation are defined in Section 10 of [RFC7252]. The implementation
guidelines for HTTP/CoAP mappings are elaborated in [RFC8075]. guidelines for HTTP/CoAP mappings are elaborated in [RFC8075].
The rules defined in Section 5 of [RFC7959] are to be followed. The rules defined in Section 5 of [RFC7959] are to be followed.
10. Examples with Non-confirmable Messages 10. Examples with Non-confirmable Messages
This section provides some sample flows to illustrate the use of the This section provides some sample flows to illustrate the use of
Q-Block1 and Q-Block2 options with NON. Examples with CON are Q-Block1 and Q-Block2 Options with NON. Examples with CON are
provided in Appendix A. provided in Appendix A.
The examples in the following subsections assume MAX_PAYLOADS is set The examples in the following subsections assume MAX_PAYLOADS is set
to 10 and NON_MAX_RETRANSMIT is set to 4. to 10 and NON_MAX_RETRANSMIT is set to 4.
The list below contains the conventions that are used in the figures Figure 2 lists the conventions that are used in the following
in the following subsections. subsections.
T: Token value
O: Observe option value
M: Message ID
RT: Request-Tag
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
\: Trimming long lines
[[]]: Comments
-->X: Message loss (request)
X<--: Message loss (response)
...: Passage of time T: Token value
O: Observe Option value
M: Message ID
RT: Request-Tag
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
\: Trimming long lines
[[]]: Comments
-->X: Message loss (request)
X<--: Message loss (response)
...: Passage of time
Payload N: Corresponds to the CoAP message that conveys
a block number (N-1) of a given block-wise exchange.
Payload N: Corresponds to the CoAP message that conveys a block Figure 2: Notations Used in the Figures
number (N-1) of a given block-wise exchange.
10.1. Q-Block1 Option 10.1. Q-Block1 Option
10.1.1. A Simple Example 10.1.1. A Simple Example
Figure 2 depicts an example of a NON PUT request conveying the Figure 3 depicts an example of a NON PUT request conveying Q-Block1
Q-Block1 option. All the blocks are received by the server. Option. All the blocks are received by the server.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON PUT /path M:0x81 T:0xc0 RT=9 QB1:0/1/1024 +--------->| 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: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:0x83 T:0xc2 RT=9 QB1:2/1/1024
+--------->| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024 +--------->| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024
|<---------+ NON 2.04 M:0xf1 T:0xc3 |<---------+ NON 2.04 M:0xf1 T:0xc3
| ... | | ... |
Figure 2: Example of a NON Request with the Q-Block1 option Figure 3: Example of NON Request with Q-Block1 Option (Without Loss)
(without Loss)
10.1.2. Handling MAX_PAYLOADS Limits 10.1.2. Handling MAX_PAYLOADS Limits
Figure 3 depicts an example of a NON PUT request conveying the Figure 4 depicts an example of a NON PUT request conveying Q-Block1
Q-Block1 option. The number of payloads exceeds MAX_PAYLOADS. All Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks
the blocks are received by the server. are received by the server.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024 +--------->| 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 +--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]] +--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024 +--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024
[[MAX_PAYLOADS_SET has been received]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET receipt acknowledged by server]] | [[MAX_PAYLOADS_SET receipt acknowledged by server]]
|<---------+ NON 2.31 M:0x81 T:0xfa |<---------+ NON 2.31 M:0x81 T:0xfa
+--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024 +--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024
|<---------+ NON 2.04 M:0x82 T:0xfb |<---------+ NON 2.04 M:0x82 T:0xfb
| ... | | ... |
Figure 3: Example of a MAX_PAYLOADS NON Request with the Q-Block1 Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
Option (without Loss) (Without Loss)
10.1.3. Handling MAX_PAYLOADS with Recovery 10.1.3. Handling MAX_PAYLOADS with Recovery
Consider now a scenario where a new body of data is to be sent by the 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 client, but some blocks are dropped in transmission as illustrated in
in Figure 4. Figure 5.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 +--------->| 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 +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024
+--------->| [[Payloads 3 - 8 not detailed]] +--------->| [[Payloads 3 - 8 not detailed]]
+--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 +--------->| 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 +--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024
[[Some of the MAX_PAYLOADS_SET has been received]] [[Some of MAX_PAYLOADS_SET have been received]]
| ... | | ... |
[[NON_TIMEOUT_RANDOM (client) delay expires]] [[NON_TIMEOUT_RANDOM (client) delay expires]]
| [[Client starts sending next MAX_PAYLOADS_SET]] | [[Client starts sending next MAX_PAYLOAD_SET]]
+--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 +--->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 +--------->| 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 Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
Option (with Loss) (With Loss)
On seeing a payload from the next MAX_PAYLOADS_SET, the server On seeing a payload from the next MAX_PAYLOAD_SET, the server
realizes that some blocks are missing from the previous realizes that some blocks are missing from the previous
MAX_PAYLOADS_SET and asks for the missing blocks in one go MAX_PAYLOADS_SET and asks for the missing blocks in one go
(Figure 5). It does so by indicating which blocks from the previous (Figure 6). It does so by indicating which blocks from the previous
MAX_PAYLOADS_SET have not been received in the data portion of the 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 response (Section 5). The token used in the response should be the
token that was used in the last received payload. The client can token that was used in the last received payload. The client can
then derive the Request-Tag by matching the token with the sent then derive the Request-Tag by matching the token with the sent
request. request.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
|<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9] |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9]
| [[Client responds with missing payloads]] | [[Client responds with missing payloads]]
+--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 +--------->| 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 +--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024
| [[Client continues sending next MAX_PAYLOADS_SET]] | [[Client continues sending next MAX_PAYLOAD_SET]]
+--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]] [[NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks | [[The server realizes a block is still missing and asks
| for the missing one]] | for the missing one]]
|<---------+ NON 4.08 M:0x92 T:0xef [Missing 10] |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10]
+--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024
|<---------+ NON 2.04 M:0x93 T:0xf0 |<---------+ NON 2.04 M:0x93 T:0xf0
| ... | | ... |
Figure 5: Example of a NON Request with the Q-Block1 Option Figure 6: Example of NON Request with Q-Block1 Option (Blocks
(Block Recovery) Recovery)
10.1.4. Handling Recovery if Failure Occurs 10.1.4. Handling Recovery with Failure
Figure 6 depicts an example of a NON PUT request conveying the Figure 7 depicts an example of a NON PUT request conveying Q-Block1
Q-Block1 option where recovery takes place but eventually fails. Option where recovery takes place, but eventually fails.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024 +--------->| 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 +--->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 PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]] [[NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is missing and asks | [[The server realizes a block is missing and asks
| for the missing one. Retry #1]] | for the missing one. Retry #1]]
|<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1] |<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1]
| ... | | ... |
[[2 * NON_RECEIVE_TIMEOUT (server) delay expires]] [[2 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks | [[The server realizes a block is still missing and asks
| for the missing one. Retry #2]] | for the missing one. Retry #2]]
|<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1] |<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1]
| ... | | ... |
[[4 * NON_RECEIVE_TIMEOUT (server) delay expires]] [[4 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks | [[The server realizes a block is still missing and asks
| for the missing one. Retry #3]] | for the missing one. Retry #3]]
|<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1] |<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1]
| ... | | ... |
[[8 * NON_RECEIVE_TIMEOUT (server) delay expires]] [[8 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks | [[The server realizes a block is still missing and asks
| for the missing one. Retry #4]] | for the missing one. Retry #4]]
|<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1] |<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1]
| ... | | ... |
[[16 * NON_RECEIVE_TIMEOUT (server) delay expires]] [[16 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[NON_MAX_RETRANSMIT exceeded. Server stops requesting | [[NON_MAX_RETRANSMIT exceeded. Server stops requesting
| the missing blocks and releases partial body]] | for missing blocks and releases partial body]]
| ... | | ... |
Figure 6: Example of a NON Request with the Q-Block1 Option (with Figure 7: Example of NON Request with Q-Block1 Option (With Eventual
Eventual Failure) Failure)
10.2. Q-Block2 Option 10.2. Q-Block2 Option
These examples include the Observe option to demonstrate how that These examples include the Observe Option to demonstrate how that
option is used. Note that the Observe option is not required for option is used. Note that the Observe Option is not required for
Q-Block2. Q-Block2; the observe detail can thus be ignored.
10.2.1. A Simple Example 10.2.1. A Simple Example
Figure 7 illustrates an example of the Q-Block2 option. The client Figure 8 illustrates the example of Q-Block2 Option. The client
sends a NON GET carrying the Observe and Q-Block2 options. The sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2
Q-Block2 option indicates a block size hint (1024 bytes). The server Option indicates a block size hint (1024 bytes). This request is
replies to this request using four (4) blocks that are transmitted to replied to by the server using four (4) blocks that are transmitted
the client without any loss. Each of these blocks carries a Q-Block2 to the client without any loss. Each of these blocks carries a
option. The same process is repeated when an Observe is triggered, Q-Block2 Option. The same process is repeated when an Observe is
but no loss is experienced by any of the notification blocks. triggered, but no loss is experienced by any of the notification
blocks.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024 +--------->| 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: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: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: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 |<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024 |<---------+ 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: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: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 |<---------+ 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 Figure 8: Example of NON Notifications with Q-Block2 Option (Without
(without Loss) Loss)
10.2.2. Handling MAX_PAYLOADS Limits 10.2.2. Handling MAX_PAYLOADS Limits
Figure 8 illustrates the same scenario as Figure 7, but this time Figure 9 illustrates the same as Figure 8 but this time has eleven
with eleven (11) payloads, which exceeds MAX_PAYLOADS. There is no (11) payloads which exceeds MAX_PAYLOADS. There is no loss
loss experienced. experienced.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 +--------->| 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: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 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024 |<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ 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 |<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 8: Example of NON Notifications with the Q-Block2 Option Figure 9: Example of NON Notifications with Q-Block2 Option (Without
(without Loss) Loss)
10.2.3. Handling MAX_PAYLOADS with Recovery 10.2.3. Handling MAX_PAYLOADS with Recovery
Figure 9 shows an example of an Observe that is triggered but for Figure 10 shows the example of an Observe that is triggered but for
which some notification blocks are lost. The client detects the which some notification blocks are lost. The client detects the
missing blocks and requests their retransmission. It does so by missing blocks and requests their retransmission. It does so by
indicating the blocks that are missing as one or more Q-Block2 indicating the blocks that are missing as one or more Q-Block2
options. Options.
CoAP CoAP CoAP CoAP
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ 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 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
| X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 | 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]] [[Some of MAX_PAYLOADS_SET have been received]]
| ... | | ... |
[[NON_TIMEOUT_RANDOM (server) delay expires]] [[NON_TIMEOUT_RANDOM (server) delay expires]]
| [[Server sends next MAX_PAYLOADS_SET]] | [[Server sends next MAX_PAYLOAD_SET]]
|<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 |<---------+ 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, | [[On seeing a payload from the next MAX_PAYLOAD_SET,
| client realizes blocks are missing and asks for the | Client realizes blocks are missing and asks for the
| missing ones in one go]] | missing ones in one go]]
+--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
| | QB2:9/0/1024 | | QB2:9/0/1024
| X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/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 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for | [[Client realizes block is still missing and asks for
| missing block]] | missing block]]
+--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024
|<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 9: Example of NON Notifications with the Q-Block2 Option Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks
(Block Recovery) Recovery)
10.2.4. Handling Recovery by Setting the M Bit 10.2.4. Handling Recovery using M-bit Set
Figure 10 shows an example where an Observe is triggered but only the Figure 11 shows the example of an Observe that is triggered but only
first two notification blocks reach the client. In order to retrieve the first two notification blocks reach the client. In order to
the missing blocks, the client sends a request with a single Q-Block2 retrieve the missing blocks, the client sends a request with a single
option with the M bit set. Q-Block2 Option with the M bit set.
CoAP CoAP CoAP CoAP
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 |<---------+ 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 |<---------+ 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<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024
| X<---+ [[Payloads 4 - 9 not detailed]] | X<---+ [[Payloads 4 - 9 not detailed]]
| X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 | 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]] [[Some of MAX_PAYLOADS_SET have been received]]
| ... | | ... |
[[NON_TIMEOUT_RANDOM (server) delay expires]] [[NON_TIMEOUT_RANDOM (server) delay expires]]
| [[Server sends next MAX_PAYLOADS_SET]] | [[Server sends next MAX_PAYLOAD_SET]]
| X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024 | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes blocks are missing and asks for the | [[Client realizes blocks are missing and asks for the
| missing ones in one go by setting the M bit]] | missing ones in one go by setting the M bit]]
+--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024
|<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using 'Continue' | [[MAX_PAYLOADS_SET acknowledged by client using 'Continue'
| Q-Block2]] | Q-Block2]]
+--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 10: Example of NON Notifications with the Q-Block2 Option Figure 11: Example of NON Notifications with Q-Block2 Option (Blocks
(Block Recovery with the M Bit Set) Recovery with M bit Set)
10.3. Q-Block1 and Q-Block2 Options 10.3. Q-Block1 and Q-Block2 Options
10.3.1. A Simple Example 10.3.1. A Simple Example
Figure 11 illustrates an example of a FETCH using both the Q-Block1 Figure 12 illustrates the example of a FETCH using both Q-Block1 and
and Q-Block2 options along with an Observe option. No loss is Q-Block2 Options along with an Observe Option. No loss is
experienced. experienced.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024 +--------->| 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: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 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: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: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: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 |<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024 |<---------+ 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: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: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 |<---------+ 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 Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options
Options (without Loss) (Without Loss)
10.3.2. Handling MAX_PAYLOADS Limits 10.3.2. Handling MAX_PAYLOADS Limits
Figure 12 illustrates the same scenario as Figure 11, but this time Figure 13 illustrates the same as Figure 12 but this time has eleven
with eleven (11) payloads in both directions, which exceeds (11) payloads in both directions which exceeds MAX_PAYLOADS. There
MAX_PAYLOADS. There is no loss experienced. is no loss experienced.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 +--------->| 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 +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024
+--------->| [[Payloads 3 - 9 not detailed]] +--------->| [[Payloads 3 - 9 not detailed]]
+--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024
[[MAX_PAYLOADS_SET has been received]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by server]] | [[MAX_PAYLOADS_SET acknowledged by server]]
skipping to change at line 1606 skipping to change at page 36, line 39
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 +--------->| 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 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 12: Example of a NON FETCH with the Q-Block1 and Q-Block2 Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options
Options (without Loss) (Without Loss)
Note that, as 'Continue' was used, the server continues to use the Note that as 'Continue' was used, the server continues to use the
same token (0xaa), since the 'Continue' is not being used as a same token (0xaa) since the 'Continue' is not being used as a request
request for a new set of packets but rather is being used to instruct for a new set of packets, but rather is being used to instruct the
the server to continue its transmission (Section 7.2). server to continue its transmission (Section 7.2).
10.3.3. Handling Recovery 10.3.3. Handling Recovery
Consider now a scenario where some blocks are lost in transmission, Consider now a scenario where some blocks are lost in transmission as
as illustrated in Figure 13. illustrated in Figure 14.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 +--------->| 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: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 +--->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 FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]] [[NON_RECEIVE_TIMEOUT (server) delay expires]]
Figure 13: Example of a NON FETCH with the Q-Block1 and Q-Block2 Figure 14: Example of NON FETCH with Q-Block1 and Q-Block2 Options
Options (with Loss) (With Loss)
The server realizes that some blocks are missing and asks for the 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 missing blocks in one go (Figure 15). It does so by indicating which
blocks have not been received in the data portion of the response. 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 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 received payload. The client can then derive the Request-Tag by
matching the token with the sent request. matching the token with the sent request.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
|<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2] |<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2]
| [[Client responds with missing payloads]] | [[Client responds with missing payloads]]
+--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024 +--------->| 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 +--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024
| [[Server received FETCH body, | [[Server received FETCH body,
| starts transmitting response body]] | starts transmitting response body]]
|<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024 |<---------+ 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 | 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 |<---------+ 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 | X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| | | |
Figure 14: Example of a NON Request with the Q-Block1 Option Figure 15: Example of NON Request with Q-Block1 Option (Server
(Server Recovery) Recovery)
The client realizes that not all the payloads of the response have 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 been returned. The client then asks for the missing blocks in one go
(Figure 15). Note that, following Section 2.7 of [RFC7959], the (Figure 16). Note that, following Section 2.7 of [RFC7959], the
FETCH request does not include the Q-Block1 or any payload. FETCH request does not include the Q-Block1 or any payload.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\ +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\
| | QB2:3/0/1024 | | QB2:3/0/1024
| [[Server receives FETCH request for missing payloads, | [[Server receives FETCH request for missing payloads,
| starts transmitting missing blocks]] | starts transmitting missing blocks]]
| X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024 | 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 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for | [[Client realizes block is still missing and asks for
| missing block]] | missing block]]
+--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024 +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024
| [[Server receives FETCH request for missing payload, | [[Server receives FETCH request for missing payload,
| starts transmitting missing block]] | starts transmitting missing block]]
|<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024 |<---------+ 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 | 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 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for | [[Client realizes block is still missing and asks for
| missing block]] | missing block]]
+--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024 +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024
| [[Server receives FETCH request for missing payload, | [[Server receives FETCH request for missing payload,
| starts transmitting missing block]] | starts transmitting missing block]]
|<---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024 |<---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
Figure 15: Example of a NON Request with the Q-Block1 Option Figure 16: Example of NON Request with Q-Block1 Option (Client
(Client Recovery) Recovery)
11. Security Considerations 11. Security Considerations
Security considerations discussed in Section 7 of [RFC7959] should be Security considerations discussed in Section 7 of [RFC7959] should be
taken into account. taken into account.
Security considerations discussed in Sections 11.3 and 11.4 of Security considerations discussed in Sections 11.3 and 11.4 of
[RFC7252] should also be taken into account. [RFC7252] should be taken into account.
OSCORE provides end-to-end protection of all information that is not OSCORE provides end-to-end protection of all information that is not
required for proxy operations and requires that a security context is 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 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 endpoint is legitimate even if NoSec security mode is used. However,
intermediary node can modify the unprotected Outer Q-Block1 and/or 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 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 requesting all the blocks by setting the M bit and, thus, causing
attack amplification. As discussed in Section 12.1 of [RFC8613], attack amplification. As discussed in Section 12.1 of [RFC8613],
applications need to consider that certain message fields and message applications need to consider that certain message fields and
types are not protected end to end and may be spoofed or manipulated. messages types are not protected end-to-end and may be spoofed or
Therefore, it is NOT RECOMMENDED to use the NoSec mode if either the manipulated. Therefore, it is NOT RECOMMENDED to use the NoSec
Q-Block1 or Q-Block2 option is used. security mode if either the Q-Block1 or Q-Block2 Options is used.
If OSCORE is not used, it is also NOT RECOMMENDED to use the 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. security mode if either the Q-Block1 or Q-Block2 Options is used.
If NoSec is being used, Appendix D.5 of [RFC8613] discusses the If NoSec is being used, Section D.5 of [RFC8613] discusses the
security analysis and considerations for unprotected message fields security analysis and considerations for unprotected message fields
even if OSCORE is not being used. even if OSCORE is not being used.
Security considerations related to the use of Request-Tag are Security considerations related to the use of Request-Tag are
discussed in Section 5 of [RFC9175]. discussed in Section 5 of [I-D.ietf-core-echo-request-tag].
12. IANA Considerations 12. IANA Considerations
RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be
assigned to this document.
12.1. CoAP Option Numbers Registry 12.1. CoAP Option Numbers Registry
IANA has added the following entries to the "CoAP Option Numbers" IANA is requested to add the following entries to the "CoAP Option
subregistry [IANA-Options] defined in [RFC7252] within the Numbers" sub-registry [Options] defined in [RFC7252] within the
"Constrained RESTful Environments (CoRE) Parameters" registry: "Constrained RESTful Environments (CoRE) Parameters" registry:
+========+==========+===========+ +--------+------------------+-----------+
| Number | Name | Reference | | Number | Name | Reference |
+========+==========+===========+ +========+==================+===========+
| 19 | Q-Block1 | RFC 9177 | | TBA1 | Q-Block1 | [RFCXXXX] |
+--------+----------+-----------+ | TBA2 | Q-Block2 | [RFCXXXX] |
| 31 | Q-Block2 | RFC 9177 | +--------+------------------+-----------+
+--------+----------+-----------+
Table 4: Additions to CoAP Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers
Option Numbers Registry
This document suggests 19 (TBA1) and 31 (TBA2) as values to be
assigned for the new option numbers.
12.2. Media Type Registration 12.2. Media Type Registration
IANA has registered the "application/missing-blocks+cbor-seq" media This document requests IANA to register the "application/missing-
type in the "Media Types" registry [IANA-MediaTypes]. This blocks+cbor-seq" media type in the "Media Types" registry
registration follows the procedures specified in [RFC6838]. [IANA-MediaTypes]. This registration follows the procedures
specified in [RFC6838]:
Type name: application Type name: application
Subtype name: missing-blocks+cbor-seq Subtype name: missing-blocks+cbor-seq
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: Must be encoded as a CBOR Sequence Encoding considerations: Must be encoded as a CBOR
[RFC8742], as defined in Section 5 of RFC 9177. sequence [RFC8742], as defined in Section 4 of [RFCXXXX].
Security considerations: See Section 11 of RFC 9177. Security considerations: See Section 10 of [RFCXXXX].
Interoperability considerations: N/A Interoperability considerations: N/A
Published specification: RFC 9177 Published specification: [RFCXXXX]
Applications that use this media type: Data serialization and Applications that use this media type: Data serialization and
deserialization. In particular, the type is used by applications deserialization. In particular, the type is used by applications
relying upon block-wise transfers, allowing a server to specify relying upon block-wise transfers, allowing a server to specify
non-received blocks and request their retransmission, as defined non-received blocks and request for their retransmission, as
in Section 4 of RFC 9177. defined in Section 4 of [RFCXXXX].
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: N/A Additional information: N/A
Person & email address to contact for further information: IETF, Person & email address to contact for further information: IETF,
iesg@ietf.org iesg@ietf.org
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: See Authors' Addresses section of RFC 9177. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
Provisional registration? No Provisional registration? No
12.3. CoAP Content-Formats Registry 12.3. CoAP Content-Formats Registry
IANA has registered the following CoAP Content-Format for the This document requests IANA to register the following CoAP Content-
"application/missing-blocks+cbor-seq" media type in the "CoAP Format for the "application/missing-blocks+cbor-seq" media type in
Content-Formats" registry [IANA-Format] defined in [RFC7252] within the "CoAP Content-Formats" registry [Format], defined in [RFC7252],
the "Constrained RESTful Environments (CoRE) Parameters" registry: within the "Constrained RESTful Environments (CoRE) Parameters"
registry:
+=====================================+==========+=====+===========+ o Media Type: application/missing-blocks+cbor-seq
| Media Type | Encoding | ID | Reference | o Encoding: -
+=====================================+==========+=====+===========+ o Id: TBA3
| application/missing-blocks+cbor-seq | - | 272 | RFC 9177 | o Reference: [RFCXXXX]
+-------------------------------------+----------+-----+-----------+
Table 5: Addition to CoAP Content-Format Registry This document suggests 272 (TBA3) as a value to be assigned for the
new content format number.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J. P., and G. Selander, "CoAP:
Echo, Request-Tag, and Token Processing", draft-ietf-core-
echo-request-tag-12 (work in progress), February 2021.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
skipping to change at line 1881 skipping to change at page 42, line 40
[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR) [RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020, Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
<https://www.rfc-editor.org/info/rfc8742>. <https://www.rfc-editor.org/info/rfc8742>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <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>.
13.2. Informative References 13.2. Informative References
[DOTS-QUICK-BLOCKS] [Format] "CoAP Content-Formats", <https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#content-formats>.
[I-D.bosh-dots-quick-blocks]
Boucadair, M. and J. Shallow, "Distributed Denial-of- Boucadair, M. and J. Shallow, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Configuration Attributes for Robust Block Transmission", Configuration Attributes for Faster Block Transmission",
Work in Progress, Internet-Draft, draft-bosh-dots-quick- draft-bosh-dots-quick-blocks-01 (work in progress),
blocks-03, 29 June 2021, January 2021.
<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>.
[IANA-Format] [I-D.ietf-dots-telemetry]
IANA, "CoAP Content-Formats", Boucadair, M., Reddy, T., Doron, E., Chen, M., and J.
<https://www.iana.org/assignments/core-parameters/>. Shallow, "Distributed Denial-of-Service Open Threat
Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15
(work in progress), December 2020.
[IANA-MediaTypes] [IANA-MediaTypes]
IANA, "Media Types", IANA, "Media Types",
<https://www.iana.org/assignments/media-types/>. <https://www.iana.org/assignments/media-types>.
[IANA-Options] [Options] "CoAP Option Numbers", <https://www.iana.org/assignments/
IANA, "CoAP Option Numbers", core-parameters/core-parameters.xhtml#option-numbers>.
<https://www.iana.org/assignments/core-parameters/>.
[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
"Increasing TCP's Initial Window", RFC 6928, "Increasing TCP's Initial Window", RFC 6928,
DOI 10.17487/RFC6928, April 2013, DOI 10.17487/RFC6928, April 2013,
<https://www.rfc-editor.org/info/rfc6928>. <https://www.rfc-editor.org/info/rfc6928>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967, No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>. August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
<https://www.rfc-editor.org/info/rfc8782>.
[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and [RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and
Stateless Clients in the Constrained Application Protocol Stateless Clients in the Constrained Application Protocol
(CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021, (CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,
<https://www.rfc-editor.org/info/rfc8974>. <https://www.rfc-editor.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>.
Appendix A. Examples with Confirmable Messages Appendix A. Examples with Confirmable Messages
The following examples assume NSTART has been increased to 3. The following examples assume NSTART has been increased to 3.
The conventions provided in Section 10 are used in the following The notations provided in Figure 2 are used in the following
subsections. subsections.
A.1. Q-Block1 Option A.1. Q-Block1 Option
Let's now consider the use of the Q-Block1 option with a CON request, Let's now consider the use of Q-Block1 Option with a CON request as
as shown in Figure 16. All the blocks are acknowledged (as noted shown in Figure 17. All the blocks are acknowledged (ACK).
with "ACK").
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 +--------->| 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:0x02 T:0xf1 RT=10 QB1:1/1/1024
+--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
[[NSTART(3) limit reached]] [[NSTART(3) limit reached]]
|<---------+ ACK 0.00 M:0x01 |<---------+ ACK 0.00 M:0x01
+--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
|<---------+ ACK 0.00 M:0x02 |<---------+ ACK 0.00 M:0x02
|<---------+ ACK 0.00 M:0x03 |<---------+ ACK 0.00 M:0x03
|<---------+ ACK 2.04 M:0x04 |<---------+ ACK 2.04 M:0x04
| | | |
Figure 16: Example of a CON Request with the Q-Block1 Option Figure 17: Example of CON Request with Q-Block1 Option (Without Loss)
(without Loss)
Now, suppose that a new body of data is to be sent but with some 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 blocks dropped in transmission as illustrated in Figure 18. The
client will retry sending blocks for which no ACK was received. client will retry sending blocks for which no ACK was received.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 +--------->| 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:0x06 T:0xf5 RT=11 QB1:1/1/1024
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
[[NSTART(3) limit reached]] [[NSTART(3) limit reached]]
|<---------+ ACK 0.00 M:0x05 |<---------+ ACK 0.00 M:0x05
+--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024
|<---------+ ACK 0.00 M:0x08 |<---------+ ACK 0.00 M:0x08
| ... | | ... |
[[ACK TIMEOUT (client) for M:0x06 delay expires]] [[ACK_TIMEOUT (client) for M:0x06 delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
[[ACK TIMEOUT (client) for M:0x07 delay expires]] [[ACK_TIMEOUT (client) for M:0x07 delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
|<---------+ ACK 0.00 M:0x06 |<---------+ ACK 0.00 M:0x06
| ... | | ... |
[[ACK TIMEOUT exponential backoff (client) delay expires]] [[ACK_TIMEOUT exponential backoff (client) delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
| ... | | ... |
[[Either body transmission failure (acknowledge retry timeout) [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted]] or successfully transmitted.]]
Figure 17: Example of a CON Request with the Q-Block1 Option Figure 18: Example of CON Request with Q-Block1 Option (Blocks
(Block Recovery) Recovery)
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload or separately tries to initiate the MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions. under these adverse traffic conditions.
If transient network losses are possible, then the use of NON should If there is likely to be the possibility of transient network losses,
be considered. then the use of NON should be considered.
A.2. Q-Block2 Option A.2. Q-Block2 Option
An example of the use of the Q-Block2 option with Confirmable An example of the use of Q-Block2 Option with Confirmable messages is
messages is shown in Figure 18. shown in Figure 19.
Client Server Client Server
| | | |
+--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 +--------->| 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 |<---------+ 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: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: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 |<---------+ CON 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xe1 |--------->+ ACK 0.00 M:0xe1
|--------->+ ACK 0.00 M:0xe2 |--------->+ ACK 0.00 M:0xe2
|--------->+ ACK 0.00 M:0xe3 |--------->+ ACK 0.00 M:0xe3
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ 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: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 |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024
[[NSTART(3) limit reached]] [[NSTART(3) limit reached]]
|--------->+ ACK 0.00 M:0xe4 |--------->+ ACK 0.00 M:0xe4
|<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xe5 |--------->+ ACK 0.00 M:0xe5
|--------->+ ACK 0.00 M:0xe6 |--------->+ ACK 0.00 M:0xe6
|--------->+ ACK 0.00 M:0xe7 |--------->+ ACK 0.00 M:0xe7
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ 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: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 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
[[NSTART(3) limit reached]] [[NSTART(3) limit reached]]
|--------->+ ACK 0.00 M:0xe8 |--------->+ ACK 0.00 M:0xe8
|<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xeb |--------->+ ACK 0.00 M:0xeb
| ... | | ... |
[[ACK TIMEOUT (server) for M:0xe9 delay expires]] [[ACK_TIMEOUT (server) for M:0xe9 delay expires]]
| [[Server retransmits packet]] | [[Server retransmits packet]]
|<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
[[ACK TIMEOUT (server) for M:0xea delay expires]] [[ACK_TIMEOUT (server) for M:0xea delay expires]]
| [[Server retransmits packet]] | [[Server retransmits packet]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
|--------->+ ACK 0.00 M:0xe9 |--------->+ ACK 0.00 M:0xe9
| ... | | ... |
[[ACK TIMEOUT exponential backoff (server) delay expires]] [[ACK_TIMEOUT exponential backoff (server) delay expires]]
| [[Server retransmits packet]] | [[Server retransmits packet]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
| ... | | ... |
[[Either body transmission failure (acknowledge retry timeout) [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted]] or successfully transmitted.]]
Figure 18: Example of CON Notifications with the Q-Block2 Option Figure 19: Example of CON Notifications with Q-Block2 Option
It is up to the implementation as to whether the application process It is up to the implementation as to whether the application process
stops trying to send this particular body of data on reaching stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload or separately tries to initiate the MAX_RETRANSMIT for any payload, or separately tries to initiate the
new transmission of the payloads that have not been acknowledged new transmission of the payloads that have not been acknowledged
under these adverse traffic conditions. under these adverse traffic conditions.
If transient network losses are possible, then the use of NON should If there is likely to be the possibility of transient network losses,
be considered. then the use of NON should be considered.
Appendix B. Examples with Reliable Transports Appendix B. Examples with Reliable Transports
The conventions provided in Section 10 are used in the following The notations provided in Figure 2 are used in the following
subsections. subsections.
B.1. Q-Block1 Option B.1. Q-Block1 Option
Let's now consider the use of the Q-Block1 option with a reliable Let's now consider the use of Q-Block1 Option with a reliable
transport, as shown in Figure 19. There is no acknowledgment of transport as shown in Figure 20. There is no acknowledgment of
packets at the CoAP layer, just the final result. packets at the CoAP layer, just the final result.
CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024 +--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024
+--------->| PUT /path T:0xf1 RT=10 QB1:1/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:0xf2 RT=10 QB1:2/1/1024
+--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024 +--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024
|<---------+ 2.04 |<---------+ 2.04
| | | |
Figure 19: Example of a Reliable Request with the Q-Block1 Option Figure 20: Example of Reliable Request with Q-Block1 Option
If transient network losses are possible, then the use of unreliable If there is likely to be the possibility of transient network losses,
transport with NON should be considered. then the use of unreliable transport with NON should be considered.
B.2. Q-Block2 Option B.2. Q-Block2 Option
An example of the use of the Q-Block2 option with a reliable An example of the use of Q-Block2 Option with a reliable transport is
transport is shown in Figure 20. shown in Figure 21.
Client Server Client Server
| | | |
+--------->| GET /path T:0xf0 O:0 QB2:0/1/1024 +--------->| 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:0/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:1/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:2/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ 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:1/1/1024
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:2/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 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:3/0/1024
| ... | | ... |
Figure 20: Example of Notifications with the Q-Block2 Option Figure 21: Example of Notifications with Q-Block2 Option
If transient network losses are possible, then the use of unreliable If there is likely to be the possibility of network transient losses,
transport with NON should be considered. then the use of unreliable transport with NON should be considered.
Acknowledgments Acknowledgements
Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their
comments. comments.
Special thanks to Christian Amsüss, Carsten Bormann, and Marco Tiloca Special thanks to Christian Amsuess, Carsten Bormann, and Marco
for their suggestions and several reviews, which improved this Tiloca for their suggestions and several reviews, which improved this
specification significantly. Thanks to Francesca Palombini for the specification significantly. Thanks to Francesca Palombini for the
AD review. Thanks to Pete Resnick for the Gen-ART review, Colin AD review.
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.
Some text from [RFC7959] is reused for the readers' convenience. Thanks to Pete Resnick for the Gen-ART review, Colin Perkins for the
Tsvart review, and Emmanuel Baccelli for the Iotdir review. Thanks
to Martin Duke, Eric Vyncke, Benjamin Kaduk, Roman Danyliw, John
Scudder, and Lars Eggert for the IESG review.
Some text from [RFC7959] is reused for readers convenience.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
35000 Rennes Rennes 35000
France France
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.com
Jon Shallow Jon Shallow
United Kingdom United Kingdom
Email: supjps-ietf@jpshallow.com Email: supjps-ietf@jpshallow.com
 End of changes. 304 change blocks. 
1114 lines changed or deleted 1097 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/