File: rfc9177.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (3863 lines) | stat: -rw-r--r-- 211,643 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9177: Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission</title>
<meta content="Mohamed Boucadair" name="author">
<meta content="Jon Shallow" name="author">
<meta content="
       This document specifies alternative Constrained Application Protocol
      (CoAP) block-wise transfer options: Q-Block1 and Q-Block2. 
       These options are similar to, but distinct from, the CoAP Block1 and
      Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are
      not intended to replace the Block1 and Block2 options but rather have the
      goal of supporting Non-confirmable (NON) messages for large amounts of data
      with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options
      support faster recovery should any of the blocks get lost in
      transmission. 
    " name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="Quick-Block" name="keyword">
<meta content="Robust-Block" name="keyword">
<meta content="R-Block" name="keyword">
<meta content="Tough-Block" name="keyword">
<meta content="Resilient-Block" name="keyword">
<meta content="Fast-Block" name="keyword">
<meta content="Resilience" name="keyword">
<meta content="Filtering" name="keyword">
<meta content="Faster transmission" name="keyword">
<meta content="Large amounts of data" name="keyword">
<meta content="Less packet interchange" name="keyword">
<meta content="Fast recovery" name="keyword">
<meta content="DOTS" name="keyword">
<meta content="9177" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.2
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9177.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9177" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-core-new-block-14" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9177</td>
<td class="center">Quick Block-Wise Transfer Options</td>
<td class="right">March 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Boucadair &amp; Shallow</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9177" class="eref">9177</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-03" class="published">March 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Boucadair</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">J. Shallow</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9177</h1>
<h1 id="title">Constrained Application Protocol (CoAP) Block-Wise Transfer Options Supporting Robust Transmission</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document specifies alternative Constrained Application Protocol
      (CoAP) block-wise transfer options: Q-Block1 and Q-Block2.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">These options are similar to, but distinct from, the CoAP Block1 and
      Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are
      not intended to replace the Block1 and Block2 options but rather have the
      goal of supporting Non-confirmable (NON) messages for large amounts of data
      with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options
      support faster recovery should any of the blocks get lost in
      transmission.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9177">https://www.rfc-editor.org/info/rfc9177</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-alternative-coap-block-wise" class="xref">Alternative CoAP Block-Wise Transfer Options</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-coap-response-code-408-usag" class="xref">CoAP Response Code (4.08) Usage</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-applicability-scope" class="xref">Applicability Scope</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-the-q-block1-and-q-block2-o" class="xref">The Q-Block1 and Q-Block2 Options</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-properties-of-the-q-block1-" class="xref">Properties of the Q-Block1 and Q-Block2 Options</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-structure-of-the-q-block1-a" class="xref">Structure of the Q-Block1 and Q-Block2 Options</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-using-the-q-block1-option" class="xref">Using the Q-Block1 Option</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-using-the-q-block2-option" class="xref">Using the Q-Block2 Option</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-using-the-observe-option" class="xref">Using the Observe Option</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-using-the-size1-and-size2-o" class="xref">Using the Size1 and Size2 Options</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-using-the-q-block1-and-q-bl" class="xref">Using the Q-Block1 and Q-Block2 Options Together</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.8">
                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="xref">4.8</a>.  <a href="#name-using-the-q-block2-option-w" class="xref">Using the Q-Block2 Option with Multicast</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-the-use-of-the-408-request-" class="xref">The Use of the 4.08 (Request Entity Incomplete) Response Code</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-the-use-of-tokens" class="xref">The Use of Tokens</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-congestion-control-for-unre" class="xref">Congestion Control for Unreliable Transports</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-confirmable-con" class="xref">Confirmable (CON)</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-non-confirmable-non" class="xref">Non-confirmable (NON)</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-caching-considerations" class="xref">Caching Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-http-mapping-considerations" class="xref">HTTP Mapping Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-examples-with-non-confirmab" class="xref">Examples with Non-confirmable Messages</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-q-block1-option" class="xref">Q-Block1 Option</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1.2.1">
                    <p id="section-toc.1-1.10.2.1.2.1.1"><a href="#section-10.1.1" class="xref">10.1.1</a>.  <a href="#name-a-simple-example" class="xref">A Simple Example</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1.2.2">
                    <p id="section-toc.1-1.10.2.1.2.2.1"><a href="#section-10.1.2" class="xref">10.1.2</a>.  <a href="#name-handling-max_payloads-limit" class="xref">Handling MAX_PAYLOADS Limits</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1.2.3">
                    <p id="section-toc.1-1.10.2.1.2.3.1"><a href="#section-10.1.3" class="xref">10.1.3</a>.  <a href="#name-handling-max_payloads-with-" class="xref">Handling MAX_PAYLOADS with Recovery</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1.2.4">
                    <p id="section-toc.1-1.10.2.1.2.4.1"><a href="#section-10.1.4" class="xref">10.1.4</a>.  <a href="#name-handling-recovery-if-failur" class="xref">Handling Recovery if Failure Occurs</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-q-block2-option" class="xref">Q-Block2 Option</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.1">
                    <p id="section-toc.1-1.10.2.2.2.1.1"><a href="#section-10.2.1" class="xref">10.2.1</a>.  <a href="#name-a-simple-example-2" class="xref">A Simple Example</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.2">
                    <p id="section-toc.1-1.10.2.2.2.2.1"><a href="#section-10.2.2" class="xref">10.2.2</a>.  <a href="#name-handling-max_payloads-limits" class="xref">Handling MAX_PAYLOADS Limits</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.3">
                    <p id="section-toc.1-1.10.2.2.2.3.1"><a href="#section-10.2.3" class="xref">10.2.3</a>.  <a href="#name-handling-max_payloads-with-r" class="xref">Handling MAX_PAYLOADS with Recovery</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.4">
                    <p id="section-toc.1-1.10.2.2.2.4.1"><a href="#section-10.2.4" class="xref">10.2.4</a>.  <a href="#name-handling-recovery-by-settin" class="xref">Handling Recovery by Setting the M Bit</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-q-block1-and-q-block2-optio" class="xref">Q-Block1 and Q-Block2 Options</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3.2.1">
                    <p id="section-toc.1-1.10.2.3.2.1.1"><a href="#section-10.3.1" class="xref">10.3.1</a>.  <a href="#name-a-simple-example-3" class="xref">A Simple Example</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3.2.2">
                    <p id="section-toc.1-1.10.2.3.2.2.1"><a href="#section-10.3.2" class="xref">10.3.2</a>.  <a href="#name-handling-max_payloads-limits-2" class="xref">Handling MAX_PAYLOADS Limits</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3.2.3">
                    <p id="section-toc.1-1.10.2.3.2.3.1"><a href="#section-10.3.3" class="xref">10.3.3</a>.  <a href="#name-handling-recovery" class="xref">Handling Recovery</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-coap-option-numbers-registr" class="xref">CoAP Option Numbers Registry</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-media-type-registration" class="xref">Media Type Registration</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.3">
                <p id="section-toc.1-1.12.2.3.1"><a href="#section-12.3" class="xref">12.3</a>.  <a href="#name-coap-content-formats-regist" class="xref">CoAP Content-Formats Registry</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.1">
                <p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="xref">13.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.2">
                <p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="xref">13.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-examples-with-confirmable-m" class="xref">Examples with Confirmable Messages</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.1">
                <p id="section-toc.1-1.14.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-q-block1-option-2" class="xref">Q-Block1 Option</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14.2.2">
                <p id="section-toc.1-1.14.2.2.1"><a href="#appendix-A.2" class="xref">A.2</a>.  <a href="#name-q-block2-option-2" class="xref">Q-Block2 Option</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-examples-with-reliable-tran" class="xref">Examples with Reliable Transports</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.1">
                <p id="section-toc.1-1.15.2.1.1"><a href="#appendix-B.1" class="xref">B.1</a>.  <a href="#name-q-block1-option-3" class="xref">Q-Block1 Option</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15.2.2">
                <p id="section-toc.1-1.15.2.2.1"><a href="#appendix-B.2" class="xref">B.2</a>.  <a href="#name-q-block2-option-3" class="xref">Q-Block2 Option</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#appendix-C" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#appendix-D" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">The Constrained Application Protocol (CoAP) <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, 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 (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-1.2" class="relref">Section 1.2</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>): Confirmable (CON) and Non-confirmable (NON). Unlike NON
      messages, every CON message will elicit an acknowledgment or a reset.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">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, <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span> introduced the concept of block-wise transfers
      and the companion CoAP Block1 and Block2 options. However, this concept
      is designed to work exclusively with Confirmable messages (<span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-1" class="relref">Section 1</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>).
 Note that the block-wise transfer was
      further updated by <span>[<a href="#RFC8323" class="xref">RFC8323</a>]</span> for use over TCP, TLS,
      and WebSockets.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">The CoAP Block1 and Block2 options work well in environments where
      there are no, or minimal, packet losses. These options operate
      synchronously, i.e., each individual block has to be requested. A CoAP
      endpoint can only ask for (or send) the next block when the transfer of
      the previous block has completed. The packet transmission rate, and hence
      the block transmission rate, is controlled by Round-Trip Times (RTTs).<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">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., <span>[<a href="#RFC9132" class="xref">RFC9132</a>]</span> <span>[<a href="#DOTS-TELEMETRY" class="xref">DOTS-TELEMETRY</a>]</span>).
      As a reminder, <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span> recommends the use of CON responses to handle potential packet loss. However, such a
      recommendation does not work with a "flooded pipe" DDoS situation (e.g.,
      <span>[<a href="#RFC9132" class="xref">RFC9132</a>]</span>).<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">This document introduces the CoAP Q-Block1 and Q-Block2 options, which
      allow block-wise transfers to work with a series of Non-confirmable
      messages instead of lock-stepping using Confirmable messages (<a href="#alt" class="xref">Section 3</a>).
      In other words, this document provides a missing
      piece of <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>, namely the support of
      block-wise transfers using Non-confirmable messages where an entire body of data
      can be transmitted without the requirement that intermediate
      acknowledgments be received from the peer (but recovery is available
      should it be needed).<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Similar to <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>, this specification does
      not remove any of the constraints posed by the base CoAP specification
      <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> it is strictly layered on top of.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="notation">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">Readers should be familiar with the terms and concepts defined in
      <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>, <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>, and
      <span>[<a href="#RFC8132" class="xref">RFC8132</a>]</span>. Particularly, the document uses the
      following key concepts:<a href="#section-2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-3">
        <dt id="section-2-3.1">Token:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.2">used to match responses to requests
        independently from the underlying messages (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.3.1" class="relref">Section 5.3.1</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-2-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-3.3">ETag:</dt>
        <dd style="margin-left: 1.5em" id="section-2-3.4">used as a resource-local identifier for
          differentiating between representations of the same resource that
          vary over time (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.10.6" class="relref">Section 5.10.6</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-2-3.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-4">The terms "payload" and "body" are defined in <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>. 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.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">Request-Tag refers to an option that allows a CoAP server to match
      message fragments belonging to the same request <span>[<a href="#RFC9175" class="xref">RFC9175</a>]</span>.<a href="#section-2-5" class="pilcrow">¶</a></p>
<p id="section-2-6">MAX_PAYLOADS is the maximum number of payloads that can be
      transmitted at any one time.<a href="#section-2-6" class="pilcrow">¶</a></p>
<p id="section-2-7">MAX_PAYLOADS_SET is the set of blocks identified by block numbers
      that, when divided by MAX_PAYLOADS, have the same numeric result. For
      example, if MAX_PAYLOADS is set to 10, a MAX_PAYLOADS_SET could be
      blocks #0 to #9, #10 to #19, etc.
      Depending on the overall data size,
      there could be fewer than MAX_PAYLOADS blocks in the final
      MAX_PAYLOADS_SET.<a href="#section-2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="alt">
<section id="section-3">
      <h2 id="name-alternative-coap-block-wise">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-alternative-coap-block-wise" class="section-name selfRef">Alternative CoAP Block-Wise Transfer Options</a>
      </h2>
<p id="section-3-1">This document introduces the CoAP Q-Block1 and Q-Block2 options.
      These options are designed to work in particular with NON requests and
      responses.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Using NON messages, faster transmissions can occur, as all the blocks
      can be transmitted serially (akin to fragmented IP packets) without
      having to wait for a response or next request from the remote CoAP peer.
      Recovery of missing blocks is faster in that multiple missing blocks can
      be requested in a single CoAP message. Even if there is asymmetrical
      packet loss, a body can still be sent and received by the peer whether
      the body comprises a single payload or multiple payloads, assuming no recovery
      is required.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">A CoAP endpoint can acknowledge all or a subset of the blocks.
      Concretely, the receiving CoAP endpoint either informs the sending CoAP 
      endpoint of successful reception or reports on all blocks in the body
      that have not yet been received. The sending CoAP endpoint will then
      retransmit only the blocks that have been lost in transmission.<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">Note that similar transmission rate benefits can be applied to
      Confirmable messages if the value of NSTART is increased from 1 (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>). However, the use of Confirmable
      messages will not work effectively if there is asymmetrical packet loss.
      Some examples with Confirmable messages are provided in <a href="#CON" class="xref">Appendix A</a>.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">There is little, if any, benefit of using these options with CoAP
      running over a reliable connection <span>[<a href="#RFC8323" class="xref">RFC8323</a>]</span>. In
      this case, there is no differentiation between CON and NON, as they are
      not used. Some examples using a reliable transport are provided in <a href="#REL" class="xref">Appendix B</a>.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">The Q-Block1 and Q-Block2 options are similar in operation to the CoAP
      Block1 and Block2 options, respectively. They are not a replacement for
      them but have the following benefits:<a href="#section-3-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-7.1">They can operate in environments where packet loss is highly
          asymmetrical.<a href="#section-3-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-7.2">They enable faster transmissions of sets of blocks of data with
          fewer packet interchanges.<a href="#section-3-7.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-7.3">They support faster recovery should any of the blocks get lost in
          transmission.<a href="#section-3-7.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-7.4">They support sending an entire body using NON messages without
          requiring that an intermediate response be received from the
          peer.<a href="#section-3-7.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-8">The disadvantages of using the CoAP Block1 and Block2 options are as follows:<a href="#section-3-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-9.1">There is a loss of lock-stepping, so payloads are not always received in the
          correct order (blocks in ascending order).<a href="#section-3-9.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-9.2">Additional congestion control measures need to be put in place
          for NON messages (<a href="#cc-non" class="xref">Section 7.2</a>).<a href="#section-3-9.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-9.3">To reduce the transmission times for CON transmissions of large
          bodies, NSTART needs to be increased from 1, but this affects
          congestion control and incurs a requirement to retune other
          parameters (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>). Such
          tuning is out of scope of this document.<a href="#section-3-9.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-9.4">Mixing of NON and CON during an exchange of requests/responses using
   Q-Block options is not supported.<a href="#section-3-9.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-9.5">The Q-Block options do not support stateless operation/random
          access.<a href="#section-3-9.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-9.6">Proxying of Q-Block options is limited to caching full
          representations.<a href="#section-3-9.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-9.7">There is no multicast support.<a href="#section-3-9.7" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-10">The Q-Block1 and Q-Block2 options can be used instead of the Block1 and
      Block2 options when the different transmission properties are required.
      If the new options are not supported by a peer, then transmissions can
      fall back to using the Block1 and Block2 options (<a href="#prop" class="xref">Section 4.1</a>).<a href="#section-3-10" class="pilcrow">¶</a></p>
<p id="section-3-11">The deviations from the Block1 and Block2 options are specified in <a href="#spec" class="xref">Section 4</a>. Pointers to the appropriate sections in <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span> are provided.<a href="#section-3-11" class="pilcrow">¶</a></p>
<p id="section-3-12">The specification refers to the base CoAP methods defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.8" class="relref">Section 5.8</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span> and the new
      CoAP methods, FETCH, PATCH, and iPATCH, which are introduced in <span>[<a href="#RFC8132" class="xref">RFC8132</a>]</span>.<a href="#section-3-12" class="pilcrow">¶</a></p>
<p id="section-3-13">The No-Response option <span>[<a href="#RFC7967" class="xref">RFC7967</a>]</span> was considered
      but was abandoned, as it does not apply to Q-Block2 responses. A unified
      solution is defined in the document.<a href="#section-3-13" class="pilcrow">¶</a></p>
<section id="section-3.1">
        <h3 id="name-coap-response-code-408-usag">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-coap-response-code-408-usag" class="section-name selfRef">CoAP Response Code (4.08) Usage</a>
        </h3>
<p id="section-3.1-1">This document adds a media type for the 4.08 (Request Entity
        Incomplete) response defining an additional message format for reporting on
        payloads using the Q-Block1 option that are not received by the server.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">See <a href="#code" class="xref">Section 5</a> for more details.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
</section>
<div id="scope">
<section id="section-3.2">
        <h3 id="name-applicability-scope">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-applicability-scope" class="section-name selfRef">Applicability Scope</a>
        </h3>
<p id="section-3.2-1">The block-wise transfer specified in <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>
        covers the general case using Confirmable messages but falls short in
        situations where packet loss is highly asymmetrical or there is no
        need for an acknowledgment. In other words, there is a need for
        Non-confirmable support.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">The mechanism specified in this document provides roughly similar
        features to the Block1/Block2 options. It provides additional
        properties that are tailored towards the intended use case of
        Non-confirmable transmission. Concretely, this mechanism primarily
        targets applications, such as DDoS Open Threat Signaling (DOTS), that
        cannot use CON requests/responses because of potential packet loss and
        that support application-specific mechanisms to assess whether the
        remote peer is not overloaded and thus is able to process the messages
        sent by a CoAP endpoint (e.g., DOTS heartbeats in <span><a href="https://www.rfc-editor.org/rfc/rfc9132#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC9132" class="xref">RFC9132</a>]</span>). Other use cases are when an application
        sends data but has no need for an acknowledgment of receipt and any
        data transmission loss is not critical.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">The mechanism includes guards to prevent a CoAP agent from
        overloading the network by adopting an aggressive sending rate. These
        guards <span class="bcp14">MUST</span> be followed in addition to the existing CoAP congestion
        control, as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>.
        See <a href="#cc" class="xref">Section 7</a> for more details.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">Any usage outside the primary use case of Non-confirmable messages with
        block transfers should be carefully weighed against the potential loss
        of interoperability with generic CoAP applications (see the
        disadvantages listed in <a href="#alt" class="xref">Section 3</a>). 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.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">It is not recommended that these options are used in the "NoSec"
        security mode (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-9" class="relref">Section 9</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>), as
 the source endpoint needs to be trusted. Using Object Security for Constrained
 RESTful Environments (OSCORE) <span>[<a href="#RFC8613" class="xref">RFC8613</a>]</span> does
 provide a security context and hence a
        trust of the source endpoint that prepared the inner OSCORE content.
        However, even with OSCORE, using the NoSec mode with these
        options may still be inadequate, for reasons discussed in <a href="#security" class="xref">Section 11</a>.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="spec">
<section id="section-4">
      <h2 id="name-the-q-block1-and-q-block2-o">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-the-q-block1-and-q-block2-o" class="section-name selfRef">The Q-Block1 and Q-Block2 Options</a>
      </h2>
<div id="prop">
<section id="section-4.1">
        <h3 id="name-properties-of-the-q-block1-">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-properties-of-the-q-block1-" class="section-name selfRef">Properties of the Q-Block1 and Q-Block2 Options</a>
        </h3>
<p id="section-4.1-1">The properties of the Q-Block1 and Q-Block2 options are shown in
        <a href="#coap" class="xref">Table 1</a>. The formatting of this table follows the
 one used in Table 4
        of <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.10" class="relref">Section 5.10</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>. The C, U, N, and R
        columns indicate the properties Critical, UnSafe, NoCacheKey, and
        Repeatable, which are  defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.4" class="relref">Section 5.4</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>.
        Only the Critical and UnSafe columns are marked for the Q-Block1 option.
        The Critical, UnSafe, and Repeatable columns are marked for the Q-Block2
        option. As these options are UnSafe, NoCacheKey has no meaning and so
        is marked with a dash.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<span id="name-coap-q-block1-and-q-block2-"></span><div id="coap">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-coap-q-block1-and-q-block2-" class="selfRef">CoAP Q-Block1 and Q-Block2 Option Properties</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">No.</th>
              <th class="text-left" rowspan="1" colspan="1">C</th>
              <th class="text-left" rowspan="1" colspan="1">U</th>
              <th class="text-left" rowspan="1" colspan="1">N</th>
              <th class="text-left" rowspan="1" colspan="1">R</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Format</th>
              <th class="text-left" rowspan="1" colspan="1">Length</th>
              <th class="text-left" rowspan="1" colspan="1">Default</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">19</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
              <td class="text-left" rowspan="1" colspan="1">Q-Block1</td>
              <td class="text-left" rowspan="1" colspan="1">uint</td>
              <td class="text-left" rowspan="1" colspan="1">0-3</td>
              <td class="text-left" rowspan="1" colspan="1">(none)</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">31</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">Q-Block2</td>
              <td class="text-left" rowspan="1" colspan="1">uint</td>
              <td class="text-left" rowspan="1" colspan="1">0-3</td>
              <td class="text-left" rowspan="1" colspan="1">(none)</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-4.1-3">The Q-Block1 and Q-Block2 options can be present in both the
        request and response messages. The Q-Block1 option pertains to the
        request payload, and the Q-Block2 option pertains to the response
        payload. When the Content-Format option is present together with the
        Q-Block1 or Q-Block2 option, the option applies to the body, not to the
        payload (i.e., it must be the same for all payloads of the same
        body).<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">The Q-Block1 option is useful with the payload-bearing (e.g., POST,
        PUT, FETCH, PATCH, and iPATCH) requests and their responses.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">The Q-Block2 option is useful, for example, with GET, POST, PUT, FETCH,
        PATCH, and iPATCH requests and their payload-bearing responses
        (response codes 2.01, 2.02, 2.04, and 2.05) (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.5" class="relref">Section 5.5</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1-6">A CoAP endpoint (or proxy) <span class="bcp14">MUST</span> support either both or neither of
        the Q-Block1 and Q-Block2 options.<a href="#section-4.1-6" class="pilcrow">¶</a></p>
<p id="section-4.1-7">If the Q-Block1 option is present in a request or the Q-Block2
        option is returned in a response, this indicates a block-wise transfer
        and describes how this specific block-wise payload forms part of the
        entire body being transferred. If it is present in the opposite
        direction, it provides additional control on how that payload will be
        formed or was processed.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1-8">To indicate support for Q-Block2 responses, the CoAP client <span class="bcp14">MUST</span>
        include the Q-Block2 option in a GET or similar request (e.g., FETCH), the
 Q-Block2 option in a PUT or similar request (e.g., POST), or the Q-Block1
 option in a PUT or similar request so that
        the server knows that the client supports this Q-Block functionality
        should it need to send back a body that spans multiple payloads.
        Otherwise, the server would use the Block2 option (if supported) to
        send back a message body that is too large to fit into a single IP
        packet <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<p id="section-4.1-9">How a client decides whether it needs to include a Q-Block1 or
        Q-Block2 option can be driven by a local configuration parameter,
        triggered by an application (e.g., DOTS), etc. Such
        considerations are out of the scope of this document.<a href="#section-4.1-9" class="pilcrow">¶</a></p>
<p id="section-4.1-10">Implementation of the Q-Block1 and Q-Block2 options is intended to
        be optional. However, when a Q-Block1 or Q-Block2 option is present in a CoAP
 message, it <span class="bcp14">MUST</span> be
        processed (or the message rejected). Therefore, the Q-Block1 and Q-Block2
        options are identified as critical options.<a href="#section-4.1-10" class="pilcrow">¶</a></p>
<p id="section-4.1-11">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 (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.4.1" class="relref">Section 5.4.1</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>). A
        Non-confirmable message with an unrecognized critical option is either
        rejected with a Reset message or just silently ignored (Sections <a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.4.1" class="relref">5.4.1</a>
        and <a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.3" class="relref">4.3</a> of <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>). To reliably get a
        rejection message, it is therefore <span class="bcp14">REQUIRED</span> that clients use a
        Confirmable message for determining support for the Q-Block1 and Q-Block2
        options. This Confirmable message can be sent under the base CoAP congestion
        control setup specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span> (that is, NSTART does not need to be
        increased (<a href="#cc-con" class="xref">Section 7.1</a>)).<a href="#section-4.1-11" class="pilcrow">¶</a></p>
<p id="section-4.1-12">The Q-Block1 and Q-Block2 options are unsafe to forward. That is, a
        CoAP proxy that does not understand the Q-Block1 (or Q-Block2) option
        must reject the request or response that uses either option (see
        <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.7.1" class="relref">Section 5.7.1</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-4.1-12" class="pilcrow">¶</a></p>
<p id="section-4.1-13">The Q-Block2 option is repeatable when requesting retransmission of
        missing blocks but not otherwise. Except for that case, any request
        carrying multiple Q-Block1 (or Q-Block2) options <span class="bcp14">MUST</span> be handled
        following the procedure specified in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.4.5" class="relref">Section 5.4.5</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>.<a href="#section-4.1-13" class="pilcrow">¶</a></p>
<p id="section-4.1-14">The Q-Block1 and Q-Block2 options, like the Block1 and Block2
        options, are of both class E and class U for OSCORE processing (<a href="#oscore" class="xref">Table 2</a>). The Q-Block1 (or Q-Block2) option
 <span class="bcp14">MAY</span> be an Inner or Outer option
        (<span><a href="https://www.rfc-editor.org/rfc/rfc8613#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>). The
 Inner and Outer
        values are therefore independent of each other. The Inner option is
        encrypted and integrity protected between clients and servers and
        provides message body identification in case of end-to-end
        fragmentation of requests. The Outer option is visible to proxies and
        labels message bodies in case of hop-by-hop fragmentation of
        requests.<a href="#section-4.1-14" class="pilcrow">¶</a></p>
<span id="name-oscore-protection-of-the-q-"></span><div id="oscore">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-oscore-protection-of-the-q-" class="selfRef">OSCORE Protection of the Q-Block1 and Q-Block2 Options</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Number</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">E</th>
              <th class="text-left" rowspan="1" colspan="1">U</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">19</td>
              <td class="text-left" rowspan="1" colspan="1">Q-Block1</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">31</td>
              <td class="text-left" rowspan="1" colspan="1">Q-Block2</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
              <td class="text-left" rowspan="1" colspan="1">x</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-4.1-16">Note that, if the Q-Block1 or Q-Block2 options are included in a packet
        as Inner options, the Block1 or Block2 options <span class="bcp14">MUST NOT</span> be included
 as Inner options. Similarly, there <span class="bcp14">MUST NOT</span> be a mix of Q-Block and
 Block options for the Outer options. Messages that do not adhere to this behavior
        <span class="bcp14">MUST</span> be rejected with a 4.02 (Bad Option). The Q-Block and Block options can
        be mixed across Inner and Outer options, as these are handled
        independently of each other. For clarity, if OSCORE is not being used,
        there <span class="bcp14">MUST NOT</span> be a mix of Q-Block and Block options in the same
        packet.<a href="#section-4.1-16" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.2">
        <h3 id="name-structure-of-the-q-block1-a">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-structure-of-the-q-block1-a" class="section-name selfRef">Structure of the Q-Block1 and Q-Block2 Options</a>
        </h3>
<p id="section-4.2-1">The structure of the Q-Block1 and Q-Block2 options follows the
        structure defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.2" class="relref">Section 2.2</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">There is no default value for the Q-Block1 and Q-Block2 options.
        The absence of one of these options is equivalent to an option value of 0
        with respect to the value of block number (NUM) and more bit (M) that
        could be given in the option, i.e., it indicates that the current
        block is the first and only block of the transfer (block number is set
        to 0; M is unset). However, in contrast to the explicit value 0, which
        would indicate a size of the block (SZX) of 0, and thus a size value
        of 16 bytes, there is no specific size implied by the absence
        of the option -- the size is left unspecified. (As for any uint, the
        explicit value 0 is efficiently indicated by a zero-length option;
        therefore, this is semantically different from the absence of the
        option.)<a href="#section-4.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3">
        <h3 id="name-using-the-q-block1-option">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-using-the-q-block1-option" class="section-name selfRef">Using the Q-Block1 Option</a>
        </h3>
<p id="section-4.3-1">The Q-Block1 option is used when the client wants to send a large
        amount of data to the server using the POST, PUT, FETCH, PATCH, or
        iPATCH methods where the data and headers do not fit into a single
        packet.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">When the Q-Block1 option is used, the client <span class="bcp14">MUST</span> include a
 Request-Tag option <span>[<a href="#RFC9175" class="xref">RFC9175</a>]</span>. The
        Request-Tag value <span class="bcp14">MUST</span> be the same for all of the requests for the
        body of data that is being transferred. The Request-Tag is opaque, but
        the client <span class="bcp14">MUST</span> ensure that it is unique for every different body of
        transmitted data.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-4.3-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.<a href="#section-4.3-3" class="pilcrow">¶</a></p>
<p id="section-4.3-4"><a href="#size" class="xref">Section 4.6</a> discusses the use of the Size1 option.<a href="#section-4.3-4" class="pilcrow">¶</a></p>
<p id="section-4.3-5">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., <span>[<a href="#RFC8323" class="xref">RFC8323</a>]</span>), a response is not
        required until successful receipt of the body by the server.<a href="#section-4.3-5" class="pilcrow">¶</a></p>
<p id="section-4.3-6">Each individual message that carries a block of the body is treated
        as a new request (<a href="#token" class="xref">Section 6</a>).<a href="#section-4.3-6" class="pilcrow">¶</a></p>
<p id="section-4.3-7">The client <span class="bcp14">MUST</span> send the payloads in order of increasing block
        number, starting from zero, until the body is complete (subject to any
        congestion control (<a href="#cc" class="xref">Section 7</a>)). In addition, any
 missing payloads requested by the server must be separately transmitted
        with increasing block numbers.<a href="#section-4.3-7" class="pilcrow">¶</a></p>
<p id="section-4.3-8">The following response codes are used:<a href="#section-4.3-8" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-4.3-9">
          <dt id="section-4.3-9.1">2.01 (Created)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.2">This response code indicates successful receipt of the entire
        body and that the resource was created. The token to use <span class="bcp14">MUST</span> be
        one of the tokens that were received in a request for this
        block-wise exchange. However, it is desirable to provide the one
        used in the last received request, since that will aid any
        troubleshooting. The client should then release all of the tokens
        used for this body. Note that the last received payload might not
        be the one with the highest block number.<a href="#section-4.3-9.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-9.3">2.02 (Deleted)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.4">This response code indicates successful receipt of the entire
        body and that the resource was deleted when using POST (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.8.2" class="relref">Section 5.8.2</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>). The token to use
 <span class="bcp14">MUST</span> be
        one of the tokens that were received in a request for this
        block-wise exchange. However, it is desirable to provide the one
        used in the last received request. The client should then release
        all of the tokens used for this body.<a href="#section-4.3-9.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-9.5">2.04 (Changed)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.6">This response code indicates successful receipt of the entire
        body and that the resource was updated. The token to use <span class="bcp14">MUST</span> be
        one of the tokens that were received in a request for this
        block-wise exchange. However, it is desirable to provide the one
        used in the last received request. The client should then release
        all of the tokens used for this body.<a href="#section-4.3-9.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-9.7">2.05 (Content)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.8">
            <p id="section-4.3-9.8.1">This response code indicates successful receipt of the entire
        FETCH request body (<span><a href="https://www.rfc-editor.org/rfc/rfc8132#section-2" class="relref">Section 2</a> of [<a href="#RFC8132" class="xref">RFC8132</a>]</span>)
        and that the appropriate representation of the resource is being
        returned. The token to use <span class="bcp14">MUST</span> 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.<a href="#section-4.3-9.8.1" class="pilcrow">¶</a></p>
<p id="section-4.3-9.8.2">If the FETCH request includes the Observe option, then the
        server <span class="bcp14">MUST</span> use the same token as used for the 2.05 (Content)
        response for returning any triggered Observe responses so that the
        client can match them up.<a href="#section-4.3-9.8.2" class="pilcrow">¶</a></p>
<p id="section-4.3-9.8.3">The client should then release all of the tokens used for this
        body apart from the one used for tracking an observed
        resource.<a href="#section-4.3-9.8.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-9.9">2.31 (Continue)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.10">
            <p id="section-4.3-9.10.1">This response code can be used to indicate that all of the
        blocks up to and including the Q-Block1 option block NUM (all
        having the M bit set) have been successfully received. The token
        to use <span class="bcp14">MUST</span> 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.<a href="#section-4.3-9.10.1" class="pilcrow">¶</a></p>
<p id="section-4.3-9.10.2">The client should then release all of the tokens used for this
        MAX_PAYLOADS_SET.<a href="#section-4.3-9.10.2" class="pilcrow">¶</a></p>
<p id="section-4.3-9.10.3">A response using this response code <span class="bcp14">MUST NOT</span> be generated for
        every received Q-Block1 option request. It <span class="bcp14">SHOULD</span> 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 <a href="#cc-non" class="xref">Section 7.2</a>.<a href="#section-4.3-9.10.3" class="pilcrow">¶</a></p>
<p id="section-4.3-9.10.4">This response code <span class="bcp14">SHOULD NOT</span> be generated for CON, as this may
        cause duplicated payloads to unnecessarily be sent.<a href="#section-4.3-9.10.4" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-9.11">4.00 (Bad Request)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.12">This response code <span class="bcp14">MUST</span> be returned if the request does not
        include a Request-Tag option or a Size1 option but does include a
        Q-Block1 option.<a href="#section-4.3-9.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-9.13">4.02 (Bad Option)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.14">This response code <span class="bcp14">MUST</span> be returned for a Confirmable request
        if the server does not support the Q-Block options. Note that a
        Reset message may be sent in case of a Non-confirmable request.<a href="#section-4.3-9.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-9.15">4.08 (Request Entity Incomplete)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.16">
            <p id="section-4.3-9.16.1">As a reminder, this response code returned without content type
        "application/missing-blocks+cbor-seq" (<a href="#new-format" class="xref">Section 12.3</a>) is handled as in <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.9.2" class="relref">Section 2.9.2</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-4.3-9.16.1" class="pilcrow">¶</a></p>
<p id="section-4.3-9.16.2">This response code returned with content type
        "application/missing-blocks+cbor-seq" indicates that some of the
        payloads are missing and need to be resent. The client then
        retransmits the individual missing payloads using the same
        Request-Tag, Size1, and Q-Block1 options to specify the same NUM,
        SZX, and M bit values as those sent initially in the original (but not
 received) packets.<a href="#section-4.3-9.16.2" class="pilcrow">¶</a></p>
<p id="section-4.3-9.16.3">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.<a href="#section-4.3-9.16.3" class="pilcrow">¶</a></p>
<p id="section-4.3-9.16.4">The token to use in the 4.08 (Request Entity Incomplete)
        response <span class="bcp14">MUST</span> 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 <a href="#code" class="xref">Section 5</a> for further information.<a href="#section-4.3-9.16.4" class="pilcrow">¶</a></p>
<p id="section-4.3-9.16.5">If the server has not received all the blocks of a body, but
        one or more NON payloads have been received, it <span class="bcp14">SHOULD</span> wait for
        NON_RECEIVE_TIMEOUT (<a href="#cc-non" class="xref">Section 7.2</a>) before sending
        a 4.08 (Request Entity Incomplete) response.<a href="#section-4.3-9.16.5" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-4.3-9.17">4.13 (Request Entity Too Large)</dt>
          <dd style="margin-left: 1.5em" id="section-4.3-9.18">
            <p id="section-4.3-9.18.1">This response code can be returned under conditions similar to
        those discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.9.3" class="relref">Section 2.9.3</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-4.3-9.18.1" class="pilcrow">¶</a></p>
<p id="section-4.3-9.18.2">This response code can be returned if there is insufficient
        space to create a response PDU with a block size of 16 bytes (SZX
        = 0) to send back all the response options as appropriate. In this
        case, the Size1 option is not included in the response.<a href="#section-4.3-9.18.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.3-10">Further considerations related to the transmission timings of the 4.08
        (Request Entity Incomplete) and 2.31 (Continue) response codes are
        discussed in <a href="#cc-non" class="xref">Section 7.2</a>.<a href="#section-4.3-10" class="pilcrow">¶</a></p>
<p id="section-4.3-11">If a server receives payloads with different Request-Tags for the
        same resource, it should continue to process all the bodies, as it has
        no way of determining which is the latest version or which body, if
        any, the client is terminating the transmission for.<a href="#section-4.3-11" class="pilcrow">¶</a></p>
<p id="section-4.3-12">If the client elects to stop the transmission of a complete body,
        then absent any local policy, the client <span class="bcp14">MUST</span> "forget" all
 tracked
        tokens associated with the body's Request-Tag so that a Reset message
        is generated for the invalid token in the 4.08 (Request Entity
        Incomplete) response. On receipt of the Reset message, the server
        <span class="bcp14">SHOULD</span> delete the partial body.<a href="#section-4.3-12" class="pilcrow">¶</a></p>
<p id="section-4.3-13">If the server receives a duplicate block with the same Request-Tag,
        it <span class="bcp14">MUST</span> ignore the payload of the packet but <span class="bcp14">MUST</span> still respond as if
        the block was received for the first time.<a href="#section-4.3-13" class="pilcrow">¶</a></p>
<p id="section-4.3-14">A server <span class="bcp14">SHOULD</span> maintain a partial body (missing payloads) for
        NON_PARTIAL_TIMEOUT (<a href="#cc-non" class="xref">Section 7.2</a>).<a href="#section-4.3-14" class="pilcrow">¶</a></p>
</section>
<div id="qblock2">
<section id="section-4.4">
        <h3 id="name-using-the-q-block2-option">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-using-the-q-block2-option" class="section-name selfRef">Using the Q-Block2 Option</a>
        </h3>
<p id="section-4.4-1">In a request for any block number, an unset M bit indicates the
        request is just for that block. If the M bit is set, this has
        different meanings based on the NUM value:<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.4-2">
          <dt id="section-4.4-2.1">NUM is zero:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-2.2">This is a request for the entire body.<a href="#section-4.4-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-2.3">'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-2.4">This is used to confirm that the current MAX_PAYLOADS_SET (the latest
          block having block number NUM-1) has been successfully received
          and that, upon receipt of this request, the server can continue to
          send the next MAX_PAYLOADS_SET (the first block having block
          number NUM). This is the 'Continue' Q-Block-2 and conceptually has
          the same usage (i.e., continue sending the next set of data) as
          the use of 2.31 (Continue) for Q-Block1.<a href="#section-4.4-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.4-2.5">Any other value of NUM:</dt>
          <dd style="margin-left: 1.5em" id="section-4.4-2.6">This is a request for that block and for all of the remaining blocks in the
   current MAX_PAYLOADS_SET.<a href="#section-4.4-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.4-3">If the request includes multiple Q-Block2 options and these options
        overlap (e.g., combination of M being set (this and later blocks) and
        unset (this individual block)), resulting in an individual block
        being requested multiple times, the server <span class="bcp14">MUST</span> only send back one
        instance of that block. This behavior is meant to prevent
        amplification attacks.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">The payloads sent back from the server as a response <span class="bcp14">MUST</span> all have
        the same ETag (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.10.6" class="relref">Section 5.10.6</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>) for
        the same body. The server <span class="bcp14">MUST NOT</span> use the same ETag value for
        different representations of a resource.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
<p id="section-4.4-5">The ETag is opaque, but the server <span class="bcp14">MUST</span> ensure that it is unique
        for every different body of transmitted data.<a href="#section-4.4-5" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-4.4-6">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.<a href="#section-4.4-6" class="pilcrow">¶</a></p>
<p id="section-4.4-7"><a href="#size" class="xref">Section 4.6</a> discusses the use of the Size2 option.<a href="#section-4.4-7" class="pilcrow">¶</a></p>
<p id="section-4.4-8">The client may elect to request any detected missing blocks or just
        ignore the partial body. This decision is implementation specific.<a href="#section-4.4-8" class="pilcrow">¶</a></p>
<p id="section-4.4-9">For NON payloads, the client <span class="bcp14">SHOULD</span> wait for NON_RECEIVE_TIMEOUT (<a href="#cc-non" class="xref">Section 7.2</a>) after the last received payload before
        requesting retransmission of any missing blocks. Retransmission is
        requested by issuing a GET, POST, PUT, FETCH, PATCH, or iPATCH request
        that contains one or more Q-Block2 options that define the missing
        block(s). Generally, the M bit on the Q-Block2 option(s) <span class="bcp14">SHOULD</span> be
        unset, although the M bit <span class="bcp14">MAY</span> be set to request this and later
 blocks
        from this MAX_PAYLOADS_SET; see <a href="#sec-nonb411" class="xref">Section 10.2.4</a> for
        an example of this in operation. Further considerations related to the
        transmission timing for missing requests are discussed in <a href="#cc-non" class="xref">Section 7.2</a>.<a href="#section-4.4-9" class="pilcrow">¶</a></p>
<p id="section-4.4-10">The missing block numbers requested by the client <span class="bcp14">MUST</span> have an
        increasing block number in each additional Q-Block2 option with no
        duplicates. The server <span class="bcp14">SHOULD</span> 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.<a href="#section-4.4-10" class="pilcrow">¶</a></p>
<p id="section-4.4-11">If the client receives a duplicate block with the same ETag, it
        <span class="bcp14">MUST</span> silently ignore the payload.<a href="#section-4.4-11" class="pilcrow">¶</a></p>
<p id="section-4.4-12">A client <span class="bcp14">SHOULD</span> maintain a partial body (missing payloads) for
        NON_PARTIAL_TIMEOUT (<a href="#cc-non" class="xref">Section 7.2</a>) or as defined by
        the Max-Age option (or its default of 60 seconds (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.6.1" class="relref">Section 5.6.1</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>)), whichever is less.
 On release of
        the partial body, the client should then release all of the tokens
        used for this body apart from the token that is used to track a
        resource that is being observed.<a href="#section-4.4-12" class="pilcrow">¶</a></p>
<p id="section-4.4-13">The ETag option should not be used in the request for missing
        blocks, as the server could respond with a 2.03 (Valid) response with
        no payload. It can be used in the request if the client wants to check
        the freshness of the locally cached body response.<a href="#section-4.4-13" class="pilcrow">¶</a></p>
<p id="section-4.4-14">The server <span class="bcp14">SHOULD</span> maintain a cached copy of the body when using the
        Q-Block2 option to facilitate retransmission of any missing
        payloads.<a href="#section-4.4-14" class="pilcrow">¶</a></p>
<p id="section-4.4-15">If the server detects partway through a body transfer that the
        resource data has changed and the server is not maintaining a cached
        copy of the old data, then the transmission is terminated. Any
        subsequent missing block requests <span class="bcp14">MUST</span> be responded to using the
        latest ETag and Size2 option values with the updated data.<a href="#section-4.4-15" class="pilcrow">¶</a></p>
<p id="section-4.4-16">If the server responds during a body update with a different ETag
        option value (as the resource representation has changed), then the
        client should treat the partial body with the old ETag as no longer
        being fresh. The client may then request all of the new data by
        specifying Q-Block2 with block number '0' and the M bit set.<a href="#section-4.4-16" class="pilcrow">¶</a></p>
<p id="section-4.4-17">If the server transmits a new body of data (e.g., a triggered
        Observe notification) with a new ETag to the same client as an
        additional response, the client should remove any partially received
        body held for a previous ETag for that resource, as it is unlikely the
        missing blocks can be retrieved.<a href="#section-4.4-17" class="pilcrow">¶</a></p>
<p id="section-4.4-18">If there is insufficient space to create a response PDU with a
        block size of 16 bytes (SZX = 0) to send back all the response options
        as appropriate, a 4.13 (Request Entity Too Large) is returned without
        the Size1 option.<a href="#section-4.4-18" class="pilcrow">¶</a></p>
<p id="section-4.4-19">For Confirmable traffic, the server typically acknowledges the
        initial request using an Acknowledgment (ACK) with a piggybacked payload and then
        sends the subsequent payloads of the MAX_PAYLOADS_SET as CON
        responses. These CON responses are individually ACKed by the client.
        The server will detect failure to send a packet and <span class="bcp14">SHOULD</span> 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.<a href="#section-4.4-19" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.5">
        <h3 id="name-using-the-observe-option">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-using-the-observe-option" class="section-name selfRef">Using the Observe Option</a>
        </h3>
<p id="section-4.5-1">For a request that uses Q-Block1, the Observe value <span>[<a href="#RFC7641" class="xref">RFC7641</a>]</span> <span class="bcp14">MUST</span> be the same for all the payloads of the
        same body. This includes any missing payloads that are
        retransmitted.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">For a response that uses Q-Block2, the Observe value <span class="bcp14">MUST</span> 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 (<span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-3.4" class="relref">Section 3.4</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>). This includes
        payloads transmitted following receipt of the 'Continue' Q-Block2
        option (<a href="#qblock2" class="xref">Section 4.4</a>) by the server. If a missing
        payload is requested by a client, then both the request and response
        <span class="bcp14">MUST NOT</span> include the Observe option.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
</section>
<div id="size">
<section id="section-4.6">
        <h3 id="name-using-the-size1-and-size2-o">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-using-the-size1-and-size2-o" class="section-name selfRef">Using the Size1 and Size2 Options</a>
        </h3>
<p id="section-4.6-1"><span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-4" class="relref">Section 4</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span> 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.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
<p id="section-4.6-2">For the Q-Block1 and Q-Block2 options, the Size1 or Size2 option values
        <span class="bcp14">MUST</span> exactly represent the size of the data on the body so that any
        missing data can easily be determined.<a href="#section-4.6-2" class="pilcrow">¶</a></p>
<p id="section-4.6-3">The Size1 option <span class="bcp14">MUST</span> be used with the Q-Block1 option when used in
        a request and <span class="bcp14">MUST</span> be present in all payloads of the request,
        preserving the same value. The Size2 option <span class="bcp14">MUST</span> be used with the
        Q-Block2 option when used in a response and <span class="bcp14">MUST</span> be present in all
        payloads of the response, preserving the same value.<a href="#section-4.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.7">
        <h3 id="name-using-the-q-block1-and-q-bl">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-using-the-q-block1-and-q-bl" class="section-name selfRef">Using the Q-Block1 and Q-Block2 Options Together</a>
        </h3>
<p id="section-4.7-1">The behavior is similar to the one defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span> with Q-Block1 substituted for Block1 and
        Q-Block2 substituted for Block2.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
</section>
<section id="section-4.8">
        <h3 id="name-using-the-q-block2-option-w">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-using-the-q-block2-option-w" class="section-name selfRef">Using the Q-Block2 Option with Multicast</a>
        </h3>
<p id="section-4.8-1">Servers <span class="bcp14">MUST</span> ignore multicast requests that contain the Q-Block2
        option. As a reminder, the Block2 option can be used as stated in <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.8" class="relref">Section 2.8</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>.<a href="#section-4.8-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="code">
<section id="section-5">
      <h2 id="name-the-use-of-the-408-request-">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-the-use-of-the-408-request-" class="section-name selfRef">The Use of the 4.08 (Request Entity Incomplete) Response Code</a>
      </h2>
<p id="section-5-1">The 4.08 (Request Entity Incomplete) response code has a new content type
      "application/missing-blocks+cbor-seq" used to indicate that the server
      has not received all of the blocks of the request body that it needs to
      proceed. Such messages must not be treated by the client as a fatal
      error.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Likely causes are the client has not sent all blocks, some blocks
      were dropped during transmission, or the client sent them
      a long enough time ago that the server has already discarded them.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">The new data payload of the 4.08 (Request Entity Incomplete) response
      with content type "application/missing-blocks+cbor-seq" is
      encoded as a Concise Binary Object Representation (CBOR) Sequence <span>[<a href="#RFC8742" class="xref">RFC8742</a>]</span>. It comprises
      one or more missing block numbers encoded as CBOR unsigned integers
      <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span>. The missing block numbers <span class="bcp14">MUST</span> be unique
      in each 4.08 (Request Entity Incomplete) response when created by the
      server; the client <span class="bcp14">MUST</span> ignore any duplicates in the same 4.08 (Request
      Entity Incomplete) response.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">The Content-Format option (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-5.10.3" class="relref">Section 5.10.3</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>) <span class="bcp14">MUST</span> be used in the 4.08 (Request Entity
      Incomplete) response. It <span class="bcp14">MUST</span> be set to
      "application/missing-blocks+cbor-seq" (<a href="#new-format" class="xref">Section 12.3</a>).<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">The Concise Data Definition Language (CDDL) <span>[<a href="#RFC8610" class="xref">RFC8610</a>]</span>
      (and see <span><a href="https://www.rfc-editor.org/rfc/rfc8742#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC8742" class="xref">RFC8742</a>]</span>) for the data describing these missing blocks is as follows:<a href="#section-5-5" class="pilcrow">¶</a></p>
<span id="name-structure-of-the-missing-bl"></span><div id="cddl">
<figure id="figure-1">
        <div id="section-5-6.1">
<pre class="lang-cddl sourcecode">
; 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
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-structure-of-the-missing-bl" class="selfRef">Structure of the Missing Blocks Payload</a>
        </figcaption></figure>
</div>
<p id="section-5-7">This CDDL syntax <span class="bcp14">MUST</span> be followed.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">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.<a href="#section-5-8" class="pilcrow">¶</a></p>
<p id="section-5-9">If the size of the 4.08 (Request Entity Incomplete) response packet
      is larger than that defined by <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.6" class="relref">Section 4.6</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>, then the number of reported missing blocks
      <span class="bcp14">MUST</span> be limited so that the response can fit into a single packet. If
      this is the case, then the server can send subsequent 4.08 (Request
      Entity Incomplete) responses containing those additional missing blocks on
      receipt of a new request providing a missing payload with the same
      Request-Tag.<a href="#section-5-9" class="pilcrow">¶</a></p>
<p id="section-5-10">The missing blocks <span class="bcp14">MUST</span> be reported in ascending order without any
      duplicates. The client <span class="bcp14">SHOULD</span> silently drop 4.08 (Request Entity
      Incomplete) responses not adhering to this behavior.<a href="#section-5-10" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-5-11">Implementation Note: Consider limiting the number of
      missing payloads to MAX_PAYLOADS to minimize the need for congestion control.
      The CBOR Sequence does not include any array
      wrapper.<a href="#section-5-11" class="pilcrow">¶</a></p>
<p id="section-5-12">A 4.08 (Request Entity Incomplete) response with content type
      "application/missing-blocks+cbor-seq" <span class="bcp14">SHOULD NOT</span> be used when using
      Confirmable requests or a reliable connection <span>[<a href="#RFC8323" class="xref">RFC8323</a>]</span>, 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.<a href="#section-5-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="token">
<section id="section-6">
      <h2 id="name-the-use-of-tokens">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-the-use-of-tokens" class="section-name selfRef">The Use of Tokens</a>
      </h2>
<p id="section-6-1">Each new request generally uses a new Token (and sometimes must; see
      <span><a href="https://www.rfc-editor.org/rfc/rfc9175#section-4" class="relref">Section 4</a> of [<a href="#RFC9175" class="xref">RFC9175</a>]</span>).
      Additional responses to a request all use the token of the request they
      respond to.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-6-2">Implementation Note: By using 8-byte tokens, it is
      possible to easily minimize the number of tokens that have to be
      tracked by clients, by keeping the bottom 32 bits the same for the
      same body and the upper 32 bits containing the current body's
      request number (incrementing every request, including every
      retransmit). This alleviates the client's need to keep
      all the per-request state, e.g., per <span><a href="https://www.rfc-editor.org/rfc/rfc8974#section-3" class="relref">Section 3</a> of [<a href="#RFC8974" class="xref">RFC8974</a>]</span>. However, if using NoSec, <span><a href="https://www.rfc-editor.org/rfc/rfc8974#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC8974" class="xref">RFC8974</a>]</span> needs to be considered for security
      implications.<a href="#section-6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cc">
<section id="section-7">
      <h2 id="name-congestion-control-for-unre">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-congestion-control-for-unre" class="section-name selfRef">Congestion Control for Unreliable Transports</a>
      </h2>
<p id="section-7-1">The transmission of all the blocks of a single body over an
      unreliable transport <span class="bcp14">MUST</span> either all be Confirmable or all be
      Non-confirmable. This is meant to simplify the congestion control
      procedure.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">As a reminder, there is no need for CoAP-specific congestion control
      for reliable transports <span>[<a href="#RFC8323" class="xref">RFC8323</a>]</span>.<a href="#section-7-2" class="pilcrow">¶</a></p>
<div id="cc-con">
<section id="section-7.1">
        <h3 id="name-confirmable-con">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-confirmable-con" class="section-name selfRef">Confirmable (CON)</a>
        </h3>
<p id="section-7.1-1">Congestion control for CON requests and responses is specified in
        <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>. 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 (<a href="#scope" class="xref">Section 3.2</a>)
        apart from the initial Q-Block functionality negotiation.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">Following the failure to transmit a packet due to packet loss after
        MAX_TRANSMIT_SPAN time (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.8.2" class="relref">Section 4.8.2</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>), it is implementation specific as to whether
        there should be any further requests for missing data.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cc-non">
<section id="section-7.2">
        <h3 id="name-non-confirmable-non">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-non-confirmable-non" class="section-name selfRef">Non-confirmable (NON)</a>
        </h3>
<p id="section-7.2-1">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
        (<a href="#congestion" class="xref">Table 3</a>).<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-7.2-2">Note: Randomness may naturally be provided based on the traffic
        profile, how PROBING_RATE is computed (as this is an average), and
        when the peer responds. Randomness is explicitly added for some of
        the congestion control parameters to handle situations where everything is in sync when retrying.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
<p id="section-7.2-3">MAX_PAYLOADS should be configurable with a default value of 10.
        Both CoAP endpoints <span class="bcp14">MUST</span> have the same value (otherwise, there will be
        transmission delays in one direction), and the value <span class="bcp14">MAY</span> be negotiated
        between the endpoints to a common value by using a higher-level
        protocol (out of scope of this document). This is the maximum number
        of payloads that can be transmitted at any one time.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-7.2-4">Note: The default value of 10 is chosen for reasons similar to
        those discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc6928#section-5" class="relref">Section 5</a> of [<a href="#RFC6928" class="xref">RFC6928</a>]</span>,
        especially given the target application discussed in <a href="#scope" class="xref">Section 3.2</a>.<a href="#section-7.2-4" class="pilcrow">¶</a></p>
<p id="section-7.2-5">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 (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.8" class="relref">Section 4.8</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-7.2-5" class="pilcrow">¶</a></p>
<p id="section-7.2-6">NON_TIMEOUT_RANDOM is the initial actual delay between sending the
        first two MAX_PAYLOADS_SETs of the same body. The same delay is then
        used between the subsequent MAX_PAYLOADS_SETs. It is a random duration
        (not an integral number of seconds) between NON_TIMEOUT and
        (NON_TIMEOUT * ACK_RANDOM_FACTOR). ACK_RANDOM_FACTOR is set to 1.5, as
        discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.8" class="relref">Section 4.8</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>.<a href="#section-7.2-6" class="pilcrow">¶</a></p>
<p id="section-7.2-7">NON_RECEIVE_TIMEOUT is the initial time to wait for a missing
        payload before requesting retransmission for the first time. Every
        time the missing payload is re-requested, the Time-to-Wait value
        doubles. The time to wait is calculated as:<a href="#section-7.2-7" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-7.2-8">Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count -
            1))<a href="#section-7.2-8" class="pilcrow">¶</a></p>
<p id="section-7.2-9">NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT.
        NON_RECEIVE_TIMEOUT <span class="bcp14">MUST</span> 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.<a href="#section-7.2-9" class="pilcrow">¶</a></p>
<p id="section-7.2-10">NON_MAX_RETRANSMIT is the maximum number of times a request for the
        retransmission of missing payloads can occur without a response from
        the remote peer. After this occurs, the local endpoint <span class="bcp14">SHOULD</span> consider
        the body stale, remove any body, and release the tokens and Request-Tag on
        the client (or the ETag on the server). By default, NON_MAX_RETRANSMIT
        has the same value as MAX_RETRANSMIT (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.8" class="relref">Section 4.8</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>).<a href="#section-7.2-10" class="pilcrow">¶</a></p>
<p id="section-7.2-11">NON_PROBING_WAIT is used to limit the potential wait needed when
        using PROBING_RATE. By default, NON_PROBING_WAIT is computed in a way
        similar to EXCHANGE_LIFETIME (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.8.2" class="relref">Section 4.8.2</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>) but with ACK_TIMEOUT, MAX_RETRANSMIT, and
        PROCESSING_DELAY substituted with NON_TIMEOUT, NON_MAX_RETRANSMIT, and
        NON_TIMEOUT_RANDOM, respectively:<a href="#section-7.2-11" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-7.2-12">NON_PROBING_WAIT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT) -
        1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT_RANDOM<a href="#section-7.2-12" class="pilcrow">¶</a></p>
<p id="section-7.2-13">NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
        By default, NON_PARTIAL_TIMEOUT is computed in the same way as
        EXCHANGE_LIFETIME (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.8.2" class="relref">Section 4.8.2</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>)
        but with ACK_TIMEOUT and MAX_RETRANSMIT substituted with NON_TIMEOUT
        and NON_MAX_RETRANSMIT, respectively:<a href="#section-7.2-13" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-7.2-14">NON_PARTIAL_TIMEOUT = NON_TIMEOUT * ((2 ** NON_MAX_RETRANSMIT)
        - 1) * ACK_RANDOM_FACTOR + (2 * MAX_LATENCY) + NON_TIMEOUT<a href="#section-7.2-14" class="pilcrow">¶</a></p>
<span id="name-congestion-control-paramete"></span><div id="congestion">
<table class="center" id="table-3">
          <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-congestion-control-paramete" class="selfRef">Congestion Control Parameters</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Parameter Name</th>
              <th class="text-left" rowspan="1" colspan="1">Default Value</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">MAX_PAYLOADS</td>
              <td class="text-left" rowspan="1" colspan="1">10</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NON_MAX_RETRANSMIT</td>
              <td class="text-left" rowspan="1" colspan="1">4</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NON_TIMEOUT</td>
              <td class="text-left" rowspan="1" colspan="1">2 s</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NON_TIMEOUT_RANDOM</td>
              <td class="text-left" rowspan="1" colspan="1">between 2-3 s</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NON_RECEIVE_TIMEOUT</td>
              <td class="text-left" rowspan="1" colspan="1">4 s</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NON_PROBING_WAIT</td>
              <td class="text-left" rowspan="1" colspan="1">between 247-248 s</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">NON_PARTIAL_TIMEOUT</td>
              <td class="text-left" rowspan="1" colspan="1">247 s</td>
            </tr>
          </tbody>
        </table>
</div>
<p id="section-7.2-16">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 (<span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-4.7" class="relref">Section 4.7</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>), not the
        individual packets. If the wait time between sending bodies that are
        not being responded to based on PROBING_RATE exceeds NON_PROBING_WAIT,
        then the wait time is limited to NON_PROBING_WAIT.<a href="#section-7.2-16" class="pilcrow">¶</a></p>
<aside id="section-7.2-17">
          <p id="section-7.2-17.1">Note: For the particular DOTS application, PROBING_RATE and
        other transmission parameters are negotiated between peers. Even
        when not negotiated, the DOTS application uses customized defaults,
        as discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc9132#section-4.5.2" class="relref">Section 4.5.2</a> of [<a href="#RFC9132" class="xref">RFC9132</a>]</span>.
        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 <span>[<a href="#I-D.bosh-dots-quick-blocks" class="xref">DOTS-QUICK-BLOCKS</a>]</span>. When explicit values
        are configured for NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT, these
        values are used without applying any jitter.<a href="#section-7.2-17.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-7.2-18">Each NON 4.08 (Request Entity Incomplete) response is subject
        to PROBING_RATE.<a href="#section-7.2-18" class="pilcrow">¶</a></p>
<p id="section-7.2-19">Each NON GET or FETCH request using a Q-Block2 option is subject to
        PROBING_RATE.<a href="#section-7.2-19" class="pilcrow">¶</a></p>
<p id="section-7.2-20">As the sending of many payloads of a single body may itself cause
        congestion, after transmission of every MAX_PAYLOADS_SET of a single
        body, a delay of NON_TIMEOUT_RANDOM <span class="bcp14">MUST</span> be introduced before sending
        the next MAX_PAYLOADS_SET, unless a 'Continue' is received from the
        peer for the current MAX_PAYLOADS_SET, in which case the next
        MAX_PAYLOADS_SET <span class="bcp14">MAY</span> start transmission immediately.<a href="#section-7.2-20" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-7.2-21">Note: Assuming 1500-byte packets and the MAX_PAYLOADS_SET
        having 10 payloads, this corresponds to 1500 * 10 * 8 = 120 kbits.
        With a delay of 2 seconds between MAX_PAYLOADS_SET, this indicates
        an average speed requirement of 60 kbps for a single body should
        there be no responses. This transmission rate is further reduced
        by being subject to PROBING_RATE.<a href="#section-7.2-21" class="pilcrow">¶</a></p>
<p id="section-7.2-22">The sending of a set of missing blocks of a body is restricted to
        those in a MAX_PAYLOADS_SET at a time. In other words, a
        NON_TIMEOUT_RANDOM delay is still observed between each
        MAX_PAYLOADS_SET.<a href="#section-7.2-22" class="pilcrow">¶</a></p>
<p id="section-7.2-23">For the Q-Block1 option, if the server responds with a 2.31 (Continue)
        response code for the latest payload sent, then the client can
        continue to send the next MAX_PAYLOADS_SET without any further delay.
        If the server responds with a 4.08 (Request Entity Incomplete)
        response code, then the missing payloads <span class="bcp14">SHOULD</span> be retransmitted
        before going into another NON_TIMEOUT_RANDOM delay prior to sending
        the next set of payloads.<a href="#section-7.2-23" class="pilcrow">¶</a></p>
<p id="section-7.2-24">For the server receiving NON Q-Block1 requests, it <span class="bcp14">SHOULD</span> send
 back a 2.31 (Continue) response code on receipt of all of the
        MAX_PAYLOADS_SET to prevent the client unnecessarily delaying the transfer of remaining blocks. If not
        all of the MAX_PAYLOADS_SET were received, the server <span class="bcp14">SHOULD</span> delay for
        NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request
        count for a payload) before sending the 4.08 (Request Entity
        Incomplete) response code for the missing payload(s). If all of the
        MAX_PAYLOADS_SET were received and a 2.31 (Continue) response code had been sent,
        but no more payloads were received for NON_RECEIVE_TIMEOUT
        (exponentially scaled), the server <span class="bcp14">SHOULD</span> send a 4.08 (Request Entity
        Incomplete) response detailing the missing payloads after the block
        number that was indicated in the sent 2.31 (Continue) response code. If the repeat
        response count of the 4.08 (Request Entity Incomplete) exceeds
        NON_MAX_RETRANSMIT, the server <span class="bcp14">SHOULD</span> discard the partial body and
        stop requesting the missing payloads.<a href="#section-7.2-24" class="pilcrow">¶</a></p>
<p id="section-7.2-25">It is likely that the client will start transmitting the next
        MAX_PAYLOADS_SET before the server times out on waiting for the last block
        of the previous MAX_PAYLOADS_SET. On receipt of a payload from the
        next MAX_PAYLOADS_SET, the server <span class="bcp14">SHOULD</span> send a 4.08 (Request Entity
        Incomplete) response code indicating any missing payloads from any
        previous MAX_PAYLOADS_SET. Upon receipt of the 4.08 (Request Entity
        Incomplete) response code, the client <span class="bcp14">SHOULD</span> 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.<a href="#section-7.2-25" class="pilcrow">¶</a></p>
<p id="section-7.2-26">For the client receiving NON Q-Block2 responses, it <span class="bcp14">SHOULD</span> send a
        'Continue' Q-Block2 request (<a href="#qblock2" class="xref">Section 4.4</a>) for the
        next MAX_PAYLOADS_SET on receipt of all of the MAX_PAYLOADS_SET to
        prevent the server unnecessarily delaying the transfer of remaining blocks. Otherwise, the client <span class="bcp14">SHOULD</span>
        delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the
        repeat request count for a payload) before sending the request for
        the missing payload(s). If the repeat request count for a missing
        payload exceeds NON_MAX_RETRANSMIT, the client <span class="bcp14">SHOULD</span> discard the
        partial body and stop requesting the missing payloads.<a href="#section-7.2-26" class="pilcrow">¶</a></p>
<p id="section-7.2-27">The server <span class="bcp14">SHOULD</span> recognize the 'Continue' Q-Block2 request
        per the definition in <a href="#qblock2" class="xref">Section 4.4</a> and just continue the transmission of the body
        (including the Observe option, if appropriate for an unsolicited response)
        rather than treat 'Continue' as a request for the remaining missing blocks.<a href="#section-7.2-27" class="pilcrow">¶</a></p>
<p id="section-7.2-28">It is likely that the server will start transmitting the next
        MAX_PAYLOADS_SET before the client times out on waiting for the last block
        of the previous MAX_PAYLOADS_SET. Upon receipt of a payload from the
        new MAX_PAYLOADS_SET, the client <span class="bcp14">SHOULD</span> send a request indicating any
        missing payloads from any previous MAX_PAYLOADS_SET. Upon receipt of
        such a request, the server <span class="bcp14">SHOULD</span> 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.<a href="#section-7.2-28" class="pilcrow">¶</a></p>
<p id="section-7.2-29">The client does not need to acknowledge the receipt of the entire
        body.<a href="#section-7.2-29" class="pilcrow">¶</a></p>
<p style="margin-left: 1.5em" id="section-7.2-30">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.<a href="#section-7.2-30" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-8">
      <h2 id="name-caching-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-caching-considerations" class="section-name selfRef">Caching Considerations</a>
      </h2>
<p id="section-8-1">Caching block-based information is not straightforward in a proxy.
      For the Q-Block1 and Q-Block2 options, for simplicity, it is expected that
      the proxy will reassemble the body (using any appropriate recovery
      options for packet loss) before passing the body onward to the appropriate
      CoAP endpoint. This does not preclude an implementation doing a more
      complex per-payload caching, but how to do this is out of the scope of
      this document. The onward transmission of the body does not require the
      use of the Q-Block1 or Q-Block2 options, as these options may not be
      supported in that link. This means that the proxy must fully support the
      Q-Block1 and Q-Block2 options.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">How the body is cached in the CoAP client (for Q-Block1
      transmissions) or the CoAP server (for Q-Block2 transmissions) is
      implementation specific.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">As the entire body is being cached in the proxy, the Q-Block1 and
      Q-Block2 options are removed as part of the block assembly and thus do
      not reach the cache.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">For Q-Block2 responses, the ETag option value is associated with the
      data (and transmitted onward to the CoAP client) but is not part of the
      cache key.<a href="#section-8-4" class="pilcrow">¶</a></p>
<p id="section-8-5">For requests with the Q-Block1 option, the Request-Tag option is
      associated with building the body from successive payloads but
      is not part of the cache key. For the onward transmission of the body
      using CoAP, a new Request-Tag <span class="bcp14">SHOULD</span> be generated and used. Ideally,
      this new Request-Tag should replace the Request-Tag used by the client.<a href="#section-8-5" class="pilcrow">¶</a></p>
<p id="section-8-6">It is possible that two or more CoAP clients are concurrently
      updating the same resource through a common proxy to the same CoAP
      server using the Q-Block1 (or Block1) option. If this is the case, the first
      client to complete building the body causes that body to start
      transmitting to the CoAP server with an appropriate Request-Tag value.
      When the next client completes building the body, any existing partial
      body transmission to the CoAP server is terminated, and the transmission of the
      new body representation starts with a new Request-Tag value. Note
      that it cannot be assumed that the proxy will always receive a complete
      body from a client.<a href="#section-8-6" class="pilcrow">¶</a></p>
<p id="section-8-7">A proxy that supports the Q-Block2 option <span class="bcp14">MUST</span> be prepared to
      receive a GET or similar request indicating one or more missing blocks. From its
      cache, the proxy will serve the missing blocks that are available in its
      cache in the same way a server would send all the appropriate Q-Block2
      responses. If a body matching the cache key is not available in the
      cache, the proxy <span class="bcp14">MUST</span> request the entire body from the CoAP server using
      the information in the cache key.<a href="#section-8-7" class="pilcrow">¶</a></p>
<p id="section-8-8">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).<a href="#section-8-8" class="pilcrow">¶</a></p>
</section>
<section id="section-9">
      <h2 id="name-http-mapping-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-http-mapping-considerations" class="section-name selfRef">HTTP Mapping Considerations</a>
      </h2>
<p id="section-9-1">As a reminder, the basic normative requirements on HTTP/CoAP mappings
      are defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7252#section-10" class="relref">Section 10</a> of [<a href="#RFC7252" class="xref">RFC7252</a>]</span>. The
      implementation guidelines for HTTP/CoAP mappings are elaborated in <span>[<a href="#RFC8075" class="xref">RFC8075</a>]</span>.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">The rules defined in <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-5" class="relref">Section 5</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span> are
      to be followed.<a href="#section-9-2" class="pilcrow">¶</a></p>
</section>
<div id="non-confirm">
<section id="section-10">
      <h2 id="name-examples-with-non-confirmab">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-examples-with-non-confirmab" class="section-name selfRef">Examples with Non-confirmable Messages</a>
      </h2>
<p id="section-10-1">This section provides some sample flows to illustrate the use of the
      Q-Block1 and Q-Block2 options with NON. Examples with CON are provided
      in <a href="#CON" class="xref">Appendix A</a>.<a href="#section-10-1" class="pilcrow">¶</a></p>
<p id="section-10-2">The examples in the following subsections assume MAX_PAYLOADS is set
      to 10 and NON_MAX_RETRANSMIT is set to 4.<a href="#section-10-2" class="pilcrow">¶</a></p>
<p id="section-10-3">The list below contains the conventions that are
      used in the figures in the following subsections.<a href="#section-10-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-10-4">
        <dt id="section-10-4.1">T:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.2">Token value<a href="#section-10-4.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.3">O:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.4">Observe option value<a href="#section-10-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.5">M:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.6">Message ID<a href="#section-10-4.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.7">RT:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.8">Request-Tag<a href="#section-10-4.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.9">ET:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.10">ETag<a href="#section-10-4.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.11">QB1:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.12">Q-Block1 option values NUM/More/Size<a href="#section-10-4.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.13">QB2:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.14">Q-Block2 option values NUM/More/Size<a href="#section-10-4.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.15">Size:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.16">Actual block size encoded in SZX<a href="#section-10-4.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.17">\:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.18">Trimming long lines<a href="#section-10-4.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.19">[[]]:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.20">Comments<a href="#section-10-4.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.21">--&gt;X:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.22">Message loss (request)<a href="#section-10-4.22" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.23">X&lt;--:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.24">Message loss (response)<a href="#section-10-4.24" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.25">...:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.26">Passage of time<a href="#section-10-4.26" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-10-4.27">Payload N:</dt>
        <dd style="margin-left: 3.5em" id="section-10-4.28">Corresponds to the CoAP message that conveys 
           a block number (N-1) of a given block-wise exchange.<a href="#section-10-4.28" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<section id="section-10.1">
        <h3 id="name-q-block1-option">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-q-block1-option" class="section-name selfRef">Q-Block1 Option</a>
        </h3>
<section id="section-10.1.1">
          <h4 id="name-a-simple-example">
<a href="#section-10.1.1" class="section-number selfRef">10.1.1. </a><a href="#name-a-simple-example" class="section-name selfRef">A Simple Example</a>
          </h4>
<p id="section-10.1.1-1"><a href="#B3non" class="xref">Figure 2</a> depicts an example of a NON PUT
          request conveying the Q-Block1 option. All the blocks are received by
          the server.<a href="#section-10.1.1-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-non-request-wi"></span><div id="B3non">
<figure id="figure-2">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.1.1-2.1">
<pre>
 CoAP        CoAP
Client      Server
  |          |
  +---------&gt;| NON PUT /path M:0x81 T:0xc0 RT=9 QB1:0/1/1024
  +---------&gt;| NON PUT /path M:0x82 T:0xc1 RT=9 QB1:1/1/1024
  +---------&gt;| NON PUT /path M:0x83 T:0xc2 RT=9 QB1:2/1/1024
  +---------&gt;| NON PUT /path M:0x84 T:0xc3 RT=9 QB1:3/0/1024
  |&lt;---------+ NON 2.04 M:0xf1 T:0xc3
  |   ...    |
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-example-of-a-non-request-wi" class="selfRef">Example of a NON Request with the Q-Block1 option (without Loss)</a>
            </figcaption></figure>
</div>
</section>
<section id="section-10.1.2">
          <h4 id="name-handling-max_payloads-limit">
<a href="#section-10.1.2" class="section-number selfRef">10.1.2. </a><a href="#name-handling-max_payloads-limit" class="section-name selfRef">Handling MAX_PAYLOADS Limits</a>
          </h4>
<p id="section-10.1.2-1"><a href="#B3non0" class="xref">Figure 3</a> depicts an example of a NON PUT
          request conveying the Q-Block1 option. The number of payloads exceeds
          MAX_PAYLOADS. All the blocks are received by the server.<a href="#section-10.1.2-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-max_payloads-n"></span><div id="B3non0">
<figure id="figure-3">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.1.2-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| NON PUT /path M:0x01 T:0xf1 RT=10 QB1:0/1/1024
   +---------&gt;| NON PUT /path M:0x02 T:0xf2 RT=10 QB1:1/1/1024
   +---------&gt;| [[Payloads 3 - 9 not detailed]]
   +---------&gt;| 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]]
   |&lt;---------+ NON 2.31 M:0x81 T:0xfa
   +---------&gt;| NON PUT /path M:0x0b T:0xfb RT=10 QB1:10/0/1024
   |&lt;---------+ NON 2.04 M:0x82 T:0xfb
   |   ...    |
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-example-of-a-max_payloads-n" class="selfRef">Example of a MAX_PAYLOADS NON Request with the Q-Block1 Option (without
     Loss)</a>
            </figcaption></figure>
</div>
</section>
<section id="section-10.1.3">
          <h4 id="name-handling-max_payloads-with-">
<a href="#section-10.1.3" class="section-number selfRef">10.1.3. </a><a href="#name-handling-max_payloads-with-" class="section-name selfRef">Handling MAX_PAYLOADS with Recovery</a>
          </h4>
<p id="section-10.1.3-1">Consider now a scenario where a new body of data is to be sent by
          the client, but some blocks are dropped in transmission, as
          illustrated in <a href="#B3non1" class="xref">Figure 4</a>.<a href="#section-10.1.3-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-max_payloads-no"></span><div id="B3non1">
<figure id="figure-4">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.1.3-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| NON PUT /path M:0x11 T:0xe1 RT=11 QB1:0/1/1024
   +---&gt;X     | NON PUT /path M:0x12 T:0xe2 RT=11 QB1:1/1/1024
   +---------&gt;| [[Payloads 3 - 8 not detailed]]
   +---------&gt;| NON PUT /path M:0x19 T:0xe9 RT=11 QB1:8/1/1024
   +---&gt;X     | NON PUT /path M:0x1a T:0xea RT=11 QB1:9/1/1024
   [[Some of the MAX_PAYLOADS_SET has been received]]
   |   ...    |
[[NON_TIMEOUT_RANDOM (client) delay expires]]
   |     [[Client starts sending next MAX_PAYLOADS_SET]]
   +---&gt;X     | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024
   +---------&gt;| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024
   |          |
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-example-of-a-max_payloads-no" class="selfRef">Example of a MAX_PAYLOADS NON Request with the Q-Block1 Option (with
     Loss)</a>
            </figcaption></figure>
