rfc9177xml2.original.xml   rfc9177.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?> <!DOCTYPE rfc [
<?rfc tocompact="yes"?> <!ENTITY nbsp "&#160;">
<?rfc tocdepth="4"?> <!ENTITY zwsp "&#8203;">
<?rfc tocindent="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc symrefs="yes"?> <!ENTITY wj "&#8288;">
<?rfc sortrefs="yes"?> ]>
<?rfc comments="yes"?>
<?rfc inline="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-core-new-blo
<?rfc compact="yes"?> ck-14" number="9177" ipr="trust200902" obsoletes="" updates="" submissionType="I
<?rfc subcompact="no"?> ETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4
<rfc category="std" docName="draft-ietf-core-new-block-14" ipr="trust200902"> " symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.8.0 -->
<front> <front>
<title abbrev="Quick Block-Wise Transfer Options">Constrained Application <title abbrev="Quick Block-Wise Transfer Options">Constrained Application
Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Protocol (CoAP) Block-Wise Transfer Options Supporting Robust
Transmission</title> Transmission</title>
<seriesInfo name="RFC" value="9177"/>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<region/>
<region></region>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<author fullname="Jon Shallow" initials="J." surname="Shallow"> <author fullname="Jon Shallow" initials="J." surname="Shallow">
<organization></organization> <organization/>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city/>
<city></city> <region/>
<code/>
<region></region>
<code></code>
<country>United Kingdom</country> <country>United Kingdom</country>
</postal> </postal>
<email>supjps-ietf@jpshallow.com</email> <email>supjps-ietf@jpshallow.com</email>
</address> </address>
</author> </author>
<date year="2022" month="March"/>
<date />
<workgroup>CoRE Working Group</workgroup> <workgroup>CoRE Working Group</workgroup>
<keyword>Quick-Block</keyword> <keyword>Quick-Block</keyword>
<keyword>Robust-Block</keyword> <keyword>Robust-Block</keyword>
<keyword>R-Block</keyword> <keyword>R-Block</keyword>
<keyword>Tough-Block</keyword> <keyword>Tough-Block</keyword>
<keyword>Resilient-Block</keyword> <keyword>Resilient-Block</keyword>
<keyword>Fast-Block</keyword> <keyword>Fast-Block</keyword>
<keyword>Resilience</keyword> <keyword>Resilience</keyword>
<keyword>Filtering</keyword> <keyword>Filtering</keyword>
<keyword>Faster transmission</keyword> <keyword>Faster transmission</keyword>
<keyword>Large amounts of data</keyword> <keyword>Large amounts of data</keyword>
<keyword>Less packet interchange</keyword> <keyword>Less packet interchange</keyword>
<keyword>Fast recovery</keyword> <keyword>Fast recovery</keyword>
<keyword>DOTS</keyword> <keyword>DOTS</keyword>
<abstract> <abstract>
<t>This document specifies alternative Constrained Application Protocol <t>This document specifies alternative Constrained Application Protocol
(CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.</t> (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.</t>
<t>These options are similar to, but distinct from, the CoAP Block1 and <t>These options are similar to, but distinct from, the CoAP Block1 and
Block2 Options defined in RFC 7959. Q-Block1 and Q-Block2 Options are Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are
not intended to replace Block1 and Block2 Options, but rather have the not intended to replace the Block1 and Block2 options but rather have the
goal of supporting Non-confirmable messages for large amounts of data goal of supporting Non-confirmable (NON) messages for large amounts of dat
with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 Options a
with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options
support faster recovery should any of the blocks get lost in support faster recovery should any of the blocks get lost in
transmission.</t> transmission.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<t>The Constrained Application Protocol (CoAP) <xref <name>Introduction</name>
target="RFC7252"></xref>, although inspired by HTTP, was designed to use <t>The Constrained Application Protocol (CoAP) <xref target="RFC7252" form
at="default"/>, although inspired by HTTP, was designed to use
UDP instead of TCP. The message layer of CoAP over UDP includes support UDP instead of TCP. The message layer of CoAP over UDP includes support
for reliable delivery, simple congestion control, and flow control. CoAP for reliable delivery, simple congestion control, and flow control. CoAP
supports two message types (Section 1.2 of <xref supports two message types (<xref target="RFC7252" section="1.2" sectionFo
target="RFC7252"></xref>): Confirmable (CON) and Non-confirmable (NON) rmat="of"
messages. Unlike NON messages, every CON message will elicit an format="default"/>): Confirmable (CON) and Non-confirmable (NON). Unlike N
acknowledgement or a reset.</t> ON
messages, every CON message will elicit an acknowledgment or a reset.</t>
<t>The CoAP specification recommends that a CoAP message should fit <t>The CoAP specification recommends that a CoAP message should fit
within a single IP packet (i.e., avoid IP fragmentation). To handle data within a single IP packet (i.e., avoid IP fragmentation). To handle data
records that cannot fit in a single IP packet, <xref records that cannot fit in a single IP packet, <xref target="RFC7959" form
target="RFC7959"></xref> introduced the concept of block-wise transfer at="default"/> introduced the concept of block-wise transfers
and the companion CoAP Block1 and Block2 Options. However, this concept and the companion CoAP Block1 and Block2 options. However, this concept
is designed to work exclusively with Confirmable messages (Section 1 of is designed to work exclusively with Confirmable messages (<xref target="R
<xref target="RFC7959"></xref>). Note that the block-wise transfer was FC7959" section="1" sectionFormat="of" format="default"/>).
further updated by <xref target="RFC8323"></xref> for use over TCP, TLS, Note that the block-wise transfer was
further updated by <xref target="RFC8323" format="default"/> for use over
TCP, TLS,
and WebSockets.</t> and WebSockets.</t>
<t>The CoAP Block1 and Block2 options work well in environments where
<t>The CoAP Block1 and Block2 Options work well in environments where
there are no, or minimal, packet losses. These options operate there are no, or minimal, packet losses. These options operate
synchronously, i.e., each individual block has to be requested. A CoAP synchronously, i.e., each individual block has to be requested. A CoAP
endpoint can only ask for (or send) the next block when the transfer of endpoint can only ask for (or send) the next block when the transfer of
the previous block has completed. Packet transmission rate, and hence the previous block has completed. The packet transmission rate, and hence
block transmission rate, is controlled by Round Trip Times (RTTs).</t> the block transmission rate, is controlled by Round-Trip Times (RTTs).</t>
<t>There is a requirement for blocks of data larger than a single IP <t>There is a requirement for blocks of data larger than a single IP
datagram to be transmitted under network conditions where there may be datagram to be transmitted under network conditions where there may be
asymmetrical transient packet loss (e.g., acknowledgment responses may asymmetrical transient packet loss (e.g., acknowledgment responses may
get dropped). An example is when a network is subject to a Distributed get dropped).
An example is when a network is subject to a Distributed
Denial of Service (DDoS) attack and there is a need for DDoS mitigation Denial of Service (DDoS) attack and there is a need for DDoS mitigation
agents relying upon CoAP to communicate with each other (e.g., <xref agents relying upon CoAP to communicate with each other (e.g., <xref targe
target="RFC8782"></xref><xref target="I-D.ietf-dots-telemetry"></xref>). t="RFC9132" format="default"/> <xref target="DOTS-TELEMETRY" format="default"/>)
As a reminder, <xref target="RFC7959"></xref> recommends the use of CON .
responses to handle potential packet loss. However, such a As a reminder, <xref target="RFC7959" format="default"/> recommends the us
recommendation does not work with a flooded pipe DDoS situation (e.g., e of CON responses to handle potential packet loss. However, such a
<xref target="RFC8782"></xref>).</t> recommendation does not work with a "flooded pipe" DDoS situation (e.g.,
<xref target="RFC9132" format="default"/>).</t>
<t>This document introduces the CoAP Q-Block1 and Q-Block2 Options which <t>This document introduces the CoAP Q-Block1 and Q-Block2 options, which
allow block-wise transfer to work with series of Non-confirmable allow block-wise transfers to work with a series of Non-confirmable
messages, instead of lock-stepping using Confirmable messages (<xref messages instead of lock-stepping using Confirmable messages (<xref target
target="alt"></xref>). In other words, this document provides a missing ="alt" format="default"/>).
piece of <xref target="RFC7959"></xref>, namely the support of In other words, this document provides a missing
block-wise transfer using Non-confirmable where an entire body of data piece of <xref target="RFC7959" format="default"/>, namely the support of
block-wise transfers using Non-confirmable messages where an entire body o
f data
can be transmitted without the requirement that intermediate can be transmitted without the requirement that intermediate
acknowledgments be received from the peer (but recovery is available acknowledgments be received from the peer (but recovery is available
should it be needed).</t> should it be needed).</t>
<t>Similar to <xref target="RFC7959" format="default"/>, this specificatio
<t>Similar to <xref target="RFC7959"></xref>, this specification does n does
not remove any of the constraints posed by the base CoAP specification not remove any of the constraints posed by the base CoAP specification
<xref target="RFC7252"></xref> it is strictly layered on top of.</t> <xref target="RFC7252" format="default"/> it is strictly layered on top of .</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<section anchor="notation" title="Terminology"> <name>Terminology</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
only when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>Readers should be familiar with the terms and concepts defined in <t>Readers should be familiar with the terms and concepts defined in
<xref target="RFC7252"></xref>, <xref target="RFC7959"></xref>, and <xref target="RFC7252" format="default"/>, <xref target="RFC7959" format="
<xref target="RFC8132"></xref>. Particularly, the document uses the default"/>, and
following key concepts:<list style="hanging"> <xref target="RFC8132" format="default"/>. Particularly, the document uses
<t hangText="Token:">is used to match responses to requests the
independently from the underlying messages (Section 5.3.1 of <xref following key concepts:</t>
target="RFC7252"></xref>).</t> <dl newline="false" spacing="normal">
<dt>Token:</dt><dd>used to match responses to requests
<t hangText="ETag:">is used as a resource-local identifier for independently from the underlying messages (<xref target="RFC7252"
section="5.3.1" sectionFormat="of" format="default"/>).</dd>
<dt>ETag:</dt><dd>used as a resource-local identifier for
differentiating between representations of the same resource that differentiating between representations of the same resource that
vary over time (Section 5.10.6 of <xref vary over time (<xref target="RFC7252" section="5.10.6" sectionFormat=
target="RFC7252"></xref>).</t> "of"
</list></t> format="default"/>).</dd>
</dl>
<t>The terms "payload" and "body" are defined in <xref <t>The terms "payload" and "body" are defined in <xref target="RFC7959" fo
target="RFC7959"></xref>. The term "payload" is thus used for the rmat="default"/>. The term "payload" is thus used for the
content of a single CoAP message (i.e., a single block being content of a single CoAP message (i.e., a single block being
transferred), while the term "body" is used for the entire resource transferred), while the term "body" is used for the entire resource
representation that is being transferred in a block-wise fashion.</t> representation that is being transferred in a block-wise fashion.</t>
<t>Request-Tag refers to an option that allows a CoAP server to match <t>Request-Tag refers to an option that allows a CoAP server to match
message fragments belonging to the same request <xref message fragments belonging to the same request <xref target="RFC9175" for
target="I-D.ietf-core-echo-request-tag"></xref>.</t> mat="default"/>.</t>
<t>MAX_PAYLOADS is the maximum number of payloads that can be <t>MAX_PAYLOADS is the maximum number of payloads that can be
transmitted at any one time.</t> transmitted at any one time.</t>
<t>MAX_PAYLOADS_SET is the set of blocks identified by block numbers <t>MAX_PAYLOADS_SET is the set of blocks identified by block numbers
that, when divided by MAX_PAYLOADS, have the same numeric result. For that, when divided by MAX_PAYLOADS, have the same numeric result. For
example, if MAX_PAYLOADS is set to '10', a MAX_PAYLOADS_SET could be example, if MAX_PAYLOADS is set to 10, a MAX_PAYLOADS_SET could be
blocks #0 to #9, #10 to #19, etc. Depending on the overall data size, blocks #0 to #9, #10 to #19, etc.
Depending on the overall data size,
there could be fewer than MAX_PAYLOADS blocks in the final there could be fewer than MAX_PAYLOADS blocks in the final
MAX_PAYLOADS_SET.</t> MAX_PAYLOADS_SET.</t>
</section> </section>
<section anchor="alt" numbered="true" toc="default">
<section anchor="alt" title="Alternative CoAP Block-Wise Transfer Options"> <name>Alternative CoAP Block-Wise Transfer Options</name>
<t>This document introduces the CoAP Q-Block1 and Q-Block2 Options. <t>This document introduces the CoAP Q-Block1 and Q-Block2 options.
These options are designed to work in particular with NON requests and These options are designed to work in particular with NON requests and
responses.</t> responses.</t>
<t>Using NON messages, faster transmissions can occur, as all the blocks
<t>Using NON messages, faster transmissions can occur as all the blocks
can be transmitted serially (akin to fragmented IP packets) without can be transmitted serially (akin to fragmented IP packets) without
having to wait for a response or next request from the remote CoAP peer. having to wait for a response or next request from the remote CoAP peer.
Recovery of missing blocks is faster in that multiple missing blocks can Recovery of missing blocks is faster in that multiple missing blocks can
be requested in a single CoAP message. Even if there is asymmetrical be requested in a single CoAP message. Even if there is asymmetrical
packet loss, a body can still be sent and received by the peer whether packet loss, a body can still be sent and received by the peer whether
the body comprises a single or multiple payloads, assuming no recovery the body comprises a single payload or multiple payloads, assuming no reco very
is required.</t> is required.</t>
<t>A CoAP endpoint can acknowledge all or a subset of the blocks. <t>A CoAP endpoint can acknowledge all or a subset of the blocks.
Concretely, the receiving CoAP endpoint either informs the CoAP sender Concretely, the receiving CoAP endpoint either informs the sending CoAP
endpoint of successful reception or reports on all blocks in the body endpoint of successful reception or reports on all blocks in the body
that have not yet been received. The CoAP sender endpoint will then that have not yet been received. The sending CoAP endpoint will then
retransmit only the blocks that have been lost in transmission.</t> retransmit only the blocks that have been lost in transmission.</t>
<t>Note that similar transmission rate benefits can be applied to <t>Note that similar transmission rate benefits can be applied to
Confirmable messages if the value of NSTART is increased from 1 (Section Confirmable messages if the value of NSTART is increased from 1 (<xref tar
4.7 of <xref target="RFC7252"></xref>). However, the use of Confirmable get="RFC7252" section="4.7" sectionFormat="of" format="default"/>). However, the
use of Confirmable
messages will not work effectively if there is asymmetrical packet loss. messages will not work effectively if there is asymmetrical packet loss.
Some examples with Confirmable messages are provided in <xref Some examples with Confirmable messages are provided in <xref target="CON"
target="CON"></xref>.</t> format="default"/>.</t>
<t>There is little, if any, benefit of using these options with CoAP <t>There is little, if any, benefit of using these options with CoAP
running over a reliable connection <xref target="RFC8323"></xref>. In running over a reliable connection <xref target="RFC8323" format="default"
this case, there is no differentiation between CON and NON as they are />. In
not used. Some examples using a reliable transport are provided in <xref this case, there is no differentiation between CON and NON, as they are
target="REL"></xref>.</t> not used. Some examples using a reliable transport are provided in <xref t
arget="REL" format="default"/>.</t>
<t>Q-Block1 and Q-Block2 Options are similar in operation to the CoAP <t>The Q-Block1 and Q-Block2 options are similar in operation to the CoAP
Block1 and Block2 Options, respectively. They are not a replacement for Block1 and Block2 options, respectively. They are not a replacement for
them, but have the following benefits:<list style="symbols"> them but have the following benefits:</t>
<t>They can operate in environments where packet loss is highly <ul spacing="normal">
asymmetrical.</t> <li>They can operate in environments where packet loss is highly
asymmetrical.</li>
<t>They enable faster transmissions of sets of blocks of data with <li>They enable faster transmissions of sets of blocks of data with
fewer packet interchanges.</t> fewer packet interchanges.</li>
<li>They support faster recovery should any of the blocks get lost in
<t>They support faster recovery should any of the blocks get lost in transmission.</li>
transmission.</t> <li>They support sending an entire body using NON messages without
<t>They support sending an entire body using NON messages without
requiring that an intermediate response be received from the requiring that an intermediate response be received from the
peer.</t> peer.</li>
</list></t> </ul>
<t>The disadvantages of using the CoAP Block1 and Block2 options are as fo
<t>There are the following disadvantages over using CoAP Block1 and llows:</t>
Block2 Options:<list style="symbols"> <ul spacing="normal">
<t>Loss of lock-stepping so payloads are not always received in the <li>There is a loss of lock-stepping, so payloads are not always receive
correct (block ascending) order.</t> d in the
correct order (blocks in ascending order).</li>
<t>Additional congestion control measures need to be put in place <li>Additional congestion control measures need to be put in place
for NON messages (<xref target="cc-non"></xref>).</t> for NON messages (<xref target="cc-non" format="default"/>).</li>
<li>To reduce the transmission times for CON transmissions of large
<t>To reduce the transmission times for CON transmission of large
bodies, NSTART needs to be increased from 1, but this affects bodies, NSTART needs to be increased from 1, but this affects
congestion control and incurs a requirement to re-tune other congestion control and incurs a requirement to retune other
parameters (Section 4.7 of <xref target="RFC7252"></xref>). Such parameters (<xref target="RFC7252" section="4.7" sectionFormat="of" fo
tuning is out of scope of this document.</t> rmat="default"/>). Such
tuning is out of scope of this document.</li>
<t>Mixing of NON and CON during requests/responses using Q-Block is <li>Mixing of NON and CON during an exchange of requests/responses usin
not supported.</t> g
Q-Block options is not supported.</li>
<t>The Q-Block Options do not support stateless operation/random <li>The Q-Block options do not support stateless operation/random
access.</t> access.</li>
<li>Proxying of Q-Block options is limited to caching full
<t>Proxying of Q-Block is limited to caching full representations.</li>
representations.</t> <li>There is no multicast support.</li>
</ul>
<t>There is no multicast support.</t> <t>The Q-Block1 and Q-Block2 options can be used instead of the Block1 and
</list></t> Block2 options when the different transmission properties are required.
<t>Q-Block1 and Q-Block2 Options can be used instead of Block1 and
Block2 Options when the different transmission properties are required.
If the new options are not supported by a peer, then transmissions can If the new options are not supported by a peer, then transmissions can
fall back to using Block1 and Block2 Options (<xref fall back to using the Block1 and Block2 options (<xref target="prop"
target="prop"></xref>).</t> format="default"/>).</t>
<t>The deviations from the Block1 and Block2 options are specified in <xre
<t>The deviations from Block1 and Block2 Options are specified in <xref f
target="spec"></xref>. Pointers to appropriate <xref target="spec" format="default"/>. Pointers to the appropriate sections in
target="RFC7959"></xref> sections are provided.</t> <xref
target="RFC7959" format="default"/> are provided.</t>
<t>The specification refers to the base CoAP methods defined in Section <t>The specification refers to the base CoAP methods defined in <xref
5.8 of <xref target="RFC7252"></xref> and the new CoAP methods, FETCH, target="RFC7252" section="5.8" sectionFormat="of" format="default"/> and t
PATCH, and iPATCH introduced in <xref target="RFC8132"></xref>.</t> he new
CoAP methods, FETCH, PATCH, and iPATCH, which are introduced in <xref
<t>The No-Response Option <xref target="RFC7967"></xref> was considered target="RFC8132" format="default"/>.</t>
but was abandoned as it does not apply to Q-Block2 responses. A unified <t>The No-Response option <xref target="RFC7967" format="default"/> was co
nsidered
but was abandoned, as it does not apply to Q-Block2 responses. A unified
solution is defined in the document.</t> solution is defined in the document.</t>
<section numbered="true" toc="default">
<section title="CoAP Response Code (4.08) Usage"> <name>CoAP Response Code (4.08) Usage</name>
<t>This document adds a media type for the 4.08 (Request Entity <t>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
reporting on payloads using the Q-Block1 Option that are not received on
by the server.</t> payloads using the Q-Block1 option that are not received by the server.<
/t>
<t>See <xref target="code"></xref> for more details.</t> <t>See <xref target="code" format="default"/> for more details.</t>
</section> </section>
<section anchor="scope" numbered="true" toc="default">
<section anchor="scope" title="Applicability Scope"> <name>Applicability Scope</name>
<t>The block-wise transfer specified in <xref target="RFC7959"></xref> <t>The block-wise transfer specified in <xref target="RFC7959" format="d
covers the general case using Confirmable messages, but falls short in efault"/>
covers the general case using Confirmable messages but falls short in
situations where packet loss is highly asymmetrical or there is no situations where packet loss is highly asymmetrical or there is no
need for an acknowledgement. In other words, there is a need for need for an acknowledgment. In other words, there is a need for
Non-confirmable support.</t> Non-confirmable support.</t>
<t>The mechanism specified in this document provides roughly similar <t>The mechanism specified in this document provides roughly similar
features to the Block1/Block2 Options. It provides additional features to the Block1/Block2 options. It provides additional
properties that are tailored towards the intended use case of properties that are tailored towards the intended use case of
Non-confirmable transmission. Concretely, this mechanism primarily Non-confirmable transmission. Concretely, this mechanism primarily
targets applications such as DDoS Open Threat Signaling (DOTS) that targets applications, such as DDoS Open Threat Signaling (DOTS), that
cannot use CON requests/responses because of potential packet loss and cannot use CON requests/responses because of potential packet loss and
that support application-specific mechanisms to assess whether the that support application-specific mechanisms to assess whether the
remote peer is not overloaded and thus is able to process the messages remote peer is not overloaded and thus is able to process the messages
sent by a CoAP endpoint (e.g., DOTS heartbeats in Section 4.7 of <xref sent by a CoAP endpoint (e.g., DOTS heartbeats in <xref target="RFC9132"
target="RFC8782"></xref>). Other use cases are when an application section="4.7" sectionFormat="of" format="default"/>). Other use cases are when
sends data but has no need for an acknowledgement of receipt and, any an application
sends data but has no need for an acknowledgment of receipt and any
data transmission loss is not critical.</t> data transmission loss is not critical.</t>
<t>The mechanism includes guards to prevent a CoAP agent from <t>The mechanism includes guards to prevent a CoAP agent from
overloading the network by adopting an aggressive sending rate. These overloading the network by adopting an aggressive sending rate. These
guards MUST be followed in addition to the existing CoAP congestion guards <bcp14>MUST</bcp14> be followed in addition to the existing CoAP
control as specified in Section 4.7 of <xref target="RFC7252"></xref>. congestion
See <xref target="cc"></xref> for more details.</t> control, as specified in <xref target="RFC7252" section="4.7" sectionFor
mat="of" format="default"/>.
<t>Any usage outside the primary use case of Non-confirmable with See <xref target="cc" format="default"/> for more details.</t>
<t>Any usage outside the primary use case of Non-confirmable messages wi
th
block transfers should be carefully weighed against the potential loss block transfers should be carefully weighed against the potential loss
of interoperability with generic CoAP applications (See the of interoperability with generic CoAP applications (see the
disadvantages listed in <xref target="alt"></xref>). It is hoped that disadvantages listed in <xref target="alt" format="default"/>). It is ho
ped that
the experience gained with this mechanism can feed future extensions the experience gained with this mechanism can feed future extensions
of the block-wise mechanism that will both be generally applicable and of the block-wise mechanism that will both be generally applicable and
serve this particular use case.</t> serve this particular use case.</t>
<t>It is not recommended that these options are used in the "NoSec"
<t>It is not recommended that these options are used in a NoSec security mode (<xref target="RFC7252" section="9" sectionFormat="of" for
security mode (Section 9 of <xref target="RFC7252"></xref>) as the mat="default"/>), as
source endpoint needs to be trusted. Using OSCORE <xref the source endpoint needs to be trusted. Using Object Security for Constr
target="RFC8613"></xref> does provide a security context and, hence, a ained
RESTful Environments (OSCORE) <xref target="RFC8613" format="default"/> d
oes
provide a security context and hence a
trust of the source endpoint that prepared the inner OSCORE content. trust of the source endpoint that prepared the inner OSCORE content.
However, even with OSCORE, using a NoSec security mode with these However, even with OSCORE, using the NoSec mode with these
options may still be inadequate, for reasons discussed in <xref options may still be inadequate, for reasons discussed in <xref target="
target="security"></xref>.</t> security" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="spec" numbered="true" toc="default">
<section anchor="spec" title="The Q-Block1 and Q-Block2 Options"> <name>The Q-Block1 and Q-Block2 Options</name>
<section anchor="prop" <section anchor="prop" numbered="true" toc="default">
title="Properties of Q-Block1 and Q-Block2 Options"> <name>Properties of the Q-Block1 and Q-Block2 Options</name>
<t>The properties of the Q-Block1 and Q-Block2 Options are shown in <t>The properties of the Q-Block1 and Q-Block2 options are shown in
Table 1. The formatting of this table follows the one used in Table 4 <xref target="coap" format="default"/>. The formatting of this table fol
of <xref target="RFC7252"></xref> (Section 5.10). The C, U, N, and R lows the
one used in Table 4
of <xref target="RFC7252" section="5.10" sectionFormat="of" format="defa
ult"/>. The C, U, N, and R
columns indicate the properties Critical, UnSafe, NoCacheKey, and columns indicate the properties Critical, UnSafe, NoCacheKey, and
Repeatable defined in Section 5.4 of <xref target="RFC7252"></xref>. Repeatable, which are defined in <xref target="RFC7252" section="5.4" s
Only Critical and UnSafe columns are marked for the Q-Block1 Option. ectionFormat="of" format="default"/>.
Critical, UnSafe, and Repeatable columns are marked for the Q-Block2 Only the Critical and UnSafe columns are marked for the Q-Block1 option.
Option. As these options are UnSafe, NoCacheKey has no meaning and so The Critical, UnSafe, and Repeatable columns are marked for the Q-Block2
option. As these options are UnSafe, NoCacheKey has no meaning and so
is marked with a dash.</t> is marked with a dash.</t>
<t><figure align="center"> <table align="center" anchor="coap">
<artwork align="center"><![CDATA[+--------+---+---+---+---+--------- <name>CoAP Q-Block1 and Q-Block2 Option Properties</name>
-----+--------+--------+---------+ <thead>
| Number | C | U | N | R | Name | Format | Length | Default | <tr>
+========+===+===+===+===+==============+========+========+=========+ <th>No.</th>
| TBA1 | x | x | - | | Q-Block1 | uint | 0-3 | (none) | <th>C</th>
| TBA2 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) | <th>U</th>
+--------+---+---+---+---+--------------+--------+--------+---------+ <th>N</th>
<th>R</th>
Table 1: CoAP Q-Block1 and Q-Block2 Option Properties <th>Name</th>
]]></artwork> <th>Format</th>
</figure></t> <th>Length</th>
<th>Default</th>
<t>The Q-Block1 and Q-Block2 Options can be present in both the </tr>
request and response messages. The Q-Block1 Option pertains to the </thead>
request payload and the Q-Block2 Option pertains to the response <tbody>
payload. When the Content-Format Option is present together with the <tr>
Q-Block1 or Q-Block2 Option, the option applies to the body not to the <td>19</td>
<td>x</td>
<td>x</td>
<td>-</td>
<td></td>
<td>Q-Block1</td>
<td>uint</td>
<td>0-3</td>
<td>(none)</td>
</tr>
<tr>
<td>31</td>
<td>x</td>
<td>x</td>
<td>-</td>
<td>x</td>
<td>Q-Block2</td>
<td>uint</td>
<td>0-3</td>
<td>(none)</td>
</tr>
</tbody>
</table>
<t>The Q-Block1 and Q-Block2 options can be present in both the
request and response messages. The Q-Block1 option pertains to the
request payload, and the Q-Block2 option pertains to the response
payload. When the Content-Format option is present together with the
Q-Block1 or Q-Block2 option, the option applies to the body, not to the
payload (i.e., it must be the same for all payloads of the same payload (i.e., it must be the same for all payloads of the same
body).</t> body).</t>
<t>The Q-Block1 option is useful with the payload-bearing (e.g., POST,
<t>The Q-Block1 Option is useful with the payload-bearing, e.g., POST, PUT, FETCH, PATCH, and iPATCH) requests and their responses.</t>
PUT, FETCH, PATCH, and iPATCH requests and their responses.</t> <t>The Q-Block2 option is useful, for example, with GET, POST, PUT, FETC
H,
<t>The Q-Block2 Option is useful, e.g., with GET, POST, PUT, FETCH,
PATCH, and iPATCH requests and their payload-bearing responses PATCH, and iPATCH requests and their payload-bearing responses
(response codes 2.01, 2.02, 2.04, and 2.05) (Section 5.5 of <xref (response codes 2.01, 2.02, 2.04, and 2.05) (<xref target="RFC7252" sect
target="RFC7252"></xref>).</t> ion="5.5" sectionFormat="of" format="default"/>).</t>
<t>A CoAP endpoint (or proxy) <bcp14>MUST</bcp14> support either both or
<t>A CoAP endpoint (or proxy) MUST support either both or neither of neither of
the Q-Block1 and Q-Block2 Options.</t> the Q-Block1 and Q-Block2 options.</t>
<t>If the Q-Block1 option is present in a request or the Q-Block2
<t>If the Q-Block1 Option is present in a request or the Q-Block2 option is returned in a response, this indicates a block-wise transfer
Option is returned in a response, this indicates a block-wise transfer
and describes how this specific block-wise payload forms part of the and describes how this specific block-wise payload forms part of the
entire body being transferred. If it is present in the opposite entire body being transferred. If it is present in the opposite
direction, it provides additional control on how that payload will be direction, it provides additional control on how that payload will be
formed or was processed.</t> formed or was processed.</t>
<t>To indicate support for Q-Block2 responses, the CoAP client <bcp14>MU
<t>To indicate support for Q-Block2 responses, the CoAP client MUST ST</bcp14>
include the Q-Block2 Option in a GET or similar request (FETCH, for include the Q-Block2 option in a GET or similar request (e.g., FETCH), t
example), the Q-Block2 Option in a PUT or similar request (POST, for he
example), or the Q-Block1 Option in a PUT or similar request so that Q-Block2 option in a PUT or similar request (e.g., POST), or the Q-Block1
option in a PUT or similar request so that
the server knows that the client supports this Q-Block functionality the server knows that the client supports this Q-Block functionality
should it need to send back a body that spans multiple payloads. should it need to send back a body that spans multiple payloads.
Otherwise, the server would use the Block2 Option (if supported) to Otherwise, the server would use the Block2 option (if supported) to
send back a message body that is too large to fit into a single IP send back a message body that is too large to fit into a single IP
packet <xref target="RFC7959"></xref>.</t> packet <xref target="RFC7959" format="default"/>.</t>
<t>How a client decides whether it needs to include a Q-Block1 or <t>How a client decides whether it needs to include a Q-Block1 or
Q-Block2 Option can be driven by a local configuration parameter, Q-Block2 option can be driven by a local configuration parameter,
triggered by an application (DOTS, for example), etc. Such triggered by an application (e.g., DOTS), etc. Such
considerations are out of the scope of the document.</t> considerations are out of the scope of this document.</t>
<t>Implementation of the Q-Block1 and Q-Block2 options is intended to
<t>Implementation of the Q-Block1 and Q-Block2 Options is intended to be optional. However, when a Q-Block1 or Q-Block2 option is present in a
be optional. However, when it is present in a CoAP message, it MUST be CoAP
processed (or the message rejected). Therefore, Q-Block1 and Q-Block2 message, it <bcp14>MUST</bcp14> be
Options are identified as Critical options.</t> processed (or the message rejected). Therefore, the Q-Block1 and Q-Block
2
options are identified as critical options.</t>
<t>With CoAP over UDP, the way a request message is rejected for <t>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 <xref target="RFC7252"></xref>). A Option) response (<xref target="RFC7252" section="5.4.1" sectionFormat="
of"
format="default"/>). A
Non-confirmable message with an unrecognized critical option is either Non-confirmable message with an unrecognized critical option is either
rejected with a Reset message or just silently ignored (Sections 5.4.1 rejected with a Reset message or just silently ignored (Sections <xref
and 4.3 of <xref target="RFC7252"></xref>). To reliably get a target="RFC7252" section="5.4.1" sectionFormat="bare"/>
rejection message, it is therefore REQUIRED that clients use a and <xref target="RFC7252" section="4.3" sectionFormat="bare"/> of <xref
Confirmable message for determining support for Q-Block1 and Q-Block2 target="RFC7252" format="default"/>). To reliably get a
Options. This CON message can be sent under the base CoAP congestion rejection message, it is therefore <bcp14>REQUIRED</bcp14> that clients
control setup specified in Section 4.7 of <xref use a
target="RFC7252"></xref> (that is, NSTART does not need to be Confirmable message for determining support for the Q-Block1 and Q-Block
increased (<xref target="cc-con"></xref>)).</t> 2
options. This Confirmable message can be sent under the base CoAP conges
<t>The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a tion
CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option control setup specified in <xref target="RFC7252" section="4.7"
must reject the request or response that uses either option (See sectionFormat="of" format="default"/> (that is, NSTART does not need to b
Section 5.7.1 of <xref target="RFC7252"></xref>).</t> e
increased (<xref target="cc-con" format="default"/>)).</t>
<t>The Q-Block2 Option is repeatable when requesting retransmission of <t>The Q-Block1 and Q-Block2 options are unsafe to forward. That is, a
missing blocks, but not otherwise. Except that case, any request CoAP proxy that does not understand the Q-Block1 (or Q-Block2) option
carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled must reject the request or response that uses either option (see
following the procedure specified in Section 5.4.5 of <xref <xref target="RFC7252" section="5.7.1" sectionFormat="of" format="defaul
target="RFC7252"></xref>.</t> t"/>).</t>
<t>The Q-Block2 option is repeatable when requesting retransmission of
<t>The Q-Block1 and Q-Block2 Options, like the Block1 and Block2 missing blocks but not otherwise. Except for that case, any request
Options, are of both class E and class U for OSCORE processing (Table carrying multiple Q-Block1 (or Q-Block2) options <bcp14>MUST</bcp14> be
2). The Q-Block1 (or Q-Block2) Option MAY be an Inner or Outer option handled
(Section 4.1 of <xref target="RFC8613"></xref>). The Inner and Outer following the procedure specified in <xref target="RFC7252" section="5.4
.5"
sectionFormat="of" format="default"/>.</t>
<t>The Q-Block1 and Q-Block2 options, like the Block1 and Block2
options, are of both class E and class U for OSCORE processing (<xref
target="oscore" format="default"/>). The Q-Block1 (or Q-Block2) option
<bcp14>MAY</bcp14> be an Inner or Outer option
(<xref target="RFC8613" section="4.1" sectionFormat="of" format="default
"/>). The
Inner and Outer
values are therefore independent of each other. The Inner option is values are therefore independent of each other. The Inner option is
encrypted and integrity protected between clients and servers, and encrypted and integrity protected between clients and servers and
provides message body identification in case of end-to-end provides message body identification in case of end-to-end
fragmentation of requests. The Outer option is visible to proxies and fragmentation of requests. The Outer option is visible to proxies and
labels message bodies in case of hop-by-hop fragmentation of labels message bodies in case of hop-by-hop fragmentation of
requests.</t> requests.</t>
<table align="center" anchor="oscore">
<t><figure align="center"> <name>OSCORE Protection of the Q-Block1 and Q-Block2 Options</name>
<artwork align="center"><![CDATA[ +--------+------ <thead>
-----------+---+---+ <tr>
| Number | Name | E | U | <th>Number</th>
+========+=================+===+===+ <th>Name</th>
| TBA1 | Q-Block1 | x | x | <th>E</th>
| TBA2 | Q-Block2 | x | x | <th>U</th>
+--------+-----------------+---+---+ </tr>
Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options </thead>
]]></artwork> <tbody>
</figure></t> <tr>
<td>19</td>
<t></t> <td>Q-Block1</td>
<td>x</td>
<t>Note that if Q-Block1 or Q-Block2 Options are included in a packet <td>x</td>
as Inner options, Block1 or Block2 Options MUST NOT be included as </tr>
Inner options. Similarly, there MUST NOT be a mix of Q-Block and Block <tr>
for the Outer options. Messages that do not adhere with this behavior <td>31</td>
MUST be rejected with 4.02 (Bad Option). Q-Block and Block Options can <td>Q-Block2</td>
be mixed across Inner and Outer options as these are handled <td>x</td>
<td>x</td>
</tr>
</tbody>
</table>
<t>Note that, if the Q-Block1 or Q-Block2 options are included in a pack
et
as Inner options, the Block1 or Block2 options <bcp14>MUST NOT</bcp14> b
e included
as Inner options. Similarly, there <bcp14>MUST NOT</bcp14> be a mix of Q-
Block and
Block options for the Outer options. Messages that do not adhere to this
behavior
<bcp14>MUST</bcp14> be rejected with a 4.02 (Bad Option). The Q-Block an
d Block options can
be mixed across Inner and Outer options, as these are handled
independently of each other. For clarity, if OSCORE is not being used, independently of each other. For clarity, if OSCORE is not being used,
there MUST NOT be a mix of Q-Block and Block Options in the same there <bcp14>MUST NOT</bcp14> be a mix of Q-Block and Block options in t he same
packet.</t> packet.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Structure of the Q-Block1 and Q-Block2 Options</name>
<t>The structure of the Q-Block1 and Q-Block2 options follows the
structure defined in <xref target="RFC7959" section="2.2" sectionFormat=
"of"
format="default"/>.</t>
<section title="Structure of Q-Block1 and Q-Block2 Options"> <t>There is no default value for the Q-Block1 and Q-Block2 options.
<t>The structure of Q-Block1 and Q-Block2 Options follows the The absence of one of these options is equivalent to an option value of
structure defined in Section 2.2 of <xref 0
target="RFC7959"></xref>.</t>
<t>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
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 set block is the first and only block of the transfer (block number is set
to 0, M is unset). However, in contrast to the explicit value 0, which to 0; M is unset). However, in contrast to the explicit value 0, which
would indicate a size of the block (SZX) of 0, and thus a size value 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 absence of 16 bytes, there is no specific size implied by the absence
of the option -- the size is left unspecified. (As for any uint, the of the option -- the size is left unspecified. (As for any uint, the
explicit value 0 is efficiently indicated by a zero-length option; explicit value 0 is efficiently indicated by a zero-length option;
this, therefore, is different in semantics from the absence of the therefore, this is semantically different from the absence of the
option).</t> option.)</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Using the Q-Block1 Option "> <name>Using the Q-Block1 Option</name>
<t>The Q-Block1 Option is used when the client wants to send a large <t>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.</t> packet.</t>
<t>When the Q-Block1 option is used, the client <bcp14>MUST</bcp14> incl
<t>When Q-Block1 Option is used, the client MUST include a Request-Tag ude a
Option <xref target="I-D.ietf-core-echo-request-tag"></xref>. The Request-Tag option <xref target="RFC9175" format="default"/>. The
Request-Tag value MUST be the same for all of the requests for the Request-Tag value <bcp14>MUST</bcp14> be the same for all of the request
s for the
body of data that is being transferred. The Request-Tag is opaque, but body of data that is being transferred. The Request-Tag is opaque, but
the client MUST ensure that it is unique for every different body of the client <bcp14>MUST</bcp14> ensure that it is unique for every differ
transmitted data.<list style="empty"> ent body of
<t>Implementation Note: It is suggested that the client treats the transmitted data.</t>
<t indent="3">Implementation Note: It is suggested that the client tre
ats 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.</t> peers.</t>
</list></t> <t><xref target="size" format="default"/> discusses the use of the Size1
option.</t>
<t><xref target="size"></xref> discusses the use of Size1 Option.</t>
<t>For Confirmable transmission, the server continues to acknowledge <t>For Confirmable transmission, the server continues to acknowledge
each packet, but a response is not required (whether separate or each packet, but a response is not required (whether separate or
piggybacked) until successful receipt of the body by the server. For piggybacked) until successful receipt of the body by the server. For
Non-confirmable transmission, no response is required until either the Non-confirmable transmission, no response is required until either the
successful receipt of the body by the server or a timer expires with successful receipt of the body by the server or a timer expires with
some of the payloads having not yet arrived. In the latter case, a some of the payloads having not yet arrived. In the latter case, a
"retransmit missing payloads" response is needed. For reliable "retransmit missing payloads" response is needed. For reliable
transports (e.g., <xref target="RFC8323"></xref>), a response is not transports (e.g., <xref target="RFC8323" format="default"/>), a response is not
required until successful receipt of the body by the server.</t> required until successful receipt of the body by the server.</t>
<t>Each individual message that carries a block of the body is treated <t>Each individual message that carries a block of the body is treated
as a new request (<xref target="token"></xref>).</t> as a new request (<xref target="token" format="default"/>).</t>
<t>The client <bcp14>MUST</bcp14> send the payloads in order of increasi
<t>The client MUST send the payloads in order of increasing block ng block
number, starting from zero, until the body is complete (subject to any number, starting from zero, until the body is complete (subject to any
congestion control (<xref target="cc"></xref>)). Any missing payloads congestion control (<xref target="cc" format="default"/>)). In addition,
requested by the server must in addition be separately transmitted any
missing payloads requested by the server must be separately transmitted
with increasing block numbers.</t> with increasing block numbers.</t>
<t>The following response codes are used:</t>
<t>The following Response Codes are used:</t> <dl newline="true" spacing="normal">
<dt>2.01 (Created)</dt>
<t>2.01 (Created)<list style="empty"> <dd>This response code indicates successful receipt of the entire
<t>This Response Code indicates successful receipt of the entire body and that the resource was created. The token to use <bcp14>MUST</bc
body and that the resource was created. The token to use MUST be p14> be
one of the tokens that were received in a request for this one of the tokens that were received in a request for this
block-wise exchange. However, it is desirable to provide the one block-wise exchange. However, it is desirable to provide the one
used in the last received request, since that will aid any used in the last received request, since that will aid any
troubleshooting. The client should then release all of the tokens troubleshooting. The client should then release all of the tokens
used for this body. Note that the last received payload might not used for this body. Note that the last received payload might not
be the one with the highest block number.</t> be the one with the highest block number.</dd>
</list></t> <dt>2.02 (Deleted)</dt>
<dd>This response code indicates successful receipt of the entire
<t>2.02 (Deleted)<list style="empty"> body and that the resource was deleted when using POST (<xref target="RF
<t>This Response Code indicates successful receipt of the entire C7252"
body and that the resource was deleted when using POST (Section section="5.8.2" sectionFormat="of" format="default"/>). The token to use
5.8.2 <xref target="RFC7252"></xref>). The token to use MUST be <bcp14>MUST</bcp14> be
one of the tokens that were received in a request for this one of the tokens that were received in a request for this
block-wise exchange. However, it is desirable to provide the one block-wise exchange. However, it is desirable to provide the one
used in the last received request. The client should then release used in the last received request. The client should then release
all of the tokens used for this body.</t> all of the tokens used for this body.</dd>
</list></t> <dt>2.04 (Changed)</dt>
<dd>This response code indicates successful receipt of the entire
<t>2.04 (Changed)<list style="empty"> body and that the resource was updated. The token to use <bcp14>MUST</bc
<t>This Response Code indicates successful receipt of the entire p14> be
body and that the resource was updated. The token to use MUST be one of the tokens that were received in a request for this
one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one
block-wise exchange. However, it is desirable to provide the one used in the last received request. The client should then release
used in the last received request. The client should then release all of the tokens used for this body.</dd>
all of the tokens used for this body.</t> <dt>2.05 (Content)</dt>
</list></t> <dd><t>This response code indicates successful receipt of the entire
FETCH request body (<xref target="RFC8132" section="2" sectionFormat="of
<t>2.05 (Content)<list style="empty"> " format="default"/>)
<t>This Response Code indicates successful receipt of the entire and that the appropriate representation of the resource is being
FETCH request body (Section 2 of <xref target="RFC8132"></xref>) returned. The token to use <bcp14>MUST</bcp14> be one of the tokens that
and that the appropriate representation of the resource is being were
returned. The token to use MUST be one of the tokens that were received in a request for this block-wise exchange. However, it is
received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received
desirable to provide the one used in the last received request.</t>
request.</t> <t>If the FETCH request includes the Observe option, then the
server <bcp14>MUST</bcp14> use the same token as used for the 2.05 (Cont
<t>If the FETCH request includes the Observe Option, then the ent)
server MUST use the same token as used for the 2.05 (Content) response for returning any triggered Observe responses so that the
response for returning any Observe triggered responses so that the client can match them up.</t>
client can match them up.</t> <t>The client should then release all of the tokens used for this
body apart from the one used for tracking an observed
<t>The client should then release all of the tokens used for this resource.</t></dd>
body apart from the one used for tracking an observed <dt>2.31 (Continue)</dt>
resource.</t> <dd><t>This response code can be used to indicate that all of the
</list></t> blocks up to and including the Q-Block1 option block NUM (all
having the M bit set) have been successfully received. The token
<t>2.31 (Continue)<list style="empty"> to use <bcp14>MUST</bcp14> be one of the tokens that were received in a
<t>This Response Code can be used to indicate that all of the request
blocks up to and including the Q-Block1 Option block NUM (all for this latest MAX_PAYLOADS_SET block-wise exchange. However, it
having the M bit set) have been successfully received. The token is desirable to provide the one used in the last received
to use MUST be one of the tokens that were received in a request request.</t>
for this latest MAX_PAYLOADS_SET block-wise exchange. However, it <t>The client should then release all of the tokens used for this
is desirable to provide the one used in the last received MAX_PAYLOADS_SET.</t>
request.</t> <t>A response using this response code <bcp14>MUST NOT</bcp14> be genera
ted for
<t>The client should then release all of the tokens used for this every received Q-Block1 option request. It <bcp14>SHOULD</bcp14> only be
MAX_PAYLOADS_SET.</t> generated when all the payload requests are Non-confirmable and a
MAX_PAYLOADS_SET has been received by the server. More details
<t>A response using this Response Code MUST NOT be generated for about the motivations for this optimization are discussed in <xref
every received Q-Block1 Option request. It SHOULD only be target="cc-non" format="default"/>.</t>
generated when all the payload requests are Non-confirmable and a <t>This response code <bcp14>SHOULD NOT</bcp14> be generated for CON, as
MAX_PAYLOADS_SET has been received by the server. More details this may
about the motivations for this optimization are discussed in <xref cause duplicated payloads to unnecessarily be sent.</t></dd>
target="cc-non"></xref>.</t> <dt>4.00 (Bad Request)</dt>
<dd>This response code <bcp14>MUST</bcp14> be returned if the request do
<t>This Response Code SHOULD NOT be generated for CON as this may es not
cause duplicated payloads to unnecessarily be sent.</t> include a Request-Tag option or a Size1 option but does include a
</list></t> Q-Block1 option.</dd>
<dt>4.02 (Bad Option)</dt>
<t>4.00 (Bad Request)<list style="empty"> <dd>This response code <bcp14>MUST</bcp14> be returned for a Confirmable
<t>This Response Code MUST be returned if the request does not request
include a Request-Tag Option or a Size1 Option but does include a if the server does not support the Q-Block options. Note that a
Q-Block1 option.</t> Reset message may be sent in case of a Non-confirmable request.</dd>
</list></t> <dt>4.08 (Request Entity Incomplete)</dt>
<dd><t>As a reminder, this response code returned without content type
<t>4.02 (Bad Option)<list style="empty"> "application/missing-blocks+cbor-seq" (<xref target="new-format"
<t>This Response Code MUST be returned for a Confirmable request format="default"/>) is handled as in <xref target="RFC7959" section="2.9.
if the server does not support the Q-Block Options. Note that a 2"
reset message may be sent in case of Non-confirmable request.</t> sectionFormat="of" format="default"/>.</t>
</list></t> <t>This response code returned with content type
"application/missing-blocks+cbor-seq" indicates that some of the
<t>4.08 (Request Entity Incomplete)<list style="empty"> payloads are missing and need to be resent. The client then
<t>As a reminder, this Response Code returned without Content-Type retransmits the individual missing payloads using the same
"application/missing-blocks+cbor-seq" (<xref Request-Tag, Size1, and Q-Block1 options to specify the same NUM,
target="new-format"></xref>) is handled as in Section 2.9.2 <xref SZX, and M bit values as those sent initially in the original (but not
target="RFC7959"></xref>.</t> received) packets.</t>
<t>The Request-Tag value to use is determined by taking the token
<t>This Response Code returned with Content-Type in the 4.08 (Request Entity Incomplete) response, locating the
"application/missing-blocks+cbor-seq" indicates that some of the matching client request, and then using its Request-Tag.</t>
payloads are missing and need to be resent. The client then <t>The token to use in the 4.08 (Request Entity Incomplete)
retransmits the individual missing payloads using the same response <bcp14>MUST</bcp14> be one of the tokens that were received in
Request-Tag, Size1, and, Q-Block1 Option to specify the same NUM, a request
SZX, and M bit as sent initially in the original, but not for this block-wise body exchange. However, it is desirable to
received, packet.</t> provide the one used in the last received request. See <xref target="cod
e"
<t>The Request-Tag value to use is determined by taking the token format="default"/> for further information.</t>
in the 4.08 (Request Entity Incomplete) response, locating the <t>If the server has not received all the blocks of a body, but
matching client request, and then using its Request-Tag.</t> one or more NON payloads have been received, it <bcp14>SHOULD</bcp14> wa
it for
<t>The token to use in the 4.08 (Request Entity Incomplete) NON_RECEIVE_TIMEOUT (<xref target="cc-non" format="default"/>) before se
response MUST be one of the tokens that were received in a request nding
for this block-wise body exchange. However, it is desirable to a 4.08 (Request Entity Incomplete) response.</t></dd>
provide the one used in the last received request. See <xref <dt>4.13 (Request Entity Too Large)</dt>
target="code"></xref> for further information.</t> <dd><t>This response code can be returned under conditions similar to
those discussed in <xref target="RFC7959" section="2.9.3" sectionFormat=
<t>If the server has not received all the blocks of a body, but "of"
one or more NON payloads have been received, it SHOULD wait for format="default"/>.</t>
NON_RECEIVE_TIMEOUT (<xref target="cc-non"></xref>) before sending <t>This response code can be returned if there is insufficient
a 4.08 (Request Entity Incomplete) response.</t> space to create a response PDU with a block size of 16 bytes (SZX
</list></t> = 0) to send back all the response options as appropriate. In this
case, the Size1 option is not included in the response.</t></dd>
<t>4.13 (Request Entity Too Large)<list style="empty"> </dl>
<t>This Response Code can be returned under similar conditions to <t>Further considerations related to the transmission timings of the 4.0
those discussed in Section 2.9.3 of <xref 8
target="RFC7959"></xref>.</t> (Request Entity Incomplete) and 2.31 (Continue) response codes are
discussed in <xref target="cc-non" format="default"/>.</t>
<t>This Response Code can be returned if there is insufficient
space to create a response PDU with a block size of 16 bytes (SZX
= 0) to send back all the response options as appropriate. In this
case, the Size1 Option is not included in the response.</t>
</list></t>
<t>Further considerations related to the transmission timings of 4.08
(Request Entity Incomplete) and 2.31 (Continue) Response Codes are
discussed in <xref target="cc-non"></xref>.</t>
<t>If a server receives payloads with different Request-Tags for the <t>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.</t> any, the client is terminating the transmission for.</t>
<t>If the client elects to stop the transmission of a complete body, <t>If the client elects to stop the transmission of a complete body,
and absent any local policy, the client MUST "forget" all tracked then absent any local policy, the client <bcp14>MUST</bcp14> "forget" al
tokens associated with the body's Request-Tag so that a reset message l
tracked
tokens associated with the body's Request-Tag so that a Reset message
is generated for the invalid token in the 4.08 (Request Entity is generated for the invalid token in the 4.08 (Request Entity
Incomplete) response. The server on receipt of the reset message Incomplete) response. On receipt of the Reset message, the server
SHOULD delete the partial body.</t> <bcp14>SHOULD</bcp14> delete the partial body.</t>
<t>If the server receives a duplicate block with the same Request-Tag, <t>If the server receives a duplicate block with the same Request-Tag,
it MUST ignore the payload of the packet, but MUST still respond as if it <bcp14>MUST</bcp14> ignore the payload of the packet but <bcp14>MUST< /bcp14> still respond as if
the block was received for the first time.</t> the block was received for the first time.</t>
<t>A server <bcp14>SHOULD</bcp14> maintain a partial body (missing paylo
<t>A server SHOULD maintain a partial body (missing payloads) for ads) for
NON_PARTIAL_TIMEOUT (<xref target="cc-non"></xref>).</t> NON_PARTIAL_TIMEOUT (<xref target="cc-non" format="default"/>).</t>
</section> </section>
<section anchor="qblock2" numbered="true" toc="default">
<section anchor="qblock2" title="Using the Q-Block2 Option"> <name>Using the Q-Block2 Option</name>
<t>In a request for any block number, the M bit unset indicates the <t>In a request for any block number, an unset M bit indicates the
request is just for that block. If the M bit is set, this has request is just for that block. If the M bit is set, this has
different meanings based on the NUM value:<list style="hanging"> different meanings based on the NUM value:</t>
<t hangText="NUM is zero:">This is a request for the entire <dl newline="false" spacing="normal">
body.</t> <dt>NUM is zero:</dt>
<dd>This is a request for the entire body.</dd>
<t <dt>'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero:</dt>
hangText="'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero:" <dd>This is used to confirm that the current MAX_PAYLOADS_SET (the lat
>This est
is used to confirm that the current MAX_PAYLOADS_SET (the latest block having block number NUM-1) has been successfully received
block having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to
and that, upon receipt of this request, the server can continue to send the next MAX_PAYLOADS_SET (the first block having block
send the next MAX_PAYLOADS_SET (the first block having block number NUM). This is the 'Continue' Q-Block-2 and conceptually has
number NUM). This is the 'Continue' Q-Block-2 and conceptually has the same usage (i.e., continue sending the next set of data) as
the same usage (i.e., continue sending the next set of data) as the use of 2.31 (Continue) for Q-Block1.</dd>
the use of 2.31 (Continue) for Q-Block1.</t> <dt>Any other value of NUM:</dt>
<dd>This is a request for that block and for all of the remaining bloc
<t hangText="Any other value of NUM:">This is a request for that ks in the
block and for all of the remaining blocks in the current current MAX_PAYLOADS_SET.</dd>
MAX_PAYLOADS_SET.</t> </dl>
</list></t> <t>If the request includes multiple Q-Block2 options and these options
<t>If the request includes multiple Q-Block2 Options and these options
overlap (e.g., combination of M being set (this and later blocks) and overlap (e.g., combination of M being set (this and later blocks) and
being unset (this individual block)) resulting in an individual block unset (this individual block)), resulting in an individual block
being requested multiple times, the server MUST only send back one being requested multiple times, the server <bcp14>MUST</bcp14> 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.</t> amplification attacks.</t>
<t>The payloads sent back from the server as a response <bcp14>MUST</bcp
<t>The payloads sent back from the server as a response MUST all have 14> all have
the same ETag (Section 5.10.6 of <xref target="RFC7252"></xref>) for the same ETag (<xref target="RFC7252" section="5.10.6" sectionFormat="of
the same body. The server MUST NOT use the same ETag value for " format="default"/>) for
the same body. The server <bcp14>MUST NOT</bcp14> use the same ETag valu
e for
different representations of a resource.</t> different representations of a resource.</t>
<t>The ETag is opaque, but the server <bcp14>MUST</bcp14> ensure that it
<t>The ETag is opaque, but the server MUST ensure that it is unique is unique
for every different body of transmitted data.</t> for every different body of transmitted data.</t>
<t indent="3">Implementation Note: It is suggested that the server treat
<t><list style="empty"> s the
<t>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.</t>
whenever a new body of data is being transmitted between <t><xref target="size" format="default"/> discusses the use of the Size2
peers.</t> option.</t>
</list></t>
<t><xref target="size"></xref> discusses the use of Size2 Option.</t>
<t>The client may elect to request any detected missing blocks or just <t>The client may elect to request any detected missing blocks or just
ignore the partial body. This decision is implementation specific.</t> ignore the partial body. This decision is implementation specific.</t>
<t>For NON payloads, the client <bcp14>SHOULD</bcp14> wait for NON_RECEI
<t>For NON payloads, the client SHOULD wait NON_RECEIVE_TIMEOUT (<xref VE_TIMEOUT (<xref target="cc-non" format="default"/>) after the last received pa
target="cc-non"></xref>) after the last received payload before yload before
requesting retransmission of any missing blocks. Retransmission is requesting retransmission of any missing blocks. Retransmission is
requested by issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request requested by issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request
that contains one or more Q-Block2 Options that define the missing that contains one or more Q-Block2 options that define the missing
block(s). Generally the M bit on the Q-Block2 Option(s) SHOULD be block(s). Generally, the M bit on the Q-Block2 option(s) <bcp14>SHOULD</
unset, although the M bit MAY be set to request this and later blocks bcp14> be
from this MAX_PAYLOADS_SET, see <xref target="sec-nonb411"></xref> for unset, although the M bit <bcp14>MAY</bcp14> be set to request this and
later
blocks
from this MAX_PAYLOADS_SET; see <xref target="sec-nonb411" format="defau
lt"/> for
an example of this in operation. Further considerations related to the an example of this in operation. Further considerations related to the
transmission timing for missing requests are discussed in <xref transmission timing for missing requests are discussed in <xref target="
target="cc-non"></xref>.</t> cc-non" format="default"/>.</t>
<t>The missing block numbers requested by the client <bcp14>MUST</bcp14>
<t>The missing block numbers requested by the client MUST have an have an
increasing block number in each additional Q-Block2 Option with no increasing block number in each additional Q-Block2 option with no
duplicates. The server SHOULD respond with a 4.00 (Bad Request) to duplicates. The server <bcp14>SHOULD</bcp14> respond with a 4.00 (Bad Re
quest) to
requests not adhering to this behavior. Note that the ordering requests not adhering to this behavior. Note that the ordering
constraint is meant to force the client to check for duplicates and constraint is meant to force the client to check for duplicates and
remove them. This also helps with troubleshooting.</t> remove them. This also helps with troubleshooting.</t>
<t>If the client receives a duplicate block with the same ETag, it <t>If the client receives a duplicate block with the same ETag, it
MUST silently ignore the payload.</t> <bcp14>MUST</bcp14> silently ignore the payload.</t>
<t>A client <bcp14>SHOULD</bcp14> maintain a partial body (missing paylo
<t>A client SHOULD maintain a partial body (missing payloads) for ads) for
NON_PARTIAL_TIMEOUT (<xref target="cc-non"></xref>) or as defined by NON_PARTIAL_TIMEOUT (<xref target="cc-non" format="default"/>) or as def
the Max-Age Option (or its default of 60 seconds (Section 5.6.1 of ined by
<xref target="RFC7252"></xref>)), whichever is the less. On release of the Max-Age option (or its default of 60 seconds (<xref target="RFC7252"
section="5.6.1" sectionFormat="of" format="default"/>)), whichever is les
s.
On release of
the partial body, the client should then release all of the tokens the partial body, the client should then release all of the tokens
used for this body apart from the token that is used to track a used for this body apart from the token that is used to track a
resource that is being observed.</t> resource that is being observed.</t>
<t>The ETag option should not be used in the request for missing
<t>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
blocks as the server could respond with a 2.03 (Valid) response with
no payload. It can be used in the request if the client wants to check no payload. It can be used in the request if the client wants to check
the freshness of the locally cached body response.</t> the freshness of the locally cached body response.</t>
<t>The server <bcp14>SHOULD</bcp14> maintain a cached copy of the body w
<t>The server SHOULD maintain a cached copy of the body when using the hen using the
Q-Block2 Option to facilitate retransmission of any missing Q-Block2 option to facilitate retransmission of any missing
payloads.</t> payloads.</t>
<t>If the server detects partway through a body transfer that the
<t>If the server detects part way through a body transfer that the
resource data has changed and the server is not maintaining a cached resource data has changed and the server is not maintaining a cached
copy of the old data, then the transmission is terminated. Any copy of the old data, then the transmission is terminated. Any
subsequent missing block requests MUST be responded to using the subsequent missing block requests <bcp14>MUST</bcp14> be responded to us
latest ETag and Size2 Option values with the updated data.</t> ing the
latest ETag and Size2 option values with the updated data.</t>
<t>If the server responds during a body update with a different ETag <t>If the server responds during a body update with a different ETag
Option value (as the resource representation has changed), then the option value (as the resource representation has changed), then the
client should treat the partial body with the old ETag as no longer client should treat the partial body with the old ETag as no longer
being fresh. The client may then request all of the new data by being fresh. The client may then request all of the new data by
specifying Q-Block2 with block number '0' and the M bit set.</t> specifying Q-Block2 with block number '0' and the M bit set.</t>
<t>If the server transmits a new body of data (e.g., a triggered <t>If the server transmits a new body of data (e.g., a triggered
Observe notification) with a new ETag to the same client as an Observe notification) with a new ETag to the same client as an
additional response, the client should remove any partially received additional response, the client should remove any partially received
body held for a previous ETag for that resource as it is unlikely the body held for a previous ETag for that resource, as it is unlikely the
missing blocks can be retrieved.</t> missing blocks can be retrieved.</t>
<t>If there is insufficient space to create a response PDU with a <t>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 block size of 16 bytes (SZX = 0) to send back all the response options
as appropriate, a 4.13 (Request Entity Too Large) is returned without as appropriate, a 4.13 (Request Entity Too Large) is returned without
the Size1 Option.</t> the Size1 option.</t>
<t>For Confirmable traffic, the server typically acknowledges the <t>For Confirmable traffic, the server typically acknowledges the
initial request using an ACK with a piggybacked payload, and then initial request using an Acknowledgment (ACK) with a piggybacked payload and then
sends the subsequent payloads of the MAX_PAYLOADS_SET as CON sends the subsequent payloads of the MAX_PAYLOADS_SET as CON
responses. These CON responses are individually ACKed by the client. responses. These CON responses are individually ACKed by the client.
The server will detect failure to send a packet and SHOULD terminate The server will detect failure to send a packet and <bcp14>SHOULD</bcp14 > terminate
the body transfer, but the client can issue, after a MAX_TRANSMIT_SPAN the body transfer, but the client can issue, after a MAX_TRANSMIT_SPAN
delay, a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for any delay, a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for any
missing blocks as needed.</t> missing blocks as needed.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Using Observe Option"> <name>Using the Observe Option</name>
<t>For a request that uses Q-Block1, the Observe value <xref <t>For a request that uses Q-Block1, the Observe value <xref target="RFC
target="RFC7641"></xref> MUST be the same for all the payloads of the 7641" format="default"/> <bcp14>MUST</bcp14> be the same for all the payloads of
the
same body. This includes any missing payloads that are same body. This includes any missing payloads that are
retransmitted.</t> retransmitted.</t>
<t>For a response that uses Q-Block2, the Observe value <bcp14>MUST</bcp
<t>For a response that uses Q-Block2, the Observe value MUST be the 14> be the
same for all the payloads of the same body. This is different from same for all the payloads of the same body. This is different from
Block2 usage where the Observe value is only present in the first Block2 usage where the Observe value is only present in the first
block (Section 3.4 of <xref target="RFC7959"></xref>). This includes block (<xref target="RFC7959" section="3.4" sectionFormat="of" format="d efault"/>). This includes
payloads transmitted following receipt of the 'Continue' Q-Block2 payloads transmitted following receipt of the 'Continue' Q-Block2
Option (<xref target="qblock2"></xref>) by the server. If a missing option (<xref target="qblock2" format="default"/>) by the server. If a m issing
payload is requested by a client, then both the request and response payload is requested by a client, then both the request and response
MUST NOT include the Observe Option.</t> <bcp14>MUST NOT</bcp14> include the Observe option.</t>
</section> </section>
<section anchor="size" numbered="true" toc="default">
<section anchor="size" title="Using Size1 and Size2 Options"> <name>Using the Size1 and Size2 Options</name>
<t>Section 4 of <xref target="RFC7959"></xref> defines two CoAP <t><xref target="RFC7959" section="4" sectionFormat="of" format="default
"/> defines two CoAP
options: Size1 for indicating the size of the representation options: Size1 for indicating the size of the representation
transferred in requests and Size2 for indicating the size of the transferred in requests and Size2 for indicating the size of the
representation transferred in responses.</t> representation transferred in responses.</t>
<t>For the Q-Block1 and Q-Block2 options, the Size1 or Size2 option valu
<t>For Q-Block1 and Q-Block2 Options, the Size1 or Size2 Option values es
MUST exactly represent the size of the data on the body so that any <bcp14>MUST</bcp14> exactly represent the size of the data on the body s
o that any
missing data can easily be determined.</t> missing data can easily be determined.</t>
<t>The Size1 option <bcp14>MUST</bcp14> be used with the Q-Block1 option
<t>The Size1 Option MUST be used with the Q-Block1 Option when used in when used in
a request and MUST be present in all payloads of the request, a request and <bcp14>MUST</bcp14> be present in all payloads of the requ
preserving the same value. The Size2 Option MUST be used with the est,
Q-Block2 Option when used in a response and MUST be present in all preserving the same value. The Size2 option <bcp14>MUST</bcp14> be used
with the
Q-Block2 option when used in a response and <bcp14>MUST</bcp14> be prese
nt in all
payloads of the response, preserving the same value.</t> payloads of the response, preserving the same value.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Using Q-Block1 and Q-Block2 Options Together"> <name>Using the Q-Block1 and Q-Block2 Options Together</name>
<t>The behavior is similar to the one defined in Section 3.3 of <xref <t>The behavior is similar to the one defined in <xref target="RFC7959"
target="RFC7959"></xref> with Q-Block1 substituted for Block1 and section="3.3" sectionFormat="of" format="default"/> with Q-Block1 substituted fo
Q-Block2 for Block2.</t> r Block1 and
Q-Block2 substituted for Block2.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Using Q-Block2 Option With Multicast"> <name>Using the Q-Block2 Option with Multicast</name>
<t>Servers MUST ignore multicast requests that contain the Q-Block2 <t>Servers <bcp14>MUST</bcp14> ignore multicast requests that contain th
Option. As a reminder, Block2 Option can be used as stated in Section e Q-Block2
2.8 of <xref target="RFC7959"></xref>.</t> option. As a reminder, the Block2 option can be used as stated in <xref
target="RFC7959" section="2.8" sectionFormat="of" format="default"/>.</t>
</section> </section>
</section> </section>
<section anchor="code" numbered="true" toc="default">
<section anchor="code" <name>The Use of the 4.08 (Request Entity Incomplete) Response Code</name>
title="The Use of 4.08 (Request Entity Incomplete) Response Code"> <t>The 4.08 (Request Entity Incomplete) response code has a new content ty
<t>4.08 (Request Entity Incomplete) Response Code has a new Content-Type pe
"application/missing-blocks+cbor-seq" used to indicate that the server "application/missing-blocks+cbor-seq" used to indicate that the server
has not received all of the blocks of the request body that it needs to has not received all of the blocks of the request body that it needs to
proceed. Such messages must not be treated by the client as a fatal proceed. Such messages must not be treated by the client as a fatal
error.</t> error.</t>
<t>Likely causes are the client has not sent all blocks, some blocks <t>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 sent them
sufficiently long ago that the server has already discarded them.</t> a long enough time ago that the server has already discarded them.</t>
<t>The new data payload of the 4.08 (Request Entity Incomplete) response <t>The new data payload of the 4.08 (Request Entity Incomplete) response
with Content-Type set to "application/missing-blocks+cbor-seq" is with content type "application/missing-blocks+cbor-seq" is
encoded as a CBOR Sequence <xref target="RFC8742"></xref>. It comprises encoded as a Concise Binary Object Representation (CBOR) Sequence <xref
target="RFC8742" format="default"/>. It comprises
one or more missing block numbers encoded as CBOR unsigned integers one or more missing block numbers encoded as CBOR unsigned integers
<xref target="RFC8949"></xref>. The missing block numbers MUST be unique <xref target="RFC8949" format="default"/>. The missing block numbers <bcp1 4>MUST</bcp14> be unique
in each 4.08 (Request Entity Incomplete) response when created by the in each 4.08 (Request Entity Incomplete) response when created by the
server; the client MUST ignore any duplicates in the same 4.08 (Request server; the client <bcp14>MUST</bcp14> ignore any duplicates in the same 4 .08 (Request
Entity Incomplete) response.</t> Entity Incomplete) response.</t>
<t>The Content-Format option (<xref target="RFC7252" section="5.10.3" sect
ionFormat="of" format="default"/>) <bcp14>MUST</bcp14> be used in the 4.08 (Requ
est Entity
Incomplete) response. It <bcp14>MUST</bcp14> be set to
"application/missing-blocks+cbor-seq" (<xref target="new-format" format="d
efault"/>).</t>
<t>The Concise Data Definition Language (CDDL) <xref target="RFC8610" form
at="default"/>
(and see <xref target="RFC8742" section="4.1" sectionFormat="of"
format="default"/>) for the data describing these missing blocks is as fol
lows:</t>
<t>The Content-Format Option (Section 5.10.3 of <xref <figure anchor="cddl">
target="RFC7252"></xref>) MUST be used in the 4.08 (Request Entity <name>Structure of the Missing Blocks Payload</name>
Incomplete) response. It MUST be set to <sourcecode type="cddl"><![CDATA[
"application/missing-blocks+cbor-seq" (<xref ; This defines an array, the elements of which are to be used
target="new-format"></xref>).</t>
<t>The Concise Data Definition Language <xref target="RFC8610"></xref>
(and see Section 4.1 <xref target="RFC8742"></xref>) for the data
describing these missing blocks is as follows:</t>
<figure align="center" anchor="cddl"
title="Structure of the Missing Blocks Payload">
<artwork align="center"><![CDATA[; This defines an array, the elements o
f 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
]]></artwork> ]]></sourcecode>
</figure> </figure>
<t>This CDDL syntax <bcp14>MUST</bcp14> be followed.</t>
<t>This CDDL syntax MUST be followed.</t>
<t>It is desirable that the token to use for the response is the token <t>It is desirable that the token to use for the response is the token
that was used in the last block number received so far with the same that was used in the last block number received so far with the same
Request-Tag value. Note that the use of any received token with the same Request-Tag value. Note that the use of any received token with the same
Request-Tag would be acceptable, but providing the one used in the last Request-Tag would be acceptable, but providing the one used in the last
received payload will aid any troubleshooting. The client will use the received payload will aid any troubleshooting. The client will use the
token to determine what was the previously sent request to obtain the token to determine what was the previously sent request to obtain the
Request-Tag value that was used.</t> Request-Tag value that was used.</t>
<t>If the size of the 4.08 (Request Entity Incomplete) response packet <t>If the size of the 4.08 (Request Entity Incomplete) response packet
is larger than that defined by Section 4.6 <xref is larger than that defined by <xref target="RFC7252" section="4.6"
target="RFC7252"></xref>, then the number of reported missing blocks sectionFormat="of" format="default"/>, then the number of reported missing
MUST be limited so that the response can fit into a single packet. If blocks
<bcp14>MUST</bcp14> be limited so that the response can fit into a single
packet. If
this is the case, then the server can send subsequent 4.08 (Request this is the case, then the server can send subsequent 4.08 (Request
Entity Incomplete) responses containing the missing other blocks on Entity Incomplete) responses containing those additional missing blocks on
receipt of a new request providing a missing payload with the same receipt of a new request providing a missing payload with the same
Request-Tag.</t> Request-Tag.</t>
<t>The missing blocks <bcp14>MUST</bcp14> be reported in ascending order w
<t>The missing blocks MUST be reported in ascending order without any ithout any
duplicates. The client SHOULD silently drop 4.08 (Request Entity duplicates. The client <bcp14>SHOULD</bcp14> silently drop 4.08 (Request E
Incomplete) responses not adhering with this behavior.</t> ntity
Incomplete) responses not adhering to this behavior.</t>
<t><list style="hanging"> <t indent="3">Implementation Note: Consider limiting the number of
<t hangText="Implementation Note:">Consider limiting the number of missing payloads to MAX_PAYLOADS to minimize the need for congestion contr
missing payloads to MAX_PAYLOADS to minimize congestion control ol.
being needed. The CBOR sequence does not include any array The CBOR Sequence does not include any array
wrapper.</t> wrapper.</t>
</list></t> <t>A 4.08 (Request Entity Incomplete) response with content type
"application/missing-blocks+cbor-seq" <bcp14>SHOULD NOT</bcp14> be used wh
<t>The 4.08 (Request Entity Incomplete) with Content-Type en using
"application/missing-blocks+cbor-seq" SHOULD NOT be used when using Confirmable requests or a reliable connection <xref target="RFC8323" forma
Confirmable requests or a reliable connection <xref t="default"/>, as the client will be able to determine that
target="RFC8323"></xref> as the client will be able to determine that
there is a transmission failure of a particular payload and hence that there is a transmission failure of a particular payload and hence that
the server is missing that payload.</t> the server is missing that payload.</t>
</section> </section>
<section anchor="token" numbered="true" toc="default">
<section anchor="token" title="The Use of Tokens"> <name>The Use of Tokens</name>
<t>Each new request generally uses a new Token (and sometimes must, see <t>Each new request generally uses a new Token (and sometimes must; see
Section 4 of <xref target="I-D.ietf-core-echo-request-tag"></xref>). <xref target="RFC9175" section="4" sectionFormat="of" format="default"/>).
Additional responses to a request all use the token of the request they Additional responses to a request all use the token of the request they
respond to.</t> respond to.</t>
<t indent="3">Implementation Note: By using 8-byte tokens, it is
<t><list style="hanging"> possible to easily minimize the number of tokens that have to be
<t hangText="Implementation Note:">By using 8-byte tokens, it is tracked by clients, by keeping the bottom 32 bits the same for the
possible to easily minimize the number of tokens that have to be same body and the upper 32 bits containing the current body's
tracked by clients, by keeping the bottom 32 bits the same for the request number (incrementing every request, including every
same body and the upper 32 bits containing the current body's retransmit). This alleviates the client's need to keep
request number (incrementing every request, including every all the per-request state, e.g., per <xref target="RFC8974" section="3" se
re-transmit). This allows the client to be alleviated from keeping ctionFormat="of" format="default"/>. However, if using NoSec, <xref target="RFC8
all the per-request-state, e.g., in Section 3 of <xref 974" section="5.2" sectionFormat="of" format="default"/> needs to be considered
target="RFC8974"></xref>. However, if using NoSec, Section 5.2 of for security
<xref target="RFC8974"></xref> needs to be considered for security implications.</t>
implications.</t>
</list></t>
</section> </section>
<section anchor="cc" numbered="true" toc="default">
<section anchor="cc" title="Congestion Control for Unreliable Transports"> <name>Congestion Control for Unreliable Transports</name>
<t>The transmission of all the blocks of a single body over an <t>The transmission of all the blocks of a single body over an
unreliable transport MUST either all be Confirmable or all be unreliable transport <bcp14>MUST</bcp14> either all be Confirmable or all be
Non-confirmable. This is meant to simplify the congestion control Non-confirmable. This is meant to simplify the congestion control
procedure.</t> procedure.</t>
<t>As a reminder, there is no need for CoAP-specific congestion control <t>As a reminder, there is no need for CoAP-specific congestion control
for reliable transports <xref target="RFC8323"></xref>.</t> for reliable transports <xref target="RFC8323" format="default"/>.</t>
<section anchor="cc-con" numbered="true" toc="default">
<section anchor="cc-con" title="Confirmable (CON)"> <name>Confirmable (CON)</name>
<t>Congestion control for CON requests and responses is specified in <t>Congestion control for CON requests and responses is specified in
Section 4.7 of <xref target="RFC7252"></xref>. In order to benefit <xref target="RFC7252" section="4.7" sectionFormat="of" format="default" />. In order to benefit
from faster transmission rates, NSTART will need to be increased from from faster transmission rates, NSTART will need to be increased from
1. However, the other CON congestion control parameters will need to 1. However, the other CON congestion control parameters will need to
be tuned to cover this change. This tuning is not specified in this be tuned to cover this change. This tuning is not specified in this
document, given that the applicability scope of the current document, given that the applicability scope of the current
specification assumes that all requests and responses using Q-Block1 specification assumes that all requests and responses using Q-Block1
and Q-Block2 will be Non-confirmable (<xref target="scope"></xref>) and Q-Block2 will be Non-confirmable (<xref target="scope" format="defau lt"/>)
apart from the initial Q-Block functionality negotiation.</t> apart from the initial Q-Block functionality negotiation.</t>
<t>Following the failure to transmit a packet due to packet loss after <t>Following the failure to transmit a packet due to packet loss after
MAX_TRANSMIT_SPAN time (Section 4.8.2 of <xref MAX_TRANSMIT_SPAN time (<xref target="RFC7252" section="4.8.2" sectionFo
target="RFC7252"></xref>), it is implementation specific as to whether rmat="of" format="default"/>), it is implementation specific as to whether
there should be any further requests for missing data.</t> there should be any further requests for missing data.</t>
</section> </section>
<section anchor="cc-non" numbered="true" toc="default">
<section anchor="cc-non" title="Non-confirmable (NON)"> <name>Non-confirmable (NON)</name>
<t>This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT, <t>This document introduces the new parameters MAX_PAYLOADS, NON_TIMEOUT
,
NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT,
NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON
(Table 3).<list style="empty"> (<xref target="congestion" format="default"/>).</t>
<t>Note: Randomness may naturally be provided based on the traffic <t indent="3">Note: Randomness may naturally be provided based on the tr
profile, how PROBING_RATE is computed (as this is an average), and affic
when the peer responds. Randomness is explicitly added for some of profile, how PROBING_RATE is computed (as this is an average), and
the congestion control parameters to handle situations where every when the peer responds. Randomness is explicitly added for some of
thing is in sync when retrying.</t> the congestion control parameters to handle situations where everything
</list></t> is in sync when retrying.</t>
<t>MAX_PAYLOADS should be configurable with a default value of 10. <t>MAX_PAYLOADS should be configurable with a default value of 10.
Both CoAP endpoints MUST have the same value (otherwise there will be Both CoAP endpoints <bcp14>MUST</bcp14> have the same value (otherwise,
transmission delays in one direction) and the value MAY be negotiated there will be
between the endpoints to a common value by using a higher level transmission delays in one direction), and the value <bcp14>MAY</bcp14>
be negotiated
between the endpoints to a common value by using a higher-level
protocol (out of scope of this document). This is the maximum number protocol (out of scope of this document). This is the maximum number
of payloads that can be transmitted at any one time.<list of payloads that can be transmitted at any one time.</t>
style="empty"> <t indent="3">Note: The default value of 10 is chosen for reasons simila
<t>Note: The default value of 10 is chosen for reasons similar to r to
those discussed in Section 5 of <xref target="RFC6928"></xref>, those discussed in <xref target="RFC6928" section="5" sectionFormat="of"
especially given the target application discussed in <xref format="default"/>,
target="scope"></xref>.</t> especially given the target application discussed in <xref target="scope
</list></t> "
format="default"/>.</t>
<t>NON_TIMEOUT is used to compute the delay between sending <t>NON_TIMEOUT is used to compute the delay between sending
MAX_PAYLOADS_SET for the same body. By default, NON_TIMEOUT has the MAX_PAYLOADS_SET for the same body. By default, NON_TIMEOUT has the
same value as ACK_TIMEOUT (Section 4.8 of <xref same value as ACK_TIMEOUT (<xref target="RFC7252" section="4.8" sectionF
target="RFC7252"></xref>).</t> ormat="of" format="default"/>).</t>
<t>NON_TIMEOUT_RANDOM is the initial actual delay between sending the <t>NON_TIMEOUT_RANDOM is the initial actual delay between sending the
first two MAX_PAYLOADS_SETs of the same body. The same delay is then first two MAX_PAYLOADS_SETs of the same body. The same delay is then
used between the subsequent MAX_PAYLOADS_SETs. It is a random duration used between the subsequent MAX_PAYLOADS_SETs. It is a random duration
(not an integral number of seconds) between NON_TIMEOUT and (not an integral number of seconds) between NON_TIMEOUT and
(NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to 1.5 as (NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to 1.5, as
discussed in Section 4.8 of <xref target="RFC7252"></xref>.</t> discussed in <xref target="RFC7252" section="4.8" sectionFormat="of" for
mat="default"/>.</t>
<t>NON_RECEIVE_TIMEOUT is the initial time to wait for a missing <t>NON_RECEIVE_TIMEOUT is the initial time to wait for a missing
payload before requesting retransmission for the first time. Every payload before requesting retransmission for the first time. Every
time the missing payload is re-requested, the time to wait value time the missing payload is re-requested, the Time-to-Wait value
doubles. The time to wait is calculated as:<list style="empty"> doubles. The time to wait is calculated as:</t>
<t>Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - <t indent="3">Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Cou
nt -
1))</t> 1))</t>
</list></t>
<t>NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT. <t>NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT.
NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT_RANDOM by NON_RECEIVE_TIMEOUT <bcp14>MUST</bcp14> always be greater than NON_TIMEO UT_RANDOM by
at least one second so that the sender of the payloads has the at least one second so that the sender of the payloads has the
opportunity to start sending the next MAX_PAYLOADS_SET before the opportunity to start sending the next MAX_PAYLOADS_SET before the
receiver times out.</t> receiver times out.</t>
<t>NON_MAX_RETRANSMIT is the maximum number of times a request for the <t>NON_MAX_RETRANSMIT is the maximum number of times a request for the
retransmission of missing payloads can occur without a response from retransmission of missing payloads can occur without a response from
the remote peer. After this occurs, the local endpoint SHOULD consider the remote peer. After this occurs, the local endpoint <bcp14>SHOULD</bc
the body stale, remove any body, and release Tokens and Request-Tag on p14> consider
the body stale, remove any body, and release the tokens and Request-Tag
on
the client (or the ETag on the server). By default, NON_MAX_RETRANSMIT the client (or the ETag on the server). By default, NON_MAX_RETRANSMIT
has the same value as MAX_RETRANSMIT (Section 4.8 of <xref has the same value as MAX_RETRANSMIT (<xref target="RFC7252" section="4.
target="RFC7252"></xref>).</t> 8" sectionFormat="of" format="default"/>).</t>
<t>NON_PROBING_WAIT is used to limit the potential wait needed when <t>NON_PROBING_WAIT is used to limit the potential wait needed when
using PROBING_RATE. By default, NON_PROBING_WAIT is computed in a using PROBING_RATE. By default, NON_PROBING_WAIT is computed in a way
similar way as EXCHANGE_LIFETIME (Section 4.8.2 of <xref similar to EXCHANGE_LIFETIME (<xref target="RFC7252" section="4.8.2" sec
target="RFC7252"></xref>) but with ACK_TIMEOUT, MAX_RETRANSMIT, and tionFormat="of" format="default"/>) but with ACK_TIMEOUT, MAX_RETRANSMIT, and
PROCESSING_DELAY substituted with NON_TIMEOUT, NON_MAX_RETRANSMIT, and PROCESSING_DELAY substituted with NON_TIMEOUT, NON_MAX_RETRANSMIT, and
NON_TIMEOUT_RANDOM, respectively:<list style="empty"> NON_TIMEOUT_RANDOM, respectively:</t>
<t>NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - <t indent="3">NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT
1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + ) -
NON_TIMEOUT_RANDOM</t> 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT_RANDOM</t>
</list></t>
<t>NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. <t>NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
By default, NON_PARTIAL_TIMEOUT is computed in the same way as By default, NON_PARTIAL_TIMEOUT is computed in the same way as
EXCHANGE_LIFETIME (Section 4.8.2 of <xref target="RFC7252"></xref>) EXCHANGE_LIFETIME (<xref target="RFC7252" section="4.8.2" sectionFormat= "of" format="default"/>)
but with ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT but with ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT
and NON_MAX_RETRANSMIT, respectively:<list style="empty"> and NON_MAX_RETRANSMIT, respectively:</t>
<t>NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) <t indent="3">NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANS
- 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT</t> MIT)
</list></t> - 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT</t>
<table align="center" anchor="congestion">
<t><figure align="center"> <name>Congestion Control Parameters</name>
<artwork align="center"><![CDATA[+---------------------+------------ <thead>
-------+ <tr>
| Parameter Name | Default Value | <th>Parameter Name</th>
+=====================+===================+ <th>Default Value</th>
| MAX_PAYLOADS | 10 | </tr>
| NON_MAX_RETRANSMIT | 4 | </thead>
| NON_TIMEOUT | 2 s | <tbody>
| NON_TIMEOUT_RANDOM | between 2-3 s | <tr>
| NON_RECEIVE_TIMEOUT | 4 s | <td>MAX_PAYLOADS</td>
| NON_PROBING_WAIT | between 247-248 s | <td>10</td>
| NON_PARTIAL_TIMEOUT | 247 s | </tr>
+---------------------+-------------------+ <tr>
<td>NON_MAX_RETRANSMIT</td>
Table 3: Congestion Control Parameters]]></artwork> <td>4</td>
</figure></t> </tr>
<tr>
<td>NON_TIMEOUT</td>
<td>2 s</td>
</tr>
<tr>
<td>NON_TIMEOUT_RANDOM</td>
<td>between 2-3 s</td>
</tr>
<tr>
<td>NON_RECEIVE_TIMEOUT</td>
<td>4 s</td>
</tr>
<tr>
<td>NON_PROBING_WAIT</td>
<td>between 247-248 s</td>
</tr>
<tr>
<td>NON_PARTIAL_TIMEOUT</td>
<td>247 s</td>
</tr>
</tbody>
</table>
<t>The PROBING_RATE parameter in CoAP indicates the average data rate <t>The PROBING_RATE parameter in CoAP indicates the average data rate
that must not be exceeded by a CoAP endpoint in sending to a peer that must not be exceeded by a CoAP endpoint in sending to a peer
endpoint that does not respond. A single body will be subjected to endpoint that does not respond. A single body will be subjected to
PROBING_RATE (Section 4.7 of <xref target="RFC7252"></xref>), not the PROBING_RATE (<xref target="RFC7252" section="4.7" sectionFormat="of" fo rmat="default"/>), not the
individual packets. If the wait time between sending bodies that are individual packets. If the wait time between sending bodies that are
not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT,
then the wait time is limited to NON_PROBING_WAIT.<list style="empty"> then the wait time is limited to NON_PROBING_WAIT.</t>
<t>Note: For the particular DOTS application, PROBING_RATE and <aside><t>Note: For the particular DOTS application, PROBING_RATE and
other transmission parameters are negotiated between peers. Even other transmission parameters are negotiated between peers. Even
when not negotiated, the DOTS application uses customized defaults when not negotiated, the DOTS application uses customized defaults,
as discussed in Section 4.5.2 of <xref target="RFC8782"></xref>. as discussed in <xref target="RFC9132" section="4.5.2" sectionFormat="of
Note that MAX_PAYLOADS, NON_MAX_RETRANSMIT, NON_TIMEOUT, " format="default"/>.
NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT can be negotiated Note that MAX_PAYLOADS, NON_MAX_RETRANSMIT, NON_TIMEOUT,
between DOTS peers, e.g., as per <xref NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT can be negotiated
target="I-D.bosh-dots-quick-blocks"></xref>. When explicit values between DOTS peers, e.g., as per <xref target="I-D.bosh-dots-quick-blocks
are configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these "
values are used without applying any jitter.</t> format="default"/>. When explicit values
</list>Each NON 4.08 (Request Entity Incomplete) response is subject are configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
values are used without applying any jitter.</t></aside>
<t>Each NON 4.08 (Request Entity Incomplete) response is subject
to PROBING_RATE.</t> to PROBING_RATE.</t>
<t>Each NON GET or FETCH request using a Q-Block2 option is subject to
<t>Each NON GET or FETCH request using a Q-Block2 Option is subject to
PROBING_RATE.</t> PROBING_RATE.</t>
<t>As the sending of many payloads of a single body may itself cause <t>As the sending of many payloads of a single body may itself cause
congestion, after transmission of every MAX_PAYLOADS_SET of a single congestion, after transmission of every MAX_PAYLOADS_SET of a single
body, a delay MUST be introduced of NON_TIMEOUT_RANDOM before sending body, a delay of NON_TIMEOUT_RANDOM <bcp14>MUST</bcp14> be introduced be
the next MAX_PAYLOADS_SET unless a 'Continue' is received from the fore sending
the next MAX_PAYLOADS_SET, unless a 'Continue' is received from the
peer for the current MAX_PAYLOADS_SET, in which case the next peer for the current MAX_PAYLOADS_SET, in which case the next
MAX_PAYLOADS_SET MAY start transmission immediately.</t> MAX_PAYLOADS_SET <bcp14>MAY</bcp14> start transmission immediately.</t>
<t indent="3">Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET
<t><list style="empty"> having 10 payloads, this corresponds to 1500 * 10 * 8 = 120 kbits.
<t>Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET With a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates
having 10 payloads, this corresponds to 1500 * 10 * 8 = 120 Kbits. an average speed requirement of 60 kbps for a single body should
With a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates there be no responses. This transmission rate is further reduced
an average speed requirement of 60 Kbps for a single body should by being subject to PROBING_RATE.</t>
there be no responses. This transmission rate is further reduced
by being subject to PROBING_RATE.</t>
</list></t>
<t>The sending of a set of missing blocks of a body is restricted to <t>The sending of a set of missing blocks of a body is restricted to
those in a MAX_PAYLOADS_SET at a time. In other words, a those in a MAX_PAYLOADS_SET at a time. In other words, a
NON_TIMEOUT_RANDOM delay is still observed between each NON_TIMEOUT_RANDOM delay is still observed between each
MAX_PAYLOAD_SET.</t> MAX_PAYLOADS_SET.</t>
<t>For the Q-Block1 option, if the server responds with a 2.31 (Continue
<t>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 MAX_PAYLOADS_SET without any further delay. continue to send the next MAX_PAYLOADS_SET without any further delay.
If the server responds with a 4.08 (Request Entity Incomplete) If the server responds with a 4.08 (Request Entity Incomplete)
Response Code, then the missing payloads SHOULD be retransmitted response code, then the missing payloads <bcp14>SHOULD</bcp14> be retran smitted
before going into another NON_TIMEOUT_RANDOM delay prior to sending before going into another NON_TIMEOUT_RANDOM delay prior to sending
the next set of payloads.</t> the next set of payloads.</t>
<t>For the server receiving NON Q-Block1 requests, it <bcp14>SHOULD</bcp
<t>For the server receiving NON Q-Block1 requests, it SHOULD send back 14> send
a 2.31 (Continue) Response Code on receipt of all of the back a 2.31 (Continue) response code on receipt of all of the
MAX_PAYLOADS_SET to prevent the client unnecessarily delaying. If not MAX_PAYLOADS_SET to prevent the client unnecessarily delaying the transf
all of the MAX_PAYLOADS_SET were received, the server SHOULD delay for er of remaing blocks. If not
all of the MAX_PAYLOADS_SET were received, the server <bcp14>SHOULD</bcp
14> delay for
NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request
count for a payload) before sending the 4.08 (Request Entity count for a payload) before sending the 4.08 (Request Entity
Incomplete) Response Code for the missing payload(s). If all of the Incomplete) response code for the missing payload(s). If all of the
MAX_PAYLOADS_SET were received and a 2.31 (Continue) had been sent, MAX_PAYLOADS_SET were received and a 2.31 (Continue) response code had b
een sent,
but no more payloads were received for NON_RECEIVE_TIMEOUT but no more payloads were received for NON_RECEIVE_TIMEOUT
(exponentially scaled), the server SHOULD send a 4.08 (Request Entity (exponentially scaled), the server <bcp14>SHOULD</bcp14> send a 4.08 (Re quest Entity
Incomplete) response detailing the missing payloads after the block Incomplete) response detailing the missing payloads after the block
number that was indicated in the sent 2.31 (Continue). If the repeated number that was indicated in the sent 2.31 (Continue) response code. If the repeat
response count of the 4.08 (Request Entity Incomplete) exceeds response count of the 4.08 (Request Entity Incomplete) exceeds
NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and NON_MAX_RETRANSMIT, the server <bcp14>SHOULD</bcp14> discard the partial body and
stop requesting the missing payloads.</t> stop requesting the missing payloads.</t>
<t>It is likely that the client will start transmitting the next <t>It is likely that the client will start transmitting the next
MAX_PAYLOADS_SET before the server times out on waiting for the last MAX_PAYLOADS_SET before the server times out on waiting for the last blo ck
of the previous MAX_PAYLOADS_SET. On receipt of a payload from the of the previous MAX_PAYLOADS_SET. On receipt of a payload from the
next MAX_PAYLOADS_SET, the server SHOULD send a 4.08 (Request Entity next MAX_PAYLOADS_SET, the server <bcp14>SHOULD</bcp14> send a 4.08 (Req
Incomplete) Response Code indicating any missing payloads from any uest Entity
Incomplete) response code indicating any missing payloads from any
previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity
Incomplete) Response Code, the client SHOULD send the missing payloads Incomplete) response code, the client <bcp14>SHOULD</bcp14> send the mis
before continuing to send the remainder of the MAX_PAYLOADS_SET and sing
payloads before continuing to send the remainder of the MAX_PAYLOADS_SET
and
then go into another NON_TIMEOUT_RANDOM delay prior to sending the then go into another NON_TIMEOUT_RANDOM delay prior to sending the
next MAX_PAYLOADS_SET.</t> next MAX_PAYLOADS_SET.</t>
<t>For the client receiving NON Q-Block2 responses, it <bcp14>SHOULD</bc
<t>For the client receiving NON Q-Block2 responses, it SHOULD send a p14> send a
'Continue' Q-Block2 request (<xref target="qblock2"></xref>) for the 'Continue' Q-Block2 request (<xref target="qblock2" format="default"/>)
next MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET, to for the
prevent the server unnecessarily delaying. Otherwise the client SHOULD next MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET to
prevent the server unnecessarily delaying the transfer of remaining bloc
ks. Otherwise, the client <bcp14>SHOULD</bcp14>
delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the
repeat request count for a payload), before sending the request for repeat request count for a payload) before sending the request for
the missing payload(s). If the repeat request count for a missing the 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 <bcp14>SHOULD</bcp14> dis card the
partial body and stop requesting the missing payloads.</t> partial body and stop requesting the missing payloads.</t>
<t>The server <bcp14>SHOULD</bcp14> recognize the 'Continue' Q-Block2 re
<t>The server SHOULD recognize the 'Continue' Q-Block2 request as a quest
continue request and just continue the transmission of the body per the definition in <xref target="qblock2" format="default"/> and just
(including Observe Option, if appropriate for an unsolicited response) continue the transmission of the body
rather than as a request for the remaining missing blocks.</t> (including the Observe option, if appropriate for an unsolicited respons
e)
rather than treat 'Continue' as a request for the remaining missing bloc
ks.</t>
<t>It is likely that the server will start transmitting the next <t>It is likely that the server will start transmitting the next
MAX_PAYLOADS_SET before the client times out on waiting for the last MAX_PAYLOADS_SET before the client times out on waiting for the last blo ck
of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the
new MAX_PAYLOADS_SET, the client SHOULD send a request indicating any new MAX_PAYLOADS_SET, the client <bcp14>SHOULD</bcp14> send a request in dicating any
missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of
such request, the server SHOULD send the missing payloads before such a request, the server <bcp14>SHOULD</bcp14> send the missing payloa ds before
continuing to send the remainder of the MAX_PAYLOADS_SET and then go continuing to send the remainder of the MAX_PAYLOADS_SET and then go
into another NON_TIMEOUT_RANDOM delay prior to sending the next into another NON_TIMEOUT_RANDOM delay prior to sending the next
MAX_PAYLOADS_SET.</t> MAX_PAYLOADS_SET.</t>
<t>The client does not need to acknowledge the receipt of the entire <t>The client does not need to acknowledge the receipt of the entire
body.</t> body.</t>
<t indent="3">Note: If there is asymmetric traffic loss causing response
<t><list style="empty"> s to
<t>Note: If there is asymmetric traffic loss causing responses to never get received, a delay of NON_TIMEOUT_RANDOM after every
never get received, a delay of NON_TIMEOUT_RANDOM after every transmission of MAX_PAYLOADS_SET will be observed. The endpoint
transmission of MAX_PAYLOADS_SET will be observed. The endpoint receiving the body is still likely to receive the entire body.</t>
receiving the body is still likely to receive the entire body.</t>
</list></t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Caching Considerations"> <name>Caching Considerations</name>
<t>Caching block based information is not straight forward in a proxy. <t>Caching block-based information is not straightforward in a proxy.
For Q-Block1 and Q-Block2 Options, for simplicity it is expected that For the 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 appropriate options for packet loss) before passing the body onward to the appropriate
CoAP endpoint. This does not preclude an implementation doing a more CoAP endpoint. This does not preclude an implementation doing a more
complex per payload caching, but how to do this is out of the scope of complex per-payload caching, but how to do this is out of the scope of
this document. The onward transmission of the body does not require the this document. The onward transmission of the body does not require the
use of the Q-Block1 or Q-Block2 Options as these options may not be use of the Q-Block1 or Q-Block2 options, as these options may not be
supported in that link. This means that the proxy must fully support the supported in that link. This means that the proxy must fully support the
Q-Block1 and Q-Block2 Options.</t> Q-Block1 and Q-Block2 options.</t>
<t>How the body is cached in the CoAP client (for Q-Block1 <t>How the body is cached in the CoAP client (for Q-Block1
transmissions) or the CoAP server (for Q-Block2 transmissions) is transmissions) or the CoAP server (for Q-Block2 transmissions) is
implementation specific.</t> implementation specific.</t>
<t>As the entire body is being cached in the proxy, the Q-Block1 and <t>As the entire body is being cached in the proxy, the Q-Block1 and
Q-Block2 Options are removed as part of the block assembly and thus do Q-Block2 options are removed as part of the block assembly and thus do
not reach the cache.</t> not reach the cache.</t>
<t>For Q-Block2 responses, the ETag option value is associated with the
<t>For Q-Block2 responses, the ETag Option value is associated with the data (and transmitted onward to the CoAP client) but is not part of the
data (and onward transmitted to the CoAP client), but is not part of the
cache key.</t> cache key.</t>
<t>For requests with the Q-Block1 option, the Request-Tag option is
<t>For requests with Q-Block1 Option, the Request-Tag Option is associated with building the body from successive payloads but
associated with the build up of the body from successive payloads, but
is not part of the cache key. For the onward transmission of the body is not part of the cache key. For the onward transmission of the body
using CoAP, a new Request-Tag SHOULD be generated and used. Ideally this using CoAP, a new Request-Tag <bcp14>SHOULD</bcp14> be generated and used.
new Request-Tag should replace the client's request Request-Tag.</t> Ideally,
this new Request-Tag should replace the Request-Tag used by the client.</t
>
<t>It is possible that two or more CoAP clients are concurrently <t>It is possible that two or more CoAP clients are concurrently
updating the same resource through a common proxy to the same CoAP updating the same resource through a common proxy to the same CoAP
server using Q-Block1 (or Block1) Option. If this is the case, the first server using the Q-Block1 (or Block1) option. If this is the case, the fir st
client to complete building the body causes that body to start client to complete building the body causes that body to start
transmitting to the CoAP server with an appropriate Request-Tag value. transmitting to the CoAP server with an appropriate Request-Tag value.
When the next client completes building the body, any existing partial When the next client completes building the body, any existing partial
body transmission to the CoAP server is terminated and the new body body transmission to the CoAP server is terminated, and the transmission o
representation transmission starts with a new Request-Tag value. Note f the
new body representation starts with a new Request-Tag value. Note
that it cannot be assumed that the proxy will always receive a complete that it cannot be assumed that the proxy will always receive a complete
body from a client.</t> body from a client.</t>
<t>A proxy that supports the Q-Block2 option <bcp14>MUST</bcp14> be prepar
<t>A proxy that supports Q-Block2 Option MUST be prepared to receive a ed to
GET or similar request indicating one or more missing blocks. The proxy receive a GET or similar request indicating one or more missing blocks. Fr
will serve from its cache the missing blocks that are available in its om its
cache, the proxy will serve the missing blocks that are available in its
cache in the same way a server would send all the appropriate Q-Block2 cache in the same way a server would send all the appropriate Q-Block2
responses. If a body matching the cache key is not available in the responses. If a body matching the cache key is not available in the
cache, the proxy MUST request the entire body from the CoAP server using cache, the proxy <bcp14>MUST</bcp14> request the entire body from the CoAP server using
the information in the cache key.</t> the information in the cache key.</t>
<t>How long a CoAP endpoint (or proxy) keeps the body in its cache is <t>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).</t> implementation specific (e.g., it may be based on Max-Age).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="HTTP-Mapping Considerations"> <name>HTTP Mapping Considerations</name>
<t>As a reminder, the basic normative requirements on HTTP/CoAP mappings <t>As a reminder, the basic normative requirements on HTTP/CoAP mappings
are defined in Section 10 of <xref target="RFC7252"></xref>. The are defined in <xref target="RFC7252" section="10" sectionFormat="of" form
implementation guidelines for HTTP/CoAP mappings are elaborated in <xref at="default"/>. The
target="RFC8075"></xref>.</t> implementation guidelines for HTTP/CoAP mappings are elaborated in <xref t
arget="RFC8075" format="default"/>.</t>
<t>The rules defined in Section 5 of <xref target="RFC7959"></xref> are <t>The rules defined in <xref target="RFC7959" section="5" sectionFormat="
of" format="default"/> are
to be followed.</t> to be followed.</t>
</section> </section>
<section numbered="true" toc="default" anchor="non-confirm">
<section title="Examples with Non-confirmable Messages"> <name>Examples with Non-confirmable Messages</name>
<t>This section provides some sample flows to illustrate the use of <t>This section provides some sample flows to illustrate the use of the
Q-Block1 and Q-Block2 Options with NON. Examples with CON are provided Q-Block1 and Q-Block2 options with NON. Examples with CON are provided
in <xref target="CON"></xref>.</t> in <xref target="CON" format="default"/>.</t>
<t>The examples in the following subsections assume MAX_PAYLOADS is set <t>The examples in the following subsections assume MAX_PAYLOADS is set
to 10 and NON_MAX_RETRANSMIT is set to 4.</t> to 10 and NON_MAX_RETRANSMIT is set to 4.</t>
<t>The list below contains the conventions that are
<t><xref target="legend"></xref> lists the conventions that are used in used in the figures in the following subsections.</t>
the following subsections.</t> <dl newline="false" spacing="normal" indent="7">
<dt>T:</dt>
<t><figure align="center" anchor="legend" <dd>Token value</dd>
title="Notations Used in the Figures"> <dt>O:</dt>
<artwork align="center"><![CDATA[ T: Token value <dd>Observe option value</dd>
O: Observe Option value <dt>M:</dt>
M: Message ID <dd>Message ID</dd>
RT: Request-Tag <dt>RT:</dt>
ET: ETag <dd>Request-Tag</dd>
QB1: Q-Block1 Option values NUM/More/Size <dt>ET:</dt>
QB2: Q-Block2 Option values NUM/More/Size <dd>ETag</dd>
Size: Actual block size encoded in SZX <dt>QB1:</dt>
\: Trimming long lines <dd>Q-Block1 option values NUM/More/Size</dd>
[[]]: Comments <dt>QB2:</dt>
-->X: Message loss (request) <dd>Q-Block2 option values NUM/More/Size</dd>
X<--: Message loss (response) <dt>Size:</dt>
...: Passage of time <dd>Actual block size encoded in SZX</dd>
Payload N: Corresponds to the CoAP message that conveys <dt>\:</dt>
a block number (N-1) of a given block-wise exchange. <dd>Trimming long lines</dd>
]]></artwork> <dt>[[]]:</dt>
</figure></t> <dd>Comments</dd>
<dt>--&gt;X:</dt>
<section title="Q-Block1 Option "> <dd>Message loss (request)</dd>
<section title="A Simple Example"> <dt>X&lt;--:</dt>
<t><xref target="B3non"></xref> depicts an example of a NON PUT <dd>Message loss (response)</dd>
request conveying Q-Block1 Option. All the blocks are received by <dt>...:</dt>
<dd>Passage of time</dd>
<dt>Payload N:</dt>
<dd>Corresponds to the CoAP message that conveys
a block number (N-1) of a given block-wise exchange.</dd>
</dl>
<section numbered="true" toc="default">
<name>Q-Block1 Option</name>
<section numbered="true" toc="default">
<name>A Simple Example</name>
<t><xref target="B3non" format="default"/> depicts an example of a NON
PUT
request conveying the Q-Block1 option. All the blocks are received by
the server.</t> the server.</t>
<figure anchor="B3non">
<t><figure anchor="B3non" <name>Example of a NON Request with the Q-Block1 option (without Los
title="Example of NON Request with Q-Block1 Option (Without Loss)" s)</name>
> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<artwork><![CDATA[ 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
| ... | | ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Handling MAX_PAYLOADS Limits"> <name>Handling MAX_PAYLOADS Limits</name>
<t><xref target="B3non0"></xref> depicts an example of a NON PUT <t><xref target="B3non0" format="default"/> depicts an example of a NO
request conveying Q-Block1 Option. The number of payloads exceeds N PUT
request conveying the Q-Block1 option. The number of payloads exceeds
MAX_PAYLOADS. All the blocks are received by the server.</t> MAX_PAYLOADS. All the blocks are received by the server.</t>
<figure anchor="B3non0">
<t><figure anchor="B3non0" <name>Example of a MAX_PAYLOADS NON Request with the Q-Block1 Option
title="Example of MAX_PAYLOADS NON Request with Q-Block1 Option (W (without
ithout Loss)"> Loss)</name>
<artwork><![CDATA[ CoAP CoAP <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server CoAP CoAP
| | Client Server
+--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024 | |
+--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024 +--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024
+--------->| [[Payloads 3 - 9 not detailed]] +--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024
+--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024 +--------->| [[Payloads 3 - 9 not detailed]]
[[MAX_PAYLOADS_SET has been received]] +--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024
| [[MAX_PAYLOADS_SET receipt acknowledged by server]] [[MAX_PAYLOADS_SET has been received]]
|<---------+ NON 2.31 M:0x81 T:0xfa | [[MAX_PAYLOADS_SET receipt acknowledged by server]]
+--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024 |<---------+ NON 2.31 M:0x81 T:0xfa
|<---------+ NON 2.04 M:0x82 T:0xfb +--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024
| ... | |<---------+ NON 2.04 M:0x82 T:0xfb
| ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Handling MAX_PAYLOADS with Recovery"> <name>Handling MAX_PAYLOADS with Recovery</name>
<t>Consider now a scenario where a new body of data is to be sent by <t>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 the client, but some blocks are dropped in transmission, as
illustrated in <xref target="B3non1"></xref>.</t> illustrated in <xref target="B3non1" format="default"/>.</t>
<figure anchor="B3non1">
<t><figure anchor="B3non1" <name>Example of a MAX_PAYLOADS NON Request with the Q-Block1 Option
title="Example of MAX_PAYLOADS NON Request with Q-Block1 Option (W (with
ith Loss)"> Loss)</name>
<artwork><![CDATA[ CoAP CoAP <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server CoAP CoAP
| | Client Server
+--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 | |
+--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024 +--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024
+--------->| [[Payloads 3 - 8 not detailed]] +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024
+--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 +--------->| [[Payloads 3 - 8 not detailed]]
+--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024 +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024
[[Some of MAX_PAYLOADS_SET have been received]] +--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024
| ... | [[Some of the MAX_PAYLOADS_SET has been received]]
[[NON_TIMEOUT_RANDOM (client) delay expires]] | ... |
| [[Client starts sending next MAX_PAYLOAD_SET]] [[NON_TIMEOUT_RANDOM (client) delay expires]]
+--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 | [[Client starts sending next MAX_PAYLOADS_SET]]
+--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024 +--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024
| | +--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024
| |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>On seeing a payload from the next MAX_PAYLOADS_SET, the server
<t>On seeing a payload from the next MAX_PAYLOAD_SET, the server
realizes that some blocks are missing from the previous realizes that some blocks are missing from the previous
MAX_PAYLOADS_SET and asks for the missing blocks in one go (<xref MAX_PAYLOADS_SET and asks for the missing blocks in one go (<xref targ
target="B3non2"></xref>). It does so by indicating which blocks from et="B3non2" format="default"/>). It does so by indicating which blocks from
the previous MAX_PAYLOADS_SET have not been received in the data the previous MAX_PAYLOADS_SET have not been received in the data
portion of the response (<xref target="code"></xref>). The token portion of the response (<xref target="code" format="default"/>). The
used in the response should be the token that was used in the last token
received payload. The client can then derive the Request-Tag by used in the response should be the token that was used in the last rec
eived
payload. The client can then derive the Request-Tag by
matching the token with the sent request.</t> matching the token with the sent request.</t>
<figure anchor="B3non2">
<t><figure anchor="B3non2" <name>Example of a NON Request with the Q-Block1 Option (Block Recov
title="Example of NON Request with Q-Block1 Option (Blocks Recover ery)</name>
y)"> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<artwork><![CDATA[ CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
|<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9] |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9]
| [[Client responds with missing payloads]] | [[Client responds with missing payloads]]
+--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 +--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024
+--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024 +--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024
| [[Client continues sending next MAX_PAYLOAD_SET]] | [[Client continues sending next MAX_PAYLOADS_SET]]
+--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]] [[NON_RECEIVE_TIMEOUT (server) delay expires]]
| [[The server realizes a block is still missing and asks | [[The server realizes a block is still missing and asks
| for the missing one]] | for the missing one]]
|<---------+ NON 4.08 M:0x92 T:0xef [Missing 10] |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10]
+--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024
|<---------+ NON 2.04 M:0x93 T:0xf0 |<---------+ NON 2.04 M:0x93 T:0xf0
| ... | | ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Handling Recovery with Failure"> <name>Handling Recovery if Failure Occurs</name>
<t><xref target="B3non3"></xref> depicts an example of a NON PUT <t><xref target="B3non3" format="default"/> depicts an example of a NO
request conveying Q-Block1 Option where recovery takes place, but N PUT
request conveying the Q-Block1 option where recovery takes place but
eventually fails.</t> eventually fails.</t>
<figure anchor="B3non3">
<t><figure anchor="B3non3" <name>Example of a NON Request with the Q-Block1 Option (with Eventu
title="Example of NON Request with Q-Block1 Option (With Eventual al
Failure)"> Failure)</name>
<artwork><![CDATA[ CoAP CoAP <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server CoAP CoAP
| | Client Server
+--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024 | |
+--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024 +--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024
+--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024 +--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024
| ... | +--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024
[[NON_RECEIVE_TIMEOUT (server) delay expires]] | ... |
| [[The server realizes a block is missing and asks [[NON_RECEIVE_TIMEOUT (server) delay expires]]
| for the missing one. Retry #1]] | [[The server realizes a block is missing and asks
|<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1] | for the missing one. Retry #1]]
| ... | |<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1]
[[2 * NON_RECEIVE_TIMEOUT (server) delay expires]] | ... |
| [[The server realizes a block is still missing and asks [[2 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| for the missing one. Retry #2]] | [[The server realizes a block is still missing and asks
|<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1] | for the missing one. Retry #2]]
| ... | |<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1]
[[4 * NON_RECEIVE_TIMEOUT (server) delay expires]] | ... |
| [[The server realizes a block is still missing and asks [[4 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| for the missing one. Retry #3]] | [[The server realizes a block is still missing and asks
|<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1] | for the missing one. Retry #3]]
| ... | |<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1]
[[8 * NON_RECEIVE_TIMEOUT (server) delay expires]] | ... |
| [[The server realizes a block is still missing and asks [[8 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| for the missing one. Retry #4]] | [[The server realizes a block is still missing and asks
|<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1] | for the missing one. Retry #4]]
| ... | |<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1]
[[16 * NON_RECEIVE_TIMEOUT (server) delay expires]] | ... |
| [[NON_MAX_RETRANSMIT exceeded. Server stops requesting [[16 * NON_RECEIVE_TIMEOUT (server) delay expires]]
| for missing blocks and releases partial body]] | [[NON_MAX_RETRANSMIT exceeded. Server stops requesting
| ... | | the missing blocks and releases partial body]]
| ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Q-Block2 Option"> <name>Q-Block2 Option</name>
<t>These examples include the Observe Option to demonstrate how that <t>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.</t> Q-Block2.</t>
<section numbered="true" toc="default">
<section title="A Simple Example"> <name>A Simple Example</name>
<t><xref target="nonb4"></xref> illustrates the example of Q-Block2 <t><xref target="nonb4" format="default"/> illustrates an example of t
Option. The client sends a NON GET carrying Observe and Q-Block2 he Q-Block2
Options. The Q-Block2 Option indicates a block size hint (1024 option. The client sends a NON GET carrying the Observe and Q-Block2
bytes). This request is replied to by the server using four (4) options. The Q-Block2 option indicates a block size hint (1024
bytes). The server replies to this request using four (4)
blocks that are transmitted to the client without any loss. Each of blocks that are transmitted to the client without any loss. Each of
these blocks carries a Q-Block2 Option. The same process is repeated these blocks carries a Q-Block2 option. The same process is repeated
when an Observe is triggered, but no loss is experienced by any of when an Observe is triggered, but no loss is experienced by any of
the notification blocks.</t> the notification blocks.</t>
<figure anchor="nonb4">
<t><figure anchor="nonb4" <name>Example of NON Notifications with the Q-Block2 Option (without
title="Example of NON Notifications with Q-Block2 Option (Without Loss)</name>
Loss)"> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<artwork><![CDATA[ CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024 +--------->| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf2 T:0xc0 O:1220 ET=19 QB2:1/1/1024 |<---------+ NON 2.05 M:0xf2 T:0xc0 O:1220 ET=19 QB2:1/1/1024
|<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024 |<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024
|<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024 |<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024
|<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024 |<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024
|<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024 |<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024
|<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024 |<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024
| ... | | ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Handling MAX_PAYLOADS Limits"> <name>Handling MAX_PAYLOADS Limits</name>
<t><xref target="nonb40"></xref> illustrates the same as <xref <t><xref target="nonb40" format="default"/> illustrates the same scena
target="nonb4"></xref> but this time has eleven (11) payloads which rio as <xref target="nonb4" format="default"/>, but this time with eleven (11) p
ayloads, which
exceeds MAX_PAYLOADS. There is no loss experienced.</t> exceeds MAX_PAYLOADS. There is no loss experienced.</t>
<figure anchor="nonb40">
<t><figure anchor="nonb40" <name>Example of NON Notifications with the Q-Block2 Option (without
title="Example of NON Notifications with Q-Block2 Option (Without Loss)</name>
Loss)"> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<artwork><![CDATA[ CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
|<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024 |<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024 |<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024 +--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024
|<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024 |<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
|<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024
[[MAX_PAYLOADS_SET has been received]] [[MAX_PAYLOADS_SET has been received]]
| [[MAX_PAYLOADS_SET acknowledged by client using | [[MAX_PAYLOADS_SET acknowledged by client using
| 'Continue' Q-Block2]] | 'Continue' Q-Block2]]
+--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 +--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024
|<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Handling MAX_PAYLOADS with Recovery"> <name>Handling MAX_PAYLOADS with Recovery</name>
<t><xref target="nonb41"></xref> shows the example of an Observe <t><xref target="nonb41" format="default"/> shows an example of an Obs
erve
that is triggered but for which some notification blocks are lost. that is triggered but for which some notification blocks are lost.
The client detects the missing blocks and requests their The client detects the missing blocks and requests their
retransmission. It does so by indicating the blocks that are missing retransmission. It does so by indicating the blocks that are missing
as one or more Q-Block2 Options.</t> as one or more Q-Block2 options.</t>
<figure anchor="nonb41">
<t><figure anchor="nonb41" <name>Example of NON Notifications with the Q-Block2 Option (Block
title="Example of NON Notifications with Q-Block2 Option (Blocks R Recovery)</name>
ecovery)"> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<artwork><![CDATA[ CoAP CoAP CoAP CoAP
Client Server Client Server
| ... | | ... |
| [[Observe triggered]] | [[Observe triggered]]
|<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 |<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ [[Payloads 3 - 9 not detailed]]
| X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024
[[Some of MAX_PAYLOADS_SET have been received]] [[Some of the MAX_PAYLOADS_SET has been received]]
| ... | | ... |
[[NON_TIMEOUT_RANDOM (server) delay expires]] [[NON_TIMEOUT_RANDOM (server) delay expires]]
| [[Server sends next MAX_PAYLOAD_SET]] | [[Server sends next MAX_PAYLOADS_SET]]
|<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024
| [[On seeing a payload from the next MAX_PAYLOAD_SET, | [[On seeing a payload from the next MAX_PAYLOADS_SET,
| Client realizes blocks are missing and asks for the | client realizes blocks are missing and asks for the
| missing ones in one go]] | missing ones in one go]]
+--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
| | QB2:9/0/1024 | | QB2:9/0/1024
| X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024 |<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| [[Client realizes block is still missing and asks for | [[Client realizes block is still missing and asks for
| missing block]] | missing block]]
+--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024
|<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024
[[Body has been received]] [[Body has been received]]
| ... | | ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section anchor="sec-nonb411" numbered="true" toc="default">
<section anchor="sec-nonb411" <name>Handling Recovery by Setting the M Bit</name>
title="Handling Recovery using M-bit Set"> <t><xref target="nonb411" format="default"/> shows an example where an
<t><xref target="nonb411"></xref> shows the example of an Observe Observe
that is triggered but only the first two notification blocks reach is triggered but only the first two notification blocks reach
the client. In order to retrieve the missing blocks, the client the client. In order to retrieve the missing blocks, the client
sends a request with a single Q-Block2 Option with the M bit sends a request with a single Q-Block2 option with the M bit
set.</t> set.</t>
<figure anchor="nonb411">
<t><figure anchor="nonb411" <name>Example of NON Notifications with the Q-Block2 Option (Block R
title="Example of NON Notifications with Q-Block2 Option (Blocks R ecovery
ecovery with M bit Set)"> with the M Bit Set)</name>
<artwork><![CDATA[ CoAP CoAP <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server CoAP CoAP
| ... | Client Server
| [[Observe triggered]] | ... |
|<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 | [[Observe triggered]]
|<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024 |<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024
| X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024 |<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024
| X<---+ [[Payloads 4 - 9 not detailed]] | X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024
| X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 | X<---+ [[Payloads 4 - 9 not detailed]]
[[Some of MAX_PAYLOADS_SET have been received]] | X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024
| ... | [[Some of the MAX_PAYLOADS_SET has been received]]
[[NON_TIMEOUT_RANDOM (server) delay expires]] | ... |
| [[Server sends next MAX_PAYLOAD_SET]] [[NON_TIMEOUT_RANDOM (server) delay expires]]
| X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024 | [[Server sends next MAX_PAYLOADS_SET]]
| ... | | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024
[[NON_RECEIVE_TIMEOUT (client) delay expires]] | ... |
| [[Client realizes blocks are missing and asks for the [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| missing ones in one go by setting the M bit]] | [[Client realizes blocks are missing and asks for the
+--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 | missing ones in one go by setting the M bit]]
|<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024
|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]]
[[MAX_PAYLOADS_SET has been received]] |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024
| [[MAX_PAYLOADS_SET acknowledged by client using 'Continue' [[MAX_PAYLOADS_SET has been received]]
| Q-Block2]] | [[MAX_PAYLOADS_SET acknowledged by client using 'Continue'
+--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 | Q-Block2]]
|<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024 +--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024
[[Body has been received]] |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024
| ... | [[Body has been received]]
| ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Q-Block1 and Q-Block2 Options"> <name>Q-Block1 and Q-Block2 Options</name>
<section title="A Simple Example"> <section numbered="true" toc="default">
<t><xref target="b12non"></xref> illustrates the example of a FETCH <name>A Simple Example</name>
using both Q-Block1 and Q-Block2 Options along with an Observe <t><xref target="b12non" format="default"/> illustrates an example of
Option. No loss is experienced.</t> a FETCH
using both the Q-Block1 and Q-Block2 options along with an Observe
<t><figure anchor="b12non" option. No loss is experienced.</t>
title="Example of NON FETCH with Q-Block1 and Q-Block2 Options (Wi <figure anchor="b12non">
thout Loss)"> <name>Example of a NON FETCH with the Q-Block1 and Q-Block2 Options
<artwork><![CDATA[ CoAP CoAP (without
Client Server Loss)</name>
| | <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
+--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024 CoAP CoAP
+--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024 Client Server
+--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024 | |
|<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024 +--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024
|<---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024 +--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024
|<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024 +--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024
|<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024 |<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024
| ... | |<---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024
| [[Observe triggered]] |<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024
|<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024 |<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/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 | [[Observe triggered]]
|<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/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: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
| ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
<section numbered="true" toc="default">
<section title="Handling MAX_PAYLOADS Limits"> <name>Handling MAX_PAYLOADS Limits</name>
<t><xref target="b12non0"></xref> illustrates the same as <xref <t><xref target="b12non0" format="default"/> illustrates the same scen
target="b12non"></xref> but this time has eleven (11) payloads in ario as <xref target="b12non" format="default"/>, but this time with eleven (11)
both directions which exceeds MAX_PAYLOADS. There is no loss payloads in
both directions, which exceeds MAX_PAYLOADS. There is no loss
experienced.</t> experienced.</t>
<figure anchor="b12non0">
<t><figure anchor="b12non0" <name>Example of a NON FETCH with the Q-Block1 and Q-Block2 Options
title="Example of NON FETCH with Q-Block1 and Q-Block2 Options (Wi (without
thout Loss)"> Loss)</name>
<artwork><![CDATA[ CoAP CoAP <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
Client Server CoAP CoAP
| | Client Server
+--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 | |
+--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024 +--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024
+--------->| [[Payloads 3 - 9 not detailed]] +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024
+--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 +--------->| [[Payloads 3 - 9 not detailed]]
[[MAX_PAYLOADS_SET has been received]] +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024
| [[MAX_PAYLOADS_SET acknowledged by server]] [[MAX_PAYLOADS_SET has been received]]
|<---------+ NON 2.31 M:0x80 T:0xa9 | [[MAX_PAYLOADS_SET acknowledged by server]]
+--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024 |<---------+ NON 2.31 M:0x80 T:0xa9
|<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024 +--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024
|<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024 |<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024
|<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]]
[[MAX_PAYLOADS_SET has been received]] |<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024
| [[MAX_PAYLOADS_SET acknowledged by client using [[MAX_PAYLOADS_SET has been received]]
| 'Continue' Q-Block2]] | [[MAX_PAYLOADS_SET acknowledged by client using
+--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 | 'Continue' Q-Block2]]
|<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024 +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024
| ... | |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024
| [[Observe triggered]] | ... |
|<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024 | [[Observe triggered]]
|<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024 |<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024
|<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024
|<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]]
[[MAX_PAYLOADS_SET has been received]] |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024
| [[MAX_PAYLOADS_SET acknowledged by client using [[MAX_PAYLOADS_SET has been received]]
| 'Continue' Q-Block2]] | [[MAX_PAYLOADS_SET acknowledged by client using
+--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 | 'Continue' Q-Block2]]
|<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024
[[Body has been received]] |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024
| ... | [[Body has been received]]
| ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Note that, as 'Continue' was used, the server continues to use the
<t>Note that as 'Continue' was used, the server continues to use the same token (0xaa), since the 'Continue' is not being used as a
same token (0xaa) since the 'Continue' is not being used as a request for a new set of packets but rather is being used to
request for a new set of packets, but rather is being used to instruct the server to continue its transmission (<xref target="cc-non
instruct the server to continue its transmission (<xref " format="default"/>).</t>
target="cc-non"></xref>).</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Handling Recovery"> <name>Handling Recovery</name>
<t>Consider now a scenario where some blocks are lost in <t>Consider now a scenario where some blocks are lost in
transmission as illustrated in <xref target="b12non1"></xref>.</t> transmission, as illustrated in <xref target="b12non1" format="default
"/>.</t>
<t><figure anchor="b12non1" <figure anchor="b12non1">
title="Example of NON FETCH with Q-Block1 and Q-Block2 Options (Wi <name>Example of a NON FETCH with the Q-Block1 and Q-Block2 Options
th Loss)"> (with
<artwork><![CDATA[ CoAP CoAP Loss)</name>
Client Server <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
| | CoAP CoAP
+--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 Client Server
+--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024 | |
+--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024 +--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024
+--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024 +--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024
| ... | +--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024
[[NON_RECEIVE_TIMEOUT (server) delay expires]] +--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024
| ... |
[[NON_RECEIVE_TIMEOUT (server) delay expires]]
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The server realizes that some blocks are missing and asks for the <t>The server realizes that some blocks are missing and asks for the
missing blocks in one go (<xref target="b12non2"></xref>). It does missing blocks in one go (<xref target="b12non2" format="default"/>). It does
so by indicating which blocks have not been received in the data so by indicating which blocks have not been received in the data
portion of the response. The token used in the response is the token portion of the response. The token used in the response is the token
that was used in the last received payload. The client can then that was used in the last received payload. The client can then
derive the Request-Tag by matching the token with the sent derive the Request-Tag by matching the token with the sent
request.</t> request.</t>
<figure anchor="b12non2">
<t><figure anchor="b12non2" <name>Example of a NON Request with the Q-Block1 Option (Server Reco
title="Example of NON Request with Q-Block1 Option (Server Recover very)</name>
y)"> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<artwork><![CDATA[ CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
|<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2] |<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2]
| [[Client responds with missing payloads]] | [[Client responds with missing payloads]]
+--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024 +--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024
+--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024 +--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024
| [[Server received FETCH body, | [[Server received FETCH body,
| starts transmitting response body]] | starts transmitting response body]]
|<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024 |<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024
| X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024 | X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024
|<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024 |<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024
| X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024 | X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024
| ... | | ... |
[[NON_RECEIVE_TIMEOUT (client) delay expires]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
| | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>The client realizes that not all the payloads of the response <t>The client realizes that not all the payloads of the response
have been returned. The client then asks for the missing blocks in have been returned. The client then asks for the missing blocks in
one go (<xref target="b12non3"></xref>). Note that, following one go (<xref target="b12non3" format="default"/>). Note that, followi
Section 2.7 of <xref target="RFC7959"></xref>, the FETCH request ng
does not include the Q-Block1 or any payload.</t> <xref target="RFC7959" section="2.7" sectionFormat="of" format="defaul
t"/>, the
<t><figure anchor="b12non3" FETCH request does not include the Q-Block1 or any payload.</t>
title="Example of NON Request with Q-Block1 Option (Client Recover <figure anchor="b12non3">
y)"> <name>Example of a NON Request with the Q-Block1 Option (Client Reco
<artwork><![CDATA[ CoAP CoAP very)</name>
Client Server <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
| | CoAP CoAP
+--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\ Client Server
| | QB2:3/0/1024 | |
| [[Server receives FETCH request for missing payloads, +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\
| starts transmitting missing blocks]] | | QB2:3/0/1024
| X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024 | [[Server receives FETCH request for missing payloads,
|<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024 | starts transmitting missing blocks]]
| ... | | X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024
[[NON_RECEIVE_TIMEOUT (client) delay expires]] |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024
| [[Client realizes block is still missing and asks for | ... |
| missing block]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
+--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024 | [[Client realizes block is still missing and asks for
| [[Server receives FETCH request for missing payload, | missing block]]
| starts transmitting missing block]] +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024
|<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024 | [[Server receives FETCH request for missing payload,
[[Body has been received]] | starts transmitting missing block]]
| ... | |<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024
| [[Observe triggered]] [[Body has been received]]
|<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024 | ... |
| X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024 | [[Observe triggered]]
|<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024 |<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024
[[NON_RECEIVE_TIMEOUT (client) delay expires]] | X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024
| [[Client realizes block is still missing and asks for |<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024
| missing block]] [[NON_RECEIVE_TIMEOUT (client) delay expires]]
+--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024 | [[Client realizes block is still missing and asks for
| [[Server receives FETCH request for missing payload, | missing block]]
| starts transmitting missing block]] +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024
|<---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024 | [[Server receives FETCH request for missing payload,
[[Body has been received]] | starts transmitting missing block]]
| ... | |<---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024
[[Body has been received]]
| ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security" numbered="true" toc="default">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>Security considerations discussed in Section 7 of <xref <t>Security considerations discussed in <xref target="RFC7959" section="7"
target="RFC7959"></xref> should be taken into account.</t> sectionFormat="of" format="default"/> should be taken into account.</t>
<t>Security considerations discussed in Sections <xref target="RFC7252"
<t>Security considerations discussed in Sections 11.3 and 11.4 of <xref section="11.3" sectionFormat="bare"/> and <xref target="RFC7252" section="
target="RFC7252"></xref> should be taken into account.</t> 11.4"
sectionFormat="bare"/> of <xref target="RFC7252" format="default"/> should
also be
taken into account.</t>
<t>OSCORE provides end-to-end protection of all information that is not <t>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 <xref target="RFC8613"></xref>). It can be set up (<xref target="RFC8613" section="3.1" sectionFormat="of"
trusted that the source endpoint is legitimate even if NoSec security format="default"/>). It can be
trusted that the source endpoint is legitimate even if the NoSec
mode is used. However, an intermediary node can modify the unprotected mode is used. However, an intermediary node can modify the unprotected
outer Q-Block1 and/or Q-Block2 Options to cause a Q-Block transfer to Outer Q-Block1 and/or Q-Block2 options to cause a Q-Block transfer to
fail or keep requesting all the blocks by setting the M bit and, thus, fail or keep requesting all the blocks by setting the M bit and thus
causing attack amplification. As discussed in Section 12.1 of <xref causing attack amplification. As discussed in <xref target="RFC8613" secti
target="RFC8613"></xref>, applications need to consider that certain on="12.1" sectionFormat="of" format="default"/>, applications need to consider t
message fields and messages types are not protected end-to-end and may hat certain
be spoofed or manipulated. Therefore, it is NOT RECOMMENDED to use the message fields and message types are not protected end to end and may
NoSec security mode if either the Q-Block1 or Q-Block2 Options is be spoofed or manipulated. Therefore, it is <bcp14>NOT RECOMMENDED</bcp14>
to use the
NoSec mode if either the Q-Block1 or Q-Block2 option is
used.</t> used.</t>
<t>If OSCORE is not used, it is also <bcp14>NOT RECOMMENDED</bcp14> to use
<t>If OSCORE is not used, it is also NOT RECOMMENDED to use the NoSec the NoSec
security mode if either the Q-Block1 or Q-Block2 Options is used.</t> mode if either the Q-Block1 or Q-Block2 option is used.</t>
<t>If NoSec is being used, <xref target="RFC8613" section="D.5" sectionFor
<t>If NoSec is being used, Section D.5 of <xref target="RFC8613"></xref> mat="of"
format="default"/>
discusses the security analysis and considerations for unprotected discusses the security analysis and considerations for unprotected
message fields even if OSCORE is not being used.</t> message fields even if OSCORE is not being used.</t>
<t>Security considerations related to the use of Request-Tag are <t>Security considerations related to the use of Request-Tag are
discussed in Section 5 of <xref discussed in <xref target="RFC9175" section="5" sectionFormat="of" format=
target="I-D.ietf-core-echo-request-tag"></xref>.</t> "default"/>.</t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<section anchor="IANA" title="IANA Considerations"> <name>IANA Considerations</name>
<t><list style="hanging"> <section numbered="true" toc="default">
<t hangText="RFC Editor Note:">Please replace [RFCXXXX] with the RFC <name>CoAP Option Numbers Registry</name>
number to be assigned to this document.</t> <t>IANA has added the following entries to the "CoAP Option Numbers"
</list></t> subregistry <xref target="IANA-Options" format="default"/> defined in <x
ref
<section title="CoAP Option Numbers Registry"> target="RFC7252" format="default"/> within the "Constrained RESTful
<t>IANA is requested to add the following entries to the "CoAP Option Environments (CoRE) Parameters" registry:</t>
Numbers" sub-registry <xref target="Options"></xref> defined in <xref <table align="center">
target="RFC7252"></xref> within the "Constrained RESTful Environments <name>Additions to CoAP Option Numbers Registry</name>
(CoRE) Parameters" registry:</t> <thead>
<tr>
<t><figure align="center"> <th>Number</th>
<artwork align="center"><![CDATA[+--------+------------------+------ <th>Name</th>
-----+ <th>Reference</th>
| Number | Name | Reference | </tr>
+========+==================+===========+ </thead>
| TBA1 | Q-Block1 | [RFCXXXX] | <tbody>
| TBA2 | Q-Block2 | [RFCXXXX] | <tr>
+--------+------------------+-----------+ <td>19</td>
<td>Q-Block1</td>
Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers]]></artwork> <td>RFC 9177</td>
</figure></t> </tr>
<tr>
<t>This document suggests 19 (TBA1) and 31 (TBA2) as values to be <td>31</td>
assigned for the new option numbers.</t> <td>Q-Block2</td>
<td>RFC 9177</td>
</tr>
</tbody>
</table>
</section> </section>
<section numbered="true" toc="default">
<section title="Media Type Registration"> <name>Media Type Registration</name>
<t>This document requests IANA to register the <t>IANA has registered the
"application/missing-blocks+cbor-seq" media type in the "Media Types" "application/missing-blocks+cbor-seq" media type in the "Media Types"
registry <xref target="IANA-MediaTypes"></xref>. This registration registry <xref target="IANA-MediaTypes" format="default"/>. This registr
follows the procedures specified in <xref target="RFC6838"></xref>: ation
<figure> follows the procedures specified in <xref target="RFC6838" format="defau
<artwork><![CDATA[ Type name: application lt"/>.
</t>
Subtype name: missing-blocks+cbor-seq
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: Must be encoded as a CBOR
sequence [RFC8742], as defined in Section 4 of [RFCXXXX].
Security considerations: See Section 10 of [RFCXXXX].
Interoperability considerations: N/A
Published specification: [RFCXXXX]
Applications that use this media type: Data serialization and
deserialization. In particular, the type is used by applications
relying upon block-wise transfers, allowing a server to specify
non-received blocks and request for their retransmission, as
defined in Section 4 of [RFCXXXX].
Fragment identifier considerations: N/A
Additional information: N/A
Person & email address to contact for further information: IETF,
iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: none
Author: See Authors' Addresses section.
Change controller: IESG
Provisional registration? No]]></artwork> <dl newline="false" spacing="normal">
</figure></t> <dt>Type name:</dt>
<dd>application</dd>
<dt>Subtype name:</dt>
<dd>missing-blocks+cbor-seq</dd>
<dt>Required parameters:</dt>
<dd>N/A</dd>
<dt>Optional parameters:</dt>
<dd>N/A</dd>
<dt>Encoding considerations:</dt>
<dd>Must be encoded as a CBOR Sequence <xref target="RFC8742" format="d
efault"/>,
as defined in <xref target="code" format="default"/> of RFC 9177.</dd>
<dt>Security considerations:</dt>
<dd>See <xref target="security" format="default"/> of RFC 9177.</dd>
<dt>Interoperability considerations:</dt>
<dd>N/A</dd>
<dt>Published specification:</dt>
<dd>RFC 9177</dd>
<dt>Applications that use this media type:</dt>
<dd>Data serialization and
deserialization. In particular, the type is used by applications
relying upon block-wise transfers, allowing a server to specify
non-received blocks and request their retransmission, as
defined in <xref target="spec" format="default"/> of RFC 9177.</dd>
<dt>Fragment identifier considerations:</dt>
<dd>N/A</dd>
<dt>Additional information:</dt>
<dd>N/A</dd>
<dt>Person &amp; email address to contact for further information:</dt>
<dd>IETF, iesg&zwsp;@&zwsp;ietf.org</dd>
<dt>Intended usage:</dt>
<dd>COMMON</dd>
<dt>Restrictions on usage:</dt>
<dd>none</dd>
<dt>Author:</dt>
<dd>See Authors' Addresses section of RFC 9177.</dd>
<dt>Change controller:</dt>
<dd>IESG</dd>
<dt>Provisional registration?</dt>
<dd>No</dd>
</dl>
</section> </section>
<section anchor="new-format" numbered="true" toc="default">
<section anchor="new-format" title="CoAP Content-Formats Registry"> <name>CoAP Content-Formats Registry</name>
<t>This document requests IANA to register the following CoAP <t>IANA has registered the following CoAP
Content-Format for the "application/missing-blocks+cbor-seq" media Content-Format for the "application/missing-blocks+cbor-seq" media
type in the "CoAP Content-Formats" registry <xref type in the "CoAP Content-Formats" registry <xref target="IANA-Format" f
target="Format"></xref>, defined in <xref target="RFC7252"></xref>, ormat="default"/> defined in <xref target="RFC7252" format="default"/>
within the "Constrained RESTful Environments (CoRE) Parameters" within the "Constrained RESTful Environments (CoRE) Parameters"
registry:</t> registry:</t>
<table align="center">
<figure> <name>Addition to CoAP Content-Format Registry</name>
<artwork><![CDATA[o Media Type: application/missing-blocks+cbor-seq <thead>
o Encoding: - <tr>
o Id: TBA3 <th>Media Type</th>
o Reference: [RFCXXXX]]]></artwork> <th>Encoding</th>
</figure> <th>ID</th>
<th>Reference</th>
<t>This document suggests 272 (TBA3) as a value to be assigned for the </tr>
new content format number.</t> </thead>
<tbody>
<tr>
<td>application/missing-blocks+cbor-seq</td>
<td>-</td>
<td>272</td>
<td>RFC 9177</td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.6838'?>
<?rfc include='reference.RFC.7252'?>
<?rfc include='reference.RFC.8174'?>
<?rfc include='reference.RFC.8075'?> <displayreference target="I-D.bosh-dots-quick-blocks" to="DOTS-QUICK-BLOCKS"/>
<?rfc include='reference.RFC.7959'?>
<?rfc include='reference.RFC.7641'?>
<?rfc include='reference.RFC.8132'?>
<?rfc include='reference.RFC.8323'?>
<?rfc include='reference.RFC.8610'?>
<?rfc include='reference.RFC.8613'?>
<?rfc include='reference.RFC.8742'?>
<?rfc include='reference.RFC.8949'?>
<?rfc include='reference.I-D.ietf-core-echo-request-tag'?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-dots-telemetry"?>
<?rfc include='reference.RFC.8974'?>
<?rfc include='reference.I-D.bosh-dots-quick-blocks'?>
<?rfc include='reference.RFC.6928'?>
<?rfc include='reference.RFC.8782'?>
<?rfc include='reference.RFC.7967'?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6838.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7252.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8075.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7959.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7641.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8132.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8323.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8610.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8613.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8742.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8949.xml"/>
<reference anchor="Format" <!-- draft-ietf-core-echo-request-tag (RFC 9175) -->
target="https://www.iana.org/assignments/core-parameters/core-p <reference anchor='RFC9175' target="https://www.rfc-editor.org/info/rfc9175">
arameters.xhtml#content-formats"> <front>
<front> <title>Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Pro
<title>CoAP Content-Formats</title> cessing</title>
<author initials='C' surname='Amsüss' fullname='Christian Amsüss'>
<organization />
</author>
<author initials='J' surname='Preuß Mattsson' fullname='John Preuß Mattsson'>
<organization />
</author>
<author initials='G' surname='Selander' fullname='Goeran Selander'>
<organization />
</author>
<date year='2022' month='February' />
</front>
<seriesInfo name="RFC" value="9175"/>
<seriesInfo name="DOI" value="10.17487/RFC9175"/>
</reference>
<author> </references>
<organization></organization> <references>
</author> <name>Informative References</name>
<date /> <!-- draft-ietf-dots-telemetry (IESG state Publication Requested)
</front> LB: Two editors, so had to do "long way" -->
</reference> <reference anchor="DOTS-TELEMETRY">
<front>
<title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetr
y</title>
<author fullname="Mohamed Boucadair" role="editor">
<organization>Orange</organization>
</author>
<author fullname="Tirumaleswar Reddy" role="editor">
<organization>Akamai</organization>
</author>
<author fullname="Ehud Doron">
<organization>Radware Ltd.</organization>
</author>
<author fullname="Meiling Chen">
<organization>CMCC</organization>
</author>
<author fullname="Jon Shallow">
</author>
<date month="January" day="4" year="2022" />
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-dots-telemetry-19" />
</reference>
<reference anchor="Options" <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
target="https://www.iana.org/assignments/core-parameters/core-p FC.8974.xml"/>
arameters.xhtml#option-numbers">
<front>
<title>CoAP Option Numbers</title>
<author> <!-- [I-D.bosh-dots-quick-blocks] IESG state I-D Exists -->
<organization></organization>
</author>
<date /> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
</front> .bosh-dots-quick-blocks.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6928.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9132.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7967.xml"/>
<reference anchor="IANA-MediaTypes" <reference anchor="IANA-Format" target="https://www.iana.org/assignments
target="https://www.iana.org/assignments/media-types"> /core-parameters/">
<front> <front>
<title>Media Types</title> <title>CoAP Content-Formats</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<author fullname="IANA"> <reference anchor="IANA-Options" target="https://www.iana.org/assignment
<organization></organization> s/core-parameters/">
</author> <front>
<title>CoAP Option Numbers</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
<date /> <reference anchor="IANA-MediaTypes" target="https://www.iana.org/assignm
</front> ents/media-types/">
</reference> <front>
<title>Media Types</title>
<author>
<organization>IANA</organization>
</author>
</front>
</reference>
</references>
</references> </references>
<section anchor="CON" numbered="true" toc="default">
<section anchor="CON" title="Examples with Confirmable Messages"> <name>Examples with Confirmable Messages</name>
<t>The following examples assume NSTART has been increased to 3.</t> <t>The following examples assume NSTART has been increased to 3.</t>
<t>The conventions provided in <xref target="non-confirm" format="default"
<t>The notations provided in <xref target="legend"></xref> are used in /> are used
the following subsections.</t> in the following subsections.</t>
<section numbered="true" toc="default">
<section title="Q-Block1 Option"> <name>Q-Block1 Option</name>
<t>Let's now consider the use of Q-Block1 Option with a CON request as <t>Let's now consider the use of the Q-Block1 option with a CON request,
shown in <xref target="con3"></xref>. All the blocks are acknowledged as
(ACK).</t> shown in <xref target="con3" format="default"/>. All the blocks are ackn
owledged
<t><figure anchor="con3" (as noted with "ACK").</t>
title="Example of CON Request with Q-Block1 Option (Without Loss)"> <figure anchor="con3">
<artwork><![CDATA[ CoAP CoAP <name>Example of a CON Request with the Q-Block1 Option (without Loss)
Client Server </name>
| | <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
+--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 CoAP CoAP
+--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 Client Server
+--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 | |
[[NSTART(3) limit reached]] +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024
|<---------+ ACK 0.00 M:0x01 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024
+--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
|<---------+ ACK 0.00 M:0x02 [[NSTART(3) limit reached]]
|<---------+ ACK 0.00 M:0x03 |<---------+ ACK 0.00 M:0x01
|<---------+ ACK 2.04 M:0x04 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
| | |<---------+ ACK 0.00 M:0x02
|<---------+ ACK 0.00 M:0x03
|<---------+ ACK 2.04 M:0x04
| |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>Now, suppose that a new body of data is to be sent but with some <t>Now, suppose that a new body of data is to be sent but with some
blocks dropped in transmission as illustrated in <xref blocks dropped in transmission, as illustrated in <xref target="con32"
target="con32"></xref>. The client will retry sending blocks for which format="default"/>. The client will retry sending blocks for which
no ACK was received.</t> no ACK was received.</t>
<figure anchor="con32">
<t><figure anchor="con32" <name>Example of a CON Request with the Q-Block1 Option (Block Recover
title="Example of CON Request with Q-Block1 Option (Blocks Recovery) y)</name>
"> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<artwork><![CDATA[ CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024
+--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
[[NSTART(3) limit reached]] [[NSTART(3) limit reached]]
|<---------+ ACK 0.00 M:0x05 |<---------+ ACK 0.00 M:0x05
+--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024
|<---------+ ACK 0.00 M:0x08 |<---------+ ACK 0.00 M:0x08
| ... | | ... |
[[ACK TIMEOUT (client) for M:0x06 delay expires]] [[ACK TIMEOUT (client) for M:0x06 delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
[[ACK TIMEOUT (client) for M:0x07 delay expires]] [[ACK TIMEOUT (client) for M:0x07 delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
|<---------+ ACK 0.00 M:0x06 |<---------+ ACK 0.00 M:0x06
| ... | | ... |
[[ACK TIMEOUT exponential backoff (client) delay expires]] [[ACK TIMEOUT exponential backoff (client) delay expires]]
| [[Client retransmits packet]] | [[Client retransmits packet]]
+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
| ... | | ... |
[[Either body transmission failure (acknowledge retry timeout) [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted.]] or successfully transmitted]]
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>It is up to the implementation as to whether the application <t>It is up to the implementation as to whether the application
process stops trying to send this particular body of data on reaching process stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the MAX_RETRANSMIT for any payload or separately tries to initiate the
new transmission of the payloads that have not been acknowledged under new transmission of the payloads that have not been acknowledged under
these adverse traffic conditions.</t> these adverse traffic conditions.</t>
<t>If transient network losses are possible, then the use of NON should
<t>If there is likely to be the possibility of transient network be considered.</t>
losses, then the use of NON should be considered.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Q-Block2 Option"> <name>Q-Block2 Option</name>
<t>An example of the use of Q-Block2 Option with Confirmable messages <t>An example of the use of the Q-Block2 option with Confirmable message
is shown in <xref target="b4con"></xref>.</t> s
is shown in <xref target="b4con" format="default"/>.</t>
<t><figure align="center" anchor="b4con" <figure anchor="b4con">
title="Example of CON Notifications with Q-Block2 Option"> <name>Example of CON Notifications with the Q-Block2 Option</name>
<artwork align="center"><![CDATA[ Client Server <artwork align="left" name="" type="ascii-art" alt=""><![CDATA[
| | Client Server
+--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 | |
|<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024 +--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
|<---------+ CON 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ CON 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 |<---------+ CON 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ CON 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 |<---------+ CON 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024
|--------->+ ACK 0.00 M:0xe1 |<---------+ CON 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xe2 |--------->+ ACK 0.00 M:0xe1
|--------->+ ACK 0.00 M:0xe3 |--------->+ ACK 0.00 M:0xe2
| ... | |--------->+ ACK 0.00 M:0xe3
| [[Observe triggered]] | ... |
|<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 | [[Observe triggered]]
|<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024 |<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024
[[NSTART(3) limit reached]] |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024
|--------->+ ACK 0.00 M:0xe4 [[NSTART(3) limit reached]]
|<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 |--------->+ ACK 0.00 M:0xe4
|--------->+ ACK 0.00 M:0xe5 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024
|--------->+ ACK 0.00 M:0xe6 |--------->+ ACK 0.00 M:0xe5
|--------->+ ACK 0.00 M:0xe7 |--------->+ ACK 0.00 M:0xe6
| ... | |--------->+ ACK 0.00 M:0xe7
| [[Observe triggered]] | ... |
|<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 | [[Observe triggered]]
| X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
[[NSTART(3) limit reached]] | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
|--------->+ ACK 0.00 M:0xe8 [[NSTART(3) limit reached]]
|<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 |--------->+ ACK 0.00 M:0xe8
|--------->+ ACK 0.00 M:0xeb |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024
| ... | |--------->+ ACK 0.00 M:0xeb
[[ACK TIMEOUT (server) for M:0xe9 delay expires]] | ... |
| [[Server retransmits packet]] [[ACK TIMEOUT (server) for M:0xe9 delay expires]]
|<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 | [[Server retransmits packet]]
[[ACK TIMEOUT (server) for M:0xea delay expires]] |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
| [[Server retransmits packet]] [[ACK TIMEOUT (server) for M:0xea delay expires]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | [[Server retransmits packet]]
|--------->+ ACK 0.00 M:0xe9 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
| ... | |--------->+ ACK 0.00 M:0xe9
[[ACK TIMEOUT exponential backoff (server) delay expires]] | ... |
| [[Server retransmits packet]] [[ACK TIMEOUT exponential backoff (server) delay expires]]
| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | [[Server retransmits packet]]
| ... | | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
[[Either body transmission failure (acknowledge retry timeout) | ... |
or successfully transmitted.]] [[Either body transmission failure (acknowledge retry timeout)
or successfully transmitted]]
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>It is up to the implementation as to whether the application <t>It is up to the implementation as to whether the application
process stops trying to send this particular body of data on reaching process stops trying to send this particular body of data on reaching
MAX_RETRANSMIT for any payload, or separately tries to initiate the MAX_RETRANSMIT for any payload or separately tries to initiate the
new transmission of the payloads that have not been acknowledged under new transmission of the payloads that have not been acknowledged under
these adverse traffic conditions.</t> these adverse traffic conditions.</t>
<t>If transient network losses are possible, then the use of NON should
<t>If there is likely to be the possibility of transient network be considered.</t>
losses, then the use of NON should be considered.</t>
</section> </section>
</section> </section>
<section anchor="REL" numbered="true" toc="default">
<section anchor="REL" title="Examples with Reliable Transports"> <name>Examples with Reliable Transports</name>
<t>The notations provided in <xref target="legend"></xref> are used in <t>The conventions provided in <xref target="non-confirm" format="default"
the following subsections.</t> /> are used
in the following subsections.</t>
<section title="Q-Block1 Option"> <section numbered="true" toc="default">
<t>Let's now consider the use of Q-Block1 Option with a reliable <name>Q-Block1 Option</name>
transport as shown in <xref target="rel3"></xref>. There is no <t>Let's now consider the use of the Q-Block1 option with a reliable
transport, as shown in <xref target="rel3" format="default"/>. There is
no
acknowledgment of packets at the CoAP layer, just the final acknowledgment of packets at the CoAP layer, just the final
result.</t> result.</t>
<figure anchor="rel3">
<t><figure anchor="rel3" <name>Example of a Reliable Request with the Q-Block1 Option</name>
title="Example of Reliable Request with Q-Block1 Option"> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[
<artwork><![CDATA[ CoAP CoAP CoAP CoAP
Client Server Client Server
| | | |
+--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024 +--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024
+--------->| PUT /path T:0xf1 RT=10 QB1:1/1/1024 +--------->| PUT /path T:0xf1 RT=10 QB1:1/1/1024
+--------->| PUT /path T:0xf2 RT=10 QB1:2/1/1024 +--------->| PUT /path T:0xf2 RT=10 QB1:2/1/1024
+--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024 +--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024
|<---------+ 2.04 |<---------+ 2.04
| | | |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>If transient network losses are possible, then the use of unreliable
<t>If there is likely to be the possibility of transient network transport with NON should be
losses, then the use of unreliable transport with NON should be
considered.</t> considered.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Q-Block2 Option"> <name>Q-Block2 Option</name>
<t>An example of the use of Q-Block2 Option with a reliable transport <t>An example of the use of the Q-Block2 option with a reliable transpor
is shown in <xref target="b4rel"></xref>.</t> t
is shown in <xref target="b4rel" format="default"/>.</t>
<t><figure align="center" anchor="b4rel" <figure anchor="b4rel">
title="Example of Notifications with Q-Block2 Option"> <name>Example of Notifications with the Q-Block2 Option</name>
<artwork align="center"><![CDATA[ Client Server <artwork align="left" name="" type="ascii-art" alt=""><![CDATA[
| | Client Server
+--------->| GET /path T:0xf0 O:0 QB2:0/1/1024 | |
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:0/1/1024 +--------->| GET /path T:0xf0 O:0 QB2:0/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:0/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:2/1/1024 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:1/1/1024
|<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:2/1/1024
| ... | |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024
| [[Observe triggered]] | ... |
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:0/1/1024 | [[Observe triggered]]
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:0/1/1024
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:2/1/1024 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:1/1/1024
|<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:3/0/1024 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:2/1/1024
| ... | |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:3/0/1024
| ... |
]]></artwork> ]]></artwork>
</figure></t> </figure>
<t>If transient network losses are possible, then the use of unreliable
<t>If there is likely to be the possibility of network transient transport with NON should be
losses, then the use of unreliable transport with NON should be
considered.</t> considered.</t>
</section> </section>
</section> </section>
<section numbered="false" toc="default">
<section numbered="false" title="Acknowledgements" toc="default"> <name>Acknowledgments</name>
<t>Thanks to Achim Kraus, Jim Schaad, and Michael Richardson for their <t>Thanks to <contact fullname="Achim Kraus"/>, <contact fullname="Jim Sch
aad"/>,
and <contact fullname="Michael Richardson"/> for their
comments.</t> comments.</t>
<t>Special thanks to <contact fullname="Christian Amsüss"/>, <contact
<t>Special thanks to Christian Ams&uuml;ss, Carsten Bormann, and Marco fullname="Carsten Bormann"/>, and <contact fullname="Marco
Tiloca for their suggestions and several reviews, which improved this Tiloca"/> for their suggestions and several reviews, which improved this
specification significantly. Thanks to Francesca Palombini for the AD specification significantly. Thanks to <contact fullname="Francesca Palomb
review. <vspace blankLines="1" />Thanks to Pete Resnick for the Gen-ART ini"/>
review, Colin Perkins for the Tsvart review, and Emmanuel Baccelli for for the AD review. Thanks to <contact fullname="Pete Resnick"/> for the Ge
the Iotdir review. Thanks to Martin Duke, Eric Vyncke, Benjamin Kaduk, n-ART
Roman Danyliw, John Scudder, and Lars Eggert for the IESG review.</t> review, <contact fullname="Colin Perkins"/> for the TSVART review, and
<contact fullname="Emmanuel Baccelli"/> for
<t>Some text from <xref target="RFC7959" /> is reused for readers the IOT-DIR review. Thanks to <contact fullname="Martin Duke"/>, <contact
fullname="Éric Vyncke"/>, <contact fullname="Benjamin Kaduk"/>,
<contact fullname="Roman Danyliw"/>, <contact fullname="John Scudder"/>, a
nd
<contact fullname="Lars Eggert"/> for the IESG review.</t>
<t>Some text from <xref target="RFC7959" format="default"/> is reused for
the readers'
convenience.</t> convenience.</t>
</section> </section>
</back> </back>
</rfc> </rfc>
 End of changes. 310 change blocks. 
1732 lines changed or deleted 1880 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/