draft-ietf-core-new-block-09.txt   draft-ietf-core-new-block-10.txt 
CoRE Working Group M. Boucadair CoRE Working Group M. Boucadair
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track J. Shallow Intended status: Standards Track J. Shallow
Expires: September 17, 2021 March 16, 2021 Expires: October 16, 2021 April 14, 2021
Constrained Application Protocol (CoAP) Block-Wise Transfer Options for Constrained Application Protocol (CoAP) Block-Wise Transfer Options for
Faster Transmission Faster Transmission
draft-ietf-core-new-block-09 draft-ietf-core-new-block-10
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 Options. (CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.
These options are similar to the CoAP Block1 and Block2 Options These options are similar to the CoAP Block1 and Block2 Options
defined in RFC 7959, not a replacement for them, but do enable faster defined in RFC 7959, not a replacement for them, but do enable faster
transmission rates for large amounts of data with less packet transmission rates for large amounts of data with less packet
interchanges. Also, Q-Block1 and Q-Block2 Options support faster interchanges. Also, Q-Block1 and Q-Block2 Options support faster
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 17, 2021. This Internet-Draft will expire on October 16, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 5 3. Alternative CoAP Block-Wise Transfer Options . . . . . . . . 4
1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5 3.1. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Applicability Scope . . . . . . . . . . . . . . . . . . . 6
3. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 7 4. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 7
3.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 7 4.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 7
3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 9 4.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 9
3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9 4.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9
3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 13 4.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 13
3.5. Using Observe Option . . . . . . . . . . . . . . . . . . 15 4.5. Using Observe Option . . . . . . . . . . . . . . . . . . 16
3.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15 4.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 16
3.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 16 4.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 16
3.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16 4.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16
4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16 5. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16
5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 17 6. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 18
6. Congestion Control for Unreliable Transports . . . . . . . . 17 7. Congestion Control for Unreliable Transports . . . . . . . . 18
6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18 7.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18
6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 18 7.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 19
7. Caching Considerations . . . . . . . . . . . . . . . . . . . 22 8. Caching Considerations . . . . . . . . . . . . . . . . . . . 22
8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 23 9. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 23
9. Examples with Non-confirmable Messages . . . . . . . . . . . 23 10. Examples with Non-confirmable Messages . . . . . . . . . . . 23
9.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 23 10.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . 24
9.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 23 10.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 24
9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 24 10.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 24
9.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 24 10.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 25
9.1.4. Handling Recovery with Failure . . . . . . . . . . . 26 10.1.4. Handling Recovery with Failure . . . . . . . . . . . 26
9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 26 10.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . 27
9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 27 10.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 27
9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 27 10.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 28
9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 28 10.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . 29
9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 29 10.2.4. Handling Recovery using M-bit Set . . . . . . . . . 30
9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 30 10.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . 31
9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 30 10.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 31
9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 31 10.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 32
9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 32 10.3.3. Handling Recovery . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 11. Security Considerations . . . . . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
11.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 35 12.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 36
11.2. Media Type Registration . . . . . . . . . . . . . . . . 35 12.2. Media Type Registration . . . . . . . . . . . . . . . . 36
11.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 36 12.3. CoAP Content-Formats Registry . . . . . . . . . . . . . 37
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . . 37 13.1. Normative References . . . . . . . . . . . . . . . . . . 38
12.2. Informative References . . . . . . . . . . . . . . . . . 38 13.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Examples with Confirmable Messages . . . . . . . . . 39 Appendix A. Examples with Confirmable Messages . . . . . . . . . 40
A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 39 A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 40
A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 41 A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 42
Appendix B. Examples with Reliable Transports . . . . . . . . . 43 Appendix B. Examples with Reliable Transports . . . . . . . . . 44
B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 43 B.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 44
B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 43 B.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 44
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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. [RFC7959] delivery, simple congestion control, and flow control. [RFC7959]
introduced the CoAP Block1 and Block2 Options to handle data records introduced the CoAP Block1 and Block2 Options to handle data records
that cannot fit in a single IP packet, so not having to rely on IP that cannot fit in a single IP packet, so not having to rely on IP
fragmentation and was further updated by [RFC8323] for use over TCP, fragmentation and was further updated by [RFC8323] for use over TCP,
skipping to change at page 3, line 47 skipping to change at page 3, line 47
higher rates under network conditions where there may be asymmetrical higher rates under network conditions where there may be asymmetrical
transient packet loss (i.e., responses may get dropped). An example transient packet loss (i.e., responses may get dropped). An example
is when a network is subject to a Distributed Denial of Service is when a network is subject to a Distributed Denial of Service
(DDoS) attack and there is a need for DDoS mitigation agents relying (DDoS) attack and there is a need for DDoS mitigation agents relying
upon CoAP to communicate with each other (e.g., upon CoAP to communicate with each other (e.g.,
[RFC8782][I-D.ietf-dots-telemetry]). As a reminder, [RFC7959] [RFC8782][I-D.ietf-dots-telemetry]). As a reminder, [RFC7959]
recommends the use of Confirmable (CON) responses to handle potential recommends the use of Confirmable (CON) responses to handle potential
packet loss. However, such a recommendation does not work with a packet loss. However, such a recommendation does not work with a
flooded pipe DDoS situation. flooded pipe DDoS situation.
1.1. Alternative CoAP Block-Wise Transfer Options This document introduces the CoAP Q-Block1 and Q-Block2 Options
(Section 3).
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers should be familiar with the terms and concepts defined in
[RFC7252], [RFC7959], and [RFC8132].
The terms "payload" and "body" are defined in [RFC7959]. The term
"payload" is thus used for the content of a single CoAP message
(i.e., a single block being transferred), while the term "body" is
used for the entire resource representation that is being transferred
in a block-wise fashion.
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 similar in operation to the CoAP Block1 and Block2 These options are similar in operation to the CoAP Block1 and Block2
Options, respectively. They are not a replacement for them, but have Options, respectively. They are not a replacement for them, but have
the following benefits: the following benefits:
o They can operate in environments where packet loss is highly o They can operate in environments where packet loss is highly
asymmetrical. asymmetrical.
o They enable faster transmissions of sets of blocks of data with o They enable faster transmissions of sets of blocks of data with
skipping to change at page 4, line 24 skipping to change at page 4, line 48
o They support sending an entire body using Non-confirmable (NON) o They support sending an entire body using Non-confirmable (NON)
messages without requiring a response from the peer. messages without requiring a response from the peer.
There are the following disadvantages over using CoAP Block1 and There are the following disadvantages over using CoAP Block1 and
Block2 Options: Block2 Options:
o Loss of lock-stepping so payloads are not always received in the o Loss of lock-stepping so payloads are not always received in the
correct (block ascending) order. correct (block ascending) order.
o 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 6.2). NON messages (Section 7.2).
o To reduce the transmission times for CON transmission 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 where other parameters need to be tuned congestion control where other parameters need to be tuned
(Section 4.7 of [RFC7252]). Such tuning is out of scope of this (Section 4.7 of [RFC7252]). Such tuning is out of scope of this
document. document.
o Mixing of NON and CON during requests/responses using Q-Block is o Mixing of NON and CON during requests/responses using Q-Block is
not supported. not supported.
skipping to change at page 5, line 26 skipping to change at page 5, line 50
messages are provided in Appendix A. 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.
Q-Block1 and Q-Block2 Options can be used instead of Block1 and Q-Block1 and Q-Block2 Options can be used instead of Block1 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 Block1 and Block2 Options. transmissions can fall back to using Block1 and Block2 Options
(Section 4.1).
The deviations from Block1 and Block2 Options are specified in The deviations from Block1 and Block2 Options are specified in
Section 3. Pointers to appropriate [RFC7959] sections are provided. Section 4. Pointers to appropriate [RFC7959] sections are 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 introduced in [RFC8132]. iPATCH introduced in [RFC8132].
The No-Response Option was considered but was abandoned as it does The No-Response Option [RFC7967] was considered but was abandoned as
not apply to Q-Block2 responses. A unified solution is defined in it does not apply to Q-Block2 responses. A unified solution is
the document. defined in the document.
1.2. 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 4 for more details. See Section 5 for more details.
1.3. 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, but falls short in situations where packet loss is highly case, but falls short in situations where packet loss is highly
asymmetrical. The mechanism specified in this document provides asymmetrical. The mechanism specified in this document provides
roughly similar features to the Block1/Block2 Options. It provides roughly similar features to the Block1/Block2 Options. It provides
additional properties that are tailored towards the intended use case additional properties that are tailored towards the intended use case
of Non-Confirmable transmission. Concretely, this mechanism of Non-Confirmable transmission. Concretely, this mechanism
primarily targets applications such as DDoS Open Threat Signaling primarily targets applications such as DDoS Open Threat Signaling
(DOTS) that cannot use CON responses to handle potential packet loss (DOTS) that cannot use CON responses to handle 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 able to handle the messages sent by a CoAP the remote peer is able to handle the messages sent by a CoAP
endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]). endpoint (e.g., DOTS heartbeats in Section 4.7 of [RFC8782]).
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 6 for more details. Section 7 for more details.
This mechanism is not intended for general CoAP usage, and any use This mechanism is not intended for general CoAP usage, and any use
outside the intended use case should be carefully weighed against the outside the intended use case should be carefully weighed against the
loss of interoperability with generic CoAP applications. It is hoped loss of interoperability with generic CoAP applications. It is hoped
that the experience gained with this mechanism can feed future that the experience gained with this mechanism can feed future
extensions of the block-wise mechanism that will both be generally extensions of the block-wise mechanism that will both be generally
applicable and serve this particular use case. applicable and serve this particular use case.
It is not recommended that these options are used in a NoSec security It is not recommended that these options are used in a NoSec security
mode (Section 9 of [RFC7252]) as the source endpoint needs to be mode (Section 9 of [RFC7252]) as the source endpoint needs to be
trusted. Using OSCORE [RFC8613] does provide a security context and, trusted. Using OSCORE [RFC8613] does provide a security context and,
hence, a trust of the source endpoint. However, using a NoSec hence, a trust of the source endpoint. However, using a NoSec
security mode may still be inadequate for reasons discussed in security mode may still be inadequate for reasons discussed in
Section 10. Section 11.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
Readers should be familiar with the terms and concepts defined in
[RFC7252], [RFC7959], and [RFC8132].
The terms "payload" and "body" are defined in [RFC7959]. The term
"payload" is thus used for the content of a single CoAP message
(i.e., a single block being transferred), while the term "body" is
used for the entire resource representation that is being transferred
in a block-wise fashion.
3. The Q-Block1 and Q-Block2 Options 4. The Q-Block1 and Q-Block2 Options
3.1. Properties of 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 [RFC7252] (Section 5.10). 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
defined in Section 5.4 of [RFC7252]. Only Critical and UnSafe defined in Section 5.4 of [RFC7252]. Only Critical and UnSafe
columns are marked for the Q-Block1 Option. Critical, UnSafe, and columns are marked for the Q-Block1 Option. Critical, UnSafe, and
Repeatable columns are marked for the Q-Block2 Option. As these Repeatable columns are marked for the Q-Block2 Option. As these
options are UnSafe, NoCacheKey has no meaning and so is marked with a options are UnSafe, NoCacheKey has no meaning and so is marked with a
dash. dash.
skipping to change at page 7, line 31 skipping to change at page 7, line 38
+========+===+===+===+===+==============+========+========+=========+ +========+===+===+===+===+==============+========+========+=========+
| TBA1 | 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) | | TBA2 | 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.
The Content-Format Option applies to the body, not to the payload When the Content-Format Option is present together with the Q-Block1
or Q-Block2 Option, the option applies to the body not to the payload
(i.e., it must be the same for all payloads of the same body). (i.e., it must be the same for all payloads of the same body).
Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
PATCH, and iPATCH requests and their responses. PATCH, and iPATCH requests and their responses.
Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
iPATCH requests and their payload-bearing responses (2.01, 2.02, iPATCH requests and their payload-bearing responses (2.01, 2.02,
2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]). 2.03, 2.04, and 2.05) (Section 5.5 of [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 Q-Block1 Option is present in a request or Q-Block2 Option in a If Q-Block1 Option is present in a request or Q-Block2 Option in a
response (i.e., in that message to the payload of which it pertains), response (i.e., in that message to the payload of which it pertains),
it indicates a block-wise transfer and describes how this specific it indicates a block-wise transfer and describes how this specific
block-wise payload forms part of the entire body being transferred. block-wise payload forms part of the entire body being transferred.
If it is present in the opposite direction, it provides additional If it is present in the opposite direction, it provides additional
control on how that payload will be formed or was processed. control on how that payload will be 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, the Q-Block2 include the Q-Block2 Option in a GET or similar request (FETCH, for
Option in a PUT or similar request, or the Q-Block1 Option in a PUT example), the Q-Block2 Option in a PUT or similar request, or the
or similar request so that the server knows that the client supports Q-Block1 Option in a PUT or similar request so that the server knows
this Q-Block2 functionality should it need to send back a body that that the client supports this Q-Block2 functionality should it need
spans multiple payloads. Otherwise, the server would use the Block2 to send back a body that spans multiple payloads. Otherwise, the
Option (if supported) to send back a message body that is too large server would use the Block2 Option (if supported) to send back a
to fit into a single IP packet [RFC7959]. message body that is too large to fit into a single IP packet
[RFC7959].
How a client decides whether it needs to include a Q-Block1 or
Q-Block2 Option can be driven by a local configuration knob,
triggered by an application (DOTS, for example), etc. Such
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 it is present in a CoAP message, it MUST be optional. However, when it is present in a CoAP message, it MUST be
processed (or the message rejected). Therefore, Q-Block1 and processed (or the message rejected). Therefore, Q-Block1 and
Q-Block2 Options are identified as Critical options. Q-Block2 Options are identified as 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
skipping to change at page 9, line 8 skipping to change at page 9, line 24
| Number | Name | E | U | | Number | Name | E | U |
+========+=================+===+===+ +========+=================+===+===+
| TBA1 | Q-Block1 | x | x | | TBA1 | Q-Block1 | x | x |
| TBA2 | Q-Block2 | x | x | | TBA2 | Q-Block2 | x | x |
+--------+-----------------+---+---+ +--------+-----------------+---+---+
Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options
Note that if Q-Block1 or Q-Block2 Options are included in a packet as Note that if Q-Block1 or Q-Block2 Options are included in a packet as
Inner options, Block1 or Block2 Options MUST NOT be included as Inner Inner options, Block1 or Block2 Options MUST NOT be included as Inner
options. Similarly there MUST NOT be a mix of Q-Block and Block for options. Similarly there MUST NOT be a mix of Q-Block and Block for
the Outer options. Q-Block and Block Options can be mixed across the Outer options. Messages that do not adhere with this behavior
Inner and Outer options as these are handled independently of each MUST be rejected with 4.02 (Bad Option). Q-Block and Block Options
other. can be mixed across Inner and Outer options as these are handled
independently of each other.
3.2. Structure of Q-Block1 and Q-Block2 Options 4.2. Structure of Q-Block1 and Q-Block2 Options
The structure of Q-Block1 and Q-Block2 Options follows the structure The structure of Q-Block1 and Q-Block2 Options follows the 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. 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 explicit size implied by the value of 16 bytes, there is no specific explicit size implied by the
absence of the option -- the size is left unspecified. (As for any absence of the option -- the size is left unspecified. (As for any
uint, the explicit value 0 is efficiently indicated by a zero-length uint, the explicit value 0 is efficiently indicated by a zero-length
option; this, therefore, is different in semantics from the absence option; this, therefore, is different in semantics from the absence
of the option). of the option).
3.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 Q-Block1 Option is used, the client MUST include a Request-Tag When Q-Block1 Option is used, the client MUST include a Request-Tag
Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST
be the same for all of the requests for the body of data that is be the same for all of the requests for the body of data that is
being transferred. It is also used to identify a particular payload being transferred. The Request-Tag is opaque, the server still
of a body that needs to be retransmitted. The Request-Tag is opaque, treats it as opaque but the client MUST ensure that it is unique for
the server still treats it as opaque but the client SHOULD ensure every different body of transmitted data.
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 3.6 discusses the use of 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 the Non-confirmable transmission, no response is required until the
successful receipt of the body by the server or some of the payloads successful receipt of the body by the server or some of the payloads
have not arrived after a timeout and a retransmit missing payloads have not arrived after a timeout and a retransmit missing payloads
response is needed. For reliable transports (e.g., [RFC8323]), a response is needed. For reliable transports (e.g., [RFC8323]), a
response is not required until successful receipt of the body by the response is not required until successful receipt of the body by the
server. server.
Each individual payload of the body is treated as a new request Each individual message that carries a block of the body is treated
(Section 5). as a new request (Section 6).
The client MUST send the payloads with the block numbers increasing, The client MUST send the payloads with the block numbers increasing,
starting from zero, until the body is complete (subject to any starting from zero, until the body is complete (subject to any
congestion control (Section 6)). Any missing payloads requested by congestion control (Section 7)). Any missing payloads requested by
the server must in addition be separately transmitted with increasing the server must in addition be separately transmitted with increasing
block numbers. 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 used SHOULD be from and that the resource was created. The token used MUST be any
the last received payload. The client should then release all of token that was received in a request using the same Request-Tag.
the tokens used for this body. However, it is desirable to provide the one used in the last
received request, since that will aid any troubleshooting. The
client should then release all of the tokens used for this body.
Note that the last received payload may not be the one 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
[RFC7252]). The token used SHOULD be from the last received [RFC7252]). The token used MUST be any token that was received in
payload. The client should then release all of the tokens used a request using the same Request-Tag. However, it is desirable to
for this body. provide the one used in the last received request. The client
should then release all of the tokens used for this 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 used SHOULD be from and that the resource was updated. The token used MUST be any
the last received payload. The client should then release all of token that was received in a request using the same Request-Tag.
the tokens used for this body. However, it is desirable to provide the one used in the last
received request. The client should then release all of the
tokens used for this body.
2.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 used in the response SHOULD be from the last received token used MUST be any token that was received in a request using
payload. the same Request-Tag. However, it is desirable to 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 initial response for MUST use the same token as used for the initial response for
returning any Observe triggered responses so that the client can returning any Observe triggered responses so that the client can
match them up. 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 unless a resource is being observed. body unless a resource is being observed.
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 used SHOULD M bit set) have been successfully received. The token used MUST
be from the last received payload. be any token that was received in a request using the same
Request-Tag. However, it is desirable to provide the one used in
the last received request.
A response using this Response Code SHOULD NOT be generated for A response using this Response Code SHOULD NOT be generated for
every received Q-Block1 Option request. It SHOULD only be every received Q-Block1 Option request (Section 7.2). It SHOULD
generated when all the payload requests are Non-confirmable and a only be generated when all the payload requests are Non-
set of MAX_PAYLOADS (Section 6.2) payloads have been received by confirmable and a set of MAX_PAYLOADS payloads have been received
the server. by the server. More details about the motivations for this
optimization are discussed in Section 7.2.
It SHOULD NOT be generated for CON. It SHOULD NOT be generated for CON.
4.00 (Bad Request) 4.00 (Bad Request)
This Response Code MUST be returned if the request does not This Response Code MUST be returned if the request does not
include neither a Request-Tag Option nor a Size1 Option but does include neither a Request-Tag Option nor a Size1 Option but does
include a Q-Block1 option. include a Q-Block1 option.
4.02 (Bad Option) 4.02 (Bad Option)
Either this Response Code (in case of Confirmable request) or a Either this Response Code (in case of Confirmable request) or a
reset message (in case of Non-confirmable request) MUST be reset message (in case of Non-confirmable request) MUST be
returned if the server does not support the Q-Block Options. returned if the server does not support the Q-Block Options.
4.08 (Request Entity Incomplete) 4.08 (Request Entity Incomplete)
This Response Code returned without Content-Type "application/ As a reminder, this Response Code returned without Content-Type
missing-blocks+cbor-seq" (Section 11.3) is handled as in "application/missing-blocks+cbor-seq" (Section 12.3) is handled as
Section 2.9.2 [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
missing payloads using the same Request-Tag, Size1 and Q-Block1 to missing payloads using the same Request-Tag, Size1 and Q-Block1 to
specify the block NUM, SZX, and M bit as appropriate. specify the block NUM, SZX, and M bit as appropriate.
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 used in the response SHOULD be from the last received The token used MUST be any token that was received in a request
payload. See Section 4 for further information. using the same Request-Tag. However, it is desirable to provide
the one used in the last received request. See Section 5 for
further information.
If the server has not received all the payloads 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 up to or more NON payloads have been received, it SHOULD wait for up to
NON_RECEIVE_TIMEOUT (Section 6.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 similar conditions 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 4.08 Further considerations related to the transmission timings of 4.08
(Request Entity Incomplete) and 2.31 (Continue) Response Codes are (Request Entity Incomplete) and 2.31 (Continue) Response Codes are
discussed in Section 6.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 has same resource, it should continue to process all the bodies as it has
no way of determining which is the latest version, or which body, if no way of determining which is the latest version, or which body, 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, it If the client elects to stop the transmission of a complete body, and
SHOULD "forget" all tracked tokens associated with the body's absent any local policy, the client MUST "forget" all tracked tokens
Request-Tag so that a reset message is generated for the invalid associated with the body's Request-Tag so that a reset message is
token in the 4.08 (Request Entity Incomplete) response. The server generated for the invalid token in the 4.08 (Request Entity
on receipt of the reset message SHOULD delete the partial body. Incomplete) response. The server on receipt of the reset message
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 SHOULD ignore the payload of the packet, but MUST still respond as it MUST ignore the payload of the packet, but MUST still respond as
if the block was received for the first time. if the block was received for the first time.
A server SHOULD only maintain a partial body (missing payloads) for A server SHOULD maintain a partial body (missing payloads) for up to
up to NON_PARTIAL_TIMEOUT (Section 6.2). NON_PARTIAL_TIMEOUT (Section 7.2).
3.4. Using the Q-Block2 Option 4.4. Using the Q-Block2 Option
In a request for any block number, the M bit unset 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 set of MAX_PAYLOADS payloads (the used to confirm that the current set of MAX_PAYLOADS payloads (the
latest one having block number NUM-1) has been successfully latest one having block number NUM-1) has been successfully
skipping to change at page 13, line 41 skipping to change at page 14, line 18
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, the client still treats it as opaque but the The ETag is opaque, the client still treats it as opaque but the
server SHOULD ensure that it is unique for every different body of server MUST ensure that it is unique for every different body of
transmitted data. 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 3.6 discusses the use of 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.
The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2) The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 7.2)
after the last received payload for NON payloads before issuing a after the last received payload for NON payloads before issuing a
GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
more Q-Block2 Options that define the missing blocks with the M bit more Q-Block2 Options that define the missing blocks with the M bit
unset. It is permissible to set the M bit to request this and unset. It is permissible to set the M bit to request this and later
missing blocks from this MAX_PAYLOADS set. Further considerations blocks from this MAX_PAYLOADS set. Further considerations related to
related to the transmission timing for missing requests are discussed the transmission timing for missing requests are discussed in
in Section 6.2. Section 7.2.
The requested missing block numbers MUST have an increasing block The requested missing block numbers MUST have an increasing block
number in each additional Q-Block2 Option with no duplicates. The number in each additional Q-Block2 Option with no duplicates. The
server SHOULD respond with a 4.00 (Bad Request) to requests not server SHOULD respond with a 4.00 (Bad Request) to requests not
adhering to this behavior. adhering to this behavior. Note that the ordering constraint is
meant to force the client to check for duplicates and remove them.
This also helps with troubleshooting.
For Confirmable responses, the client continues to acknowledge each For Confirmable responses, the client continues to acknowledge each
packet. The server acknowledges the initial request using an ACK packet. Typically, the server acknowledges the initial request using
with the payload, and then sends the subsequent payloads as CON an ACK with the payload, and then sends the subsequent payloads as
responses. The server will detect failure to send a packet, but the CON responses. The server will detect failure to send a packet, but
client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate
POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed. GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as
needed.
If the client receives a duplicate block with the same ETag, it If the client receives a duplicate block with the same ETag, it MUST
SHOULD silently ignore the packet. silently ignore the payload.
A client SHOULD only maintain a partial body (missing payloads) for A client SHOULD maintain a partial body (missing payloads) for up to
up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age NON_PARTIAL_TIMEOUT (Section 7.2) or as defined by the Max-Age Option
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 the less. On release of the partial body, the client whichever is the less. On release of the partial body, the client
should then release all of the tokens used for this body unless a should then release all of the tokens used for this body unless a
resource is being observed. resource 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.
It is RECOMMENDED that the server maintains a cached copy of the body It is RECOMMENDED that the server maintains a cached copy of the body
skipping to change at page 15, line 21 skipping to change at page 16, line 5
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.
3.5. Using 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 includes payloads for all the payloads of the same body. This includes payloads
transmitted following receipt of the 'Continue' Q-Block2 Option transmitted following receipt of the 'Continue' Q-Block2 Option
(Section 3.4) by the server. If a missing payload is requested, then (Section 4.4) by the server. If a missing payload is requested, then
both the request and response MUST NOT include the Observe Option. both the request and response MUST NOT include the Observe Option.
3.6. Using 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.
The Size1 or Size2 option values MUST exactly represent the size of The Size1 or Size2 option values MUST exactly represent the size of
the data on the body so that any missing data can easily be the data on the body so that any missing data can easily be
determined. 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 preserving request and MUST be present in all payloads of the request preserving
the same value. The Size2 Option MUST be used with the Q-Block2 the same value. The Size2 Option MUST be used with the Q-Block2
Option when used in a response and MUST be present in all payloads of Option when used in a response and MUST be present in all payloads of
the response preserving the same value. the response preserving the same value.
3.7. Using 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 for [RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for
Block2. Block2.
3.8. Using 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, 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].
4. The Use of 4.08 (Request Entity Incomplete) Response Code 5. The Use of 4.08 (Request Entity Incomplete) Response Code
4.08 (Request Entity Incomplete) Response Code has a new Content-Type 4.08 (Request Entity Incomplete) Response Code has a new Content-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. needs to proceed. Such messages must not be treated by the client as
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 has sent them were dropped during transmission, or the client has sent them
sufficiently long ago that the server has already discarded them. sufficiently long ago that the server has already discarded them.
The data payload of the 4.08 (Request Entity Incomplete) response is The data payload of the 4.08 (Request Entity Incomplete) response is
encoded as a CBOR Sequence [RFC8742]. It comprises of one or more encoded as a CBOR Sequence [RFC8742]. It comprises of one or more
CBOR encoded [RFC8949] missing block numbers. The missing block missing block numbers encoded as CBOR unsigned integers [RFC8949].
numbers MUST be unique in each 4.08 (Request Entity Incomplete) The missing block numbers MUST be unique in each 4.08 (Request Entity
response when created by the server; the client SHOULD drop any Incomplete) response when created by the server; the client MUST
duplicates in the same 4.08 (Request Entity Incomplete) response. ignore any duplicates in the same 4.08 (Request Entity Incomplete)
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 11.3). "application/missing-blocks+cbor-seq" (Section 12.3).
The Concise Data Definition Language [RFC8610] (and see Section 4.1 The Concise Data Definition Language [RFC8610] (and see Section 4.1
[RFC8742]) for the data describing these missing blocks is as [RFC8742]) for the data describing these missing blocks is as
follows: follows:
; A notional array, the elements of which are to be used ; A notional 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
The token to use for the response SHOULD be the token that was used The token to use for the response SHOULD be the token that was used
in the last block number received so far with the same Request-Tag in the last block number received so far with the same Request-Tag
value. Note that the use of any received token with the same value. Note that the use of any received token with the same
Request-Tag would work, but providing the one used in the last Request-Tag would be acceptable, but providing the one used in the
received payload will aid any troubleshooting. The client will use last received payload will aid any troubleshooting. The client will
the token to determine what was the previously sent request to obtain use the token to determine what was the previously sent request to
the Request-Tag value to be used. obtain the Request-Tag value to be 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 [RFC7252], then the number is larger than that defined by Section 4.6 [RFC7252], then the number
of missing blocks MUST be limited so that the response can fit into a of missing blocks MUST be limited so that the response can fit into a
single packet. If this is the case, then the server can send single packet. If this is the case, then the server can send
subsequent 4.08 (Request Entity Incomplete) responses containing the subsequent 4.08 (Request Entity Incomplete) responses containing the
missing other blocks on receipt of a new request providing a missing missing other blocks on receipt of a new request providing a missing
payload with the same Request-Tag. 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
skipping to change at page 17, line 32 skipping to change at page 18, line 15
Implementation Note: Consider limiting the number of missing Implementation Note: Consider limiting the number of missing
payloads to MAX_PAYLOADS to minimize congestion control being payloads to MAX_PAYLOADS to minimize congestion control being
needed. The CBOR sequence does not include any array wrapper. needed. The CBOR sequence does not include any array wrapper.
The 4.08 (Request Entity Incomplete) with Content-Type "application/ The 4.08 (Request Entity Incomplete) with Content-Type "application/
missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable
requests or a reliable connection [RFC8323] as the client will be requests or a reliable connection [RFC8323] as the client will be
able to determine that there is a transmission failure of a able to determine that there is a transmission failure of a
particular payload and hence that the server is missing that payload. particular payload and hence that the server is missing that payload.
5. 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 [I-D.ietf-core-echo-request-tag]). Additional responses Section 4 of [I-D.ietf-core-echo-request-tag]). Additional responses
to a request all use the token of the request they respond to. to a request all use the token of the request they respond to.
Implementation Note: To minimize on the number of tokens that have Implementation Note: By using 8-byte tokens, it is possible to
to be tracked by clients, it is suggested that the bottom 32 bits easily minimize the number of tokens that have to be tracked by
is kept the same for the same body and the upper 32 bits contains clients, by keeping the bottom 32 bits the same for the same body
the current body's request number (incrementing every request, and the upper 32 bits containing the current body's request number
including every re-transmit). This allows the client to be (incrementing every request, including every re-transmit). This
alleviated from keeping all the per-request-state, e.g., in allows the client to be alleviated from keeping all the per-
Section 3 of [RFC8974]. request-state, e.g., in Section 3 of [RFC8974].
6. Congestion Control for Unreliable Transports 7. Congestion Control for Unreliable Transports
The transmission of the payloads of a body over an unreliable The transmission of the blocks of a body over an unreliable transport
transport SHOULD either all be Confirmable or all be Non-confirmable. MUST either all be Confirmable or all be Non-confirmable. This is
This is meant to simplify the congestion control procedure. meant to simplify the congestion control 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].
6.1. Confirmable (CON) 7.1. Confirmable (CON)
Congestion control for CON requests and responses is specified in Congestion control for CON requests and responses is specified in
Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will
need to be increased from 1. However, the other CON congestion need to be increased from 1. However, the other CON congestion
control parameters will need to be tuned to cover this change. This control parameters will need to be tuned to cover this change. This
tuning is out of scope of this document as it is expected that all tuning is out of scope of this document as it is expected that all
requests and responses using Q-Block1 and Q-Block2 will be Non- requests and responses using Q-Block1 and Q-Block2 will be Non-
confirmable. confirmable (Section 3.2).
It is implementation specific as to whether there should be any It is implementation specific as to whether there should be any
further requests for missing data as there will have been significant further requests for missing data as there will have been significant
transmission failure as individual payloads will have failed after transmission failure as individual payloads will have failed after
MAX_TRANSMIT_SPAN. MAX_TRANSMIT_SPAN.
6.2. Non-confirmable (NON) 7.2. Non-confirmable (NON)
This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3). NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
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 SHOULD have the same value (otherwise there will be CoAP endpoints SHOULD have the same value (otherwise there will be
transmission delays in one direction) and the value MAY be negotiated transmission delays in one direction) and the value MAY be negotiated
between the endpoints to a common value by using a higher level between the endpoints to a common value by using a higher level
protocol (out of scope of this document). This is the maximum number protocol (out of scope of this document). This is the maximum number
skipping to change at page 20, line 31 skipping to change at page 21, line 10
the situation re-evaluated for another 24 hour period until there is the situation re-evaluated for another 24 hour period until there is
no report of missing payloads under normal operating conditions. The no report of missing payloads under normal operating conditions. The
newly derived value for MAX_PAYLOADS should be used for both ends of newly derived value for MAX_PAYLOADS should be used for both ends of
this particular CoAP peer link. Note that the CoAP peer will not this particular CoAP peer link. Note that the CoAP peer will not
know about the MAX_PAYLOADS change until it is reconfigured. As a know about the MAX_PAYLOADS change until it is reconfigured. As a
consequence of the two peers having different MAX_PAYLOADS values, a consequence of the two peers having different MAX_PAYLOADS values, a
peer may continue indicate that there are some missing payloads as peer may continue indicate that there are some missing payloads as
all of its MAX_PAYLOADS set may not have arrived. How the two peer all of its MAX_PAYLOADS set may not have arrived. How the two peer
values for MAX_PAYLOADS are synchronized is out of the scope. values for MAX_PAYLOADS are synchronized is out of the scope.
The sending of a set of missing payloads of a body is subject to The sending of a set of missing blocks of a body is subject to
MAX_PAYLOADS set of payloads. MAX_PAYLOADS set of payloads.
For Q-Block1 Option, if the server responds with a 2.31 (Continue) For Q-Block1 Option, if the server responds with a 2.31 (Continue)
Response Code for the latest payload sent, then the client can Response Code for the latest payload sent, then the client can
continue to send the next set of payloads without any delay. If the continue to send the next set of payloads without any delay. If the
server responds with a 4.08 (Request Entity Incomplete) Response server responds with a 4.08 (Request Entity Incomplete) Response
Code, then the missing payloads SHOULD be retransmitted before going Code, then the missing payloads SHOULD be retransmitted before going
into another NON_TIMEOUT delay prior to sending the next set of into another NON_TIMEOUT delay prior to sending the next set of
payloads. payloads.
skipping to change at page 21, line 10 skipping to change at page 21, line 37
payload(s). If this is a repeat for the 2.31 (Continue) response, payload(s). If this is a repeat for the 2.31 (Continue) response,
the server SHOULD send a 4.08 (Request Entity Incomplete) response the server SHOULD send a 4.08 (Request Entity Incomplete) response
detailing the missing payloads after the block number that would have detailing the missing payloads after the block number that would have
been indicated in the 2.31 (Continue). If the repeat request count been indicated in the 2.31 (Continue). If the repeat request count
for a missing payload exceeds NON_MAX_RETRANSMIT, the server SHOULD for a missing payload exceeds NON_MAX_RETRANSMIT, the server SHOULD
discard the partial body and stop requesting the missing payloads. discard the partial body and stop requesting the missing payloads.
It is likely that the client will start transmitting the next set of It is likely that the client will start transmitting the next set of
MAX_PAYLOADS payloads before the server times out on waiting for the MAX_PAYLOADS payloads before the server times out on waiting for the
last of the previous MAX_PAYLOADS payloads. On receipt of the first last of the previous MAX_PAYLOADS payloads. On receipt of the first
received payload from the new set of MAX_PAYLOADS payloads, the payload from the new set of MAX_PAYLOADS payloads, the server SHOULD
server SHOULD send a 4.08 (Request Entity Incomplete) Response Code send a 4.08 (Request Entity Incomplete) Response Code indicating any
indicating any missing payloads from any previous MAX_PAYLOADS missing payloads from any previous MAX_PAYLOADS payloads. Upon
payloads. Upon receipt of the 4.08 (Request Entity Incomplete) receipt of the 4.08 (Request Entity Incomplete) Response Code, the
Response Code, the client SHOULD send the missing payloads before client SHOULD send the missing payloads before continuing to send the
continuing to send the remainder of the MAX_PAYLOADS payloads and remainder of the MAX_PAYLOADS payloads and then go into another
then go into another NON_TIMEOUT delay prior to sending the next set NON_TIMEOUT delay prior to sending the next set of payloads.
of payloads.
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 3.4) for the next set of 'Continue' Q-Block2 request (Section 4.4) for the next set of
payloads on receipt of all of the MAX_PAYLOADS payloads to prevent payloads on receipt of all of the MAX_PAYLOADS payloads to prevent
the server unnecessarily delaying. Otherwise the client SHOULD delay the server unnecessarily delaying. Otherwise the client SHOULD delay
for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat
request count for a payload), before sending the request for the request count for a payload), before sending the request for the
missing payload(s). If the repeat request count for a missing missing payload(s). If the repeat request count for a missing
payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the
partial body and stop requesting the missing payloads. partial body and stop requesting the missing payloads.
The server SHOULD recognize the 'Continue' Q-Block2 request as a The server SHOULD recognize the 'Continue' Q-Block2 request as a
continue request and just continue the transmission of the body continue request and just continue the transmission of the body
skipping to change at page 22, line 5 skipping to change at page 22, line 31
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 after every never get received, a delay of NON_TIMEOUT after every
transmission of MAX_PAYLOADS blocks will be observed. The transmission of MAX_PAYLOADS blocks will be observed. The
endpoint receiving the body is still likely to receive the entire endpoint receiving the body is still likely to receive the entire
body. body.
7. Caching Considerations 8. Caching Considerations
Caching block based information is not straight forward in a proxy. Caching block based information is not straight forward in a proxy.
For Q-Block1 and Q-Block2 Options, for simplicity it is expected that For Q-Block1 and Q-Block2 Options, for simplicity it is expected that
the proxy will reassemble the body (using any appropriate recovery the proxy will reassemble the body (using any appropriate recovery
options for packet loss) before passing on the body to the options for packet loss) before passing on the body to the
appropriate CoAP endpoint. This does not preclude an implementation appropriate CoAP endpoint. This does not preclude an implementation
doing a more complex per payload caching, but how to do this is out doing a more complex per payload caching, but how to do this is out
of the scope of this document. The onward transmission of the body of the scope of this document. The onward transmission of the body
does not require the use of the Q-Block1 or Q-Block2 Options as these does not require the use of the Q-Block1 or Q-Block2 Options as these
options may not be supported in that link. This means that the proxy options may not be supported in that link. This means that the proxy
skipping to change at page 23, line 10 skipping to change at page 23, line 38
GET or similar request indicating one or more missing blocks. The GET or similar request indicating one or more missing blocks. The
proxy will serve from its cache 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 the cache key matching body is not available Q-Block2 responses. If the cache key matching body is not available
in the cache, the proxy MUST request the entire body from the CoAP in the cache, the proxy MUST request the entire body from the CoAP
server using the information in the cache key. 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).
8. 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.
9. Examples with Non-confirmable Messages 10. Examples with Non-confirmable Messages
This section provides some sample flows to illustrate the use of 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.
Figure 2 lists the conventions that are used in the following Figure 2 lists the conventions that are used in the following
subsections. subsections.
T: Token value T: Token value
O: Observe Option value O: Observe Option value
M: Message ID M: Message ID
RT: Request-Tag RT: Request-Tag
ET: ETag ET: ETag
QB1: Q-Block1 Option values NUM/More/SZX QB1: Q-Block1 Option values NUM/More/SZX
QB2: Q-Block2 Option values NUM/More/SZX QB2: Q-Block2 Option values NUM/More/SZX
\: Trimming long lines \: Trimming long lines
[[]]: Comments [[]]: Comments
-->X: Message loss (request) -->X: Message loss (request)
X<--: Message loss (response) X<--: Message loss (response)
...: Passage of time ...: Passage of time
Payload N: Corresponds to the CoAP message that conveys
a block number (N-1) of a given block-wise exchange.
Figure 2: Notations Used in the Figures Figure 2: Notations Used in the Figures
9.1. Q-Block1 Option 10.1. Q-Block1 Option
9.1.1. A Simple Example 10.1.1. A Simple Example
Figure 3 depicts an example of a NON PUT request conveying Q-Block1 Figure 3 depicts an example of a NON PUT request conveying 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 3: Example of NON Request with Q-Block1 Option (Without Loss) Figure 3: Example of NON Request with Q-Block1 Option (Without Loss)
9.1.2. Handling MAX_PAYLOADS Limits 10.1.2. Handling MAX_PAYLOADS Limits
Figure 4 depicts an example of a NON PUT request conveying Q-Block1 Figure 4 depicts an example of a NON PUT request conveying Q-Block1
Option. The number of payloads exceeds MAX_PAYLOADS. All the blocks Option. The number of payloads exceeds MAX_PAYLOADS. All 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
skipping to change at page 24, line 40 skipping to change at page 25, line 22
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS has been reached]]
| [[MAX_PAYLOADS blocks receipt acknowledged by server]] | [[MAX_PAYLOADS blocks 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 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option Figure 4: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
(Without Loss) (Without Loss)
9.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 in client, but some blocks are dropped in transmission as illustrated in
Figure 5. 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
skipping to change at page 26, line 5 skipping to change at page 26, line 28
| [[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 6: Example of NON Request with Q-Block1 Option (Blocks Figure 6: Example of NON Request with Q-Block1 Option (Blocks
Recovery) Recovery)
9.1.4. Handling Recovery with Failure 10.1.4. Handling Recovery with Failure
Figure 7 depicts an example of a NON PUT request conveying Q-Block1 Figure 7 depicts an example of a NON PUT request conveying 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
skipping to change at page 26, line 45 skipping to change at page 27, line 40
|<---------+ 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
| for missing blocks and releases partial body]] | for missing blocks and releases partial body]]
| ... | | ... |
Figure 7: Example of NON Request with Q-Block1 Option (With Eventual Figure 7: Example of NON Request with Q-Block1 Option (With Eventual
Failure) Failure)
9.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; the observe detail can thus be ignored. Q-Block2; the observe detail can thus be ignored.
9.2.1. A Simple Example 10.2.1. A Simple Example
Figure 8 illustrates the example of Q-Block2 Option. The client Figure 8 illustrates the example of Q-Block2 Option. The client
sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2 sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2
Option indicates a block size hint (1024 bytes). This request is Option indicates a block size hint (1024 bytes). This request is
replied to by the server using four (4) blocks that are transmitted replied to by the server using four (4) blocks that are transmitted
to the client without any loss. Each of these blocks carries a to the client without any loss. Each of these blocks carries a
Q-Block2 Option. The same process is repeated when an Observe is Q-Block2 Option. The same process is repeated when an Observe is
triggered, but no loss is experienced by any of the notification triggered, but no loss is experienced by any of the notification
blocks. blocks.
skipping to change at page 27, line 35 skipping to change at page 28, line 27
| [[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 8: Example of NON Notifications with Q-Block2 Option (Without Figure 8: Example of NON Notifications with Q-Block2 Option (Without
Loss) Loss)
9.2.2. Handling MAX_PAYLOADS Limits 10.2.2. Handling MAX_PAYLOADS Limits
Figure 9 illustrates the same as Figure 8 but this time has eleven Figure 9 illustrates the same as Figure 8 but this time has eleven
(11) payloads which exceeds MAX_PAYLOADS. There is no loss (11) payloads which exceeds MAX_PAYLOADS. There is no 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
skipping to change at page 28, line 35 skipping to change at page 29, line 35
| [[MAX_PAYLOADS blocks acknowledged by client using | [[MAX_PAYLOADS blocks 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 9: Example of NON Notifications with Q-Block2 Option (Without Figure 9: Example of NON Notifications with Q-Block2 Option (Without
Loss) Loss)
9.2.3. Handling MAX_PAYLOADS with Recovery 10.2.3. Handling MAX_PAYLOADS with Recovery
Figure 10 shows the 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 - 8 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
[[MAX_PAYLOADS has been reached]] [[MAX_PAYLOADS has been reached]]
| ... | | ... |
[[NON_TIMEOUT (server) delay expires]] [[NON_TIMEOUT (server) delay expires]]
| [[Server sends next set of payloads]] | [[Server sends next set of payloads]]
|<---------+ 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
| ... | | ... |
[[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]] | missing ones in one go]]
skipping to change at page 29, line 38 skipping to change at page 30, line 38
| [[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 10: Example of NON Notifications with Q-Block2 Option (Blocks Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery) Recovery)
9.2.4. Handling Recovery using M-bit Set 10.2.4. Handling Recovery using M-bit Set
Figure 11 shows the example of an Observe that is triggered but only Figure 11 shows the example of an Observe that is triggered but only
the first two notification blocks reach the client. In order to the first two notification blocks reach the client. In order to
retrieve the missing blocks, the client sends a request with a single retrieve the missing blocks, the client sends a request with a single
Q-Block2 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]]
skipping to change at page 30, line 38 skipping to change at page 31, line 38
| [[MAX_PAYLOADS acknowledged by client using 'Continue' | [[MAX_PAYLOADS 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 11: Example of NON Notifications with Q-Block2 Option (Blocks Figure 11: Example of NON Notifications with Q-Block2 Option (Blocks
Recovery with M bit Set) Recovery with M bit Set)
9.3. Q-Block1 and Q-Block2 Options 10.3. Q-Block1 and Q-Block2 Options
9.3.1. A Simple Example 10.3.1. A Simple Example
Figure 12 illustrates the example of a FETCH using both Q-Block1 and Figure 12 illustrates the example of a FETCH using both Q-Block1 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
skipping to change at page 31, line 26 skipping to change at page 32, line 26
| [[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 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options
(Without Loss) (Without Loss)
9.3.2. Handling MAX_PAYLOADS Limits 10.3.2. Handling MAX_PAYLOADS Limits
Figure 13 illustrates the same as Figure 12 but this time has eleven Figure 13 illustrates the same as Figure 12 but this time has eleven
(11) payloads in both directions which exceeds MAX_PAYLOADS. There (11) payloads in both directions which exceeds 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
skipping to change at page 32, line 42 skipping to change at page 33, line 42
| [[MAX_PAYLOADS blocks acknowledged by client using | [[MAX_PAYLOADS blocks 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 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options
(Without Loss) (Without Loss)
9.3.3. Handling Recovery 10.3.3. Handling Recovery
Consider now a scenario where some blocks are lost in transmission as Consider now a scenario where some blocks are lost in transmission as
illustrated in Figure 14. 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
skipping to change at page 34, line 41 skipping to change at page 35, line 41
+--------->| 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 16: Example of NON Request with Q-Block1 Option (Client Figure 16: Example of NON Request with Q-Block1 Option (Client
Recovery) Recovery)
10. 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 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
skipping to change at page 35, line 16 skipping to change at page 36, line 16
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 applications need to consider that certain message fields and
messages types are not protected end-to-end and may be spoofed or messages types are not protected end-to-end and may be spoofed or
manipulated. It is NOT RECOMMENDED that the NoSec security mode is manipulated. It is NOT RECOMMENDED that the NoSec security mode is
used if the Q-Block1 and Q-Block2 Options are to be used. used if the Q-Block1 and Q-Block2 Options are to be 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 [I-D.ietf-core-echo-request-tag]. discussed in Section 5 of [I-D.ietf-core-echo-request-tag].
11. IANA Considerations 12. IANA Considerations
RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be RFC Editor Note: Please replace [RFCXXXX] with the RFC number to be
assigned to this document. assigned to this document.
11.1. CoAP Option Numbers Registry 12.1. CoAP Option Numbers Registry
IANA is requested to add the following entries to the "CoAP Option IANA is requested to add the following entries to the "CoAP Option
Numbers" sub-registry [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 |
+========+==================+===========+ +========+==================+===========+
| TBA1 | Q-Block1 | [RFCXXXX] | | TBA1 | Q-Block1 | [RFCXXXX] |
| TBA2 | Q-Block2 | [RFCXXXX] | | TBA2 | Q-Block2 | [RFCXXXX] |
+--------+------------------+-----------+ +--------+------------------+-----------+
Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers
This document suggests 19 (TBA1) and 31 (TBA2) as values to be This document suggests 19 (TBA1) and 31 (TBA2) as values to be
assigned for the new option numbers. assigned for the new option numbers.
11.2. Media Type Registration 12.2. Media Type Registration
This document requests IANA to register the "application/missing- This document requests IANA to register the "application/missing-
blocks+cbor-seq" media type in the "Media Types" registry blocks+cbor-seq" media type in the "Media Types" registry
[IANA-MediaTypes]. This registration follows the procedures [IANA-MediaTypes]. This registration follows the procedures
specified in [RFC6838]: specified in [RFC6838]:
Type name: application Type name: application
Subtype name: missing-blocks+cbor-seq Subtype name: missing-blocks+cbor-seq
skipping to change at page 36, line 45 skipping to change at page 37, line 45
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: none Restrictions on usage: none
Author: See Authors' Addresses section. Author: See Authors' Addresses section.
Change controller: IESG Change controller: IESG
Provisional registration? No Provisional registration? No
11.3. CoAP Content-Formats Registry 12.3. CoAP Content-Formats Registry
This document requests IANA to register the following CoAP Content- This document requests IANA to register the following CoAP Content-
Format for the "application/missing-blocks+cbor-seq" media type in Format for the "application/missing-blocks+cbor-seq" media type in
the "CoAP Content-Formats" registry [Format], defined in [RFC7252], the "CoAP Content-Formats" registry [Format], defined in [RFC7252],
within the "Constrained RESTful Environments (CoRE) Parameters" within the "Constrained RESTful Environments (CoRE) Parameters"
registry: registry:
o Media Type: application/missing-blocks+cbor-seq o Media Type: application/missing-blocks+cbor-seq
o Encoding: - o Encoding: -
o Id: TBA3 o Id: TBA3
o Reference: [RFCXXXX] o Reference: [RFCXXXX]
This document suggests 272 (TBA3) as a value to be assigned for the This document suggests 272 (TBA3) as a value to be assigned for the
new content format number. new content format number.
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
Request-Tag, and Token Processing", draft-ietf-core-echo- Request-Tag, and Token Processing", draft-ietf-core-echo-
request-tag-11 (work in progress), November 2020. request-tag-11 (work in progress), November 2020.
[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>.
skipping to change at page 38, line 34 skipping to change at page 39, line 34
[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>.
12.2. Informative References 13.2. Informative References
[Format] "CoAP Content-Formats", <https://www.iana.org/assignments/ [Format] "CoAP Content-Formats", <https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#content-formats>. core-parameters/core-parameters.xhtml#content-formats>.
[I-D.bosh-dots-quick-blocks] [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 Faster Block Transmission", Configuration Attributes for Faster Block Transmission",
draft-bosh-dots-quick-blocks-01 (work in progress), draft-bosh-dots-quick-blocks-01 (work in progress),
January 2021. January 2021.
skipping to change at page 39, line 17 skipping to change at page 40, line 17
<https://www.iana.org/assignments/media-types>. <https://www.iana.org/assignments/media-types>.
[Options] "CoAP Option Numbers", <https://www.iana.org/assignments/ [Options] "CoAP Option Numbers", <https://www.iana.org/assignments/
core-parameters/core-parameters.xhtml#option-numbers>. core-parameters/core-parameters.xhtml#option-numbers>.
[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.
Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>. June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P., [RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
Mortensen, A., and N. Teague, "Distributed Denial-of- Mortensen, A., and N. Teague, "Distributed Denial-of-
Service Open Threat Signaling (DOTS) Signal Channel Service Open Threat Signaling (DOTS) Signal Channel
Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020, Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
skipping to change at page 44, line 32 skipping to change at page 45, line 32
If there is likely to be the possibility of network transient losses, If there is likely to be the possibility of network transient losses,
then the use of unreliable transport with NON should be considered. then the use of unreliable transport with NON should be considered.
Acknowledgements 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 Amsuess, Carsten Bormann, and Marco Special thanks to Christian Amsuess, Carsten Bormann, and Marco
Tiloca for their suggestions and several reviews, which improved this Tiloca for their suggestions and several reviews, which improved this
specification significantly. specification significantly. Thanks to Francesca Palombini for the
AD review.
Some text from [RFC7959] is reused for readers convenience. Some text from [RFC7959] is reused for readers convenience.
Authors' Addresses Authors' Addresses
Mohamed Boucadair Mohamed Boucadair
Orange Orange
Rennes 35000 Rennes 35000
France France
 End of changes. 99 change blocks. 
238 lines changed or deleted 276 lines changed or added

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