</div>
<p id="section-10.1.3-3">On seeing a payload from the next MAX_PAYLOADS_SET, the server
          realizes that some blocks are missing from the previous
          MAX_PAYLOADS_SET and asks for the missing blocks in one go (<a href="#B3non2" class="xref">Figure 5</a>). It does so by indicating which blocks from
          the previous MAX_PAYLOADS_SET have not been received in the data
          portion of the response (<a href="#code" class="xref">Section 5</a>). 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.<a href="#section-10.1.3-3" class="pilcrow">¶</a></p>
<span id="name-example-of-a-non-request-wit"></span><div id="B3non2">
<figure id="figure-5">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.1.3-4.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   |&lt;---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9]
   |     [[Client responds with missing payloads]]
   +---------&gt;| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024
   +---------&gt;| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024
   |     [[Client continues sending next MAX_PAYLOADS_SET]]
   +---------&gt;| 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]]
   |&lt;---------+ NON 4.08 M:0x92 T:0xef [Missing 10]
   +---------&gt;| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024
   |&lt;---------+ NON 2.04 M:0x93 T:0xf0
   |   ...    |
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-example-of-a-non-request-wit" class="selfRef">Example of a NON Request with the Q-Block1 Option (Block Recovery)</a>
            </figcaption></figure>
