<?xml version="1.0"encoding="US-ASCII"?>encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"> <?rfc toc="yes"?> <?rfc tocompact="yes"?> <?rfc tocdepth="4"?> <?rfc tocindent="yes"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes"?> <?rfc comments="yes"?> <?rfc inline="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-core-new-block-14"ipr="trust200902">number="9177" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.8.0 --> <front> <title abbrev="Quick Block-Wise Transfer Options">Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission</title> <seriesInfo name="RFC" value="9177"/> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <organization>Orange</organization> <address> <postal><street></street><street/> <city>Rennes</city><region></region><region/> <code>35000</code> <country>France</country> </postal> <email>mohamed.boucadair@orange.com</email> </address> </author> <author fullname="Jon Shallow" initials="J." surname="Shallow"><organization></organization><organization/> <address> <postal><street></street> <city></city> <region></region> <code></code><street/> <city/> <region/> <code/> <country>United Kingdom</country> </postal> <email>supjps-ietf@jpshallow.com</email> </address> </author> <date/>year="2022" month="March"/> <workgroup>CoRE Working Group</workgroup> <keyword>Quick-Block</keyword> <keyword>Robust-Block</keyword> <keyword>R-Block</keyword> <keyword>Tough-Block</keyword> <keyword>Resilient-Block</keyword> <keyword>Fast-Block</keyword> <keyword>Resilience</keyword> <keyword>Filtering</keyword> <keyword>Faster transmission</keyword> <keyword>Large amounts of data</keyword> <keyword>Less packet interchange</keyword> <keyword>Fast recovery</keyword> <keyword>DOTS</keyword> <abstract> <t>This document specifies alternative Constrained Application Protocol (CoAP)Block-Wiseblock-wise transfer options: Q-Block1 andQ-Block2 Options.</t>Q-Block2.</t> <t>These options are similar to, but distinct from, the CoAP Block1 and Block2Optionsoptions defined in RFC 7959. The Q-Block1 and Q-Block2Optionsoptions are not intended to replace the Block1 and Block2Options,options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2Optionsoptions support faster recovery should any of the blocks get lost in transmission.</t> </abstract> </front> <middle> <section anchor="introduction"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>The Constrained Application Protocol (CoAP) <xreftarget="RFC7252"></xref>,target="RFC7252" format="default"/>, although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. CoAP supports two message types(Section 1.2 of <xref target="RFC7252"></xref>):(<xref target="RFC7252" section="1.2" sectionFormat="of" format="default"/>): Confirmable (CON) and Non-confirmable(NON) messages.(NON). Unlike NON messages, every CON message will elicit anacknowledgementacknowledgment or a reset.</t> <t>The CoAP specification recommends that a CoAP message should fit within a single IP packet (i.e., avoid IP fragmentation). To handle data records that cannot fit in a single IP packet, <xreftarget="RFC7959"></xref>target="RFC7959" format="default"/> introduced the concept of block-wisetransfertransfers and the companion CoAP Block1 and Block2Options.options. However, this concept is designed to work exclusively with Confirmable messages(Section 1 of <xref target="RFC7959"></xref>).(<xref target="RFC7959" section="1" sectionFormat="of" format="default"/>). Note that the block-wise transfer was further updated by <xreftarget="RFC8323"></xref>target="RFC8323" format="default"/> for use over TCP, TLS, and WebSockets.</t> <t>The CoAP Block1 and Block2Optionsoptions work well in environments where there are no, or minimal, packet losses. These options operate synchronously, i.e., each individual block has to be requested. A CoAP endpoint can only ask for (or send) the next block when the transfer of the previous block has completed.PacketThe packet transmission rate, and hence the block transmission rate, is controlled byRound TripRound-Trip Times (RTTs).</t> <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 asymmetrical transient packet loss (e.g., acknowledgment responses may get dropped). An example is when a network is subject to a Distributed Denial of Service (DDoS) attack and there is a need for DDoS mitigation agents relying upon CoAP to communicate with each other (e.g., <xreftarget="RFC8782"></xref><xref target="I-D.ietf-dots-telemetry"></xref>).target="RFC9132" format="default"/> <xref target="DOTS-TELEMETRY" format="default"/>). As a reminder, <xreftarget="RFC7959"></xref>target="RFC7959" format="default"/> recommends the use of CON responses to handle potential packet loss. However, such a recommendation does not work with aflooded pipe"flooded pipe" DDoS situation (e.g., <xreftarget="RFC8782"></xref>).</t>target="RFC9132" format="default"/>).</t> <t>This document introduces the CoAP Q-Block1 and Q-Block2Optionsoptions, which allow block-wisetransfertransfers to work with a series of Non-confirmablemessages,messages instead of lock-stepping using Confirmable messages (<xreftarget="alt"></xref>).target="alt" format="default"/>). In other words, this document provides a missing piece of <xreftarget="RFC7959"></xref>,target="RFC7959" format="default"/>, namely the support of block-wisetransfertransfers using Non-confirmable messages where an entire body of data can be transmitted without the requirement that intermediate acknowledgments be received from the peer (but recovery is available should it be needed).</t> <t>Similar to <xreftarget="RFC7959"></xref>,target="RFC7959" format="default"/>, this specification does not remove any of the constraints posed by the base CoAP specification <xreftarget="RFC7252"></xref>target="RFC7252" format="default"/> it is strictly layered on top of.</t> </section> <section anchor="notation"title="Terminology"> <t>Thenumbered="true" toc="default"> <name>Terminology</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xreftarget="RFC2119"></xref><xref target="RFC8174"></xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> <t>Readers should be familiar with the terms and concepts defined in <xreftarget="RFC7252"></xref>,target="RFC7252" format="default"/>, <xreftarget="RFC7959"></xref>,target="RFC7959" format="default"/>, and <xreftarget="RFC8132"></xref>.target="RFC8132" format="default"/>. Particularly, the document uses the following keyconcepts:<list style="hanging"> <t hangText="Token:">is usedconcepts:</t> <dl newline="false" spacing="normal"> <dt>Token:</dt><dd>used to match responses to requests independently from the underlying messages(Section 5.3.1 of <xref target="RFC7252"></xref>).</t> <t hangText="ETag:">is used(<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 vary over time(Section 5.10.6 of <xref target="RFC7252"></xref>).</t> </list></t>(<xref target="RFC7252" section="5.10.6" sectionFormat="of" format="default"/>).</dd> </dl> <t>The terms "payload" and "body" are defined in <xreftarget="RFC7959"></xref>.target="RFC7959" format="default"/>. The term "payload" is thus used for the content of a single CoAP message (i.e., a single block being transferred), while the term "body" is used for the entire resource representation that is being transferred in a block-wise fashion.</t> <t>Request-Tag refers to an option that allows a CoAP server to match message fragments belonging to the same request <xreftarget="I-D.ietf-core-echo-request-tag"></xref>.</t>target="RFC9175" format="default"/>.</t> <t>MAX_PAYLOADS is the maximum number of payloads that can be transmitted at any one time.</t> <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 example, if MAX_PAYLOADS is set to'10',10, a MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc. Depending on the overall data size, there could be fewer than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.</t> </section> <section anchor="alt"title="Alternativenumbered="true" toc="default"> <name>Alternative CoAP Block-Wise TransferOptions">Options</name> <t>This document introduces the CoAP Q-Block1 and Q-Block2Options.options. These options are designed to work in particular with NON requests and responses.</t> <t>Using NON messages, faster transmissions canoccuroccur, as all the blocks can be transmitted serially (akin to fragmented IP packets) without having to wait for a response or next request from the remote CoAP peer. Recovery of missing blocks is faster in that multiple missing blocks can be requested in a single CoAP message. Even if there is asymmetrical packet loss, a body can still be sent and received by the peer whether the body comprises a single payload or multiple payloads, assuming no recovery is required.</t> <t>A CoAP endpoint can acknowledge all or a subset of the blocks. Concretely, the receiving CoAP endpoint either informs the sending CoAPsenderendpoint of successful reception or reports on all blocks in the body that have not yet been received. The sending CoAPsenderendpoint will then retransmit only the blocks that have been lost in transmission.</t> <t>Note that similar transmission rate benefits can be applied to Confirmable messages if the value of NSTART is increased from 1(Section 4.7 of <xref target="RFC7252"></xref>).(<xref target="RFC7252" section="4.7" sectionFormat="of" format="default"/>). However, the use of Confirmable messages will not work effectively if there is asymmetrical packet loss. Some examples with Confirmable messages are provided in <xreftarget="CON"></xref>.</t>target="CON" format="default"/>.</t> <t>There is little, if any, benefit of using these options with CoAP running over a reliable connection <xreftarget="RFC8323"></xref>.target="RFC8323" format="default"/>. In this case, there is no differentiation between CON andNONNON, as they are not used. Some examples using a reliable transport are provided in <xreftarget="REL"></xref>.</t> <t>Q-Block1target="REL" format="default"/>.</t> <t>The Q-Block1 and Q-Block2Optionsoptions are similar in operation to the CoAP Block1 and Block2Options,options, respectively. They are not a replacement forthem,them but have the followingbenefits:<list style="symbols"> <t>Theybenefits:</t> <ul spacing="normal"> <li>They can operate in environments where packet loss is highlyasymmetrical.</t> <t>Theyasymmetrical.</li> <li>They enable faster transmissions of sets of blocks of data with fewer packetinterchanges.</t> <t>Theyinterchanges.</li> <li>They support faster recovery should any of the blocks get lost intransmission.</t> <t>Theytransmission.</li> <li>They support sending an entire body using NON messages without requiring that an intermediate response be received from thepeer.</t> </list></t> <t>There are the followingpeer.</li> </ul> <t>The disadvantagesoverof using the CoAP Block1 and Block2Options:<list style="symbols"> <t>Lossoptions are as follows:</t> <ul spacing="normal"> <li>There is a loss oflock-steppinglock-stepping, so payloads are not always received in the correct(block ascending) order.</t> <t>Additionalorder (blocks in ascending order).</li> <li>Additional congestion control measures need to be put in place for NON messages (<xreftarget="cc-non"></xref>).</t> <t>Totarget="cc-non" format="default"/>).</li> <li>To reduce the transmission times for CONtransmissiontransmissions of large bodies, NSTART needs to be increased from 1, but this affects congestion control and incurs a requirement tore-tuneretune other parameters(Section 4.7 of <xref target="RFC7252"></xref>).(<xref target="RFC7252" section="4.7" sectionFormat="of" format="default"/>). Such tuning is out of scope of thisdocument.</t> <t>Mixingdocument.</li> <li>Mixing of NON and CON during an exchange of requests/responses using Q-Block options is notsupported.</t> <t>Thesupported.</li> <li>The Q-BlockOptionsoptions do not support stateless operation/randomaccess.</t> <t>Proxyingaccess.</li> <li>Proxying of Q-Block options is limited to caching fullrepresentations.</t> <t>Thererepresentations.</li> <li>There is no multicastsupport.</t> </list></t> <t>Q-Block1support.</li> </ul> <t>The Q-Block1 and Q-Block2Optionsoptions can be used instead of the Block1 and Block2Optionsoptions when the different transmission properties are required. If the new options are not supported by a peer, then transmissions can fall back to using the Block1 and Block2Optionsoptions (<xreftarget="prop"></xref>).</t>target="prop" format="default"/>).</t> <t>The deviations from the Block1 and Block2Optionsoptions are specified in <xreftarget="spec"></xref>.target="spec" format="default"/>. Pointers to the appropriate<xref target="RFC7959"></xref>sections in <xref target="RFC7959" format="default"/> are provided.</t> <t>The specification refers to the base CoAP methods defined inSection 5.8 of<xreftarget="RFC7252"></xref>target="RFC7252" section="5.8" sectionFormat="of" format="default"/> and the new CoAP methods, FETCH, PATCH, andiPATCHiPATCH, which are introduced in <xreftarget="RFC8132"></xref>.</t>target="RFC8132" format="default"/>.</t> <t>The No-ResponseOptionoption <xreftarget="RFC7967"></xref>target="RFC7967" format="default"/> was considered but wasabandonedabandoned, as it does not apply to Q-Block2 responses. A unified solution is defined in the document.</t> <sectiontitle="CoAPnumbered="true" toc="default"> <name>CoAP Response Code (4.08)Usage">Usage</name> <t>This document adds a media type for the 4.08 (Request Entity Incomplete) response defining an additional message format for reporting on payloads using the Q-Block1Optionoption that are not received by the server.</t> <t>See <xreftarget="code"></xref>target="code" format="default"/> for more details.</t> </section> <section anchor="scope"title="Applicability Scope">numbered="true" toc="default"> <name>Applicability Scope</name> <t>The block-wise transfer specified in <xreftarget="RFC7959"></xref>target="RFC7959" format="default"/> covers the general case using Confirmablemessages,messages but falls short in situations where packet loss is highly asymmetrical or there is no need for anacknowledgement.acknowledgment. In other words, there is a need for Non-confirmable support.</t> <t>The mechanism specified in this document provides roughly similar features to the Block1/Block2Options.options. It provides additional properties that are tailored towards the intended use case of Non-confirmable transmission. Concretely, this mechanism primarily targetsapplicationsapplications, such as DDoS Open Threat Signaling(DOTS)(DOTS), that cannot use CON requests/responses because of potential packet loss and that support application-specific mechanisms to assess whether the remote peer is not overloaded and thus is able to process the messages sent by a CoAP endpoint (e.g., DOTS heartbeats inSection 4.7 of<xreftarget="RFC8782"></xref>).target="RFC9132" section="4.7" sectionFormat="of" format="default"/>). Other use cases are when an application sends data but has no need for anacknowledgementacknowledgment of receiptand,and any data transmission loss is not critical.</t> <t>The mechanism includes guards to prevent a CoAP agent from overloading the network by adopting an aggressive sending rate. These guardsMUST<bcp14>MUST</bcp14> be followed in addition to the existing CoAP congestioncontrolcontrol, as specified inSection 4.7 of<xreftarget="RFC7252"></xref>.target="RFC7252" section="4.7" sectionFormat="of" format="default"/>. See <xreftarget="cc"></xref>target="cc" format="default"/> for more details.</t> <t>Any usage outside the primary use case of Non-confirmable messages with block transfers should be carefully weighed against the potential loss of interoperability with generic CoAP applications(See(see the disadvantages listed in <xreftarget="alt"></xref>).target="alt" format="default"/>). It is hoped that the experience gained with this mechanism can feed future extensions of the block-wise mechanism that will both be generally applicable and serve this particular use case.</t> <t>It is not recommended that these options are used ina NoSecthe "NoSec" security mode(Section 9 of <xref target="RFC7252"></xref>)(<xref target="RFC7252" section="9" sectionFormat="of" format="default"/>), as the source endpoint needs to be trusted. UsingOSCOREObject Security for Constrained RESTful Environments (OSCORE) <xreftarget="RFC8613"></xref>target="RFC8613" format="default"/> does provide a security contextand, hence,and hence a trust of the source endpoint that prepared the inner OSCORE content. However, even with OSCORE, usingathe NoSecsecuritymode with these options may still be inadequate, for reasons discussed in <xreftarget="security"></xref>.</t>target="security" format="default"/>.</t> </section> </section> <section anchor="spec"title="Thenumbered="true" toc="default"> <name>The Q-Block1 and Q-Block2Options">Options</name> <section anchor="prop"title="Propertiesnumbered="true" toc="default"> <name>Properties of the Q-Block1 and Q-Block2Options">Options</name> <t>The properties of the Q-Block1 and Q-Block2Optionsoptions are shown inTable 1.<xref target="coap" format="default"/>. The formatting of this table follows the one used in Table 4 of <xreftarget="RFC7252"></xref> (Section 5.10).target="RFC7252" section="5.10" sectionFormat="of" format="default"/>. The C, U, N, and R columns indicate the properties Critical, UnSafe, NoCacheKey, andRepeatableRepeatable, which are defined inSection 5.4 of<xreftarget="RFC7252"></xref>.target="RFC7252" section="5.4" sectionFormat="of" format="default"/>. Only the Critical and UnSafe columns are marked for the Q-Block1Option.option. The Critical, UnSafe, and Repeatable columns are marked for the Q-Block2Option.option. As these options are UnSafe, NoCacheKey has no meaning and so is marked with a dash.</t><t><figure align="center"> <artwork align="center"><![CDATA[+--------+---+---+---+---+--------------+--------+--------+---------+ | Number | C | U | N | R | Name | Format | Length | Default | +========+===+===+===+===+==============+========+========+=========+ | TBA1 | x | x | - | | Q-Block1 | uint | 0-3 | (none) | | TBA2 | x | x | - | x | Q-Block2 | uint | 0-3 | (none) | +--------+---+---+---+---+--------------+--------+--------+---------+ Table 1: CoAP<table align="center" anchor="coap"> <name>CoAP Q-Block1 and Q-Block2 OptionProperties ]]></artwork> </figure></t>Properties</name> <thead> <tr> <th>No.</th> <th>C</th> <th>U</th> <th>N</th> <th>R</th> <th>Name</th> <th>Format</th> <th>Length</th> <th>Default</th> </tr> </thead> <tbody> <tr> <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-Block2Optionsoptions can be present in both the request and response messages. The Q-Block1Optionoption pertains to the requestpayloadpayload, and the Q-Block2Optionoption pertains to the response payload. When the Content-FormatOptionoption is present together with the Q-Block1 or Q-Block2Option,option, the option applies to thebodybody, not to the payload (i.e., it must be the same for all payloads of the same body).</t> <t>The Q-Block1Optionoption is useful with thepayload-bearing, e.g.,payload-bearing (e.g., POST, PUT, FETCH, PATCH, andiPATCHiPATCH) requests and their responses.</t> <t>The Q-Block2Optionoption is useful,e.g.,for example, with GET, POST, PUT, FETCH, PATCH, and iPATCH requests and their payload-bearing responses (response codes 2.01, 2.02, 2.04, and 2.05)(Section 5.5 of <xref target="RFC7252"></xref>).</t>(<xref target="RFC7252" section="5.5" sectionFormat="of" format="default"/>).</t> <t>A CoAP endpoint (or proxy)MUST<bcp14>MUST</bcp14> support either both or neither of the Q-Block1 and Q-Block2Options.</t>options.</t> <t>If the Q-Block1Optionoption is present in a request or the Q-Block2Optionoption is returned in a response, this indicates a block-wise transfer and describes how this specific block-wise payload forms part of the entire body being transferred. If it is present in the opposite direction, it provides additional control on how that payload will be formed or was processed.</t> <t>To indicate support for Q-Block2 responses, the CoAP clientMUST<bcp14>MUST</bcp14> include the Q-Block2Optionoption in a GET or similar request(FETCH, for example),(e.g., FETCH), the Q-Block2Optionoption in a PUT or similar request(POST, for example),(e.g., POST), or the Q-Block1Optionoption in a PUT or similar request so that the server knows that the client supports this Q-Block functionality should it need to send back a body that spans multiple payloads. Otherwise, the server would use the Block2Optionoption (if supported) to send back a message body that is too large to fit into a single IP packet <xreftarget="RFC7959"></xref>.</t>target="RFC7959" format="default"/>.</t> <t>How a client decides whether it needs to include a Q-Block1 or Q-Block2Optionoption can be driven by a local configuration parameter, triggered by an application(DOTS, for example),(e.g., DOTS), etc. Such considerations are out of the scope ofthethis document.</t> <t>Implementation of the Q-Block1 and Q-Block2Optionsoptions is intended to be optional. However, whenita Q-Block1 or Q-Block2 option is present in a CoAP message, itMUST<bcp14>MUST</bcp14> be processed (or the message rejected). Therefore, the Q-Block1 and Q-Block2Optionsoptions are identified asCriticalcritical options.</t> <t>With CoAP over UDP, the way a request message is rejected for critical options depends on the message type. A Confirmable message with an unrecognized critical option is rejected with a 4.02 (Bad Option) response(Section 5.4.1 of <xref target="RFC7252"></xref>).(<xref target="RFC7252" section="5.4.1" sectionFormat="of" format="default"/>). A Non-confirmable message with an unrecognized critical option is either rejected with a Reset message or just silently ignored (Sections5.4.1<xref target="RFC7252" section="5.4.1" sectionFormat="bare"/> and4.3<xref target="RFC7252" section="4.3" sectionFormat="bare"/> of <xreftarget="RFC7252"></xref>).target="RFC7252" format="default"/>). To reliably get a rejection message, it is thereforeREQUIRED<bcp14>REQUIRED</bcp14> that clients use a Confirmable message for determining support for the Q-Block1 and Q-Block2Options.options. ThisCONConfirmable message can be sent under the base CoAP congestion control setup specified inSection 4.7 of<xreftarget="RFC7252"></xref>target="RFC7252" section="4.7" sectionFormat="of" format="default"/> (that is, NSTART does not need to be increased (<xreftarget="cc-con"></xref>)).</t>target="cc-con" format="default"/>)).</t> <t>The Q-Block1 and Q-Block2Optionsoptions are unsafe to forward. That is, a CoAP proxy that does not understand the Q-Block1 (or Q-Block2)Optionoption must reject the request or response that uses either option(See Section 5.7.1 of(see <xreftarget="RFC7252"></xref>).</t>target="RFC7252" section="5.7.1" sectionFormat="of" format="default"/>).</t> <t>The Q-Block2Optionoption is repeatable when requesting retransmission of missingblocks,blocks but not otherwise. Except for that case, any request carrying multiple Q-Block1 (or Q-Block2)Options MUSToptions <bcp14>MUST</bcp14> be handled following the procedure specified inSection 5.4.5 of<xreftarget="RFC7252"></xref>.</t>target="RFC7252" section="5.4.5" sectionFormat="of" format="default"/>.</t> <t>The Q-Block1 and Q-Block2Options,options, like the Block1 and Block2Options,options, are of both class E and class U for OSCORE processing(Table 2).(<xref target="oscore" format="default"/>). The Q-Block1 (or Q-Block2)Option MAYoption <bcp14>MAY</bcp14> be an Inner or Outer option(Section 4.1 of <xref target="RFC8613"></xref>).(<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 encrypted and integrity protected between clients andservers,servers and provides message body identification in case of end-to-end fragmentation of requests. The Outer option is visible to proxies and labels message bodies in case of hop-by-hop fragmentation of requests.</t><t><figure align="center"> <artwork align="center"><![CDATA[ +--------+-----------------+---+---+ | Number | Name | E | U | +========+=================+===+===+ | TBA1 | Q-Block1 | x | x | | TBA2 | Q-Block2 | x | x | +--------+-----------------+---+---+ Table 2: OSCORE<table align="center" anchor="oscore"> <name>OSCORE Protection of the Q-Block1 and Q-Block2Options ]]></artwork> </figure></t> <t></t>Options</name> <thead> <tr> <th>Number</th> <th>Name</th> <th>E</th> <th>U</th> </tr> </thead> <tbody> <tr> <td>19</td> <td>Q-Block1</td> <td>x</td> <td>x</td> </tr> <tr> <td>31</td> <td>Q-Block2</td> <td>x</td> <td>x</td> </tr> </tbody> </table> <t>Notethatthat, if the Q-Block1 or Q-Block2Optionsoptions are included in a packet as Inner options, the Block1 or Block2Options MUST NOToptions <bcp14>MUST NOT</bcp14> be included as Inner options. Similarly, thereMUST NOT<bcp14>MUST NOT</bcp14> be a mix of Q-Block and Block options for the Outer options. Messages that do not adherewithto this behaviorMUST<bcp14>MUST</bcp14> be rejected with a 4.02 (Bad Option). The Q-Block and BlockOptionsoptions can be mixed across Inner and Outeroptionsoptions, as these are handled independently of each other. For clarity, if OSCORE is not being used, thereMUST NOT<bcp14>MUST NOT</bcp14> be a mix of Q-Block and BlockOptionsoptions in the same packet.</t> </section> <sectiontitle="Structurenumbered="true" toc="default"> <name>Structure of the Q-Block1 and Q-Block2Options">Options</name> <t>The structure of the Q-Block1 and Q-Block2Optionsoptions follows the structure defined inSection 2.2 of<xreftarget="RFC7959"></xref>.</t>target="RFC7959" section="2.2" sectionFormat="of" format="default"/>.</t> <t>There is no default value for the Q-Block1 and Q-Block2Options. Absenceoptions. The absence of one of these options is equivalent to an option value of 0 with respect to the value of block number (NUM) and more bit (M) that could be given in the option, i.e., it indicates that the current block is the first and only block of the transfer (block number is set to0,0; M is unset). However, in contrast to the explicit value 0, which would indicate a size of the block (SZX) of 0, and thus a size value of 16 bytes, there is no specificexplicitsize implied by the absence of the option -- the size is left unspecified. (As for any uint, the explicit value 0 is efficiently indicated by a zero-length option;this,therefore, this is semantically differentin semanticsfrom the absence of theoption).</t>option.)</t> </section> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using the Q-Block1Option ">Option</name> <t>The Q-Block1Optionoption is used when the client wants to send a large amount of data to the server using the POST, PUT, FETCH, PATCH, or iPATCH methods where the data and headers do not fit into a single packet.</t> <t>When the Q-Block1Optionoption is used, the clientMUST<bcp14>MUST</bcp14> include a Request-TagOptionoption <xreftarget="I-D.ietf-core-echo-request-tag"></xref>.target="RFC9175" format="default"/>. The Request-Tag valueMUST<bcp14>MUST</bcp14> be the same for all of the requests for the body of data that is being transferred. The Request-Tag is opaque, but the clientMUST<bcp14>MUST</bcp14> ensure that it is unique for every different body of transmitteddata.<list style="empty"> <t>Implementationdata.</t> <t indent="3">Implementation Note: It is suggested that the client treats the Request-Tag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial Request-Tag value should be randomly generated and then subsequently incremented by the client whenever a new body of data is being transmitted between peers.</t></list></t><t><xreftarget="size"></xref>target="size" format="default"/> discusses the use of the Size1Option.</t>option.</t> <t>For Confirmable transmission, the server continues to acknowledge each packet, but a response is not required (whether separate or piggybacked) until successful receipt of the body by the server. For Non-confirmable transmission, no response is required until either the successful receipt of the body by the server or a timer expires with some of the payloads having not yet arrived. In the latter case, a "retransmit missing payloads" response is needed. For reliable transports (e.g., <xreftarget="RFC8323"></xref>),target="RFC8323" format="default"/>), a response is not required until successful receipt of the body by the server.</t> <t>Each individual message that carries a block of the body is treated as a new request (<xreftarget="token"></xref>).</t>target="token" format="default"/>).</t> <t>The clientMUST<bcp14>MUST</bcp14> send the payloads in order of increasing block number, starting from zero, until the body is complete (subject to any congestion control (<xreftarget="cc"></xref>)). Anytarget="cc" format="default"/>)). In addition, any missing payloads requested by the server mustin additionbe separately transmitted with increasing block numbers.</t> <t>The followingResponse Codesresponse codes are used:</t><t>2.01 (Created)<list style="empty"> <t>This Response Code<dl newline="true" spacing="normal"> <dt>2.01 (Created)</dt> <dd>This response code indicates successful receipt of the entire body and that the resource was created. The token to useMUST<bcp14>MUST</bcp14> be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request, since that will aid any troubleshooting. The client should then release all of the tokens used for this body. Note that the last received payload might not be the one with the highest blocknumber.</t> </list></t> <t>2.02 (Deleted)<list style="empty"> <t>This Response Codenumber.</dd> <dt>2.02 (Deleted)</dt> <dd>This response code indicates successful receipt of the entire body and that the resource was deleted when using POST(Section 5.8.2 <xref target="RFC7252"></xref>).(<xref target="RFC7252" section="5.8.2" sectionFormat="of" format="default"/>). The token to useMUST<bcp14>MUST</bcp14> be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. The client should then release all of the tokens used for thisbody.</t> </list></t> <t>2.04 (Changed)<list style="empty"> <t>This Response Codebody.</dd> <dt>2.04 (Changed)</dt> <dd>This response code indicates successful receipt of the entire body and that the resource was updated. The token to useMUST<bcp14>MUST</bcp14> be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request. The client should then release all of the tokens used for thisbody.</t> </list></t> <t>2.05 (Content)<list style="empty"> <t>This Response Codebody.</dd> <dt>2.05 (Content)</dt> <dd><t>This response code indicates successful receipt of the entire FETCH request body(Section 2 of <xref target="RFC8132"></xref>)(<xref target="RFC8132" section="2" sectionFormat="of" format="default"/>) and that the appropriate representation of the resource is being returned. The token to useMUST<bcp14>MUST</bcp14> be one of the tokens that were received in a request for this block-wise exchange. However, it is desirable to provide the one used in the last received request.</t> <t>If the FETCH request includes the ObserveOption,option, then the serverMUST<bcp14>MUST</bcp14> use the same token as used for the 2.05 (Content) response for returning anyObservetriggered Observe responses so that the 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 observedresource.</t> </list></t> <t>2.31 (Continue)<list style="empty"> <t>This Response Coderesource.</t></dd> <dt>2.31 (Continue)</dt> <dd><t>This response code can be used to indicate that all of the blocks up to and including the Q-Block1Optionoption block NUM (all having the M bit set) have been successfully received. The token to useMUST<bcp14>MUST</bcp14> be one of the tokens that were received in a request for this latest MAX_PAYLOADS_SET block-wise exchange. However, it is desirable to provide the one used in the last received request.</t> <t>The client should then release all of the tokens used for this MAX_PAYLOADS_SET.</t> <t>A response using thisResponse Code MUST NOTresponse code <bcp14>MUST NOT</bcp14> be generated for every received Q-Block1Optionoption request. ItSHOULD<bcp14>SHOULD</bcp14> only be generated when all the payload requests are Non-confirmable and a MAX_PAYLOADS_SET has been received by the server. More details about the motivations for this optimization are discussed in <xreftarget="cc-non"></xref>.</t>target="cc-non" format="default"/>.</t> <t>ThisResponse Code SHOULD NOTresponse code <bcp14>SHOULD NOT</bcp14> be generated forCONCON, as this may cause duplicated payloads to unnecessarily besent.</t> </list></t> <t>4.00sent.</t></dd> <dt>4.00 (BadRequest)<list style="empty"> <t>This Response Code MUSTRequest)</dt> <dd>This response code <bcp14>MUST</bcp14> be returned if the request does not include a Request-TagOptionoption or a Size1Optionoption but does include a Q-Block1option.</t> </list></t> <t>4.02option.</dd> <dt>4.02 (BadOption)<list style="empty"> <t>This Response Code MUSTOption)</dt> <dd>This response code <bcp14>MUST</bcp14> be returned for a Confirmable request if the server does not support the Q-BlockOptions.options. Note that aresetReset message may be sent in case of a Non-confirmablerequest.</t> </list></t> <t>4.08request.</dd> <dt>4.08 (Request EntityIncomplete)<list style="empty"> <t>AsIncomplete)</dt> <dd><t>As a reminder, thisResponse Coderesponse code returned withoutContent-Typecontent type "application/missing-blocks+cbor-seq" (<xreftarget="new-format"></xref>)target="new-format" format="default"/>) is handled as inSection 2.9.2<xreftarget="RFC7959"></xref>.</t>target="RFC7959" section="2.9.2" sectionFormat="of" format="default"/>.</t> <t>ThisResponse Coderesponse code returned withContent-Typecontent type "application/missing-blocks+cbor-seq" indicates that some of the payloads are missing and need to be resent. The client then retransmits the individual missing payloads using the same Request-Tag, Size1,and,and Q-Block1Optionoptions to specify the same NUM, SZX, and M bit values as those sent initially in theoriginal, butoriginal (but notreceived, packet.</t>received) packets.</t> <t>The Request-Tag value to use is determined by taking the token in the 4.08 (Request Entity Incomplete) response, locating the matching client request, and then using its Request-Tag.</t> <t>The token to use in the 4.08 (Request Entity Incomplete) responseMUST<bcp14>MUST</bcp14> be one of the tokens that were received in a request for this block-wise body exchange. However, it is desirable to provide the one used in the last received request. See <xreftarget="code"></xref>target="code" format="default"/> for further information.</t> <t>If the server has not received all the blocks of a body, but one or more NON payloads have been received, itSHOULD<bcp14>SHOULD</bcp14> wait for NON_RECEIVE_TIMEOUT (<xreftarget="cc-non"></xref>)target="cc-non" format="default"/>) before sending a 4.08 (Request Entity Incomplete)response.</t> </list></t> <t>4.13response.</t></dd> <dt>4.13 (Request Entity TooLarge)<list style="empty"> <t>This Response CodeLarge)</dt> <dd><t>This response code can be returned undersimilarconditions similar to those discussed inSection 2.9.3 of<xreftarget="RFC7959"></xref>.</t>target="RFC7959" section="2.9.3" sectionFormat="of" format="default"/>.</t> <t>ThisResponse Coderesponse 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 Size1Optionoption is not included in theresponse.</t> </list></t>response.</t></dd> </dl> <t>Further considerations related to the transmission timings of the 4.08 (Request Entity Incomplete) and 2.31 (Continue)Response Codesresponse codes are discussed in <xreftarget="cc-non"></xref>.</t>target="cc-non" format="default"/>.</t> <t>If a server receives payloads with different Request-Tags for the same resource, it should continue to process all thebodiesbodies, as it has no way of determining which is the latestversion,version or which body, if any, the client is terminating the transmission for.</t> <t>If the client elects to stop the transmission of a complete body,andthen absent any local policy, the clientMUST<bcp14>MUST</bcp14> "forget" all tracked tokens associated with the body's Request-Tag so that aresetReset message is generated for the invalid token in the 4.08 (Request Entity Incomplete) response.The server onOn receipt of thereset message SHOULDReset message, the server <bcp14>SHOULD</bcp14> delete the partial body.</t> <t>If the server receives a duplicate block with the same Request-Tag, itMUST<bcp14>MUST</bcp14> ignore the payload of thepacket,packet butMUST<bcp14>MUST</bcp14> still respond as if the block was received for the first time.</t> <t>A serverSHOULD<bcp14>SHOULD</bcp14> maintain a partial body (missing payloads) for NON_PARTIAL_TIMEOUT (<xreftarget="cc-non"></xref>).</t>target="cc-non" format="default"/>).</t> </section> <section anchor="qblock2"title="Usingnumbered="true" toc="default"> <name>Using the Q-Block2Option">Option</name> <t>In a request for any block number,thean unset M bitunsetindicates the request is just for that block. If the M bit is set, this has different meanings based on the NUMvalue:<list style="hanging"> <t hangText="NUMvalue:</t> <dl newline="false" spacing="normal"> <dt>NUM iszero:">Thiszero:</dt> <dd>This is a request for the entirebody.</t> <t hangText="'NUMbody.</dd> <dt>'NUM modulo MAX_PAYLOADS' is zero, while NUM is notzero:">Thiszero:</dt> <dd>This is used to confirm that the current MAX_PAYLOADS_SET (the latest block having block number NUM-1) has been successfully received and that, upon receipt of this request, the server can continue to send the next MAX_PAYLOADS_SET (the first block having block number NUM). This is the 'Continue' Q-Block-2 and conceptually has the same usage (i.e., continue sending the next set of data) as the use of 2.31 (Continue) forQ-Block1.</t> <t hangText="AnyQ-Block1.</dd> <dt>Any other value ofNUM:">ThisNUM:</dt> <dd>This is a request for that block and for all of the remaining blocks in the currentMAX_PAYLOADS_SET.</t> </list></t>MAX_PAYLOADS_SET.</dd> </dl> <t>If the request includes multiple Q-Block2Optionsoptions and these options overlap (e.g., combination of M being set (this and later blocks) andbeingunset (this individualblock))block)), resulting in an individual block being requested multiple times, the serverMUST<bcp14>MUST</bcp14> only send back one instance of that block. This behavior is meant to prevent amplification attacks.</t> <t>The payloads sent back from the server as a responseMUST<bcp14>MUST</bcp14> all have the same ETag(Section 5.10.6 of <xref target="RFC7252"></xref>)(<xref target="RFC7252" section="5.10.6" sectionFormat="of" format="default"/>) for the same body. The serverMUST NOT<bcp14>MUST NOT</bcp14> use the same ETag value for different representations of a resource.</t> <t>The ETag is opaque, but the serverMUST<bcp14>MUST</bcp14> ensure that it is unique for every different body of transmitted data.</t><t><list style="empty"> <t>Implementation<t indent="3">Implementation Note: It is suggested that the server treats the ETag as an unsigned integer of 8 bytes in length. An implementation may want to consider limiting this to 4 bytes to reduce packet overhead size. The initial ETag value should be randomly generated and then subsequently incremented by the server whenever a new body of data is being transmitted between peers.</t></list></t><t><xreftarget="size"></xref>target="size" format="default"/> discusses the use of the Size2Option.</t>option.</t> <t>The client may elect to request any detected missing blocks or just ignore the partial body. This decision is implementation specific.</t> <t>For NON payloads, the clientSHOULD<bcp14>SHOULD</bcp14> wait for NON_RECEIVE_TIMEOUT (<xreftarget="cc-non"></xref>)target="cc-non" format="default"/>) after the last received payload before requesting retransmission of any missing blocks. Retransmission is requested by issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or more Q-Block2Optionsoptions that define the missing block(s).GenerallyGenerally, the M bit on the Q-Block2Option(s) SHOULDoption(s) <bcp14>SHOULD</bcp14> be unset, although the M bitMAY<bcp14>MAY</bcp14> be set to request this and later blocks from thisMAX_PAYLOADS_SET,MAX_PAYLOADS_SET; see <xreftarget="sec-nonb411"></xref>target="sec-nonb411" format="default"/> for an example of this in operation. Further considerations related to the transmission timing for missing requests are discussed in <xreftarget="cc-non"></xref>.</t>target="cc-non" format="default"/>.</t> <t>The missing block numbers requested by the clientMUST<bcp14>MUST</bcp14> have an increasing block number in each additional Q-Block2Optionoption with no duplicates. The serverSHOULD<bcp14>SHOULD</bcp14> respond with a 4.00 (Bad Request) to requests not adhering to this behavior. Note that the ordering constraint is meant to force the client to check for duplicates and remove them. This also helps with troubleshooting.</t> <t>If the client receives a duplicate block with the same ETag, itMUST<bcp14>MUST</bcp14> silently ignore the payload.</t> <t>A clientSHOULD<bcp14>SHOULD</bcp14> maintain a partial body (missing payloads) for NON_PARTIAL_TIMEOUT (<xreftarget="cc-non"></xref>)target="cc-non" format="default"/>) or as defined by the Max-AgeOptionoption (or its default of 60 seconds(Section 5.6.1 of <xref target="RFC7252"></xref>)),(<xref target="RFC7252" section="5.6.1" sectionFormat="of" format="default"/>)), whichever istheless. On release of the partial body, the client should then release all of the tokens used for this body apart from the token that is used to track a resource that is being observed.</t> <t>The ETagOptionoption should not be used in the request for missingblocksblocks, as the server could respond with a 2.03 (Valid) response with no payload. It can be used in the request if the client wants to check the freshness of the locally cached body response.</t> <t>The serverSHOULD<bcp14>SHOULD</bcp14> maintain a cached copy of the body when using the Q-Block2Optionoption to facilitate retransmission of any missing payloads.</t> <t>If the server detectspart waypartway through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the old data, then the transmission is terminated. Any subsequent missing block requestsMUST<bcp14>MUST</bcp14> be responded to using the latest ETag and Size2Optionoption values with the updated data.</t> <t>If the server responds during a body update with a different ETagOptionoption value (as the resource representation has changed), then the client should treat the partial body with the old ETag as no longer being fresh. The client may then request all of the new data by specifying Q-Block2 with block number '0' and the M bit set.</t> <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 additional response, the client should remove any partially received body held for a previous ETag for thatresourceresource, as it is unlikely the missing blocks can be retrieved.</t> <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 as appropriate, a 4.13 (Request Entity Too Large) is returned without the Size1Option.</t>option.</t> <t>For Confirmable traffic, the server typically acknowledges the initial request using anACKAcknowledgment (ACK) with a piggybackedpayload,payload and then sends the subsequent payloads of the MAX_PAYLOADS_SET as CON responses. These CON responses are individually ACKed by the client. The server will detect failure to send a packet andSHOULD<bcp14>SHOULD</bcp14> terminate the body transfer, but the client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET, POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed.</t> </section> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using the ObserveOption">Option</name> <t>For a request that uses Q-Block1, the Observe value <xreftarget="RFC7641"></xref> MUSTtarget="RFC7641" format="default"/> <bcp14>MUST</bcp14> be the same for all the payloads of the same body. This includes any missing payloads that are retransmitted.</t> <t>For a response that uses Q-Block2, the Observe valueMUST<bcp14>MUST</bcp14> be the same for all the payloads of the same body. This is different from Block2 usage where the Observe value is only present in the first block(Section 3.4 of <xref target="RFC7959"></xref>).(<xref target="RFC7959" section="3.4" sectionFormat="of" format="default"/>). This includes payloads transmitted following receipt of the 'Continue' Q-Block2Optionoption (<xreftarget="qblock2"></xref>)target="qblock2" format="default"/>) by the server. If a missing payload is requested by a client, then both the request and responseMUST NOT<bcp14>MUST NOT</bcp14> include the ObserveOption.</t>option.</t> </section> <section anchor="size"title="Usingnumbered="true" toc="default"> <name>Using the Size1 and Size2Options"> <t>Section 4 of <xref target="RFC7959"></xref>Options</name> <t><xref target="RFC7959" section="4" sectionFormat="of" format="default"/> defines two CoAP options: Size1 for indicating the size of the representation transferred in requests and Size2 for indicating the size of the representation transferred in responses.</t> <t>For the Q-Block1 and Q-Block2Options,options, the Size1 or Size2Optionoption valuesMUST<bcp14>MUST</bcp14> exactly represent the size of the data on the body so that any missing data can easily be determined.</t> <t>The Size1Option MUSToption <bcp14>MUST</bcp14> be used with the Q-Block1Optionoption when used in a request andMUST<bcp14>MUST</bcp14> be present in all payloads of the request, preserving the same value. The Size2Option MUSToption <bcp14>MUST</bcp14> be used with the Q-Block2Optionoption when used in a response andMUST<bcp14>MUST</bcp14> be present in all payloads of the response, preserving the same value.</t> </section> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using the Q-Block1 and Q-Block2 OptionsTogether">Together</name> <t>The behavior is similar to the one defined inSection 3.3 of<xreftarget="RFC7959"></xref>target="RFC7959" section="3.3" sectionFormat="of" format="default"/> with Q-Block1 substituted for Block1 and Q-Block2 substituted for Block2.</t> </section> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using the Q-Block2 OptionWith Multicast">with Multicast</name> <t>ServersMUST<bcp14>MUST</bcp14> ignore multicast requests that contain the Q-Block2Option.option. As a reminder, the Block2Optionoption can be used as stated inSection 2.8 of<xreftarget="RFC7959"></xref>.</t>target="RFC7959" section="2.8" sectionFormat="of" format="default"/>.</t> </section> </section> <section anchor="code"title="Thenumbered="true" toc="default"> <name>The Use of the 4.08 (Request Entity Incomplete) ResponseCode"> <t>4.08Code</name> <t>The 4.08 (Request Entity Incomplete)Response Coderesponse code has a newContent-Typecontent type "application/missing-blocks+cbor-seq" used to indicate that the server has not received all of the blocks of the request body that it needs to proceed. Such messages must not be treated by the client as a fatal error.</t> <t>Likely causes are the client has not sent all blocks, some blocks were dropped during transmission, or the clienthassent themsufficientlya 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 withContent-Type set tocontent type "application/missing-blocks+cbor-seq" is encoded as aCBORConcise Binary Object Representation (CBOR) Sequence <xreftarget="RFC8742"></xref>.target="RFC8742" format="default"/>. It comprises one or more missing block numbers encoded as CBOR unsigned integers <xreftarget="RFC8949"></xref>.target="RFC8949" format="default"/>. The missing block numbersMUST<bcp14>MUST</bcp14> be unique in each 4.08 (Request Entity Incomplete) response when created by the server; the clientMUST<bcp14>MUST</bcp14> ignore any duplicates in the same 4.08 (Request Entity Incomplete) response.</t> <t>The Content-FormatOption (Section 5.10.3 of <xref target="RFC7252"></xref>) MUSToption (<xref target="RFC7252" section="5.10.3" sectionFormat="of" format="default"/>) <bcp14>MUST</bcp14> be used in the 4.08 (Request Entity Incomplete) response. ItMUST<bcp14>MUST</bcp14> be set to "application/missing-blocks+cbor-seq" (<xreftarget="new-format"></xref>).</t>target="new-format" format="default"/>).</t> <t>The Concise Data Definition Language (CDDL) <xreftarget="RFC8610"></xref>target="RFC8610" format="default"/> (and seeSection 4.1<xreftarget="RFC8742"></xref>)target="RFC8742" section="4.1" sectionFormat="of" format="default"/>) for the data describing these missing blocks is as follows:</t> <figurealign="center" anchor="cddl" title="Structureanchor="cddl"> <name>Structure of the Missing BlocksPayload"> <artwork align="center"><![CDATA[;Payload</name> <sourcecode type="cddl"><![CDATA[ ; This defines an array, the elements of which are to be used ; in a CBOR Sequence: payload = [+ missing-block-number] ; A unique block number not received: missing-block-number = uint]]></artwork>]]></sourcecode> </figure> <t>This CDDL syntaxMUST<bcp14>MUST</bcp14> be followed.</t> <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 Request-Tag value. Note that the use of any received token with the same Request-Tag would be acceptable, but providing the one used in the last received payload will aid any troubleshooting. The client will use the token to determine what was the previously sent request to obtain the Request-Tag value that was used.</t> <t>If the size of the 4.08 (Request Entity Incomplete) response packet is larger than that defined bySection 4.6<xreftarget="RFC7252"></xref>,target="RFC7252" section="4.6" sectionFormat="of" format="default"/>, then the number of reported missing blocksMUST<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 Entity Incomplete) responses containingthethose additional missingotherblocks on receipt of a new request providing a missing payload with the same Request-Tag.</t> <t>The missing blocksMUST<bcp14>MUST</bcp14> be reported in ascending order without any duplicates. The clientSHOULD<bcp14>SHOULD</bcp14> silently drop 4.08 (Request Entity Incomplete) responses not adheringwithto this behavior.</t><t><list style="hanging"><thangText="Implementation Note:">Considerindent="3">Implementation Note: Consider limiting the number of missing payloads to MAX_PAYLOADS to minimize the need for congestioncontrol being needed.control. The CBORsequenceSequence does not include any array wrapper.</t></list></t> <t>The<t>A 4.08 (Request Entity Incomplete) response withContent-Typecontent type "application/missing-blocks+cbor-seq"SHOULD NOT<bcp14>SHOULD NOT</bcp14> be used when using Confirmable requests or a reliable connection <xreftarget="RFC8323"></xref>target="RFC8323" format="default"/>, as the client will be able to determine that there is a transmission failure of a particular payload and hence that the server is missing that payload.</t> </section> <section anchor="token"title="Thenumbered="true" toc="default"> <name>The Use ofTokens">Tokens</name> <t>Each new request generally uses a new Token (and sometimesmust,must; seeSection 4 of<xreftarget="I-D.ietf-core-echo-request-tag"></xref>).target="RFC9175" section="4" sectionFormat="of" format="default"/>). Additional responses to a request all use the token of the request they respond to.</t><t><list style="hanging"><thangText="Implementation Note:">Byindent="3">Implementation Note: By using 8-byte tokens, it is possible to easily minimize the number of tokens that have to be tracked by clients, by keeping the bottom 32 bits the same for the same body and the upper 32 bits containing the current body's request number (incrementing every request, including everyre-transmit).retransmit). Thisallowsalleviates theclientclient's need tobe alleviated from keepingkeep all theper-request-state,per-request state, e.g.,in Section 3 ofper <xreftarget="RFC8974"></xref>.target="RFC8974" section="3" sectionFormat="of" format="default"/>. However, if using NoSec,Section 5.2 of<xreftarget="RFC8974"></xref>target="RFC8974" section="5.2" sectionFormat="of" format="default"/> needs to be considered for security implications.</t></list></t></section> <section anchor="cc"title="Congestionnumbered="true" toc="default"> <name>Congestion Control for UnreliableTransports">Transports</name> <t>The transmission of all the blocks of a single body over an unreliable transportMUST<bcp14>MUST</bcp14> either all be Confirmable or all be Non-confirmable. This is meant to simplify the congestion control procedure.</t> <t>As a reminder, there is no need for CoAP-specific congestion control for reliable transports <xreftarget="RFC8323"></xref>.</t>target="RFC8323" format="default"/>.</t> <section anchor="cc-con"title="Confirmable (CON)">numbered="true" toc="default"> <name>Confirmable (CON)</name> <t>Congestion control for CON requests and responses is specified inSection 4.7 of<xreftarget="RFC7252"></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 1. However, the other CON congestion control parameters will need to be tuned to cover this change. This tuning is not specified in this document, given that the applicability scope of the current specification assumes that all requests and responses using Q-Block1 and Q-Block2 will be Non-confirmable (<xreftarget="scope"></xref>)target="scope" format="default"/>) apart from the initial Q-Block functionality negotiation.</t> <t>Following the failure to transmit a packet due to packet loss after MAX_TRANSMIT_SPAN time(Section 4.8.2 of <xref target="RFC7252"></xref>),(<xref target="RFC7252" section="4.8.2" sectionFormat="of" format="default"/>), it is implementation specific as to whether there should be any further requests for missing data.</t> </section> <section anchor="cc-non"title="Non-confirmable (NON)">numbered="true" toc="default"> <name>Non-confirmable (NON)</name> <t>This document introduces the new parameters MAX_PAYLOADS, NON_TIMEOUT, NON_TIMEOUT_RANDOM, NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT primarily for use with NON(Table 3).<list style="empty"> <t>Note:(<xref target="congestion" format="default"/>).</t> <t indent="3">Note: Randomness may naturally be provided based on the traffic profile, how PROBING_RATE is computed (as this is an average), and when the peer responds. Randomness is explicitly added for some of the congestion control parameters to handle situations whereevery thingeverything is in sync when retrying.</t></list></t><t>MAX_PAYLOADS should be configurable with a default value of 10. Both CoAP endpointsMUST<bcp14>MUST</bcp14> have the same value(otherwise(otherwise, there will be transmission delays in onedirection)direction), and the valueMAY<bcp14>MAY</bcp14> be negotiated between the endpoints to a common value by using ahigher levelhigher-level protocol (out of scope of this document). This is the maximum number of payloads that can be transmitted at any onetime.<list style="empty"> <t>Note:time.</t> <t indent="3">Note: The default value of 10 is chosen for reasons similar to those discussed inSection 5 of<xreftarget="RFC6928"></xref>,target="RFC6928" section="5" sectionFormat="of" format="default"/>, especially given the target application discussed in <xreftarget="scope"></xref>.</t> </list></t>target="scope" format="default"/>.</t> <t>NON_TIMEOUT is used to compute the delay between sending MAX_PAYLOADS_SET for the same body. By default, NON_TIMEOUT has the same value as ACK_TIMEOUT(Section 4.8 of <xref target="RFC7252"></xref>).</t>(<xref target="RFC7252" section="4.8" sectionFormat="of" format="default"/>).</t> <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 used between the subsequent MAX_PAYLOADS_SETs. It is a random duration (not an integral number of seconds) between NON_TIMEOUT and (NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to1.51.5, as discussed inSection 4.8 of<xreftarget="RFC7252"></xref>.</t>target="RFC7252" section="4.8" sectionFormat="of" format="default"/>.</t> <t>NON_RECEIVE_TIMEOUT is the initial time to wait for a missing payload before requesting retransmission for the first time. Every time the missing payload is re-requested, thetime to waitTime-to-Wait value doubles. The time to wait is calculatedas:<list style="empty"> <t>Time-to-Waitas:</t> <t indent="3">Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))</t></list></t><t>NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT. NON_RECEIVE_TIMEOUTMUST<bcp14>MUST</bcp14> always be greater than NON_TIMEOUT_RANDOM by at least one second so that the sender of the payloads has the opportunity to start sending the next MAX_PAYLOADS_SET before the receiver times out.</t> <t>NON_MAX_RETRANSMIT is the maximum number of times a request for the retransmission of missing payloads can occur without a response from the remote peer. After this occurs, the local endpointSHOULD<bcp14>SHOULD</bcp14> consider the body stale, remove any body, and releaseTokensthe tokens and Request-Tag on the client (or the ETag on the server). By default, NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT(Section 4.8 of <xref target="RFC7252"></xref>).</t>(<xref target="RFC7252" section="4.8" sectionFormat="of" format="default"/>).</t> <t>NON_PROBING_WAIT is used to limit the potential wait needed when using PROBING_RATE. By default, NON_PROBING_WAIT is computed in asimilarwayassimilar to EXCHANGE_LIFETIME(Section 4.8.2 of <xref target="RFC7252"></xref>)(<xref target="RFC7252" section="4.8.2" sectionFormat="of" format="default"/>) but with ACK_TIMEOUT, MAX_RETRANSMIT, and PROCESSING_DELAY substituted with NON_TIMEOUT, NON_MAX_RETRANSMIT, and NON_TIMEOUT_RANDOM,respectively:<list style="empty"> <t>NON_PROBING_WAITrespectively:</t> <t indent="3">NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT_RANDOM</t></list></t><t>NON_PARTIAL_TIMEOUT is used for expiring partially received bodies. By default, NON_PARTIAL_TIMEOUT is computed in the same way as EXCHANGE_LIFETIME(Section 4.8.2 of <xref target="RFC7252"></xref>)(<xref target="RFC7252" section="4.8.2" sectionFormat="of" format="default"/>) but with ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT and NON_MAX_RETRANSMIT,respectively:<list style="empty"> <t>NON_PARTIAL_TIMEOUTrespectively:</t> <t indent="3">NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) - 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT</t></list></t> <t><figure align="center"> <artwork align="center"><![CDATA[+---------------------+-------------------+ | Parameter Name | Default Value | +=====================+===================+ | MAX_PAYLOADS | 10 | | NON_MAX_RETRANSMIT | 4 | | NON_TIMEOUT | 2 s | | NON_TIMEOUT_RANDOM | between<table align="center" anchor="congestion"> <name>Congestion Control Parameters</name> <thead> <tr> <th>Parameter Name</th> <th>Default Value</th> </tr> </thead> <tbody> <tr> <td>MAX_PAYLOADS</td> <td>10</td> </tr> <tr> <td>NON_MAX_RETRANSMIT</td> <td>4</td> </tr> <tr> <td>NON_TIMEOUT</td> <td>2 s</td> </tr> <tr> <td>NON_TIMEOUT_RANDOM</td> <td>between 2-3s | | NON_RECEIVE_TIMEOUT | 4 s | | NON_PROBING_WAIT | betweens</td> </tr> <tr> <td>NON_RECEIVE_TIMEOUT</td> <td>4 s</td> </tr> <tr> <td>NON_PROBING_WAIT</td> <td>between 247-248s | | NON_PARTIAL_TIMEOUT | 247 s | +---------------------+-------------------+ Table 3: Congestion Control Parameters]]></artwork> </figure></t>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 that must not be exceeded by a CoAP endpoint in sending to a peer endpoint that does not respond. A single body will be subjected to PROBING_RATE(Section 4.7 of <xref target="RFC7252"></xref>),(<xref target="RFC7252" section="4.7" sectionFormat="of" format="default"/>), not the individual packets. If the wait time between sending bodies that are not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the wait time is limited toNON_PROBING_WAIT.<list style="empty"> <t>Note:NON_PROBING_WAIT.</t> <aside><t>Note: For the particular DOTS application, PROBING_RATE and other transmission parameters are negotiated between peers. Even when not negotiated, the DOTS application uses customizeddefaultsdefaults, as discussed inSection 4.5.2 of<xreftarget="RFC8782"></xref>.target="RFC9132" section="4.5.2" sectionFormat="of" format="default"/>. Note that MAX_PAYLOADS, NON_MAX_RETRANSMIT, NON_TIMEOUT, NON_PROBING_WAIT, and NON_PARTIAL_TIMEOUT can be negotiated between DOTS peers, e.g., as per <xreftarget="I-D.bosh-dots-quick-blocks"></xref>.target="I-D.bosh-dots-quick-blocks" format="default"/>. When explicit values are configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these values are used without applying anyjitter.</t> </list>Eachjitter.</t></aside> <t>Each NON 4.08 (Request Entity Incomplete) response is subject to PROBING_RATE.</t> <t>Each NON GET or FETCH request using a Q-Block2Optionoption is subject to PROBING_RATE.</t> <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 body, a delayMUST be introducedof NON_TIMEOUT_RANDOM <bcp14>MUST</bcp14> be introduced before sending the nextMAX_PAYLOADS_SETMAX_PAYLOADS_SET, unless a 'Continue' is received from the peer for the current MAX_PAYLOADS_SET, in which case the next MAX_PAYLOADS_SETMAY<bcp14>MAY</bcp14> start transmission immediately.</t><t><list style="empty"> <t>Note:<t indent="3">Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET having 10 payloads, this corresponds to 1500 * 10 * 8 = 120Kbits.kbits. With a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates an average speed requirement of 60Kbpskbps for a single body should 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 those in a MAX_PAYLOADS_SET at a time. In other words, a NON_TIMEOUT_RANDOM delay is still observed between eachMAX_PAYLOAD_SET.</t>MAX_PAYLOADS_SET.</t> <t>For the Q-Block1Option,option, if the server responds with a 2.31 (Continue)Response Coderesponse code for the latest payload sent, then the client can continue to send the next MAX_PAYLOADS_SET without any further delay. If the server responds with a 4.08 (Request Entity Incomplete)Response Code,response code, then the missing payloadsSHOULD<bcp14>SHOULD</bcp14> be retransmitted before going into another NON_TIMEOUT_RANDOM delay prior to sending the next set of payloads.</t> <t>For the server receiving NON Q-Block1 requests, itSHOULD<bcp14>SHOULD</bcp14> send back a 2.31 (Continue)Response Coderesponse code on receipt of all of the MAX_PAYLOADS_SET to prevent the client unnecessarilydelaying.delaying the transfer of remaing blocks. If not all of the MAX_PAYLOADS_SET were received, the serverSHOULD<bcp14>SHOULD</bcp14> delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload) before sending the 4.08 (Request Entity Incomplete)Response Coderesponse code for the missing payload(s). If all of the MAX_PAYLOADS_SET were received and a 2.31 (Continue) response code had been sent, but no more payloads were received for NON_RECEIVE_TIMEOUT (exponentially scaled), the serverSHOULD<bcp14>SHOULD</bcp14> send a 4.08 (Request Entity Incomplete) response detailing the missing payloads after the block number that was indicated in the sent 2.31(Continue).(Continue) response code. If therepeatedrepeat response count of the 4.08 (Request Entity Incomplete) exceeds NON_MAX_RETRANSMIT, the serverSHOULD<bcp14>SHOULD</bcp14> discard the partial body and stop requesting the missing payloads.</t> <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 block of the previous MAX_PAYLOADS_SET. On receipt of a payload from the next MAX_PAYLOADS_SET, the serverSHOULD<bcp14>SHOULD</bcp14> send a 4.08 (Request Entity Incomplete)Response Coderesponse code indicating any missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity Incomplete)Response Code,response code, the clientSHOULD<bcp14>SHOULD</bcp14> send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay prior to sending the next MAX_PAYLOADS_SET.</t> <t>For the client receiving NON Q-Block2 responses, itSHOULD<bcp14>SHOULD</bcp14> send a 'Continue' Q-Block2 request (<xreftarget="qblock2"></xref>)target="qblock2" format="default"/>) for the next MAX_PAYLOADS_SET on receipt of all of theMAX_PAYLOADS_SET,MAX_PAYLOADS_SET to prevent the server unnecessarilydelaying. Otherwisedelaying the transfer of remaining blocks. Otherwise, the clientSHOULD<bcp14>SHOULD</bcp14> delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for apayload),payload) before sending the request for the missing payload(s). If the repeat request count for a missing payload exceeds NON_MAX_RETRANSMIT, the clientSHOULD<bcp14>SHOULD</bcp14> discard the partial body and stop requesting the missing payloads.</t> <t>The serverSHOULD<bcp14>SHOULD</bcp14> recognize the 'Continue' Q-Block2 requestas a continue requestper the definition in <xref target="qblock2" format="default"/> and just continue the transmission of the body (including the ObserveOption,option, if appropriate for an unsolicited response) rather than treat 'Continue' as a request for the remaining missing blocks.</t> <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 block of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the new MAX_PAYLOADS_SET, the clientSHOULD<bcp14>SHOULD</bcp14> send a request indicating any missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of such a request, the serverSHOULD<bcp14>SHOULD</bcp14> send the missing payloads before continuing to send the remainder of the MAX_PAYLOADS_SET and then go into another NON_TIMEOUT_RANDOM delay prior to sending the next MAX_PAYLOADS_SET.</t> <t>The client does not need to acknowledge the receipt of the entire body.</t><t><list style="empty"> <t>Note:<t indent="3">Note: If there is asymmetric traffic loss causing responses to never get received, a delay of NON_TIMEOUT_RANDOM after every transmission of MAX_PAYLOADS_SET will be observed. The endpoint receiving the body is still likely to receive the entire body.</t></list></t></section> </section> <sectiontitle="Caching Considerations">numbered="true" toc="default"> <name>Caching Considerations</name> <t>Cachingblock basedblock-based information is notstraight forwardstraightforward in a proxy. For the Q-Block1 and Q-Block2Options,options, forsimplicitysimplicity, it is expected that the proxy will reassemble the body (using any appropriate recovery options for packet loss) before passingonthe body onward to the appropriate CoAP endpoint. This does not preclude an implementation doing a more complexper payloadper-payload caching, but how to do this is out of the scope of this document. The onward transmission of the body does not require the use of the Q-Block1 or Q-Block2Optionsoptions, as these options may not be supported in that link. This means that the proxy must fully support the Q-Block1 and Q-Block2Options.</t>options.</t> <t>How the body is cached in the CoAP client (for Q-Block1 transmissions) or the CoAP server (for Q-Block2 transmissions) is implementation specific.</t> <t>As the entire body is being cached in the proxy, the Q-Block1 and Q-Block2Optionsoptions are removed as part of the block assembly and thus do not reach the cache.</t> <t>For Q-Block2 responses, the ETagOptionoption value is associated with the data (andonwardtransmitted onward to the CoAPclient),client) but is not part of the cache key.</t> <t>For requests with the Q-Block1Option,option, the Request-TagOptionoption is associated withthe build up ofbuilding the body from successivepayloads,payloads but is not part of the cache key. For the onward transmission of the body using CoAP, a new Request-TagSHOULD<bcp14>SHOULD</bcp14> be generated and used.IdeallyIdeally, this new Request-Tag should replace theclient's request Request-Tag.</t>Request-Tag used by the client.</t> <t>It is possible that two or more CoAP clients are concurrently updating the same resource through a common proxy to the same CoAP server using the Q-Block1 (or Block1)Option.option. If this is the case, the first client to complete building the body causes that body to start transmitting to the CoAP server with an appropriate Request-Tag value. When the next client completes building the body, any existing partial body transmission to the CoAP server isterminatedterminated, and the transmission of the new body representationtransmissionstarts with a new Request-Tag value. Note that it cannot be assumed that the proxy will always receive a complete body from a client.</t> <t>A proxy that supports the Q-Block2Option MUSToption <bcp14>MUST</bcp14> be prepared to receive a GET or similar request indicating one or more missing blocks.TheFrom its cache, the proxy will servefrom its cachethe missing blocks that are available in its cache in the same way a server would send all the appropriate Q-Block2 responses. If a body matching the cache key is not available in the cache, the proxyMUST<bcp14>MUST</bcp14> request the entire body from the CoAP server using the information in the cache key.</t> <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> </section> <sectiontitle="HTTP-Mapping Considerations">numbered="true" toc="default"> <name>HTTP Mapping Considerations</name> <t>As a reminder, the basic normative requirements on HTTP/CoAP mappings are defined inSection 10 of<xreftarget="RFC7252"></xref>.target="RFC7252" section="10" sectionFormat="of" format="default"/>. The implementation guidelines for HTTP/CoAP mappings are elaborated in <xreftarget="RFC8075"></xref>.</t>target="RFC8075" format="default"/>.</t> <t>The rules defined inSection 5 of<xreftarget="RFC7959"></xref>target="RFC7959" section="5" sectionFormat="of" format="default"/> are to be followed.</t> </section> <sectiontitle="Examplesnumbered="true" toc="default" anchor="non-confirm"> <name>Examples with Non-confirmableMessages">Messages</name> <t>This section provides some sample flows to illustrate the use of the Q-Block1 and Q-Block2Optionsoptions with NON. Examples with CON are provided in <xreftarget="CON"></xref>.</t>target="CON" format="default"/>.</t> <t>The examples in the following subsections assume MAX_PAYLOADS is set to 10 and NON_MAX_RETRANSMIT is set to 4.</t><t><xref target="legend"></xref> lists<t>The list below contains the conventions that are used in thefollowing subsections.</t> <t><figure align="center" anchor="legend" title="Notations Usedfigures in theFigures"> <artwork align="center"><![CDATA[ T: Token value O: Observe Option value M: Message ID RT: Request-Tag ET: ETag QB1: Q-Block1 Optionfollowing subsections.</t> <dl newline="false" spacing="normal" indent="7"> <dt>T:</dt> <dd>Token value</dd> <dt>O:</dt> <dd>Observe option value</dd> <dt>M:</dt> <dd>Message ID</dd> <dt>RT:</dt> <dd>Request-Tag</dd> <dt>ET:</dt> <dd>ETag</dd> <dt>QB1:</dt> <dd>Q-Block1 option valuesNUM/More/Size QB2: Q-Block2 OptionNUM/More/Size</dd> <dt>QB2:</dt> <dd>Q-Block2 option valuesNUM/More/Size Size: ActualNUM/More/Size</dd> <dt>Size:</dt> <dd>Actual block size encoded inSZX \: TrimmingSZX</dd> <dt>\:</dt> <dd>Trimming longlines [[]]: Comments -->X: Messagelines</dd> <dt>[[]]:</dt> <dd>Comments</dd> <dt>-->X:</dt> <dd>Message loss(request) X<--: Message(request)</dd> <dt>X<--:</dt> <dd>Message loss(response) ...: Passage of time Payload N: Corresponds(response)</dd> <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-wiseexchange. ]]></artwork> </figure></t>exchange.</dd> </dl> <sectiontitle="Q-Block1 Option ">numbered="true" toc="default"> <name>Q-Block1 Option</name> <sectiontitle="Anumbered="true" toc="default"> <name>A SimpleExample">Example</name> <t><xreftarget="B3non"></xref>target="B3non" format="default"/> depicts an example of a NON PUT request conveying the Q-Block1Option.option. All the blocks are received by the server.</t><t><figure anchor="B3non" title="Example<figure anchor="B3non"> <name>Example of a NON Request with the Q-Block1Option (Without Loss)"> <artwork><![CDATA[option (without Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON PUT /path M:0x81 T:0xc0 RT=9 QB1:0/1/1024 +--------->| NON PUT /path M:0x82 T:0xc1 RT=9 QB1:1/1/1024 +--------->| NON PUT /path M:0x83 T:0xc2 RT=9 QB1:2/1/1024 +--------->| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024 |<---------+ NON 2.04 M:0xf1 T:0xc3 | ... | ]]></artwork></figure></t></figure> </section> <sectiontitle="Handlingnumbered="true" toc="default"> <name>Handling MAX_PAYLOADSLimits">Limits</name> <t><xreftarget="B3non0"></xref>target="B3non0" format="default"/> depicts an example of a NON PUT request conveying the Q-Block1Option.option. The number of payloads exceeds MAX_PAYLOADS. All the blocks are received by the server.</t><t><figure anchor="B3non0" title="Example<figure anchor="B3non0"> <name>Example of a MAX_PAYLOADS NON Request with the Q-Block1 Option(Without Loss)"> <artwork><![CDATA[(without Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024 +--------->| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024 +--------->| [[Payloads 3 - 9 not detailed]] +--------->| NON PUT /path M:0x0a T:0xfa RT=10 QB1:9/1/1024 [[MAX_PAYLOADS_SET has been received]] | [[MAX_PAYLOADS_SET receipt acknowledged by server]] |<---------+ NON 2.31 M:0x81 T:0xfa +--------->| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024 |<---------+ NON 2.04 M:0x82 T:0xfb | ... | ]]></artwork></figure></t></figure> </section> <sectiontitle="Handlingnumbered="true" toc="default"> <name>Handling MAX_PAYLOADS withRecovery">Recovery</name> <t>Consider now a scenario where a new body of data is to be sent by the client, but some blocks are dropped intransmissiontransmission, as illustrated in <xreftarget="B3non1"></xref>.</t> <t><figure anchor="B3non1" title="Exampletarget="B3non1" format="default"/>.</t> <figure anchor="B3non1"> <name>Example of a MAX_PAYLOADS NON Request with the Q-Block1 Option(With Loss)"> <artwork><![CDATA[(with Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024 +--->X | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024 +--------->| [[Payloads 3 - 8 not detailed]] +--------->| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024 +--->X | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024 [[Some of the MAX_PAYLOADS_SEThavehas been received]] | ... | [[NON_TIMEOUT_RANDOM (client) delay expires]] | [[Client starts sending nextMAX_PAYLOAD_SET]]MAX_PAYLOADS_SET]] +--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024 +--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024 | | ]]></artwork></figure></t></figure> <t>On seeing a payload from the nextMAX_PAYLOAD_SET,MAX_PAYLOADS_SET, the server realizes that some blocks are missing from the previous MAX_PAYLOADS_SET and asks for the missing blocks in one go (<xreftarget="B3non2"></xref>).target="B3non2" format="default"/>). It does so by indicating which blocks from the previous MAX_PAYLOADS_SET have not been received in the data portion of the response (<xreftarget="code"></xref>).target="code" format="default"/>). The token used in the response should be the token that was used in the last received payload. The client can then derive the Request-Tag by matching the token with the sent request.</t><t><figure anchor="B3non2" title="Example<figure anchor="B3non2"> <name>Example of a NON Request with the Q-Block1 Option(Blocks Recovery)"> <artwork><![CDATA[(Block Recovery)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | |<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9] | [[Client responds with missing payloads]] +--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024 +--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024 | [[Client continues sending nextMAX_PAYLOAD_SET]]MAX_PAYLOADS_SET]] +--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (server) delay expires]] | [[The server realizes a block is still missing and asks | for the missing one]] |<---------+ NON 4.08 M:0x92 T:0xef [Missing 10] +--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024 |<---------+ NON 2.04 M:0x93 T:0xf0 | ... | ]]></artwork></figure></t></figure> </section> <sectiontitle="Handlingnumbered="true" toc="default"> <name>Handling Recoverywith Failure">if Failure Occurs</name> <t><xreftarget="B3non3"></xref>target="B3non3" format="default"/> depicts an example of a NON PUT request conveying the Q-Block1Optionoption where recovery takesplace,place but eventually fails.</t><t><figure anchor="B3non3" title="Example<figure anchor="B3non3"> <name>Example of a NON Request with the Q-Block1 Option(With(with EventualFailure)"> <artwork><![CDATA[Failure)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024 +--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024 +--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (server) delay expires]] | [[The server realizes a block is missing and asks | for the missing one. Retry #1]] |<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1] | ... | [[2 * NON_RECEIVE_TIMEOUT (server) delay expires]] | [[The server realizes a block is still missing and asks | for the missing one. Retry #2]] |<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1] | ... | [[4 * NON_RECEIVE_TIMEOUT (server) delay expires]] | [[The server realizes a block is still missing and asks | for the missing one. Retry #3]] |<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1] | ... | [[8 * NON_RECEIVE_TIMEOUT (server) delay expires]] | [[The server realizes a block is still missing and asks | for the missing one. Retry #4]] |<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1] | ... | [[16 * NON_RECEIVE_TIMEOUT (server) delay expires]] | [[NON_MAX_RETRANSMIT exceeded. Server stops requesting |forthe missing blocks and releases partial body]] | ... | ]]></artwork></figure></t></figure> </section> </section> <sectiontitle="Q-Block2 Option">numbered="true" toc="default"> <name>Q-Block2 Option</name> <t>These examples include the ObserveOptionoption to demonstrate how that option is used. Note that the ObserveOptionoption is not required forQ-Block2; the observe detail can thus be ignored.</t>Q-Block2.</t> <sectiontitle="Anumbered="true" toc="default"> <name>A SimpleExample">Example</name> <t><xreftarget="nonb4"></xref>target="nonb4" format="default"/> illustratesthean example of the Q-Block2Option.option. The client sends a NON GET carrying the Observe and Q-Block2Options.options. The Q-Block2Optionoption indicates a block size hint (1024 bytes).This request is replied to by theThe server replies to this request using four (4) blocks that are transmitted to the client without any loss. Each of these blocks carries a Q-Block2Option.option. The same process is repeated when an Observe is triggered, but no loss is experienced by any of the notification blocks.</t><t><figure anchor="nonb4" title="Example<figure anchor="nonb4"> <name>Example of NON Notifications with the Q-Block2 Option(Without Loss)"> <artwork><![CDATA[(without Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf2 T:0xc0 O:1220 ET=19 QB2:1/1/1024 |<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024 |<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024 | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024 |<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024 |<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024 |<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024 | ... | ]]></artwork></figure></t></figure> </section> <sectiontitle="Handlingnumbered="true" toc="default"> <name>Handling MAX_PAYLOADSLimits">Limits</name> <t><xreftarget="nonb40"></xref>target="nonb40" format="default"/> illustrates the same scenario as <xreftarget="nonb4"></xref>target="nonb4" format="default"/>, but this timehaswith eleven (11)payloadspayloads, which exceeds MAX_PAYLOADS. There is no loss experienced.</t><t><figure anchor="nonb40" title="Example<figure anchor="nonb40"> <name>Example of NON Notifications with the Q-Block2 Option(Without Loss)"> <artwork><![CDATA[(without Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024 |<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024 |<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x8a T:0xf0 O:1234 ET=21 QB2:9/1/1024 [[MAX_PAYLOADS_SET has been received]] | [[MAX_PAYLOADS_SET acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024 |<---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024 | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024 [[MAX_PAYLOADS_SET has been received]] | [[MAX_PAYLOADS_SET acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024 |<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024 [[Body has been received]] | ... | ]]></artwork></figure></t></figure> </section> <sectiontitle="Handlingnumbered="true" toc="default"> <name>Handling MAX_PAYLOADS withRecovery">Recovery</name> <t><xreftarget="nonb41"></xref>target="nonb41" format="default"/> showsthean example of an Observe that is triggered but for which some notification blocks are lost. The client detects the missing blocks and requests their retransmission. It does so by indicating the blocks that are missing as one or more Q-Block2Options.</t> <t><figure anchor="nonb41" title="Exampleoptions.</t> <figure anchor="nonb41"> <name>Example of NON Notifications with the Q-Block2 Option(Blocks Recovery)"> <artwork><![CDATA[(Block Recovery)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024 | X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]] | X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024 [[Some of the MAX_PAYLOADS_SEThavehas been received]] | ... | [[NON_TIMEOUT_RANDOM (server) delay expires]] | [[Server sends nextMAX_PAYLOAD_SET]]MAX_PAYLOADS_SET]] |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024 | [[On seeing a payload from the nextMAX_PAYLOAD_SET,MAX_PAYLOADS_SET, |Clientclient realizes blocks are missing and asks for the | missing ones in one go]] +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\ | | QB2:9/0/1024 | X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] | [[Client realizes block is still missing and asks for | missing block]] +--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024 |<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024 [[Body has been received]] | ... | ]]></artwork></figure></t></figure> </section> <section anchor="sec-nonb411"title="Handlingnumbered="true" toc="default"> <name>Handling Recoveryusing M-bit Set">by Setting the M Bit</name> <t><xreftarget="nonb411"></xref>target="nonb411" format="default"/> showsthean exampleofwhere an Observethatis triggered but only the first two notification blocks reach the client. In order to retrieve the missing blocks, the client sends a request with a single Q-Block2Optionoption with the M bit set.</t><t><figure anchor="nonb411" title="Example<figure anchor="nonb411"> <name>Example of NON Notifications with the Q-Block2 Option(Blocks(Block Recovery with the Mbit Set)"> <artwork><![CDATA[Bit Set)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024 |<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024 | X<---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024 | X<---+ [[Payloads 4 - 9 not detailed]] | X<---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024 [[Some of the MAX_PAYLOADS_SEThavehas been received]] | ... | [[NON_TIMEOUT_RANDOM (server) delay expires]] | [[Server sends nextMAX_PAYLOAD_SET]]MAX_PAYLOADS_SET]] | X<---+ NON 2.05 M:0xba T:0xf0 O:1237 ET=24 QB2:10/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] | [[Client realizes blocks are missing and asks for the | missing ones in one go by setting the M bit]] +--------->| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024 |<---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024 [[MAX_PAYLOADS_SET has been received]] | [[MAX_PAYLOADS_SET acknowledged by client using 'Continue' | Q-Block2]] +--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024 |<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024 [[Body has been received]] | ... | ]]></artwork></figure></t></figure> </section> </section> <sectiontitle="Q-Block1numbered="true" toc="default"> <name>Q-Block1 and Q-Block2Options">Options</name> <sectiontitle="Anumbered="true" toc="default"> <name>A SimpleExample">Example</name> <t><xreftarget="b12non"></xref>target="b12non" format="default"/> illustratesthean example of a FETCH using both the Q-Block1 and Q-Block2Optionsoptions along with an ObserveOption.option. No loss is experienced.</t><t><figure anchor="b12non" title="Example<figure anchor="b12non"> <name>Example of a NON FETCH with the Q-Block1 and Q-Block2 Options(Without Loss)"> <artwork><![CDATA[(without Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024 +--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024 +--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024 |<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024 |<---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024 |<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024 |<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024 | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024 |<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024 |<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024 |<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024 | ... | ]]></artwork></figure></t></figure> </section> <sectiontitle="Handlingnumbered="true" toc="default"> <name>Handling MAX_PAYLOADSLimits">Limits</name> <t><xreftarget="b12non0"></xref>target="b12non0" format="default"/> illustrates the same scenario as <xreftarget="b12non"></xref>target="b12non" format="default"/>, but this timehaswith eleven (11) payloads in bothdirectionsdirections, which exceeds MAX_PAYLOADS. There is no loss experienced.</t><t><figure anchor="b12non0" title="Example<figure anchor="b12non0"> <name>Example of a NON FETCH with the Q-Block1 and Q-Block2 Options(Without Loss)"> <artwork><![CDATA[(without Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024 +--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024 +--------->| [[Payloads 3 - 9 not detailed]] +--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024 [[MAX_PAYLOADS_SET has been received]] | [[MAX_PAYLOADS_SET acknowledged by server]] |<---------+ NON 2.31 M:0x80 T:0xa9 +--------->| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024 |<---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024 |<---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x8a T:0xaa O:1334 ET=21 QB2:9/1/1024 [[MAX_PAYLOADS_SET has been received]] | [[MAX_PAYLOADS_SET acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024 |<---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024 | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024 |<---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024 |<---------+ [[Payloads 3 - 9 not detailed]] |<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024 [[MAX_PAYLOADS_SET has been received]] | [[MAX_PAYLOADS_SET acknowledged by client using | 'Continue' Q-Block2]] +--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024 |<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024 [[Body has been received]] | ... | ]]></artwork></figure></t></figure> <t>Notethatthat, as 'Continue' was used, the server continues to use the same token(0xaa)(0xaa), since the 'Continue' is not being used as a request for a new set ofpackets,packets but rather is being used to instruct the server to continue its transmission (<xreftarget="cc-non"></xref>).</t>target="cc-non" format="default"/>).</t> </section> <sectiontitle="Handling Recovery">numbered="true" toc="default"> <name>Handling Recovery</name> <t>Consider now a scenario where some blocks are lost intransmissiontransmission, as illustrated in <xreftarget="b12non1"></xref>.</t> <t><figure anchor="b12non1" title="Exampletarget="b12non1" format="default"/>.</t> <figure anchor="b12non1"> <name>Example of a NON FETCH with the Q-Block1 and Q-Block2 Options(With Loss)"> <artwork><![CDATA[(with Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024 +--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024 +--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024 +--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (server) delay expires]] ]]></artwork></figure></t></figure> <t>The server realizes that some blocks are missing and asks for the missing blocks in one go (<xreftarget="b12non2"></xref>).target="b12non2" format="default"/>). It does so by indicating which blocks have not been received in the data portion of the response. The token used in the response is the token that was used in the last received payload. The client can then derive the Request-Tag by matching the token with the sent request.</t><t><figure anchor="b12non2" title="Example<figure anchor="b12non2"> <name>Example of a NON Request with the Q-Block1 Option (ServerRecovery)"> <artwork><![CDATA[Recovery)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | |<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2] | [[Client responds with missing payloads]] +--------->| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024 +--------->| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024 | [[Server received FETCH body, | starts transmitting response body]] |<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024 | X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024 | X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] | | ]]></artwork></figure></t></figure> <t>The client realizes that not all the payloads of the response have been returned. The client then asks for the missing blocks in one go (<xreftarget="b12non3"></xref>).target="b12non3" format="default"/>). Note that, followingSection 2.7 of<xreftarget="RFC7959"></xref>,target="RFC7959" section="2.7" sectionFormat="of" format="default"/>, the FETCH request does not include the Q-Block1 or any payload.</t><t><figure anchor="b12non3" title="Example<figure anchor="b12non3"> <name>Example of a NON Request with the Q-Block1 Option (ClientRecovery)"> <artwork><![CDATA[Recovery)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\ | | QB2:3/0/1024 | [[Server receives FETCH request for missing payloads, | starts transmitting missing blocks]] | X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024 |<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024 | ... | [[NON_RECEIVE_TIMEOUT (client) delay expires]] | [[Client realizes block is still missing and asks for | missing block]] +--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024 | [[Server receives FETCH request for missing payload, | starts transmitting missing block]] |<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024 [[Body has been received]] | ... | | [[Observe triggered]] |<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024 | X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024 |<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024 [[NON_RECEIVE_TIMEOUT (client) delay expires]] | [[Client realizes block is still missing and asks for | missing block]] +--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024 | [[Server receives FETCH request for missing payload, | starts transmitting missing block]] |<---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024 [[Body has been received]] | ... | ]]></artwork></figure></t></figure> </section> </section> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>Security considerations discussed inSection 7 of<xreftarget="RFC7959"></xref>target="RFC7959" section="7" sectionFormat="of" format="default"/> should be taken into account.</t> <t>Security considerations discussed in Sections11.3<xref target="RFC7252" section="11.3" sectionFormat="bare"/> and11.4<xref target="RFC7252" section="11.4" sectionFormat="bare"/> of <xreftarget="RFC7252"></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 required for proxy operations and requires that a security context is set up(Section 3.1 of <xref target="RFC8613"></xref>).(<xref target="RFC8613" section="3.1" sectionFormat="of" format="default"/>). It can be trusted that the source endpoint is legitimate even if the NoSecsecuritymode is used. However, an intermediary node can modify the unprotectedouterOuter Q-Block1 and/or Q-Block2Optionsoptions to cause a Q-Block transfer to fail or keep requesting all the blocks by setting the M bitand, thus,and thus causing attack amplification. As discussed inSection 12.1 of<xreftarget="RFC8613"></xref>,target="RFC8613" section="12.1" sectionFormat="of" format="default"/>, applications need to consider that certain message fields andmessagesmessage types are not protectedend-to-endend to end and may be spoofed or manipulated. Therefore, it isNOT RECOMMENDED<bcp14>NOT RECOMMENDED</bcp14> to use the NoSecsecuritymode if either the Q-Block1 or Q-Block2Optionsoption is used.</t> <t>If OSCORE is not used, it is alsoNOT RECOMMENDED<bcp14>NOT RECOMMENDED</bcp14> to use the NoSecsecuritymode if either the Q-Block1 or Q-Block2Optionsoption is used.</t> <t>If NoSec is being used,Section D.5 of<xreftarget="RFC8613"></xref>target="RFC8613" section="D.5" sectionFormat="of" format="default"/> discusses the security analysis and considerations for unprotected message fields even if OSCORE is not being used.</t> <t>Security considerations related to the use of Request-Tag are discussed inSection 5 of<xreftarget="I-D.ietf-core-echo-request-tag"></xref>.</t>target="RFC9175" section="5" sectionFormat="of" format="default"/>.</t> </section> <section anchor="IANA"title="IANA Considerations"> <t><list style="hanging"> <t hangText="RFC Editor Note:">Please replace [RFCXXXX] with the RFC number to be assigned to this document.</t> </list></t>numbered="true" toc="default"> <name>IANA Considerations</name> <sectiontitle="CoAPnumbered="true" toc="default"> <name>CoAP Option NumbersRegistry">Registry</name> <t>IANAis requested to addhas added the following entries to the "CoAP Option Numbers"sub-registrysubregistry <xreftarget="Options"></xref>target="IANA-Options" format="default"/> defined in <xreftarget="RFC7252"></xref>target="RFC7252" format="default"/> within the "Constrained RESTful Environments (CoRE) Parameters" registry:</t><t><figure<table align="center"><artwork align="center"><![CDATA[+--------+------------------+-----------+ | Number | Name | Reference | +========+==================+===========+ | TBA1 | Q-Block1 | [RFCXXXX] | | TBA2 | Q-Block2 | [RFCXXXX] | +--------+------------------+-----------+ Table 4:<name>Additions to CoAPQ-Block1 and Q-Block2OptionNumbers]]></artwork> </figure></t> <t>This document suggests 19 (TBA1) and 31 (TBA2) as values to be assigned for the new option numbers.</t>Numbers Registry</name> <thead> <tr> <th>Number</th> <th>Name</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>19</td> <td>Q-Block1</td> <td>RFC 9177</td> </tr> <tr> <td>31</td> <td>Q-Block2</td> <td>RFC 9177</td> </tr> </tbody> </table> </section> <sectiontitle="Medianumbered="true" toc="default"> <name>Media TypeRegistration"> <t>This document requests IANA to registerRegistration</name> <t>IANA has registered the "application/missing-blocks+cbor-seq" media type in the "Media Types" registry <xreftarget="IANA-MediaTypes"></xref>.target="IANA-MediaTypes" format="default"/>. This registration follows the procedures specified in <xreftarget="RFC6838"></xref>: <figure> <artwork><![CDATA[ Type name: application Subtype name: missing-blocks+cbor-seq Required parameters: N/A Optional parameters: N/A Encoding considerations: Musttarget="RFC6838" format="default"/>. </t> <dl newline="false" spacing="normal"> <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 CBORsequence [RFC8742],Sequence <xref target="RFC8742" format="default"/>, as defined inSection 4<xref target="code" format="default"/> of[RFCXXXX]. Security considerations: See Section 10RFC 9177.</dd> <dt>Security considerations:</dt> <dd>See <xref target="security" format="default"/> of[RFCXXXX]. Interoperability considerations: N/A Published specification: [RFCXXXX] ApplicationsRFC 9177.</dd> <dt>Interoperability considerations:</dt> <dd>N/A</dd> <dt>Published specification:</dt> <dd>RFC 9177</dd> <dt>Applications that use this mediatype: Datatype:</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 requestfortheir retransmission, as defined inSection 4<xref target="spec" format="default"/> of[RFCXXXX]. FragmentRFC 9177.</dd> <dt>Fragment identifierconsiderations: N/A Additional information: N/A Person &considerations:</dt> <dd>N/A</dd> <dt>Additional information:</dt> <dd>N/A</dd> <dt>Person & email address to contact for furtherinformation: IETF, iesg@ietf.org Intended usage: COMMON Restrictionsinformation:</dt> <dd>IETF, iesg&zwsp;@&zwsp;ietf.org</dd> <dt>Intended usage:</dt> <dd>COMMON</dd> <dt>Restrictions onusage: none Author: Seeusage:</dt> <dd>none</dd> <dt>Author:</dt> <dd>See Authors' Addressessection. Change controller: IESG Provisional registration? No]]></artwork> </figure></t>section of RFC 9177.</dd> <dt>Change controller:</dt> <dd>IESG</dd> <dt>Provisional registration?</dt> <dd>No</dd> </dl> </section> <section anchor="new-format"title="CoAPnumbered="true" toc="default"> <name>CoAP Content-FormatsRegistry"> <t>This document requests IANA to registerRegistry</name> <t>IANA has registered the following CoAP Content-Format for the "application/missing-blocks+cbor-seq" media type in the "CoAP Content-Formats" registry <xreftarget="Format"></xref>,target="IANA-Format" format="default"/> defined in <xreftarget="RFC7252"></xref>,target="RFC7252" format="default"/> within the "Constrained RESTful Environments (CoRE) Parameters" registry:</t><figure> <artwork><![CDATA[o Media Type: application/missing-blocks+cbor-seq o Encoding: - o Id: TBA3 o Reference: [RFCXXXX]]]></artwork> </figure> <t>This document suggests 272 (TBA3) as a value<table align="center"> <name>Addition tobe assigned for the new content format number.</t>CoAP Content-Format Registry</name> <thead> <tr> <th>Media Type</th> <th>Encoding</th> <th>ID</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>application/missing-blocks+cbor-seq</td> <td>-</td> <td>272</td> <td>RFC 9177</td> </tr> </tbody> </table> </section> </section> </middle> <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'?> <?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'?><displayreference target="I-D.bosh-dots-quick-blocks" to="DOTS-QUICK-BLOCKS"/> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6838.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8075.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8132.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8742.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <!-- draft-ietf-core-echo-request-tag (RFC 9175) --> <reference anchor='RFC9175' target="https://www.rfc-editor.org/info/rfc9175"> <front> <title>Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing</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> </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>Informative References</name> <!-- draft-ietf-dots-telemetry (IESG state Publication Requested) LB: Two editors, so had to do "long way" --> <referenceanchor="Format" target="https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#content-formats">anchor="DOTS-TELEMETRY"> <front> <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry</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> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8974.xml"/> <!-- [I-D.bosh-dots-quick-blocks] IESG state I-D Exists --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.bosh-dots-quick-blocks.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6928.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9132.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7967.xml"/> <reference anchor="IANA-Format" target="https://www.iana.org/assignments/core-parameters/"> <front> <title>CoAP Content-Formats</title> <author><organization></organization><organization>IANA</organization> </author><date /></front> </reference> <referenceanchor="Options" target="https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers">anchor="IANA-Options" target="https://www.iana.org/assignments/core-parameters/"> <front> <title>CoAP Option Numbers</title> <author><organization></organization><organization>IANA</organization> </author><date /></front> </reference> <reference anchor="IANA-MediaTypes"target="https://www.iana.org/assignments/media-types">target="https://www.iana.org/assignments/media-types/"> <front> <title>Media Types</title><author fullname="IANA"> <organization></organization><author> <organization>IANA</organization> </author><date /></front> </reference> </references> </references> <section anchor="CON"title="Examplesnumbered="true" toc="default"> <name>Examples with ConfirmableMessages">Messages</name> <t>The following examples assume NSTART has been increased to 3.</t> <t>Thenotationsconventions provided in <xreftarget="legend"></xref>target="non-confirm" format="default"/> are used in the following subsections.</t> <sectiontitle="Q-Block1 Option">numbered="true" toc="default"> <name>Q-Block1 Option</name> <t>Let's now consider the use of the Q-Block1Optionoption with a CONrequestrequest, as shown in <xreftarget="con3"></xref>.target="con3" format="default"/>. All the blocks are acknowledged(ACK).</t> <t><figure anchor="con3" title="Example(as noted with "ACK").</t> <figure anchor="con3"> <name>Example of a CON Request with the Q-Block1 Option(Without Loss)"> <artwork><![CDATA[(without Loss)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024 +--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024 +--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024 [[NSTART(3) limit reached]] |<---------+ ACK 0.00 M:0x01 +--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024 |<---------+ ACK 0.00 M:0x02 |<---------+ ACK 0.00 M:0x03 |<---------+ ACK 2.04 M:0x04 | | ]]></artwork></figure></t></figure> <t>Now, suppose that a new body of data is to be sent but with some blocks dropped intransmissiontransmission, as illustrated in <xreftarget="con32"></xref>.target="con32" format="default"/>. The client will retry sending blocks for which no ACK was received.</t><t><figure anchor="con32" title="Example<figure anchor="con32"> <name>Example of a CON Request with the Q-Block1 Option(Blocks Recovery)"> <artwork><![CDATA[(Block Recovery)</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024 +--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 [[NSTART(3) limit reached]] |<---------+ ACK 0.00 M:0x05 +--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024 |<---------+ ACK 0.00 M:0x08 | ... | [[ACK TIMEOUT (client) for M:0x06 delay expires]] | [[Client retransmits packet]] +--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024 [[ACK TIMEOUT (client) for M:0x07 delay expires]] | [[Client retransmits packet]] +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 |<---------+ ACK 0.00 M:0x06 | ... | [[ACK TIMEOUT exponential backoff (client) delay expires]] | [[Client retransmits packet]] +--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024 | ... | [[Either body transmission failure (acknowledge retry timeout) or successfullytransmitted.]]transmitted]] ]]></artwork></figure></t></figure> <t>It is up to the implementation as to whether the application process stops trying to send this particular body of data on reaching MAX_RETRANSMIT for anypayload,payload or separately tries to initiate the new transmission of the payloads that have not been acknowledged under these adverse traffic conditions.</t> <t>Ifthere is likely to be the possibility oftransient networklosses,losses are possible, then the use of NON should be considered.</t> </section> <sectiontitle="Q-Block2 Option">numbered="true" toc="default"> <name>Q-Block2 Option</name> <t>An example of the use of the Q-Block2Optionoption with Confirmable messages is shown in <xreftarget="b4con"></xref>.</t> <t><figure align="center" anchor="b4con" title="Exampletarget="b4con" format="default"/>.</t> <figure anchor="b4con"> <name>Example of CON Notifications with the Q-Block2Option">Option</name> <artworkalign="center"><![CDATA[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 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ CON 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024 |<---------+ CON 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024 |--------->+ ACK 0.00 M:0xe1 |--------->+ ACK 0.00 M:0xe2 |--------->+ ACK 0.00 M:0xe3 | ... | | [[Observe triggered]] |<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024 [[NSTART(3) limit reached]] |--------->+ ACK 0.00 M:0xe4 |<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024 |--------->+ ACK 0.00 M:0xe5 |--------->+ ACK 0.00 M:0xe6 |--------->+ ACK 0.00 M:0xe7 | ... | | [[Observe triggered]] |<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024 | X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 [[NSTART(3) limit reached]] |--------->+ ACK 0.00 M:0xe8 |<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024 |--------->+ ACK 0.00 M:0xeb | ... | [[ACK TIMEOUT (server) for M:0xe9 delay expires]] | [[Server retransmits packet]] |<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024 [[ACK TIMEOUT (server) for M:0xea delay expires]] | [[Server retransmits packet]] | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 |--------->+ ACK 0.00 M:0xe9 | ... | [[ACK TIMEOUT exponential backoff (server) delay expires]] | [[Server retransmits packet]] | X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024 | ... | [[Either body transmission failure (acknowledge retry timeout) or successfullytransmitted.]]transmitted]] ]]></artwork></figure></t></figure> <t>It is up to the implementation as to whether the application process stops trying to send this particular body of data on reaching MAX_RETRANSMIT for anypayload,payload or separately tries to initiate the new transmission of the payloads that have not been acknowledged under these adverse traffic conditions.</t> <t>Ifthere is likely to be the possibility oftransient networklosses,losses are possible, then the use of NON should be considered.</t> </section> </section> <section anchor="REL"title="Examplesnumbered="true" toc="default"> <name>Examples with ReliableTransports">Transports</name> <t>Thenotationsconventions provided in <xreftarget="legend"></xref>target="non-confirm" format="default"/> are used in the following subsections.</t> <sectiontitle="Q-Block1 Option">numbered="true" toc="default"> <name>Q-Block1 Option</name> <t>Let's now consider the use of the Q-Block1Optionoption with a reliabletransporttransport, as shown in <xreftarget="rel3"></xref>.target="rel3" format="default"/>. There is no acknowledgment of packets at the CoAP layer, just the final result.</t><t><figure anchor="rel3" title="Example<figure anchor="rel3"> <name>Example of a Reliable Request with the Q-Block1Option"> <artwork><![CDATA[Option</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ CoAP CoAP Client Server | | +--------->| PUT /path T:0xf0 RT=10 QB1:0/1/1024 +--------->| PUT /path T:0xf1 RT=10 QB1:1/1/1024 +--------->| PUT /path T:0xf2 RT=10 QB1:2/1/1024 +--------->| PUT /path T:0xf3 RT=10 QB1:3/0/1024 |<---------+ 2.04 | | ]]></artwork></figure></t></figure> <t>Ifthere is likely to be the possibility oftransient networklosses,losses are possible, then the use of unreliable transport with NON should be considered.</t> </section> <sectiontitle="Q-Block2 Option">numbered="true" toc="default"> <name>Q-Block2 Option</name> <t>An example of the use of the Q-Block2Optionoption with a reliable transport is shown in <xreftarget="b4rel"></xref>.</t> <t><figure align="center" anchor="b4rel" title="Exampletarget="b4rel" format="default"/>.</t> <figure anchor="b4rel"> <name>Example of Notifications with the Q-Block2Option">Option</name> <artworkalign="center"><![CDATA[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 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:1/1/1024 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:2/1/1024 |<---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024 | ... | | [[Observe triggered]] |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:0/1/1024 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:1/1/1024 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:2/1/1024 |<---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:3/0/1024 | ... | ]]></artwork></figure></t></figure> <t>Ifthere is likely to be the possibility of networktransientlosses,network losses are possible, then the use of unreliable transport with NON should be considered.</t> </section> </section> <section numbered="false"title="Acknowledgements"toc="default"> <name>Acknowledgments</name> <t>Thanks toAchim Kraus, Jim Schaad, and Michael Richardson<contact fullname="Achim Kraus"/>, <contact fullname="Jim Schaad"/>, and <contact fullname="Michael Richardson"/> for their comments.</t> <t>Special thanks toChristian Amsüss, Carsten Bormann, and Marco Tiloca<contact fullname="Christian Amsüss"/>, <contact fullname="Carsten Bormann"/>, and <contact fullname="Marco Tiloca"/> for their suggestions and several reviews, which improved this specification significantly. Thanks toFrancesca Palombini<contact fullname="Francesca Palombini"/> for the AD review.<vspace blankLines="1" />ThanksThanks toPete Resnick<contact fullname="Pete Resnick"/> for the Gen-ART review,Colin Perkins<contact fullname="Colin Perkins"/> for theTsvartTSVART review, andEmmanuel Baccelli<contact fullname="Emmanuel Baccelli"/> for theIotdirIOT-DIR review. Thanks toMartin Duke, Eric Vyncke, Benjamin Kaduk, Roman Danyliw, John Scudder, and Lars Eggert<contact fullname="Martin Duke"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Benjamin Kaduk"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="John Scudder"/>, and <contact fullname="Lars Eggert"/> for the IESG review.</t> <t>Some text from <xref target="RFC7959"/>format="default"/> is reused forreadersthe readers' convenience.</t> </section> </back> </rfc>