</div>
</section>
<section id="section-10.1.4">
          <h4 id="name-handling-recovery-if-failur">
<a href="#section-10.1.4" class="section-number selfRef">10.1.4. </a><a href="#name-handling-recovery-if-failur" class="section-name selfRef">Handling Recovery if Failure Occurs</a>
          </h4>
<p id="section-10.1.4-1"><a href="#B3non3" class="xref">Figure 6</a> depicts an example of a NON PUT
          request conveying the Q-Block1 option where recovery takes place but
          eventually fails.<a href="#section-10.1.4-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-non-request-with"></span><div id="B3non3">
<figure id="figure-6">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.1.4-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024
   +---&gt;X     | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024
   +---------&gt;| 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]]
   |&lt;---------+ 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]]
   |&lt;---------+ 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]]
   |&lt;---------+ 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]]
   |&lt;---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1]
   |   ...    |
[[16 * NON_RECEIVE_TIMEOUT (server) delay expires]]
   |     [[NON_MAX_RETRANSMIT exceeded.  Server stops requesting
   |       the missing blocks and releases partial body]]
   |   ...    |
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-example-of-a-non-request-with" class="selfRef">Example of a NON Request with the Q-Block1 Option (with Eventual
     Failure)</a>
            </figcaption></figure>
</div>
</section>
</section>
<section id="section-10.2">
        <h3 id="name-q-block2-option">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-q-block2-option" class="section-name selfRef">Q-Block2 Option</a>
        </h3>
<p id="section-10.2-1">These examples include the Observe option to demonstrate how that
        option is used. Note that the Observe option is not required for
        Q-Block2.<a href="#section-10.2-1" class="pilcrow">¶</a></p>
<section id="section-10.2.1">
          <h4 id="name-a-simple-example-2">
<a href="#section-10.2.1" class="section-number selfRef">10.2.1. </a><a href="#name-a-simple-example-2" class="section-name selfRef">A Simple Example</a>
          </h4>
<p id="section-10.2.1-1"><a href="#nonb4" class="xref">Figure 7</a> illustrates an example of the Q-Block2
          option. The client sends a NON GET carrying the Observe and Q-Block2
          options. The Q-Block2 option indicates a block size hint (1024
          bytes). The server replies to this request using four (4)
          blocks that are transmitted to the client without any loss. Each of
          these blocks carries a Q-Block2 option. The same process is repeated
          when an Observe is triggered, but no loss is experienced by any of
          the notification blocks.<a href="#section-10.2.1-1" class="pilcrow">¶</a></p>
<span id="name-example-of-non-notification"></span><div id="nonb4">
<figure id="figure-7">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.2.1-2.1">
<pre>
 CoAP        CoAP
Client      Server
  |          |
  +---------&gt;| NON GET /path M:0x01 T:0xc0 O:0 QB2:0/1/1024
  |&lt;---------+ NON 2.05 M:0xf1 T:0xc0 O:1220 ET=19 QB2:0/1/1024
  |&lt;---------+ NON 2.05 M:0xf2 T:0xc0 O:1220 ET=19 QB2:1/1/1024
  |&lt;---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024
  |&lt;---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024
  |   ...    |
  |     [[Observe triggered]]
  |&lt;---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024
  |&lt;---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024
  |&lt;---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024
  |&lt;---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024
  |   ...    |
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-example-of-non-notification" class="selfRef">Example of NON Notifications with the Q-Block2 Option (without Loss)</a>
            </figcaption></figure>
</div>
</section>
<section id="section-10.2.2">
          <h4 id="name-handling-max_payloads-limits">
<a href="#section-10.2.2" class="section-number selfRef">10.2.2. </a><a href="#name-handling-max_payloads-limits" class="section-name selfRef">Handling MAX_PAYLOADS Limits</a>
          </h4>
<p id="section-10.2.2-1"><a href="#nonb40" class="xref">Figure 8</a> illustrates the same scenario as <a href="#nonb4" class="xref">Figure 7</a>, but this time with eleven (11) payloads, which
          exceeds MAX_PAYLOADS. There is no loss experienced.<a href="#section-10.2.2-1" class="pilcrow">¶</a></p>
<span id="name-example-of-non-notifications"></span><div id="nonb40">
<figure id="figure-8">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.2.2-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
   |&lt;---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024
   |&lt;---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024
   |&lt;---------+ [[Payloads 3 - 9 not detailed]]
   |&lt;---------+ 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]]
   +---------&gt;| NON GET /path M:0x02 T:0xf1 QB2:10/1/1024
   |&lt;---------+ NON 2.05 M:0x8b T:0xf0 O:1234 ET=21 QB2:10/0/1024
   |   ...    |
   |     [[Observe triggered]]
   |&lt;---------+ NON 2.05 M:0x91 T:0xf0 O:1235 ET=22 QB2:0/1/1024
   |&lt;---------+ NON 2.05 M:0x92 T:0xf0 O:1235 ET=22 QB2:1/1/1024
   |&lt;---------+ [[Payloads 3 - 9 not detailed]]
   |&lt;---------+ 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]]
   +---------&gt;| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024
   |&lt;---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024
[[Body has been received]]
   |   ...    |
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-example-of-non-notifications" class="selfRef">Example of NON Notifications with the Q-Block2 Option (without
     Loss)</a>
            </figcaption></figure>
</div>
</section>
<section id="section-10.2.3">
          <h4 id="name-handling-max_payloads-with-r">
<a href="#section-10.2.3" class="section-number selfRef">10.2.3. </a><a href="#name-handling-max_payloads-with-r" class="section-name selfRef">Handling MAX_PAYLOADS with Recovery</a>
          </h4>
<p id="section-10.2.3-1"><a href="#nonb41" class="xref">Figure 9</a> shows an example of an Observe
          that is triggered but for which some notification blocks are lost.
          The client detects the missing blocks and requests their
          retransmission. It does so by indicating the blocks that are missing
          as one or more Q-Block2 options.<a href="#section-10.2.3-1" class="pilcrow">¶</a></p>
<span id="name-example-of-non-notifications-"></span><div id="nonb41">
<figure id="figure-9">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.2.3-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |   ...    |
   |     [[Observe triggered]]
   |&lt;---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024
   |     X&lt;---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
   |&lt;---------+ [[Payloads 3 - 9 not detailed]]
   |     X&lt;---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024
[[Some of the MAX_PAYLOADS_SET has been received]]
   |   ...    |
[[NON_TIMEOUT_RANDOM (server) delay expires]]
   |     [[Server sends next MAX_PAYLOADS_SET]]
   |&lt;---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024
   |     [[On seeing a payload from the next MAX_PAYLOADS_SET,
   |       client realizes blocks are missing and asks for the
   |       missing ones in one go]]
   +---------&gt;| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
   |          |                             QB2:9/0/1024
   |     X&lt;---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024
   |&lt;---------+ 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]]
   +---------&gt;| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024
   |&lt;---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024
[[Body has been received]]
   |   ...    |
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-example-of-non-notifications-" class="selfRef">Example of NON Notifications with the Q-Block2 Option (Block 
     Recovery)</a>
            </figcaption></figure>
</div>
</section>
<div id="sec-nonb411">
<section id="section-10.2.4">
          <h4 id="name-handling-recovery-by-settin">
<a href="#section-10.2.4" class="section-number selfRef">10.2.4. </a><a href="#name-handling-recovery-by-settin" class="section-name selfRef">Handling Recovery by Setting the M Bit</a>
          </h4>
<p id="section-10.2.4-1"><a href="#nonb411" class="xref">Figure 10</a> shows an example where an Observe
          is triggered but only the first two notification blocks reach
          the client. In order to retrieve the missing blocks, the client
          sends a request with a single Q-Block2 option with the M bit
          set.<a href="#section-10.2.4-1" class="pilcrow">¶</a></p>
<span id="name-example-of-non-notifications-w"></span><div id="nonb411">
<figure id="figure-10">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.2.4-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |   ...    |
   |     [[Observe triggered]]
   |&lt;---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024
   |&lt;---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024
   |     X&lt;---+ NON 2.05 M:0xb3 T:0xf0 O:1237 ET=24 QB2:2/1/1024
   |     X&lt;---+ [[Payloads 4 - 9 not detailed]]
   |     X&lt;---+ NON 2.05 M:0xb9 T:0xf0 O:1237 ET=24 QB2:9/1/1024
[[Some of the MAX_PAYLOADS_SET has been received]]
   |   ...    |
[[NON_TIMEOUT_RANDOM (server) delay expires]]
   |     [[Server sends next MAX_PAYLOADS_SET]]
   |     X&lt;---+ 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]]
   +---------&gt;| NON GET /path M:0x06 T:0xf5 QB2:2/1/1024
   |&lt;---------+ NON 2.05 M:0xbb T:0xf5 ET=24 QB2:2/1/1024
   |&lt;---------+ [[Payloads 3 - 9 not detailed]]
   |&lt;---------+ 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]]
   +---------&gt;| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024
   |&lt;---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024
[[Body has been received]]
   |   ...    |
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-example-of-non-notifications-w" class="selfRef">Example of NON Notifications with the Q-Block2 Option (Block Recovery
     with the M Bit Set)</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
<section id="section-10.3">
        <h3 id="name-q-block1-and-q-block2-optio">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-q-block1-and-q-block2-optio" class="section-name selfRef">Q-Block1 and Q-Block2 Options</a>
        </h3>
<section id="section-10.3.1">
          <h4 id="name-a-simple-example-3">
<a href="#section-10.3.1" class="section-number selfRef">10.3.1. </a><a href="#name-a-simple-example-3" class="section-name selfRef">A Simple Example</a>
          </h4>
<p id="section-10.3.1-1"><a href="#b12non" class="xref">Figure 11</a> illustrates an example of a FETCH
          using both the Q-Block1 and Q-Block2 options along with an Observe
          option. No loss is experienced.<a href="#section-10.3.1-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-non-fetch-with"></span><div id="b12non">
<figure id="figure-11">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.3.1-2.1">
<pre>
 CoAP        CoAP
Client      Server
  |          |
  +---------&gt;| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024
  +---------&gt;| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024
  +---------&gt;| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024
  |&lt;---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024
  |&lt;---------+ NON 2.05 M:0x61 T:0x93 O:1320 ET=90 QB2:1/1/1024
  |&lt;---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024
  |&lt;---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024
  |   ...    |
  |     [[Observe triggered]]
  |&lt;---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024
  |&lt;---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024
  |&lt;---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024
  |&lt;---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024
  |   ...    |
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-example-of-a-non-fetch-with" class="selfRef">Example of a NON FETCH with the Q-Block1 and Q-Block2 Options (without
     Loss)</a>
            </figcaption></figure>
</div>
</section>
<section id="section-10.3.2">
          <h4 id="name-handling-max_payloads-limits-2">
<a href="#section-10.3.2" class="section-number selfRef">10.3.2. </a><a href="#name-handling-max_payloads-limits-2" class="section-name selfRef">Handling MAX_PAYLOADS Limits</a>
          </h4>
<p id="section-10.3.2-1"><a href="#b12non0" class="xref">Figure 12</a> illustrates the same scenario as <a href="#b12non" class="xref">Figure 11</a>, but this time with eleven (11) payloads in
          both directions, which exceeds MAX_PAYLOADS. There is no loss
          experienced.<a href="#section-10.3.2-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-non-fetch-with-"></span><div id="b12non0">
<figure id="figure-12">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.3.2-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024
   +---------&gt;| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024
   +---------&gt;| [[Payloads 3 - 9 not detailed]]
   +---------&gt;| 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]]
   |&lt;---------+ NON 2.31 M:0x80 T:0xa9
   +---------&gt;| NON FETCH /path M:0x3a T:0xaa O:0 RT=10 QB1:10/0/1024
   |&lt;---------+ NON 2.05 M:0x81 T:0xaa O:1334 ET=21 QB2:0/1/1024
   |&lt;---------+ NON 2.05 M:0x82 T:0xaa O:1334 ET=21 QB2:1/1/1024
   |&lt;---------+ [[Payloads 3 - 9 not detailed]]
   |&lt;---------+ 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]]
   +---------&gt;| NON FETCH /path M:0x3b T:0xab QB2:10/1/1024
   |&lt;---------+ NON 2.05 M:0x8b T:0xaa O:1334 ET=21 QB2:10/0/1024
   |   ...    |
   |     [[Observe triggered]]
   |&lt;---------+ NON 2.05 M:0x8c T:0xaa O:1335 ET=22 QB2:0/1/1024
   |&lt;---------+ NON 2.05 M:0x8d T:0xaa O:1335 ET=22 QB2:1/1/1024
   |&lt;---------+ [[Payloads 3 - 9 not detailed]]
   |&lt;---------+ 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]]
   +---------&gt;| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024
   |&lt;---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024
[[Body has been received]]
   |   ...    |
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-example-of-a-non-fetch-with-" class="selfRef">Example of a NON FETCH with the Q-Block1 and Q-Block2 Options (without
     Loss)</a>
            </figcaption></figure>
</div>
<p id="section-10.3.2-3">Note that, as 'Continue' was used, the server continues to use the
          same token (0xaa), since the 'Continue' is not being used as a
          request for a new set of packets but rather is being used to
          instruct the server to continue its transmission (<a href="#cc-non" class="xref">Section 7.2</a>).<a href="#section-10.3.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-10.3.3">
          <h4 id="name-handling-recovery">
<a href="#section-10.3.3" class="section-number selfRef">10.3.3. </a><a href="#name-handling-recovery" class="section-name selfRef">Handling Recovery</a>
          </h4>
<p id="section-10.3.3-1">Consider now a scenario where some blocks are lost in
          transmission, as illustrated in <a href="#b12non1" class="xref">Figure 13</a>.<a href="#section-10.3.3-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-non-fetch-with-t"></span><div id="b12non1">
<figure id="figure-13">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.3.3-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024
   +---&gt;X     | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024
   +---&gt;X     | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024
   +---------&gt;| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024
   |   ...    |
[[NON_RECEIVE_TIMEOUT (server) delay expires]]
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-example-of-a-non-fetch-with-t" class="selfRef">Example of a NON FETCH with the Q-Block1 and Q-Block2 Options (with
     Loss)</a>
            </figcaption></figure>
</div>
<p id="section-10.3.3-3">The server realizes that some blocks are missing and asks for the
          missing blocks in one go (<a href="#b12non2" class="xref">Figure 14</a>). 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.<a href="#section-10.3.3-3" class="pilcrow">¶</a></p>
<span id="name-example-of-a-non-request-with-"></span><div id="b12non2">
<figure id="figure-14">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.3.3-4.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   |&lt;---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2]
   |     [[Client responds with missing payloads]]
   +---------&gt;| NON FETCH /path M:0x54 T:0xc4 O:0 RT=31 QB1:1/1/1024
   +---------&gt;| NON FETCH /path M:0x55 T:0xc5 O:0 RT=31 QB1:2/1/1024
   |     [[Server received FETCH body,
   |       starts transmitting response body]]
   |&lt;---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024
   |     X&lt;---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024
   |&lt;---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024
   |     X&lt;---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024
   |   ...    |
[[NON_RECEIVE_TIMEOUT (client) delay expires]]
   |          |
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-example-of-a-non-request-with-" class="selfRef">Example of a NON Request with the Q-Block1 Option (Server Recovery)</a>
            </figcaption></figure>
</div>
<p id="section-10.3.3-5">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 (<a href="#b12non3" class="xref">Figure 15</a>). Note that, following
          <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-2.7" class="relref">Section 2.7</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span>, the
   FETCH request does not include the Q-Block1 or any payload.<a href="#section-10.3.3-5" class="pilcrow">¶</a></p>
<span id="name-example-of-a-non-request-with-t"></span><div id="b12non3">
<figure id="figure-15">
            <div class="alignLeft art-ascii-art art-text artwork" id="section-10.3.3-6.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| 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&lt;---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024
   |&lt;---------+ 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]]
   +---------&gt;| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024
   |     [[Server receives FETCH request for missing payload,
   |       starts transmitting missing block]]
   |&lt;---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024
[[Body has been received]]
   |   ...    |
   |     [[Observe triggered]]
   |&lt;---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024
   |     X&lt;---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024
   |&lt;---------+ 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]]
   +---------&gt;| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024
   |     [[Server receives FETCH request for missing payload,
   |       starts transmitting missing block]]
   |&lt;---------+ NON 2.05 M:0xa7 T:0xc8 ET=24 QB2:1/1/1024
[[Body has been received]]
   |   ...    |
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-example-of-a-non-request-with-t" class="selfRef">Example of a NON Request with the Q-Block1 Option (Client Recovery)</a>
            </figcaption></figure>
</div>
</section>
</section>
</section>
</div>
<div id="security">
<section id="section-11">
      <h2 id="name-security-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-11-1">Security considerations discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc7959#section-7" class="relref">Section 7</a> of [<a href="#RFC7959" class="xref">RFC7959</a>]</span> should be taken into account.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">Security considerations discussed in Sections <a href="https://www.rfc-editor.org/rfc/rfc7252#section-11.3" class="relref">11.3</a> and <a href="https://www.rfc-editor.org/rfc/rfc7252#section-11.4" class="relref">11.4</a> of <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> should also be
      taken into account.<a href="#section-11-2" class="pilcrow">¶</a></p>
<p id="section-11-3">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 (<span><a href="https://www.rfc-editor.org/rfc/rfc8613#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>). It can be
      trusted that the source endpoint is legitimate even if the NoSec 
      mode is used. However, an intermediary node can modify the unprotected
      Outer Q-Block1 and/or Q-Block2 options to cause a Q-Block transfer to
      fail or keep requesting all the blocks by setting the M bit and thus
      causing attack amplification. As discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc8613#section-12.1" class="relref">Section 12.1</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>, applications need to consider that certain
      message fields and message types are not protected end to end and may
      be spoofed or manipulated. Therefore, it is <span class="bcp14">NOT RECOMMENDED</span> to use the
      NoSec mode if either the Q-Block1 or Q-Block2 option is
      used.<a href="#section-11-3" class="pilcrow">¶</a></p>
<p id="section-11-4">If OSCORE is not used, it is also <span class="bcp14">NOT RECOMMENDED</span> to use the NoSec
      mode if either the Q-Block1 or Q-Block2 option is used.<a href="#section-11-4" class="pilcrow">¶</a></p>
<p id="section-11-5">If NoSec is being used, <span><a href="https://www.rfc-editor.org/rfc/rfc8613#appendix-D.5" class="relref">Appendix D.5</a> of [<a href="#RFC8613" class="xref">RFC8613</a>]</span>
      discusses the security analysis and considerations for unprotected
      message fields even if OSCORE is not being used.<a href="#section-11-5" class="pilcrow">¶</a></p>
<p id="section-11-6">Security considerations related to the use of Request-Tag are
      discussed in <span><a href="https://www.rfc-editor.org/rfc/rfc9175#section-5" class="relref">Section 5</a> of [<a href="#RFC9175" class="xref">RFC9175</a>]</span>.<a href="#section-11-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-12">
      <h2 id="name-iana-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-coap-option-numbers-registr">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-coap-option-numbers-registr" class="section-name selfRef">CoAP Option Numbers Registry</a>
        </h3>
<p id="section-12.1-1">IANA has added the following entries to the "CoAP Option Numbers"
        subregistry <span>[<a href="#IANA-Options" class="xref">IANA-Options</a>]</span> defined in <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span> within the "Constrained RESTful
        Environments (CoRE) Parameters" registry:<a href="#section-12.1-1" class="pilcrow">¶</a></p>
<span id="name-additions-to-coap-option-nu"></span><table class="center" id="table-4">
          <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-additions-to-coap-option-nu" class="selfRef">Additions to CoAP Option Numbers Registry</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Number</th>
              <th class="text-left" rowspan="1" colspan="1">Name</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">19</td>
              <td class="text-left" rowspan="1" colspan="1">Q-Block1</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9177</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">31</td>
              <td class="text-left" rowspan="1" colspan="1">Q-Block2</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9177</td>
            </tr>
          </tbody>
        </table>
</section>
<section id="section-12.2">
        <h3 id="name-media-type-registration">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-media-type-registration" class="section-name selfRef">Media Type Registration</a>
        </h3>
<p id="section-12.2-1">IANA has registered the
        "application/missing-blocks+cbor-seq" media type in the "Media Types"
        registry <span>[<a href="#IANA-MediaTypes" class="xref">IANA-MediaTypes</a>]</span>. This registration
        follows the procedures specified in <span>[<a href="#RFC6838" class="xref">RFC6838</a>]</span>.<a href="#section-12.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-12.2-2">
          <dt id="section-12.2-2.1">Type name:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.2">application<a href="#section-12.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.3">Subtype name:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.4">missing-blocks+cbor-seq<a href="#section-12.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.5">Required parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.6">N/A<a href="#section-12.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.7">Optional parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.8">N/A<a href="#section-12.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.9">Encoding considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.10">Must be encoded as a CBOR Sequence <span>[<a href="#RFC8742" class="xref">RFC8742</a>]</span>,
   as defined in <a href="#code" class="xref">Section 5</a> of RFC 9177.<a href="#section-12.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.11">Security considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.12">See <a href="#security" class="xref">Section 11</a> of RFC 9177.<a href="#section-12.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.13">Interoperability considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.14">N/A<a href="#section-12.2-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.15">Published specification:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.16">RFC 9177<a href="#section-12.2-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.17">Applications that use this media type:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.18">Data serialization and
   deserialization. In particular, the type is used by applications
   relying upon block-wise transfers, allowing a server to specify
   non-received blocks and request their retransmission, as 
   defined in <a href="#spec" class="xref">Section 4</a> of RFC 9177.<a href="#section-12.2-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.19">Fragment identifier considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.20">N/A<a href="#section-12.2-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.21">Additional information:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.22">N/A<a href="#section-12.2-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.23">Person &amp; email address to contact for further information:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.24">IETF, iesg@ietf.org<a href="#section-12.2-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.25">Intended usage:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.26">COMMON<a href="#section-12.2-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.27">Restrictions on usage:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.28">none<a href="#section-12.2-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.29">Author:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.30">See Authors' Addresses section of RFC 9177.<a href="#section-12.2-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.31">Change controller:</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.32">IESG<a href="#section-12.2-2.32" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.33">Provisional registration?</dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.34">No<a href="#section-12.2-2.34" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<div id="new-format">
<section id="section-12.3">
        <h3 id="name-coap-content-formats-regist">
<a href="#section-12.3" class="section-number selfRef">12.3. </a><a href="#name-coap-content-formats-regist" class="section-name selfRef">CoAP Content-Formats Registry</a>
        </h3>
<p id="section-12.3-1">IANA has registered the following CoAP
        Content-Format for the "application/missing-blocks+cbor-seq" media
        type in the "CoAP Content-Formats" registry <span>[<a href="#IANA-Format" class="xref">IANA-Format</a>]</span> defined in <span>[<a href="#RFC7252" class="xref">RFC7252</a>]</span>
        within the "Constrained RESTful Environments (CoRE) Parameters"
        registry:<a href="#section-12.3-1" class="pilcrow">¶</a></p>
<span id="name-addition-to-coap-content-fo"></span><table class="center" id="table-5">
          <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-addition-to-coap-content-fo" class="selfRef">Addition to CoAP Content-Format Registry</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Media Type</th>
              <th class="text-left" rowspan="1" colspan="1">Encoding</th>
              <th class="text-left" rowspan="1" colspan="1">ID</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">application/missing-blocks+cbor-seq</td>
              <td class="text-left" rowspan="1" colspan="1">-</td>
              <td class="text-left" rowspan="1" colspan="1">272</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9177</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
</section>
</div>
<section id="section-13">
      <h2 id="name-references">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-13.1">
        <h3 id="name-normative-references">
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6838">[RFC6838]</dt>
        <dd>
<span class="refAuthor">Freed, N.</span>, <span class="refAuthor">Klensin, J.</span>, and <span class="refAuthor">T. Hansen</span>, <span class="refTitle">"Media Type Specifications and Registration Procedures"</span>, <span class="seriesInfo">BCP 13</span>, <span class="seriesInfo">RFC 6838</span>, <span class="seriesInfo">DOI 10.17487/RFC6838</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6838">https://www.rfc-editor.org/info/rfc6838</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7252">[RFC7252]</dt>
        <dd>
<span class="refAuthor">Shelby, Z.</span>, <span class="refAuthor">Hartke, K.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"The Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7252</span>, <span class="seriesInfo">DOI 10.17487/RFC7252</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7252">https://www.rfc-editor.org/info/rfc7252</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7641">[RFC7641]</dt>
        <dd>
<span class="refAuthor">Hartke, K.</span>, <span class="refTitle">"Observing Resources in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7641</span>, <span class="seriesInfo">DOI 10.17487/RFC7641</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7641">https://www.rfc-editor.org/info/rfc7641</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7959">[RFC7959]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">Z. Shelby, Ed.</span>, <span class="refTitle">"Block-Wise Transfers in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 7959</span>, <span class="seriesInfo">DOI 10.17487/RFC7959</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7959">https://www.rfc-editor.org/info/rfc7959</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8075">[RFC8075]</dt>
        <dd>
<span class="refAuthor">Castellani, A.</span>, <span class="refAuthor">Loreto, S.</span>, <span class="refAuthor">Rahman, A.</span>, <span class="refAuthor">Fossati, T.</span>, and <span class="refAuthor">E. Dijk</span>, <span class="refTitle">"Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 8075</span>, <span class="seriesInfo">DOI 10.17487/RFC8075</span>, <time datetime="2017-02" class="refDate">February 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8075">https://www.rfc-editor.org/info/rfc8075</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8132">[RFC8132]</dt>
        <dd>
<span class="refAuthor">van der Stok, P.</span>, <span class="refAuthor">Bormann, C.</span>, and <span class="refAuthor">A. Sehgal</span>, <span class="refTitle">"PATCH and FETCH Methods for the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 8132</span>, <span class="seriesInfo">DOI 10.17487/RFC8132</span>, <time datetime="2017-04" class="refDate">April 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8132">https://www.rfc-editor.org/info/rfc8132</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8323">[RFC8323]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refAuthor">Lemay, S.</span>, <span class="refAuthor">Tschofenig, H.</span>, <span class="refAuthor">Hartke, K.</span>, <span class="refAuthor">Silverajan, B.</span>, and <span class="refAuthor">B. Raymor, Ed.</span>, <span class="refTitle">"CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets"</span>, <span class="seriesInfo">RFC 8323</span>, <span class="seriesInfo">DOI 10.17487/RFC8323</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8323">https://www.rfc-editor.org/info/rfc8323</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8610">[RFC8610]</dt>
        <dd>
<span class="refAuthor">Birkholz, H.</span>, <span class="refAuthor">Vigano, C.</span>, and <span class="refAuthor">C. Bormann</span>, <span class="refTitle">"Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures"</span>, <span class="seriesInfo">RFC 8610</span>, <span class="seriesInfo">DOI 10.17487/RFC8610</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8610">https://www.rfc-editor.org/info/rfc8610</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8613">[RFC8613]</dt>
        <dd>
<span class="refAuthor">Selander, G.</span>, <span class="refAuthor">Mattsson, J.</span>, <span class="refAuthor">Palombini, F.</span>, and <span class="refAuthor">L. Seitz</span>, <span class="refTitle">"Object Security for Constrained RESTful Environments (OSCORE)"</span>, <span class="seriesInfo">RFC 8613</span>, <span class="seriesInfo">DOI 10.17487/RFC8613</span>, <time datetime="2019-07" class="refDate">July 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8613">https://www.rfc-editor.org/info/rfc8613</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8742">[RFC8742]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR) Sequences"</span>, <span class="seriesInfo">RFC 8742</span>, <span class="seriesInfo">DOI 10.17487/RFC8742</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8742">https://www.rfc-editor.org/info/rfc8742</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8949">[RFC8949]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">STD 94</span>, <span class="seriesInfo">RFC 8949</span>, <span class="seriesInfo">DOI 10.17487/RFC8949</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8949">https://www.rfc-editor.org/info/rfc8949</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9175">[RFC9175]</dt>
      <dd>
<span class="refAuthor">Amsüss, C.</span>, <span class="refAuthor">Preuß Mattsson, J.</span>, and <span class="refAuthor">G. Selander</span>, <span class="refTitle">"Constrained Application Protocol (CoAP): Echo, Request-Tag, and Token Processing"</span>, <span class="seriesInfo">RFC 9175</span>, <span class="seriesInfo">DOI 10.17487/RFC9175</span>, <time datetime="2022-02" class="refDate">February 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9175">https://www.rfc-editor.org/info/rfc9175</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-13.2">
        <h3 id="name-informative-references">
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.bosh-dots-quick-blocks">[DOTS-QUICK-BLOCKS]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span> and <span class="refAuthor">J. Shallow</span>, <span class="refTitle">"Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Configuration Attributes for Robust Block Transmission"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-bosh-dots-quick-blocks-03</span>, <time datetime="2021-06-29" class="refDate">29 June 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-bosh-dots-quick-blocks-03">https://datatracker.ietf.org/doc/html/draft-bosh-dots-quick-blocks-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DOTS-TELEMETRY">[DOTS-TELEMETRY]</dt>
        <dd>
<span class="refAuthor">Boucadair, M., Ed.</span>, <span class="refAuthor">Reddy.K, T., Ed.</span>, <span class="refAuthor">Doron, E.</span>, <span class="refAuthor">Chen, M.</span>, and <span class="refAuthor">J. Shallow</span>, <span class="refTitle">"Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-dots-telemetry-19</span>, <time datetime="2022-01-04" class="refDate">4 January 2022</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-19">https://datatracker.ietf.org/doc/html/draft-ietf-dots-telemetry-19</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA-Format">[IANA-Format]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"CoAP Content-Formats"</span>, <span>&lt;<a href="https://www.iana.org/assignments/core-parameters/">https://www.iana.org/assignments/core-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA-MediaTypes">[IANA-MediaTypes]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Media Types"</span>, <span>&lt;<a href="https://www.iana.org/assignments/media-types/">https://www.iana.org/assignments/media-types/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA-Options">[IANA-Options]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"CoAP Option Numbers"</span>, <span>&lt;<a href="https://www.iana.org/assignments/core-parameters/">https://www.iana.org/assignments/core-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6928">[RFC6928]</dt>
        <dd>
<span class="refAuthor">Chu, J.</span>, <span class="refAuthor">Dukkipati, N.</span>, <span class="refAuthor">Cheng, Y.</span>, and <span class="refAuthor">M. Mathis</span>, <span class="refTitle">"Increasing TCP's Initial Window"</span>, <span class="seriesInfo">RFC 6928</span>, <span class="seriesInfo">DOI 10.17487/RFC6928</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6928">https://www.rfc-editor.org/info/rfc6928</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7967">[RFC7967]</dt>
        <dd>
<span class="refAuthor">Bhattacharyya, A.</span>, <span class="refAuthor">Bandyopadhyay, S.</span>, <span class="refAuthor">Pal, A.</span>, and <span class="refAuthor">T. Bose</span>, <span class="refTitle">"Constrained Application Protocol (CoAP) Option for No Server Response"</span>, <span class="seriesInfo">RFC 7967</span>, <span class="seriesInfo">DOI 10.17487/RFC7967</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7967">https://www.rfc-editor.org/info/rfc7967</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8974">[RFC8974]</dt>
        <dd>
<span class="refAuthor">Hartke, K.</span> and <span class="refAuthor">M. Richardson</span>, <span class="refTitle">"Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)"</span>, <span class="seriesInfo">RFC 8974</span>, <span class="seriesInfo">DOI 10.17487/RFC8974</span>, <time datetime="2021-01" class="refDate">January 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8974">https://www.rfc-editor.org/info/rfc8974</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9132">[RFC9132]</dt>
      <dd>
<span class="refAuthor">Boucadair, M., Ed.</span>, <span class="refAuthor">Shallow, J.</span>, and <span class="refAuthor">T. Reddy.K</span>, <span class="refTitle">"Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification"</span>, <span class="seriesInfo">RFC 9132</span>, <span class="seriesInfo">DOI 10.17487/RFC9132</span>, <time datetime="2021-09" class="refDate">September 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9132">https://www.rfc-editor.org/info/rfc9132</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="CON">
<section id="appendix-A">
      <h2 id="name-examples-with-confirmable-m">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-examples-with-confirmable-m" class="section-name selfRef">Examples with Confirmable Messages</a>
      </h2>
<p id="appendix-A-1">The following examples assume NSTART has been increased to 3.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">The conventions provided in <a href="#non-confirm" class="xref">Section 10</a> are used
      in the following subsections.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<section id="appendix-A.1">
        <h3 id="name-q-block1-option-2">
<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-q-block1-option-2" class="section-name selfRef">Q-Block1 Option</a>
        </h3>
<p id="appendix-A.1-1">Let's now consider the use of the Q-Block1 option with a CON request, as
        shown in <a href="#con3" class="xref">Figure 16</a>. All the blocks are acknowledged
 (as noted with "ACK").<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-con-request-wi"></span><div id="con3">
<figure id="figure-16">
          <div class="alignLeft art-ascii-art art-text artwork" id="appendix-A.1-2.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024
   +---------&gt;| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024
   +---------&gt;| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
[[NSTART(3) limit reached]]
   |&lt;---------+ ACK 0.00 M:0x01
   +---------&gt;| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
   |&lt;---------+ ACK 0.00 M:0x02
   |&lt;---------+ ACK 0.00 M:0x03
   |&lt;---------+ ACK 2.04 M:0x04
   |          |
</pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
<a href="#name-example-of-a-con-request-wi" class="selfRef">Example of a CON Request with the Q-Block1 Option (without Loss)</a>
          </figcaption></figure>
</div>
<p id="appendix-A.1-3">Now, suppose that a new body of data is to be sent but with some
        blocks dropped in transmission, as illustrated in <a href="#con32" class="xref">Figure 17</a>. The client will retry sending blocks for which
        no ACK was received.<a href="#appendix-A.1-3" class="pilcrow">¶</a></p>
<span id="name-example-of-a-con-request-wit"></span><div id="con32">
<figure id="figure-17">
          <div class="alignLeft art-ascii-art art-text artwork" id="appendix-A.1-4.1">
<pre>
  CoAP        CoAP
 Client      Server
   |          |
   +---------&gt;| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024
   +---&gt;X     | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
   +---&gt;X     | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
[[NSTART(3) limit reached]]
   |&lt;---------+ ACK 0.00 M:0x05
   +---------&gt;| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024
   |&lt;---------+ ACK 0.00 M:0x08
   |   ...    |
[[ACK TIMEOUT (client) for M:0x06 delay expires]]
   |     [[Client retransmits packet]]
   +---------&gt;| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
[[ACK TIMEOUT (client) for M:0x07 delay expires]]
   |     [[Client retransmits packet]]
   +---&gt;X     | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
   |&lt;---------+ ACK 0.00 M:0x06
   |   ...    |
[[ACK TIMEOUT exponential backoff (client) delay expires]]
   |     [[Client retransmits packet]]
   +---&gt;X     | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
   |   ...    |
[[Either body transmission failure (acknowledge retry timeout)
   or successfully transmitted]]
</pre>
</div>
<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
<a href="#name-example-of-a-con-request-wit" class="selfRef">Example of a CON Request with the Q-Block1 Option (Block Recovery)</a>
          </figcaption></figure>
</div>
<p id="appendix-A.1-5">It is up to the implementation as to whether the application
        process stops trying to send this particular body of data on reaching
        MAX_RETRANSMIT for any payload or separately tries to initiate the
        new transmission of the payloads that have not been acknowledged under
        these adverse traffic conditions.<a href="#appendix-A.1-5" class="pilcrow">¶</a></p>
<p id="appendix-A.1-6">If transient network losses are possible, then the use of NON should be considered.<a href="#appendix-A.1-6" class="pilcrow">¶</a></p>
</section>
<section id="appendix-A.2">
        <h3 id="name-q-block2-option-2">
<a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-q-block2-option-2" class="section-name selfRef">Q-Block2 Option</a>
        </h3>
<p id="appendix-A.2-1">An example of the use of the Q-Block2 option with Confirmable messages
        is shown in <a href="#b4con" class="xref">Figure 18</a>.<a href="#appendix-A.2-1" class="pilcrow">¶</a></p>
<span id="name-example-of-con-notification"></span><div id="b4con">
<figure id="figure-18">
          <div class="alignLeft art-ascii-art art-text artwork" id="appendix-A.2-2.1">
<pre>
 Client      Server
   |          |
   +---------&gt;| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
   |&lt;---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024
   |&lt;---------+ CON 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024
   |&lt;---------+ CON 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024
   |&lt;---------+ CON 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024
   |---------&gt;+ ACK 0.00 M:0xe1
   |---------&gt;+ ACK 0.00 M:0xe2
   |---------&gt;+ ACK 0.00 M:0xe3
   |   ...    |
   |     [[Observe triggered]]
   |&lt;---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024
   |&lt;---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024
   |&lt;---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024
[[NSTART(3) limit reached]]
   |---------&gt;+ ACK 0.00 M:0xe4
   |&lt;---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024
   |---------&gt;+ ACK 0.00 M:0xe5
   |---------&gt;+ ACK 0.00 M:0xe6
   |---------&gt;+ ACK 0.00 M:0xe7
   |   ...    |
   |     [[Observe triggered]]
   |&lt;---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024
   |     X&lt;---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
   |     X&lt;---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
[[NSTART(3) limit reached]]
   |---------&gt;+ ACK 0.00 M:0xe8
   |&lt;---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024
   |---------&gt;+ ACK 0.00 M:0xeb
   |   ...    |
[[ACK TIMEOUT (server) for M:0xe9 delay expires]]
   |     [[Server retransmits packet]]
   |&lt;---------+ 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&lt;---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
   |---------&gt;+ ACK 0.00 M:0xe9
   |   ...    |
[[ACK TIMEOUT exponential backoff (server) delay expires]]
   |     [[Server retransmits packet]]
   |     X&lt;---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
   |   ...    |
[[Either body transmission failure (acknowledge retry timeout)
   or successfully transmitted]]
</pre>
</div>
<figcaption><a href="#figure-18" class="selfRef">Figure 18</a>:
<a href="#name-example-of-con-notification" class="selfRef">Example of CON Notifications with the Q-Block2 Option</a>
          </figcaption></figure>
</div>
<p id="appendix-A.2-3">It is up to the implementation as to whether the application
        process stops trying to send this particular body of data on reaching
        MAX_RETRANSMIT for any payload or separately tries to initiate the
        new transmission of the payloads that have not been acknowledged under
        these adverse traffic conditions.<a href="#appendix-A.2-3" class="pilcrow">¶</a></p>
<p id="appendix-A.2-4">If transient network losses are possible, then the use of NON should be considered.<a href="#appendix-A.2-4" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="REL">
<section id="appendix-B">
      <h2 id="name-examples-with-reliable-tran">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-examples-with-reliable-tran" class="section-name selfRef">Examples with Reliable Transports</a>
      </h2>
<p id="appendix-B-1">The conventions provided in <a href="#non-confirm" class="xref">Section 10</a> are used
      in the following subsections.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<section id="appendix-B.1">
        <h3 id="name-q-block1-option-3">
<a href="#appendix-B.1" class="section-number selfRef">B.1. </a><a href="#name-q-block1-option-3" class="section-name selfRef">Q-Block1 Option</a>
        </h3>
<p id="appendix-B.1-1">Let's now consider the use of the Q-Block1 option with a reliable
        transport, as shown in <a href="#rel3" class="xref">Figure 19</a>. There is no
        acknowledgment of packets at the CoAP layer, just the final
        result.<a href="#appendix-B.1-1" class="pilcrow">¶</a></p>
<span id="name-example-of-a-reliable-reque"></span><div id="rel3">
<figure id="figure-19">
          <div class="alignLeft art-ascii-art art-text artwork" id="appendix-B.1-2.1">
<pre>
 CoAP        CoAP
Client      Server
  |          |
  +---------&gt;| PUT /path T:0xf0 RT=10 QB1:0/1/1024
  +---------&gt;| PUT /path T:0xf1 RT=10 QB1:1/1/1024
  +---------&gt;| PUT /path T:0xf2 RT=10 QB1:2/1/1024
  +---------&gt;| PUT /path T:0xf3 RT=10 QB1:3/0/1024
  |&lt;---------+ 2.04
  |          |
</pre>
</div>
<figcaption><a href="#figure-19" class="selfRef">Figure 19</a>:
<a href="#name-example-of-a-reliable-reque" class="selfRef">Example of a Reliable Request with the Q-Block1 Option</a>
          </figcaption></figure>
</div>
<p id="appendix-B.1-3">If transient network losses are possible, then the use of unreliable transport with NON should be
        considered.<a href="#appendix-B.1-3" class="pilcrow">¶</a></p>
</section>
<section id="appendix-B.2">
        <h3 id="name-q-block2-option-3">
<a href="#appendix-B.2" class="section-number selfRef">B.2. </a><a href="#name-q-block2-option-3" class="section-name selfRef">Q-Block2 Option</a>
        </h3>
<p id="appendix-B.2-1">An example of the use of the Q-Block2 option with a reliable transport
        is shown in <a href="#b4rel" class="xref">Figure 20</a>.<a href="#appendix-B.2-1" class="pilcrow">¶</a></p>
<span id="name-example-of-notifications-wi"></span><div id="b4rel">
<figure id="figure-20">
          <div class="alignLeft art-ascii-art art-text artwork" id="appendix-B.2-2.1">
<pre>
Client      Server
  |          |
  +---------&gt;| GET /path T:0xf0 O:0 QB2:0/1/1024
  |&lt;---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:0/1/1024
  |&lt;---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:1/1/1024
  |&lt;---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:2/1/1024
  |&lt;---------+ 2.05 T:0xf0 O:1234 ET=21 QB2:3/0/1024
  |   ...    |
  |     [[Observe triggered]]
  |&lt;---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:0/1/1024
  |&lt;---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:1/1/1024
  |&lt;---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:2/1/1024
  |&lt;---------+ 2.05 T:0xf0 O:1235 ET=22 QB2:3/0/1024
  |   ...    |
</pre>
</div>
<figcaption><a href="#figure-20" class="selfRef">Figure 20</a>:
<a href="#name-example-of-notifications-wi" class="selfRef">Example of Notifications with the Q-Block2 Option</a>
          </figcaption></figure>
</div>
<p id="appendix-B.2-3">If transient network losses are possible, then the use of unreliable transport with NON should be
        considered.<a href="#appendix-B.2-3" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="appendix-C">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-C-1">Thanks to <span class="contact-name">Achim Kraus</span>, <span class="contact-name">Jim Schaad</span>,
      and <span class="contact-name">Michael Richardson</span> for their
      comments.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<p id="appendix-C-2">Special thanks to <span class="contact-name">Christian Amsüss</span>, <span class="contact-name">Carsten Bormann</span>, and <span class="contact-name">Marco       Tiloca</span> for their suggestions and several reviews, which improved this
      specification significantly. Thanks to <span class="contact-name">Francesca Palombini</span>
      for the AD review. Thanks to <span class="contact-name">Pete Resnick</span> for the Gen-ART
      review, <span class="contact-name">Colin Perkins</span> for the TSVART review, and
      <span class="contact-name">Emmanuel Baccelli</span> for
      the IOT-DIR review. Thanks to <span class="contact-name">Martin Duke</span>, <span class="contact-name">Éric Vyncke</span>, <span class="contact-name">Benjamin Kaduk</span>,
      <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">John Scudder</span>, and
      <span class="contact-name">Lars Eggert</span> for the IESG review.<a href="#appendix-C-2" class="pilcrow">¶</a></p>
<p id="appendix-C-3">Some text from <span>[<a href="#RFC7959" class="xref">RFC7959</a>]</span> is reused for the readers'
      convenience.<a href="#appendix-C-3" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="appendix-D">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mohamed Boucadair</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left">
<span class="postal-code">35000</span> <span class="locality">Rennes</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mohamed.boucadair@orange.com" class="email">mohamed.boucadair@orange.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jon Shallow</span></div>
<div dir="auto" class="left"><span class="country-name">United Kingdom</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:supjps-ietf@jpshallow.com" class="email">supjps-ietf@jpshallow.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>