draft-ietf-core-new-block-05.txt		draft-ietf-core-new-block-06.txt
	CORE M. Boucadair		CORE M. Boucadair
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track J. Shallow		Intended status: Standards Track J. Shallow
	Expires: July 17, 2021 January 13, 2021		Expires: July 23, 2021 January 19, 2021
	Constrained Application Protocol (CoAP) Block-Wise Transfer Options for		Constrained Application Protocol (CoAP) Block-Wise Transfer Options for
	Faster Transmission		Faster Transmission
	draft-ietf-core-new-block-05		draft-ietf-core-new-block-06
	Abstract		Abstract
	This document specifies alternative Constrained Application Protocol		This document specifies alternative Constrained Application Protocol
	(CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.		(CoAP) Block-Wise transfer options: Q-Block1 and Q-Block2 Options.
	These options are similar to the CoAP Block1 and Block2 Options, not		These options are similar to the CoAP Block1 and Block2 Options, not
	a replacement for them, but do enable faster transmission rates for		a replacement for them, but do enable faster transmission rates for
	large amounts of data with less packet interchanges as well as		large amounts of data with less packet interchanges as well as
	supporting faster recovery should any of the blocks get lost in		supporting faster recovery should any of the blocks get lost in
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on July 17, 2021.		This Internet-Draft will expire on July 23, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 18 ¶		skipping to change at page 2, line 18 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3		1.1. Alternative CoAP Block-Wise Transfer Options . . . . . . 3
	1.2. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 5		1.2. CoAP Response Code (4.08) Usage . . . . . . . . . . . . . 5
	1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5		1.3. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 6		3. The Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 6
	3.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 6		3.1. Properties of Q-Block1 and Q-Block2 Options . . . . . . . 6
	3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 8		3.2. Structure of Q-Block1 and Q-Block2 Options . . . . . . . 9
	3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9		3.3. Using the Q-Block1 Option . . . . . . . . . . . . . . . . 9
	3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 12		3.4. Using the Q-Block2 Option . . . . . . . . . . . . . . . . 13
	3.5. Using Observe and Q-Block1 Options . . . . . . . . . . . 14		3.5. Using Observe Option . . . . . . . . . . . . . . . . . . 15
	3.6. Using Observe and Q-Block2 Options . . . . . . . . . . . 15		3.6. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15
	3.7. Using Size1 and Size2 Options . . . . . . . . . . . . . . 15		3.7. Using Q-Block1 and Q-Block2 Options Together . . . . . . 15
	3.8. Using Q-Block1 and Q-Block2 Options Together . . . . . . 15		3.8. Using Q-Block2 Option With Multicast . . . . . . . . . . 16
	4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 15		4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 16
	5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 17		5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 17
	6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 17		6. Congestion Control for Unreliable Transports . . . . . . . . 18
	6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 17		6.1. Confirmable (CON) . . . . . . . . . . . . . . . . . . . . 18
	6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 18		6.2. Non-confirmable (NON) . . . . . . . . . . . . . . . . . . 18
	7. Caching Considerations . . . . . . . . . . . . . . . . . . . 21		7. Caching Considerations . . . . . . . . . . . . . . . . . . . 22
	8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 22		8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 23
	9. Examples with Non-confirmable Messages . . . . . . . . . . . 22		9. Examples with Non-confirmable Messages . . . . . . . . . . . 23
	9.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 23		9.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 23
	9.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 23		9.1.1. A Simple Example . . . . . . . . . . . . . . . . . . 23
	9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 23		9.1.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 24
	9.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 24		9.1.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 24
	9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 25		9.1.4. Handling Recovery with Failure . . . . . . . . . . . 26
	9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 25		9.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 26
	9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 26		9.2.1. A Simple Example . . . . . . . . . . . . . . . . . . 27
	9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 27		9.2.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 27
	9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 28		9.2.3. Handling MAX_PAYLOADS with Recovery . . . . . . . . . 28
	9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 29		9.2.4. Handling Recovery using M-bit Set . . . . . . . . . . 29
	9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 29		9.3. Q-Block1 and Q-Block2 Options . . . . . . . . . . . . . . 30
	9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 30		9.3.1. A Simple Example . . . . . . . . . . . . . . . . . . 30
	9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 31		9.3.2. Handling MAX_PAYLOADS Limits . . . . . . . . . . . . 31
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33		9.3.3. Handling Recovery . . . . . . . . . . . . . . . . . . 32
	10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 33		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 34		10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 34
	10.3. New Content Format . . . . . . . . . . . . . . . . . . . 35		10.2. New Media Type . . . . . . . . . . . . . . . . . . . . . 35
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 36		10.3. New Content Format . . . . . . . . . . . . . . . . . . . 36
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 36		10.4. New CoAP Signaling Option Number . . . . . . . . . . . . 37
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
	13.1. Normative References . . . . . . . . . . . . . . . . . . 36		11. Security Considerations . . . . . . . . . . . . . . . . . . . 37
	13.2. Informative References . . . . . . . . . . . . . . . . . 38		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
	Appendix A. Examples with Confirmable Messages . . . . . . . . . 39		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 39		13.1. Normative References . . . . . . . . . . . . . . . . . . 38
	A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 40		13.2. Informative References . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42		Appendix A. Examples with Confirmable Messages . . . . . . . . . 40
			A.1. Q-Block1 Option . . . . . . . . . . . . . . . . . . . . . 40
			A.2. Q-Block2 Option . . . . . . . . . . . . . . . . . . . . . 42
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	The Constrained Application Protocol (CoAP) [RFC7252], although		The Constrained Application Protocol (CoAP) [RFC7252], although
	inspired by HTTP, was designed to use UDP instead of TCP. The		inspired by HTTP, was designed to use UDP instead of TCP. The
	message layer of CoAP over UDP includes support for reliable		message layer of CoAP over UDP includes support for reliable
	delivery, simple congestion control, and flow control. [RFC7959]		delivery, simple congestion control, and flow control. [RFC7959]
	introduced the CoAP Block1 and Block2 Options to handle data records		introduced the CoAP Block1 and Block2 Options to handle data records
	that cannot fit in a single IP packet, so not having to rely on IP		that cannot fit in a single IP packet, so not having to rely on IP
	fragmentation and was further updated by [RFC8323] for use over TCP,		fragmentation and was further updated by [RFC8323] for use over TCP,
	skipping to change at page 4, line 29 ¶		skipping to change at page 4, line 29 ¶
	o Additional congestion control measures need to be put in place for		o Additional congestion control measures need to be put in place for
	NON (Section 6.2).		NON (Section 6.2).
	o To reduce the transmission times for CON transmission of large		o To reduce the transmission times for CON transmission of large
	bodies, NSTART needs to be increased from 1, but this affects		bodies, NSTART needs to be increased from 1, but this affects
	congestion control where other parameters need to be tuned		congestion control where other parameters need to be tuned
	(Section 4.7 of [RFC7252]). Such tuning is out of scope of this		(Section 4.7 of [RFC7252]). Such tuning is out of scope of this
	document.		document.
			o There is no multicast support.
	Using NON messages, the faster transmissions occur as all the blocks		Using NON messages, the faster transmissions occur as all the blocks
	can be transmitted serially (as are IP fragmented packets) without		can be transmitted serially (as are IP fragmented packets) without
	having to wait for a response or next request from the remote CoAP		having to wait for a response or next request from the remote CoAP
	peer. Recovery of missing blocks is faster in that multiple missing		peer. Recovery of missing blocks is faster in that multiple missing
	blocks can be requested in a single CoAP packet. Even if there is		blocks can be requested in a single CoAP packet. Even if there is
	asymmetrical packet loss, a body can still be sent and received by		asymmetrical packet loss, a body can still be sent and received by
	the peer whether the body comprises of a single or multiple payloads		the peer whether the body comprises of a single or multiple payloads
	assuming no recovery is required.		assuming no recovery is required.
	Note that similar performance benefits can be applied to Confirmable		Note that similar performance benefits can be applied to Confirmable
	skipping to change at page 5, line 18 ¶		skipping to change at page 5, line 20 ¶
	transmissions can fall back to using Block1 and Block2 Options,		transmissions can fall back to using Block1 and Block2 Options,
	respectively.		respectively.
	The deviations from Block1 and Block2 Options are specified in		The deviations from Block1 and Block2 Options are specified in
	Section 3. Pointers to appropriate [RFC7959] sections are provided.		Section 3. Pointers to appropriate [RFC7959] sections are provided.
	The specification refers to the base CoAP methods defined in		The specification refers to the base CoAP methods defined in
	Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and		Section 5.8 of [RFC7252] and the new CoAP methods, FETCH, PATCH, and
	iPATCH introduced in [RFC8132].		iPATCH introduced in [RFC8132].
	Q-Block1 and Q-Block2 Options are designed to work with Non-		Q-Block1 and Q-Block2 Options are designed to work in particular with
	confirmable requests and responses, in particular.		Non-confirmable requests and responses.
	1.2. CoAP Response Code (4.08) Usage		1.2. CoAP Response Code (4.08) Usage
	This document adds a media type for the 4.08 (Request Entity		This document adds a media type for the 4.08 (Request Entity
	Incomplete) response defining an additional message format for		Incomplete) response defining an additional message format for
	reporting on payloads using the Q-Block1 Option that are not received		reporting on payloads using the Q-Block1 Option that are not received
	by the server.		by the server.
	See Section 4 for more details.		See Section 4 for more details.
	skipping to change at page 7, line 27 ¶		skipping to change at page 7, line 27 ¶
	The Content-Format Option applies to the body, not to the payload		The Content-Format Option applies to the body, not to the payload
	(i.e., it must be the same for all payloads of the same body).		(i.e., it must be the same for all payloads of the same body).
	Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,		Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
	PATCH, and iPATCH requests and their responses.		PATCH, and iPATCH requests and their responses.
	Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and		Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
	iPATCH requests and their payload-bearing responses (2.01, 2.02,		iPATCH requests and their payload-bearing responses (2.01, 2.02,
	2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).		2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).
	However, with methods needing both Q-Block1 for the request and
	Q-Block2 for the response, and there is need for recovery following
	payload loss, the numbers of packets needed to initiate and complete
	the recovery can get very large as a function of the severity of the
	experienced loss.
	A CoAP endpoint (or proxy) MUST support either both or neither of the		A CoAP endpoint (or proxy) MUST support either both or neither of the
	Q-Block1 and Q-Block2 Options.		Q-Block1 and Q-Block2 Options.
	If Q-Block1 Option is present in a request or Q-Block2 Option in a		If Q-Block1 Option is present in a request or Q-Block2 Option in a
	response (i.e., in that message to the payload of which it pertains),		response (i.e., in that message to the payload of which it pertains),
	it indicates a block-wise transfer and describes how this specific		it indicates a block-wise transfer and describes how this specific
	block-wise payload forms part of the entire body being transferred.		block-wise payload forms part of the entire body being transferred.
	If it is present in the opposite direction, it provides additional		If it is present in the opposite direction, it provides additional
	control on how that payload will be formed or was processed.		control on how that payload will be formed or was processed.
	To indicate support for Q-Block2 responses, the CoAP client MUST		To indicate support for Q-Block2 responses, the CoAP client MUST
	include the Q-Block2 Option in a GET or similar request, the Q-Block2		include the Q-Block2 Option in a GET or similar request, the Q-Block2
	Option in a PUT or similar request, or the Q-Block1 Option in a PUT		Option in a PUT or similar request, or the Q-Block1 Option in a PUT
	or similar so that the server knows that the client supports this		or similar so that the server knows that the client supports this
	Q-Block2 functionality should it need to send back a body that spans		Q-Block2 functionality should it need to send back a body that spans
	multiple payloads. Otherwise, the server would use the Block2 Option		multiple payloads. Otherwise, the server would use the Block2 Option
	(if supported) to send back a message body that is too large to fit		(if supported) to send back a message body that is too large to fit
	into a single IP packet [RFC7959].		into a single IP packet [RFC7959].
			Alternatively, with CoAP over reliable transports, Capabilities and
			Settings Messages (CSMs) can be used to indicate support of Q-Block
			Options by means of the Q-Block-Wise-Transfer Capability Option
			(Table 2). The behavior of CoAP peers is similar to the one
			specified in Section 5.3.2 of [RFC8323], except that it indicates
			support of Q-Block Options.
			+----+---+---+---------+---------------+--------+--------+--------+
			| # | C | R | Applies | Name | Format | Length | Base |
			| | | | to | | | | Value |
			+====+===+===+=========+===============+========+========+========+
			|TBA4| | | CSM | Q-Block-Wise- | empty | 0 | (none) |
			| | | | | Transfer | | | |
			+----+---+---+---------+---------------+--------+--------+--------+
			C=Critical, R=Repeatable
			Table 2: The Q-Block-Wise-Transfer Capability Option
	Implementation of the Q-Block1 and Q-Block2 Options is intended to be		Implementation of the Q-Block1 and Q-Block2 Options is intended to be
	optional. However, when it is present in a CoAP message, it MUST be		optional. However, when it is present in a CoAP message, it MUST be
	processed (or the message rejected). Therefore, Q-Block1 and		processed (or the message rejected). Therefore, Q-Block1 and
	Q-Block2 Options are identified as Critical options.		Q-Block2 Options are identified as Critical options.
	With CoAP over UDP, the way a request message is rejected for		With CoAP over UDP, the way a request message is rejected for
	critical options depends on the message type. A Confirmable message		critical options depends on the message type. A Confirmable message
	with an unrecognized critical option is rejected with a 4.02 (Bad		with an unrecognized critical option is rejected with a 4.02 (Bad
	Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable		Option) response (Section 5.4.1 of [RFC7252]). A Non-confirmable
	message with an unrecognized critical option is either rejected with		message with an unrecognized critical option is either rejected with
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 41 ¶
	The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a		The Q-Block1 and Q-Block2 Options are unsafe to forward. That is, a
	CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option		CoAP proxy that does not understand the Q-Block1 (or Q-Block2) Option
	MUST reject the request or response that uses either option.		MUST reject the request or response that uses either option.
	The Q-Block2 Option is repeatable when requesting retransmission of		The Q-Block2 Option is repeatable when requesting retransmission of
	missing blocks, but not otherwise. Except that case, any request		missing blocks, but not otherwise. Except that case, any request
	carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled		carrying multiple Q-Block1 (or Q-Block2) Options MUST be handled
	following the procedure specified in Section 5.4.5 of [RFC7252].		following the procedure specified in Section 5.4.5 of [RFC7252].
			Note that if Q-Block1 (or Q-Block2) Option is included in a packet,
			Block1 (or Block2) Option MUST NOT be included.
	The Q-Block1 and Q-Block2 Options, like the Block1 and Block2		The Q-Block1 and Q-Block2 Options, like the Block1 and Block2
	Options, are both a class E and a class U in terms of OSCORE		Options, are both a class E and a class U in terms of OSCORE
	processing (Table 2). The Q-Block1 (or Q-Block2) Option MAY be an		processing (Table 3). The Q-Block1 (or Q-Block2) Option MAY be an
	Inner or Outer option (Section 4.1 of [RFC8613]). The Inner and		Inner or Outer option (Section 4.1 of [RFC8613]). The Inner and
	Outer values are therefore independent of each other. The Inner		Outer values are therefore independent of each other. The Inner
	option is encrypted and integrity protected between clients and		option is encrypted and integrity protected between clients and
	servers, and provides message body identification in case of end-to-		servers, and provides message body identification in case of end-to-
	end fragmentation of requests. The Outer option is visible to		end fragmentation of requests. The Outer option is visible to
	proxies and labels message bodies in case of hop-by-hop fragmentation		proxies and labels message bodies in case of hop-by-hop fragmentation
	of requests.		of requests.
	+--------+-----------------+---+---+		+--------+-----------------+---+---+
	| Number | Name | E | U |		| Number | Name | E | U |
	+========+=================+===+===+		+========+=================+===+===+
	| TBA1 | Q-Block1 | x | x |		| TBA1 | Q-Block1 | x | x |
	| TBA2 | Q-Block2 | x | x |		| TBA2 | Q-Block2 | x | x |
	+--------+-----------------+---+---+		+--------+-----------------+---+---+
	Table 2: OSCORE Protection of Q-Block1 and Q-Block2 Options		Table 3: OSCORE Protection of Q-Block1 and Q-Block2 Options
	3.2. Structure of Q-Block1 and Q-Block2 Options		3.2. Structure of Q-Block1 and Q-Block2 Options
	The structure of Q-Block1 and Q-Block2 Options follows the structure		The structure of Q-Block1 and Q-Block2 Options follows the structure
	defined in Section 2.2 of [RFC7959].		defined in Section 2.2 of [RFC7959].
	There is no default value for the Q-Block1 and Q-Block2 Options.		There is no default value for the Q-Block1 and Q-Block2 Options.
	Absence of one of these options is equivalent to an option value of 0		Absence of one of these options is equivalent to an option value of 0
	with respect to the value of block number (NUM) and more bit (M) that		with respect to the value of block number (NUM) and more bit (M) that
	could be given in the option, i.e., it indicates that the current		could be given in the option, i.e., it indicates that the current
	skipping to change at page 9, line 41 ¶		skipping to change at page 10, line 8 ¶
	that it is unique for every different body of transmitted data.		that it is unique for every different body of transmitted data.
	Implementation Note: It is suggested that the client treats the		Implementation Note: It is suggested that the client treats the
	Request-Tag as an unsigned integer of 8 bytes in length. An		Request-Tag as an unsigned integer of 8 bytes in length. An
	implementation may want to consider limiting this to 4 bytes to		implementation may want to consider limiting this to 4 bytes to
	reduce packet overhead size. The initial Request-Tag value should		reduce packet overhead size. The initial Request-Tag value should
	be randomly generated and then subsequently incremented by the		be randomly generated and then subsequently incremented by the
	client whenever a new body of data is being transmitted between		client whenever a new body of data is being transmitted between
	peers.		peers.
	Section 3.7 discusses the use of Size1 Option.		Section 3.6 discusses the use of Size1 Option.
	For Confirmable transmission, the server continues to acknowledge		For Confirmable transmission, the server continues to acknowledge
	each packet, but a response is not required (whether separate or		each packet, but a response is not required (whether separate or
	piggybacked) until successful receipt of the body or, if some of the		piggybacked) until successful receipt of the body by the server. For
	payloads are sent as Non-confirmable and have not arrived, a		Non-confirmable transmission, no response is required until the
	retransmit missing payloads response is needed.		successful receipt of the body by the server or some of the payloads
			have not arrived after a timeout and a retransmit missing payloads
			response is needed. For reliable transports (e.g., [RFC8323]), a
			response is not required until successful receipt of the body by the
			server.
	Each individual payload of the body is treated as a new request		Each individual payload of the body is treated as a new request
	(Section 5).		(Section 5).
	The client MUST send the payloads with the block numbers increasing,		The client MUST send the payloads with the block numbers increasing,
	starting from zero, until the body is complete (subject to any		starting from zero, until the body is complete (subject to any
	congestion control (Section 6)). Any missing payloads requested by		congestion control (Section 6)). Any missing payloads requested by
	the server must in addition be separately transmitted with increasing		the server must in addition be separately transmitted with increasing
	block numbers.		block numbers.
	skipping to change at page 10, line 39 ¶		skipping to change at page 11, line 9 ¶
	This Response Code indicates successful receipt of the entire body		This Response Code indicates successful receipt of the entire body
	and the resource was updated. The token used SHOULD be from the		and the resource was updated. The token used SHOULD be from the
	last received payload. The client should then release all of the		last received payload. The client should then release all of the
	tokens used for this body.		tokens used for this body.
	2.05 (Content)		2.05 (Content)
	This Response Code indicates successful receipt of the entire		This Response Code indicates successful receipt of the entire
	FETCH request body (Section 2 of [RFC8132]) and the appropriate		FETCH request body (Section 2 of [RFC8132]) and the appropriate
	representation of the resource has been returned. The token used		representation of the resource is being returned. The token used
	in the response MUST be the one in the FETCH request that has the		in the response MUST be the one in the FETCH request that has the
	Q-Block1 with the M bit unset. If the FETCH request includes the		Q-Block1 with the M bit unset. If the FETCH request includes the
	Observe Option, then the server MUST use the same token for		Observe Option, then the server MUST use the same token for
	returning any Observe triggered responses. The client should then		returning any Observe triggered responses. The client should then
	release all of the tokens used for this body unless a resource is		release all of the tokens used for this body unless a resource is
	being observed.		being observed.
	2.31 (Continue)		2.31 (Continue)
	This Response Code can be used to indicate that all of the blocks		This Response Code can be used to indicate that all of the blocks
	skipping to change at page 11, line 21 ¶		skipping to change at page 11, line 40 ¶
	It SHOULD NOT be generated for CON.		It SHOULD NOT be generated for CON.
	4.00 (Bad Request)		4.00 (Bad Request)
	This Response Code MUST be returned if the request does not		This Response Code MUST be returned if the request does not
	include both a Request-Tag Option and a Size1 Option but does		include both a Request-Tag Option and a Size1 Option but does
	include a Q-Block1 option.		include a Q-Block1 option.
	4.02 (Bad Option)		4.02 (Bad Option)
	Either this Response Code or a reset message MUST be returned if		Either this Response Code (in case of Confirmable request) or a
	the server does not support the Q-Block1 Option.		reset message (in case of Non-confirmable request) MUST be
			returned if the server does not support the Q-Block1 Option.
	4.08 (Request Entity Incomplete)		4.08 (Request Entity Incomplete)
	This Response Code returned without Content-Type "application/		This Response Code returned without Content-Type "application/
	missing-blocks+cbor-seq" (Section 10.3) is handled as in		missing-blocks+cbor-seq" (Section 10.3) is handled as in
	Section 2.9.2 [RFC7959].		Section 2.9.2 [RFC7959].
	This Response Code returned with Content-Type "application/		This Response Code returned with Content-Type "application/
	missing-blocks+cbor-seq" indicates that some of the payloads are		missing-blocks+cbor-seq" indicates that some of the payloads are
	missing and need to be resent. The client then retransmits the		missing and need to be resent. The client then retransmits the
	missing payloads using the same Request-Tag, Size1 and Q-Block1 to		missing payloads using the same Request-Tag, Size1 and Q-Block1 to
	specify the block number, SZX, and M bit as appropriate.		specify the block NUM, SZX, and M bit as appropriate.
	The Request-Tag value to use is determined from the token in the		The Request-Tag value to use is determined by taking the token in
	4.08 (Request Entity Incomplete) response and then finding the		the 4.08 (Request Entity Incomplete) response, locating the
	matching client request which contains the Request-Tag that is		matching client request, and then using its Request-Tag.
	being used for this Q-Block1 body.
	The token used in the response SHOULD be from the last received		The token used in the response SHOULD be from the last received
	payload. See Section 4 for further information.		payload. See Section 4 for further information.
	4.13 (Request Entity Too Large)		4.13 (Request Entity Too Large)
	This Response Code can be returned under similar conditions to		This Response Code can be returned under similar conditions to
	those discussed in Section 2.9.3 of [RFC7959].		those discussed in Section 2.9.3 of [RFC7959].
	This Response Code can be returned if there is insufficient space		This Response Code can be returned if there is insufficient space
	to create a response PDU with a block size of 16 bytes (SZX = 0)		to create a response PDU with a block size of 16 bytes (SZX = 0)
	to send back all the response options as appropriate. In this		to send back all the response options as appropriate. In this
	case, the Size1 Option is not included.		case, the Size1 Option is not included in the response.
	If the server has not received all the payloads of a body, but one or		If the server has not received all the payloads of a body, but one or
	more NON payloads have been received, it SHOULD wait for up to		more NON payloads have been received, it SHOULD wait for up to
	NON_RECEIVE_TIMEOUT (Section 6.2) before sending a 4.08 (Request		NON_RECEIVE_TIMEOUT (Section 6.2) before sending a 4.08 (Request
	Entity Incomplete) response. Further considerations related to the		Entity Incomplete) response. Further considerations related to the
	transmission timings of 4.08 (Request Entity Incomplete) and 2.31		transmission timings of 4.08 (Request Entity Incomplete) and 2.31
	(Continue) Response Codes are discussed in Section 6.2.		(Continue) Response Codes are discussed in Section 6.2.
	If a server receives payloads with different Request-Tags for the		If a server receives payloads with different Request-Tags for the
	same resource, it should continue to process all the bodies as it has		same resource, it should continue to process all the bodies as it has
	skipping to change at page 12, line 38 ¶		skipping to change at page 13, line 13 ¶
	up to NON_PARTIAL_TIMEOUT (Section 6.2).		up to NON_PARTIAL_TIMEOUT (Section 6.2).
	3.4. Using the Q-Block2 Option		3.4. Using the Q-Block2 Option
	In a request for any block number, the M bit unset indicates the		In a request for any block number, the M bit unset indicates the
	request is just for that block. If the M bit is set, this has		request is just for that block. If the M bit is set, this has
	different meanings based on the NUM value:		different meanings based on the NUM value:
	NUM is zero: This is a request for the entire body.		NUM is zero: This is a request for the entire body.
	'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero:		'NUM modulo MAX_PAYLOADS' is zero, while NUM is not zero: This is
			used to confirm that the current set of MAX_PAYLOADS payloads (the
	This is used to confirm that the current set of MAX_PAYLOADS		latest one having block number NUM-1) has been successfully
	payloads (the latest one having block number NUM-1) has been		received and that, upon receipt of this request, the server can
	successfully received and that, upon receipt of this request, the		continue to send the next set of payloads (the first one having
	server can continue to send the next set of payloads (the first		block number NUM). This is the 'Continue' Q-Block-2 and
	one having block number NUM). This is the 'Continue' Q-Block-2.		conceptually has the same usage (i.e., continue sending the next
			set of data) as the use of 2.31 (Continue) for Q-Block1.
	Any other value of NUM: This is a request for that block and for all		Any other value of NUM: This is a request for that block and for all
	of the remaining blocks in the current MAX_PAYLOADS set.		of the remaining blocks in the current MAX_PAYLOADS set.
	If the request includes multiple Q-Block2 Options and these options		If the request includes multiple Q-Block2 Options and these options
	overlap (e.g., combination of M being set (this and later blocks) and		overlap (e.g., combination of M being set (this and later blocks) and
	being unset (this individual block)) resulting in an individual block		being unset (this individual block)) resulting in an individual block
	being requested multiple times, the server MUST only send back one		being requested multiple times, the server MUST only send back one
	instance of that block. This behavior is meant to prevent		instance of that block. This behavior is meant to prevent
	amplification attacks.		amplification attacks.
	skipping to change at page 13, line 23 ¶		skipping to change at page 13, line 48 ¶
	server SHOULD ensure that it is unique for every different body of		server SHOULD ensure that it is unique for every different body of
	transmitted data.		transmitted data.
	Implementation Note: It is suggested that the server treats the		Implementation Note: It is suggested that the server treats the
	ETag as an unsigned integer of 8 bytes in length. An		ETag as an unsigned integer of 8 bytes in length. An
	implementation may want to consider limiting this to 4 bytes to		implementation may want to consider limiting this to 4 bytes to
	reduce packet overhead size. The initial ETag value should be		reduce packet overhead size. The initial ETag value should be
	randomly generated and then subsequently incremented by the server		randomly generated and then subsequently incremented by the server
	whenever a new body of data is being transmitted between peers.		whenever a new body of data is being transmitted between peers.
	Section 3.7 discusses the use of Size2 Option.		Section 3.6 discusses the use of Size2 Option.
	The client may elect to request any detected missing blocks or just		The client may elect to request any detected missing blocks or just
	ignore the partial body. This decision is implementation specific.		ignore the partial body. This decision is implementation specific.
	The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2)		The client SHOULD wait for up to NON_RECEIVE_TIMEOUT (Section 6.2)
	after the last received payload for NON payloads before issuing a		after the last received payload for NON payloads before issuing a
	GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or		GET, POST, PUT, FETCH, PATCH, or iPATCH request that contains one or
	more Q-Block2 Options that define the missing blocks with the M bit		more Q-Block2 Options that define the missing blocks with the M bit
	unset. It is permissible to set the M bit to request this and		unset. It is permissible to set the M bit to request this and
	missing blocks from this MAX_PAYLOADS set. Further considerations		missing blocks from this MAX_PAYLOADS set. Further considerations
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 29 ¶
	For Confirmable responses, the client continues to acknowledge each		For Confirmable responses, the client continues to acknowledge each
	packet. The server will detect failure to send a packet, but the		packet. The server will detect failure to send a packet, but the
	client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET,		client can issue, after a MAX_TRANSMIT_SPAN delay, a separate GET,
	POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed.		POST, PUT, FETCH, PATCH, or iPATCH for any missing blocks as needed.
	If the client receives a duplicate block with the same ETag, it		If the client receives a duplicate block with the same ETag, it
	SHOULD silently ignore the packet.		SHOULD silently ignore the packet.
	A client SHOULD only maintain a partial body (missing payloads) for		A client SHOULD only maintain a partial body (missing payloads) for
	up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age		up to NON_PARTIAL_TIMEOUT (Section 6.2) or as defined by the Max-Age
	Option (or its default), whichever is the less.		Option (or its default of 60 seconds (Section 5.6.1 of [RFC7252])),
			whichever is the less.
	The ETag Option should not be used in the request for missing blocks		The ETag Option should not be used in the request for missing blocks
	as the server could respond with a 2.03 (Valid Response) with no		as the server could respond with a 2.03 (Valid Response) with no
	payload. It can be used in the request if the client wants to check		payload. It can be used in the request if the client wants to check
	the freshness of the currently cached body response.		the freshness of the locally cached body response.
			It is RECOMMENDED that the server maintains a cached copy of the body
			when using the Q-Block2 Option to facilitate retransmission of any
			missing payloads.
	If the server detects part way through a body transfer that the		If the server detects part way through a body transfer that the
	resource data has changed and the server is not maintaining a cached		resource data has changed and the server is not maintaining a cached
	copy of the old data, then the body response SHOULD be restarted with		copy of the old data, then the body response SHOULD be restarted with
	a different ETag Option value. Any subsequent missing block requests		a different ETag Option value. Any subsequent missing block requests
	MUST be responded to using the latest ETag Option value.		MUST be responded to using the latest ETag Option value.
	If the server responds during a body update with a different ETag		If the server responds during a body update with a different ETag
	Option value (as the resource representation has changed), then the		Option value (as the resource representation has changed), then the
	client should treat the partial body with the old ETag as no longer		client should treat the partial body with the old ETag as no longer
	skipping to change at page 14, line 36 ¶		skipping to change at page 15, line 16 ¶
	Observe) with a new ETag to the same client as an additional		Observe) with a new ETag to the same client as an additional
	response, the client should remove any partially received body held		response, the client should remove any partially received body held
	for a previous ETag for that resource as it is unlikely the missing		for a previous ETag for that resource as it is unlikely the missing
	blocks can be retrieved.		blocks can be retrieved.
	If there is insufficient space to create a response PDU with a block		If there is insufficient space to create a response PDU with a block
	size of 16 bytes (SZX = 0) to send back all the response options as		size of 16 bytes (SZX = 0) to send back all the response options as
	appropriate, a 4.13 (Request Entity Too Large) is returned without		appropriate, a 4.13 (Request Entity Too Large) is returned without
	the Size1 Option.		the Size1 Option.
	3.5. Using Observe and Q-Block1 Options		3.5. Using Observe Option
	As the blocks of the body are sent without waiting for
	acknowledgement of the individual blocks, the observe value [RFC7641]
	MUST be the same for all the blocks of the same body.
	If the server reports any missing payload, the client re-sends the
	missing payload(s). Each re-sent payload is treated as a new request
	and the Observe Option MUST be included in the request.
	If the response (or associated response) uses Q-Block2 Option, and
	one of the response payloads is missing, the request for the missing
	payload(s) is treated as a new request. The request MUST comprise of
	all of the request payloads and the Observe Option MUST NOT be
	included in either the request or response.
	3.6. Using Observe and Q-Block2 Options
	As the blocks of the body are sent without waiting for		For a request that uses Q-Block1, the Observe value [RFC7641] MUST be
	acknowledgement of the individual blocks, the Observe value [RFC7641]		the same for all the payloads of the same body. This includes any
	MUST be the same for all the blocks of the same body.		missing payloads that are retransmitted.
	If the client requests missing blocks, this is treated as a new		For a response that uses Q-Block2, the Observe value MUST be the same
	Request and the Observe Option MUST NOT be included in either the		for all the payloads of the same body. This includes payloads
	request or response. If the ETag value in the response changes, then		transmitted following receipt of the 'Continue' Q-Block2 Option
	the previously received partial body should be considered as not		(Section 3.4) by the server. If a missing payload is requested, then
	fresh and the whole body re-requested.		both the request and response MUST NOT include the Observe Option.
	3.7. Using Size1 and Size2 Options		3.6. Using Size1 and Size2 Options
	Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating		Section 4 of [RFC7959] defines two CoAP options: Size1 for indicating
	the size of the representation transferred in requests and Size2 for		the size of the representation transferred in requests and Size2 for
	indicating the size of the representation transferred in responses.		indicating the size of the representation transferred in responses.
	The Size1 or Size2 option values MUST exactly represent the size of		The Size1 or Size2 option values MUST exactly represent the size of
	the data on the body so that any missing data can easily be		the data on the body so that any missing data can easily be
	determined.		determined.
	The Size1 Option MUST be used with the Q-Block1 Option when used in a		The Size1 Option MUST be used with the Q-Block1 Option when used in a
	request. The Size2 Option MUST be used with the Q-Block2 Option when		request. The Size2 Option MUST be used with the Q-Block2 Option when
	used in a response.		used in a response.
	If Size1 or Size2 Options are used, they MUST be used in all payloads		If Size1 or Size2 Options are used, they MUST be used in all payloads
	of the body and MUST preserve the same value in each of those		of the body and MUST preserve the same value in each of those
	payloads.		payloads.
	3.8. Using Q-Block1 and Q-Block2 Options Together		3.7. Using Q-Block1 and Q-Block2 Options Together
	The behavior is similar to the one defined in Section 3.3 of		The behavior is similar to the one defined in Section 3.3 of
	[RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for		[RFC7959] with Q-Block1 substituted for Block1 and Q-Block2 for
	Block2.		Block2.
			3.8. Using Q-Block2 Option With Multicast
			Servers MUST ignore multicast requests that contain the Q-Block2
			Option. As a reminder, Block2 Option can be used as stated in
			Section 2.8 of [RFC7959].
	4. The Use of 4.08 (Request Entity Incomplete) Response Code		4. The Use of 4.08 (Request Entity Incomplete) Response Code
	4.08 (Request Entity Incomplete) Response Code has a new Content-Type		4.08 (Request Entity Incomplete) Response Code has a new Content-Type
	"application/missing-blocks+cbor-seq" used to indicate that the		"application/missing-blocks+cbor-seq" used to indicate that the
	server has not received all of the blocks of the request body that it		server has not received all of the blocks of the request body that it
	needs to proceed.		needs to proceed.
	Likely causes are the client has not sent all blocks, some blocks		Likely causes are the client has not sent all blocks, some blocks
	were dropped during transmission, or the client has sent them		were dropped during transmission, or the client has sent them
	sufficiently long ago that the server has already discarded them.		sufficiently long ago that the server has already discarded them.
	skipping to change at page 16, line 32 ¶		skipping to change at page 16, line 49 ¶
	; A unique block number not received:		; A unique block number not received:
	missing-block-number = uint		missing-block-number = uint
	Figure 1: Structure of the Missing Blocks Payload		Figure 1: Structure of the Missing Blocks Payload
	The token to use for the response SHOULD be the token that was used		The token to use for the response SHOULD be the token that was used
	in the last block number received so far with the same Request-Tag		in the last block number received so far with the same Request-Tag
	value. Note that the use of any received token with the same		value. Note that the use of any received token with the same
	Request-Tag would work, but providing the one used in the last		Request-Tag would work, but providing the one used in the last
	received block number will aid any troubleshooting. The client will		received block number will aid any troubleshooting. The client will
	use the token to determine what is the previously sent request to		use the token to determine what was the previously sent request to
	obtain the Request-Tag value to be used.		obtain the Request-Tag value to be used.
	If the size of the 4.08 (Request Entity Incomplete) response packet		If the size of the 4.08 (Request Entity Incomplete) response packet
	is larger than that defined by Section 4.6 [RFC7252], then the number		is larger than that defined by Section 4.6 [RFC7252], then the number
	of missing blocks MUST be limited so that the response can fit into a		of missing blocks MUST be limited so that the response can fit into a
	single packet. If this is the case, then the server can send		single packet. If this is the case, then the server can send
	subsequent 4.08 (Request Entity Incomplete) responses containing the		subsequent 4.08 (Request Entity Incomplete) responses containing the
	missing other blocks on receipt of a new request providing a missing		missing other blocks on receipt of a new request providing a missing
	payload with the same Request-Tag.		payload with the same Request-Tag.
	skipping to change at page 17, line 23 ¶		skipping to change at page 17, line 42 ¶
	5. The Use of Tokens		5. The Use of Tokens
	Each new request MUST use a unique Token (Section 4 of		Each new request MUST use a unique Token (Section 4 of
	[I-D.ietf-core-echo-request-tag]). Additional responses may use the		[I-D.ietf-core-echo-request-tag]). Additional responses may use the
	same Token.		same Token.
	Implementation Note: To minimize on the number of tokens that have		Implementation Note: To minimize on the number of tokens that have
	to be tracked by clients, it is recommended that the bottom 32		to be tracked by clients, it is recommended that the bottom 32
	bits is kept the same for the same body and the upper 32 bits		bits is kept the same for the same body and the upper 32 bits
	contains the individual payload number.		contains the individual payload number. This allows the client to
			be alleviated from keeping all the per-request-state, e.g., in
			Section 3 of [RFC8974].
	Servers continue to treat the token as a unique opaque entity. If		Servers continue to treat the token as a unique opaque entity. If
	an individual payload has to be resent (e.g., requested upon		an individual payload has to be resent (e.g., requested upon
	packet loss), then the retransmitted packet is treated as a new		packet loss), then the retransmitted packet is treated as a new
	request (i.e., the bottom 32 bits must change).		request (i.e., the bottom 32 bits must change).
	6. Congestion Control		6. Congestion Control for Unreliable Transports
	The transmission of the payloads of a body either SHOULD all be		The transmission of the payloads of a body over an unreliable
	Confirmable or all be Non-confirmable. This is meant to simplify the		transport SHOULD either all be Confirmable or all be Non-confirmable.
	congestion control procedure.		This is meant to simplify the congestion control procedure.
			As a reminder, there is no need for CoAP-specific congestion control
			for reliable transports [RFC8323].
	6.1. Confirmable (CON)		6.1. Confirmable (CON)
	Congestion control for CON requests and responses is specified in		Congestion control for CON requests and responses is specified in
	Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will		Section 4.7 of [RFC7252]. For faster transmission rates, NSTART will
	need to be increased from 1. However, the other CON congestion		need to be increased from 1. However, the other CON congestion
	control parameters will need to be tuned to cover this change. This		control parameters will need to be tuned to cover this change. This
	tuning is out of scope of this document as it is expected that all		tuning is out of scope of this document as it is expected that all
	requests and responses using Q-Block1 and Q-Block2 will be Non-		requests and responses using Q-Block1 and Q-Block2 will be Non-
	confirmable.		confirmable.
	It is implementation specific as to whether there should be any		It is implementation specific as to whether there should be any
	further requests for missing data as there will have been significant		further requests for missing data as there will have been significant
	transmission failure as individual payloads will have failed after		transmission failure as individual payloads will have failed after
	MAX_TRANSMIT_SPAN.		MAX_TRANSMIT_SPAN.
	6.2. Non-confirmable (NON)		6.2. Non-confirmable (NON)
	This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,		This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
	NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and		NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
	NON_PARTIAL_TIMEOUT primarily for use with NON.		NON_PARTIAL_TIMEOUT primarily for use with NON (Table 4).
	MAX_PAYLOADS should be configurable with a default value of 10. Both		MAX_PAYLOADS should be configurable with a default value of 10. Both
	CoAP endpoints SHOULD have the same value (otherwise there will be		CoAP endpoints SHOULD have the same value (otherwise there will be
	transmission delays in one direction) and the value MAY be negotiated		transmission delays in one direction) and the value MAY be negotiated
	between the endpoints to a common value by using a higher level		between the endpoints to a common value by using a higher level
	protocol (out of scope of this document). This is the maximum number		protocol (out of scope of this document). This is the maximum number
	of payloads that can be transmitted at any one time.		of payloads that can be transmitted at any one time.
	Note: The default value of 10 is chosen for reasons similar to		Note: The default value of 10 is chosen for reasons similar to
	those discussed in Section 5 of [RFC6928].		those discussed in Section 5 of [RFC6928].
	NON_TIMEOUT is the maximum period of delay between sending sets of		NON_TIMEOUT is the maximum period of delay between sending sets of
	MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has		MAX_PAYLOADS payloads for the same body. By default, NON_TIMEOUT has
	the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]).		the same value as ACK_TIMEOUT (Section 4.8 of [RFC7252]).
	NON_RECEIVE_TIMEOUT is the maximum time to wait for a missing payload		NON_RECEIVE_TIMEOUT is the initial maximum time to wait for a missing
	before requesting retransmission. NON_RECEIVE_TIMEOUT has a value of		payload before requesting retransmission for the first time. Every
	twice NON_TIMEOUT.		time the missing payload is re-requested, the time to wait value
			doubles. The time to wait is calculated as:
			Time-to-Wait = NON_RECEIVE_TIMEOUT * (2 ** (Re-Request-Count - 1))
			NON_RECEIVE_TIMEOUT has a default value of twice NON_TIMEOUT.
			NON_RECEIVE_TIMEOUT MUST always be greater than NON_TIMEOUT by at
			least one second so that the sender of the payloads has the
			opportunity to start sending the next set of payloads before the
			receiver times out.
	NON_MAX_RETRANSMIT is the maximum number of times a request for the		NON_MAX_RETRANSMIT is the maximum number of times a request for the
	retransmission of missing payloads can occur without a response from		retransmission of missing payloads can occur without a response from
	the remote peer. After this occurs, the peer SHOULD consider the		the remote peer. After this occurs, the local endpoint SHOULD
	body stale and remove all references to it. By default,		consider the body stale and remove all references to it. By default,
	NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8		NON_MAX_RETRANSMIT has the same value as MAX_RETRANSMIT (Section 4.8
	of [RFC7252]).		of [RFC7252]).
	NON_PROBING_WAIT is used to limit the potential wait needed		NON_PROBING_WAIT is used to limit the potential wait needed
	calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same		calculated when using PROBING_WAIT. NON_PROBING_WAIT has the same
	value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).		value as computed for EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
	NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.		NON_PARTIAL_TIMEOUT is used for expiring partially received bodies.
	NON_PARTIAL_TIMEOUT has the same value as computed for		NON_PARTIAL_TIMEOUT has the same value as computed for
	EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).		EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
	skipping to change at page 19, line 16 ¶		skipping to change at page 19, line 39 ¶
	| Parameter Name | Default Value |		| Parameter Name | Default Value |
	+=====================+===============|		+=====================+===============|
	| MAX_PAYLOADS | 10 |		| MAX_PAYLOADS | 10 |
	| NON_MAX_RETRANSMIT | 4 |		| NON_MAX_RETRANSMIT | 4 |
	| NON_TIMEOUT | 2 s |		| NON_TIMEOUT | 2 s |
	| NON_RECEIVE_TIMEOUT | 4 s |		| NON_RECEIVE_TIMEOUT | 4 s |
	| NON_PROBING_WAIT | 247 s |		| NON_PROBING_WAIT | 247 s |
	| NON_PARTIAL_TIMEOUT | 247 s |		| NON_PARTIAL_TIMEOUT | 247 s |
	+---------------------+---------------+		+---------------------+---------------+
	Table 3: Congestion Control Parameters		Table 4: Congestion Control Parameters
	PROBING_RATE parameter in CoAP indicates the average data rate that		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		must not be exceeded by a CoAP endpoint in sending to a peer endpoint
	that does not respond. The single body of blocks will be subjected		that does not respond. The single body of blocks will be subjected
	to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual		to PROBING_RATE (Section 4.7 of [RFC7252]), not the individual
	packets. If the wait time between sending bodies that are not being		packets. If the wait time between sending bodies that are not being
	responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the		responded to based on PROBING_RATE exceeds NON_PROBING_WAIT, then the
	gap time is limited to NON_PROBING_WAIT.		gap time is limited to NON_PROBING_WAIT.
	Note: For the particular DOTS application, PROBING_RATE and other		Note: For the particular DOTS application, PROBING_RATE and other
	skipping to change at page 20, line 23 ¶		skipping to change at page 20, line 46 ¶
	Response Code for the latest payload sent, then the client can		Response Code for the latest payload sent, then the client can
	continue to send the next set of payloads without any delay. If the		continue to send the next set of payloads without any delay. If the
	server responds with a 4.08 (Request Entity Incomplete) Response		server responds with a 4.08 (Request Entity Incomplete) Response
	Code, then the missing payloads SHOULD be retransmitted before going		Code, then the missing payloads SHOULD be retransmitted before going
	into another NON_TIMEOUT delay prior to sending the next set of		into another NON_TIMEOUT delay prior to sending the next set of
	payloads.		payloads.
	For the server receiving NON Q-Block1 requests, it SHOULD send back a		For the server receiving NON Q-Block1 requests, it SHOULD send back a
	2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS		2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS
	payloads to prevent the client unnecessarily delaying. Otherwise the		payloads to prevent the client unnecessarily delaying. Otherwise the
	server SHOULD delay for NON_RECEIVE_TIMEOUT, before sending the 4.08		server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled
	(Request Entity Incomplete) Response Code. The NON_RECEIVE_TIMEOUT		based on the repeat request count for a payload), before sending the
	delay may be reduced for the first time that this 4.08 (Request		4.08 (Request Entity Incomplete) Response Code for the missing
	Entity Incomplete) is sent if either the last of the MAX_PAYLOADS		payload(s). If the repeat request count for a missing payload
	payloads or the final payload with the M bit unset arrives, but		exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial
	SHOULD NOT be reduced to zero as packets may arrive in the wrong		body and stop requesting the missing payloads.
	order.
	It is possible that the client may start transmitting the next set of		It is likely that the client will start transmitting the next set of
	MAX_PAYLOADS payloads before the server times out on waiting for the		MAX_PAYLOADS payloads before the server times out on waiting for the
	last of the previous MAX_PAYLOADS payloads. On receipt of the first		last of the previous MAX_PAYLOADS payloads. On receipt of the first
	received payload from the new set of MAX_PAYLOADS payloads, the		received payload from the new set of MAX_PAYLOADS payloads, the
	server SHOULD send a 4.08 (Request Entity Incomplete) Response Code		server SHOULD send a 4.08 (Request Entity Incomplete) Response Code
	indicating any missing payloads from any previous MAX_PAYLOADS		indicating any missing payloads from any previous MAX_PAYLOADS
	payloads. Upon receipt of the 4.08 (Request Entity Incomplete)		payloads. Upon receipt of the 4.08 (Request Entity Incomplete)
	Response Code, the client SHOULD send the missing payloads before		Response Code, the client SHOULD send the missing payloads before
	continuing to send the remainder of the MAX_PAYLOADS payloads and		continuing to send the remainder of the MAX_PAYLOADS payloads and
	then go into another NON_TIMEOUT delay prior to sending the next set		then go into another NON_TIMEOUT delay prior to sending the next set
	of payloads.		of payloads.
	For the client receiving NON Q-Block2 responses, it SHOULD send a		For the client receiving NON Q-Block2 responses, it SHOULD send a
	request for the next set of payloads on receipt of all of the		'Continue' Q-Block2 request (Section 3.4) for the next set of
	MAX_PAYLOADS payloads to prevent the server unnecessarily delaying.		payloads on receipt of all of the MAX_PAYLOADS payloads to prevent
	Otherwise the client SHOULD delay for NON_RECEIVE_TIMEOUT, before		the server unnecessarily delaying. Otherwise the client SHOULD delay
	sending the request for the missing payloads. The		for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat
	NON_RECEIVE_TIMEOUT delay may be reduced for the first time that this		request count for a payload), before sending the request for the
	request is sent if either the last of the MAX_PAYLOADS payloads or		missing payload(s). If the repeat request count for a missing
	the final payload with the M bit unset arrives, but SHOULD NOT be		payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the
	reduced to zero as packets may arrive in the wrong order.		partial body and stop requesting the missing payloads.
	The request that the client sends to acknowledge the receipt of all		The server SHOULD recognize the 'Continue' Q-Block2 request as a
	the current set of MAX_PAYLOADS payloads is the 'Continue' Q-Block2
	Option ('NUM modulo MAX_PAYLOADS' is zero, NUM is not zero, and M bit
	is set (Section 3.4)). The server SHOULD recognize this as a
	continue request and just continue the transmission of the body		continue request and just continue the transmission of the body
	(including Observe Option, if appropriate for an unsolicited		(including Observe Option, if appropriate for an unsolicited
	response) rather than as a request for the remaining missing blocks.		response) rather than as a request for the remaining missing blocks.
	It is possible that the server may start transmitting the next set of		It is likely that the server will start transmitting the next set of
	MAX_PAYLOADS payloads before the client times out on waiting for the		MAX_PAYLOADS payloads before the client times out on waiting for the
	last of the previous MAX_PAYLOADS payloads. Upon receipt of the		last of the previous MAX_PAYLOADS payloads. Upon receipt of the
	first payload from the new set of MAX_PAYLOADS payloads, the client		first payload from the new set of MAX_PAYLOADS payloads, the client
	SHOULD send a request indicating any missing payloads from any		SHOULD send a request indicating any missing payloads from any
	previous set of MAX_PAYLOADS payloads. Upon receipt of such request,		previous set of MAX_PAYLOADS payloads. Upon receipt of such request,
	the server SHOULD send the missing payloads before continuing to send		the server SHOULD send the missing payloads before continuing to send
	the remainder of the MAX_PAYLOADS payloads and then go into another		the remainder of the MAX_PAYLOADS payloads and then go into another
	NON_TIMEOUT delay prior to sending the next set of payloads.		NON_TIMEOUT delay prior to sending the next set of payloads.
	The client does not need to acknowledge the receipt of the entire		The client does not need to acknowledge the receipt of the entire
	skipping to change at page 24, line 50 ¶		skipping to change at page 25, line 27 ¶
	+--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024		+--->X | NON PUT /path M:0x1b T:0xeb RT=11 QB1:10/1/1024
	+--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024		+--------->| NON PUT /path M:0x1c T:0xec RT=11 QB1:11/1/1024
	| |		| |
	Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option		Figure 5: Example of MAX_PAYLOADS NON Request with Q-Block1 Option
	(With Loss)		(With Loss)
	On seeing a payload from the next set of payloads, the server		On seeing a payload from the next set of payloads, the server
	realizes that some blocks are missing from the previous MAX_PAYLOADS		realizes that some blocks are missing from the previous MAX_PAYLOADS
	payloads and asks for the missing blocks in one go (Figure 6). It		payloads and asks for the missing blocks in one go (Figure 6). It
	does so by indicating which blocks have not been received in the data		does so by indicating which blocks from the previous MAX_PAYLOADS
	portion of the response. The token used in the response should be		payloads have not been received in the data portion of the response.
	the token that was used in the last block number received payload.		The token used in the response should be the token that was used in
			the last block number received payload. The client can then derive
	The client can then derive the Request-Tag by matching the token with		the Request-Tag by matching the token with the sent request.
	the sent request.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	|<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9 [for RT=11]]		|<---------+ NON 4.08 M:0x91 T:0xec [Missing 1,9 [for RT=11]]
	| [[Client responds with missing payloads]]		| [[Client responds with missing payloads]]
	+--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024		+--------->| NON PUT /path M:0x1d T:0xed RT=11 QB1:1/1/1024
	+--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024		+--------->| NON PUT /path M:0x1e T:0xee RT=11 QB1:9/1/1024
	| [[Client continues sending next set of payloads]]		| [[Client continues sending next set of payloads]]
	+--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024		+--------->| NON PUT /path M:0x1f T:0xef RT=11 QB1:12/0/1024
	skipping to change at page 25, line 29 ¶		skipping to change at page 26, line 5 ¶
	| [[The server realizes a block is still missing and asks		| [[The server realizes a block is still missing and asks
	| for the missing one]]		| for the missing one]]
	|<---------+ NON 4.08 M:0x92 T:0xef [Missing 10 [for RT=11]]		|<---------+ NON 4.08 M:0x92 T:0xef [Missing 10 [for RT=11]]
	+--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024		+--------->| NON PUT /path M:0x20 T:0xf0 RT=11 QB1:10/1/1024
	|<---------+ NON 2.04 M:0x93 T:0xf0		|<---------+ NON 2.04 M:0x93 T:0xf0
	| ... |		| ... |
	Figure 6: Example of NON Request with Q-Block1 Option (Blocks		Figure 6: Example of NON Request with Q-Block1 Option (Blocks
	Recovery)		Recovery)
	Under high levels of traffic loss, the client can elect not to retry		9.1.4. Handling Recovery with Failure
	sending missing blocks of data by "forgetting" all the tracked tokens
	for this Request-Tag. Similarly, the server can elect to not to		Figure 7 depicts an example of a NON PUT request conveying Q-Block1
	continue asking for missing blocks. Both these decisions are		Option where recovery takes place, but eventually fails.
	implementation specific.
			CoAP CoAP
			Client Server
			| |
			+--------->| NON PUT /path M:0x91 T:0xd0 RT=12 QB1:0/1/1024
			+--->X | NON PUT /path M:0x92 T:0xd1 RT=12 QB1:1/1/1024
			+--------->| NON PUT /path M:0x93 T:0xd2 RT=12 QB1:2/0/1024
			| ... |
			[[NON_RECEIVE_TIMEOUT (server) delay expires]]
			| [[The server realizes a block is missing and asks
			| for the missing one. Retry #1]]
			|<---------+ NON 4.08 M:0x01 T:0xd2 [Missing 1 [for RT=12]]
			| ... |
			[[2 * NON_RECEIVE_TIMEOUT (server) delay expires]]
			| [[The server realizes a block is still missing and asks
			| for the missing one. Retry #2]]
			|<---------+ NON 4.08 M:0x02 T:0xd2 [Missing 1 [for RT=12]]
			| ... |
			[[4 * NON_RECEIVE_TIMEOUT (server) delay expires]]
			| [[The server realizes a block is still missing and asks
			| for the missing one. Retry #3]]
			|<---------+ NON 4.08 M:0x03 T:0xd2 [Missing 1 [for RT=12]]
			| ... |
			[[8 * NON_RECEIVE_TIMEOUT (server) delay expires]]
			| [[The server realizes a block is still missing and asks
			| for the missing one. Retry #4]]
			|<---------+ NON 4.08 M:0x04 T:0xd2 [Missing 1 [for RT=12]]
			| ... |
			[[16 * NON_RECEIVE_TIMEOUT (server) delay expires]]
			| [[NON_MAX_RETRANSMIT exceeded. Server stops requesting
			| for missing blocks and releases partial body]]
			| ... |
			Figure 7: Example of NON Request with Q-Block1 Option (With Eventual
			Failure)
	9.2. Q-Block2 Option		9.2. Q-Block2 Option
			These examples include the Observe Option to demonstrate how that
			option is used. Note that the Observe Option is not required for
			Q-Block2; the observe detail can thus be ignored.
	9.2.1. A Simple Example		9.2.1. A Simple Example
	Figure 7 illustrates the example of Q-Block2 Option. The client		Figure 8 illustrates the example of Q-Block2 Option. The client
	sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2		sends a NON GET carrying Observe and Q-Block2 Options. The Q-Block2
	Option indicates a block size hint (1024 bytes). This request is		Option indicates a block size hint (1024 bytes). This request is
	replied to by the server using four (4) blocks that are transmitted		replied to by the server using four (4) blocks that are transmitted
	to the client without any loss. Each of these blocks carries a		to the client without any loss. Each of these blocks carries a
	Q-Block2 Option. The same process is repeated when an Observe is		Q-Block2 Option. The same process is repeated when an Observe is
	triggered, but no loss is experienced by any of the notification		triggered, but no loss is experienced by any of the notification
	blocks.		blocks.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	skipping to change at page 26, line 21 ¶		skipping to change at page 27, line 32 ¶
	|<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024		|<---------+ NON 2.05 M:0xf3 T:0xc0 O:1220 ET=19 QB2:2/1/1024
	|<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024		|<---------+ NON 2.05 M:0xf4 T:0xc0 O:1220 ET=19 QB2:3/0/1024
	| ... |		| ... |
	| [[Observe triggered]]		| [[Observe triggered]]
	|<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024		|<---------+ NON 2.05 M:0xf5 T:0xc0 O:1221 ET=20 QB2:0/1/1024
	|<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024		|<---------+ NON 2.05 M:0xf6 T:0xc0 O:1221 ET=20 QB2:1/1/1024
	|<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024		|<---------+ NON 2.05 M:0xf7 T:0xc0 O:1221 ET=20 QB2:2/1/1024
	|<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024		|<---------+ NON 2.05 M:0xf8 T:0xc0 O:1221 ET=20 QB2:3/0/1024
	| ... |		| ... |
	Figure 7: Example of NON Notifications with Q-Block2 Option (Without		Figure 8: Example of NON Notifications with Q-Block2 Option (Without
	Loss)		Loss)
	9.2.2. Handling MAX_PAYLOADS Limits		9.2.2. Handling MAX_PAYLOADS Limits
	Figure 8 illustrates the same as Figure 7 but this time has eleven		Figure 9 illustrates the same as Figure 8 but this time has eleven
	(11) payloads which exceeds MAX_PAYLOADS. There is no loss		(11) payloads which exceeds MAX_PAYLOADS. There is no loss
	experienced.		experienced.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024		+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/1/1024
	|<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024		|<---------+ NON 2.05 M:0x81 T:0xf0 O:1234 ET=21 QB2:0/1/1024
	|<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024		|<---------+ NON 2.05 M:0x82 T:0xf0 O:1234 ET=21 QB2:1/1/1024
	|<---------+ [[Payloads 3 - 9 not detailed]]		|<---------+ [[Payloads 3 - 9 not detailed]]
	skipping to change at page 27, line 32 ¶		skipping to change at page 28, line 32 ¶
	|<---------+ [[Payloads 3 - 9 not detailed]]		|<---------+ [[Payloads 3 - 9 not detailed]]
	|<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024		|<---------+ NON 2.05 M:0x9a T:0xf0 O:1235 ET=22 QB2:9/1/1024
	[[MAX_PAYLOADS has been reached]]		[[MAX_PAYLOADS has been reached]]
	| [[MAX_PAYLOADS blocks acknowledged by client using		| [[MAX_PAYLOADS blocks acknowledged by client using
	| 'Continue' Q-Block2]]		| 'Continue' Q-Block2]]
	+--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024		+--------->| NON GET /path M:0x03 T:0xf2 QB2:10/1/1024
	|<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024		|<---------+ NON 2.05 M:0x9b T:0xf0 O:1235 ET=22 QB2:10/0/1024
	[[Body has been received]]		[[Body has been received]]
	| ... |		| ... |
	Figure 8: Example of NON Notifications with Q-Block2 Option (Without		Figure 9: Example of NON Notifications with Q-Block2 Option (Without
	Loss)		Loss)
	9.2.3. Handling MAX_PAYLOADS with Recovery		9.2.3. Handling MAX_PAYLOADS with Recovery
	Figure 9 shows the example of an Observe that is triggered but for		Figure 10 shows the example of an Observe that is triggered but for
	which some notification blocks are lost. The client detects the		which some notification blocks are lost. The client detects the
	missing blocks and requests their retransmission. It does so by		missing blocks and requests their retransmission. It does so by
	indicating the blocks that were successfully received.		indicating the blocks that are missing as one or more Q-Block2
			Options.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| ... |		| ... |
	| [[Observe triggered]]		| [[Observe triggered]]
	|<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024		|<---------+ NON 2.05 M:0xa1 T:0xf0 O:1236 ET=23 QB2:0/1/1024
	| X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024		| X<---+ NON 2.05 M:0xa2 T:0xf0 O:1236 ET=23 QB2:1/1/1024
	|<---------+ [[Payloads 3 - 8 not detailed]]		|<---------+ [[Payloads 3 - 8 not detailed]]
	| X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024		| X<---+ NON 2.05 M:0xaa T:0xf0 O:1236 ET=23 QB2:9/1/1024
	[[MAX_PAYLOADS has been reached]]		[[MAX_PAYLOADS has been reached]]
	skipping to change at page 28, line 35 ¶		skipping to change at page 29, line 35 ¶
	|<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024		|<---------+ NON 2.05 M:0xad T:0xf3 ET=23 QB2:9/1/1024
	| ... |		| ... |
	[[NON_RECEIVE_TIMEOUT (client) delay expires]]		[[NON_RECEIVE_TIMEOUT (client) delay expires]]
	| [[Client realizes block is still missing and asks for		| [[Client realizes block is still missing and asks for
	| missing block]]		| missing block]]
	+--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024		+--------->| NON GET /path M:0x05 T:0xf4 QB2:1/0/1024
	|<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024		|<---------+ NON 2.05 M:0xae T:0xf4 ET=23 QB2:1/1/1024
	[[Body has been received]]		[[Body has been received]]
	| ... |		| ... |
	Figure 9: Example of NON Notifications with Q-Block2 Option (Blocks		Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks
	Recovery)		Recovery)
	Under high levels of traffic loss, the client can elect not to retry
	getting missing blocks of data. This decision is implementation
	specific.
	9.2.4. Handling Recovery using M-bit Set		9.2.4. Handling Recovery using M-bit Set
	Figure 10 shows the example of an Observe that is triggered but only		Figure 11 shows the example of an Observe that is triggered but only
	the first two notification blocks reach the client. In order to		the first two notification blocks reach the client. In order to
	retrieve the missing blocks, the client sends a request with a single		retrieve the missing blocks, the client sends a request with a single
	Q-Block2 Option with the M bit set.		Q-Block2 Option with the M bit set.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| ... |		| ... |
	| [[Observe triggered]]		| [[Observe triggered]]
	|<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024		|<---------+ NON 2.05 M:0xb1 T:0xf0 O:1237 ET=24 QB2:0/1/1024
	|<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024		|<---------+ NON 2.05 M:0xb2 T:0xf0 O:1237 ET=24 QB2:1/1/1024
	skipping to change at page 29, line 35 ¶		skipping to change at page 30, line 35 ¶
	|<---------+ [[Payloads 3 - 9 not detailed]]		|<---------+ [[Payloads 3 - 9 not detailed]]
	|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024		|<---------+ NON 2.05 M:0xc2 T:0xf5 ET=24 QB2:9/1/1024
	[[MAX_PAYLOADS has been reached]]		[[MAX_PAYLOADS has been reached]]
	| [[MAX_PAYLOADS acknowledged by client using 'Continue'		| [[MAX_PAYLOADS acknowledged by client using 'Continue'
	| Q-Block2]]		| Q-Block2]]
	+--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024		+--------->| NON GET /path M:0x87 T:0xf6 QB2:10/1/1024
	|<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024		|<---------+ NON 2.05 M:0xc3 T:0xf0 O:1237 ET=24 QB2:10/0/1024
	[[Body has been received]]		[[Body has been received]]
	| ... |		| ... |
	Figure 10: Example of NON Notifications with Q-Block2 Option (Blocks		Figure 11: Example of NON Notifications with Q-Block2 Option (Blocks
	Recovery with M bit Set)		Recovery with M bit Set)
	9.3. Q-Block1 and Q-Block2 Options		9.3. Q-Block1 and Q-Block2 Options
	9.3.1. A Simple Example		9.3.1. A Simple Example
	Figure 11 illustrates the example of a FETCH using both Q-Block1 and		Figure 12 illustrates the example of a FETCH using both Q-Block1 and
	Q-Block2 Options along with an Observe Option. No loss is		Q-Block2 Options along with an Observe Option. No loss is
	experienced.		experienced.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024		+--------->| NON FETCH /path M:0x10 T:0x90 O:0 RT=30 QB1:0/1/1024
	+--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024		+--------->| NON FETCH /path M:0x11 T:0x91 O:0 RT=30 QB1:1/1/1024
	+--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024		+--------->| NON FETCH /path M:0x12 T:0x93 O:0 RT=30 QB1:2/0/1024
	|<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024		|<---------+ NON 2.05 M:0x60 T:0x93 O:1320 ET=90 QB2:0/1/1024
	skipping to change at page 30, line 23 ¶		skipping to change at page 31, line 23 ¶
	|<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024		|<---------+ NON 2.05 M:0x62 T:0x93 O:1320 ET=90 QB2:2/1/1024
	|<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024		|<---------+ NON 2.05 M:0x63 T:0x93 O:1320 ET=90 QB2:3/0/1024
	| ... |		| ... |
	| [[Observe triggered]]		| [[Observe triggered]]
	|<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024		|<---------+ NON 2.05 M:0x64 T:0x93 O:1321 ET=91 QB2:0/1/1024
	|<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024		|<---------+ NON 2.05 M:0x65 T:0x93 O:1321 ET=91 QB2:1/1/1024
	|<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024		|<---------+ NON 2.05 M:0x66 T:0x93 O:1321 ET=91 QB2:2/1/1024
	|<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024		|<---------+ NON 2.05 M:0x67 T:0x93 O:1321 ET=91 QB2:3/0/1024
	| ... |		| ... |
	Figure 11: Example of NON FETCH with Q-Block1 and Q-Block2 Options		Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options
	(Without Loss)		(Without Loss)
	9.3.2. Handling MAX_PAYLOADS Limits		9.3.2. Handling MAX_PAYLOADS Limits
	Figure 12 illustrates the same as Figure 11 but this time has eleven		Figure 13 illustrates the same as Figure 12 but this time has eleven
	(11) payloads in both directions which exceeds MAX_PAYLOADS. There		(11) payloads in both directions which exceeds MAX_PAYLOADS. There
	is no loss experienced.		is no loss experienced.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024		+--------->| NON FETCH /path M:0x30 T:0xa0 O:0 RT=10 QB1:0/1/1024
	+--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024		+--------->| NON FETCH /path M:0x31 T:0xa1 O:0 RT=10 QB1:1/1/1024
	+--------->| [[Payloads 3 - 9 not detailed]]		+--------->| [[Payloads 3 - 9 not detailed]]
	+--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024		+--------->| NON FETCH /path M:0x39 T:0xa9 O:0 RT=10 QB1:9/1/1024
	skipping to change at page 31, line 39 ¶		skipping to change at page 32, line 39 ¶
	|<---------+ [[Payloads 3 - 9 not detailed]]		|<---------+ [[Payloads 3 - 9 not detailed]]
	|<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024		|<---------+ NON 2.05 M:0x95 T:0xaa O:1335 ET=22 QB2:9/1/1024
	[[MAX_PAYLOADS has been reached]]		[[MAX_PAYLOADS has been reached]]
	| [[MAX_PAYLOADS blocks acknowledged by client using		| [[MAX_PAYLOADS blocks acknowledged by client using
	| 'Continue' Q-Block2]]		| 'Continue' Q-Block2]]
	+--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024		+--------->| NON FETCH /path M:0x3c T:0xac QB2:10/1/1024
	|<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024		|<---------+ NON 2.05 M:0x96 T:0xaa O:1335 ET=22 QB2:10/0/1024
	[[Body has been received]]		[[Body has been received]]
	| ... |		| ... |
	Figure 12: Example of NON FETCH with Q-Block1 and Q-Block2 Options		Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options
	(Without Loss)		(Without Loss)
	9.3.3. Handling Recovery		9.3.3. Handling Recovery
	Consider now a scenario where there are some blocks are lost in		Consider now a scenario where there are some blocks are lost in
	transmission as illustrated in Figure 13.		transmission as illustrated in Figure 14.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024		+--------->| NON FETCH /path M:0x50 T:0xc0 O:0 RT=31 QB1:0/1/1024
	+--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024		+--->X | NON FETCH /path M:0x51 T:0xc1 O:0 RT=31 QB1:1/1/1024
	+--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024		+--->X | NON FETCH /path M:0x52 T:0xc2 O:0 RT=31 QB1:2/1/1024
	+--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024		+--------->| NON FETCH /path M:0x53 T:0xc3 O:0 RT=31 QB1:3/0/1024
	| ... |		| ... |
	[[NON_RECEIVE_TIMEOUT (server) delay expires]]		[[NON_RECEIVE_TIMEOUT (server) delay expires]]
	Figure 13: Example of NON FETCH with Q-Block1 and Q-Block2 Options		Figure 14: Example of NON FETCH with Q-Block1 and Q-Block2 Options
	(With Loss)		(With Loss)
	The server realizes that some blocks are missing and asks for the		The server realizes that some blocks are missing and asks for the
	missing blocks in one go (Figure 14). It does so by indicating which		missing blocks in one go (Figure 15). It does so by indicating which
	blocks have not been received in the data portion of the response.		blocks have not been received in the data portion of the response.
	The token used in the response is be the token that was used in the		The token used in the response is be the token that was used in the
	last block number received payload. The client can then derive the		last block number received payload. The client can then derive the
	Request-Tag by matching the token with the sent request.		Request-Tag by matching the token with the sent request.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	|<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2 [for RT=31]]		|<---------+ NON 4.08 M:0xa0 T:0xc3 [Missing 1,2 [for RT=31]]
	| [[Client responds with missing payloads]]		| [[Client responds with missing payloads]]
	skipping to change at page 32, line 42 ¶		skipping to change at page 33, line 42 ¶
	| [[Server received FETCH body,		| [[Server received FETCH body,
	| starts transmitting response body]]		| starts transmitting response body]]
	|<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024		|<---------+ NON 2.05 M:0xa1 T:0xc3 O:1236 ET=23 QB2:0/1/1024
	| X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024		| X<---+ NON 2.05 M:0xa2 T:0xc3 O:1236 ET=23 QB2:1/1/1024
	|<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024		|<---------+ NON 2.05 M:0xa3 T:0xc3 O:1236 ET=23 QB2:2/1/1024
	| X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024		| X<---+ NON 2.05 M:0xa4 T:0xc3 O:1236 ET=23 QB2:3/0/1024
	| ... |		| ... |
	[[NON_RECEIVE_TIMEOUT (client) delay expires]]		[[NON_RECEIVE_TIMEOUT (client) delay expires]]
	| |		| |
	Figure 14: Example of NON Request with Q-Block1 Option (Server		Figure 15: Example of NON Request with Q-Block1 Option (Server
	Recovery)		Recovery)
	The client realizes that not all the payloads of the response have		The client realizes that not all the payloads of the response have
	been returned. The client then asks for the missing blocks in one go		been returned. The client then asks for the missing blocks in one go
	(Figure 15). However, because the original request is spread over		(Figure 16). Note that, following Section 2.7 of [RFC7959], the
	multiple payloads using Q-Block1, the entire FETCH body has to be		FETCH request does not include the Q-Block1 or any payload.
	used to make the request for the missing payloads.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB1:0/1/1024\		+--------->| NON FETCH /path M:0x56 T:0xc6 RT=31 QB2:1/0/1024\
	| | QB2:1/0/1024\
	| | QB2:3/0/1024
	+--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB1:1/1/1024\
	| | QB2:1/0/1024\
	| | QB2:3/0/1024
	+--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB1:2/1/1024\
	| | QB2:1/0/1024\
	| | QB2:3/0/1024
	+--------->| NON FETCH /path M:0x59 T:0xc9 RT=31 QB1:3/0/1024\
	| | QB2:1/0/1024\
	| | QB2:3/0/1024		| | QB2:3/0/1024
	| [[Server received FETCH request,		| [[Server receives FETCH request for missing payloads,
	| starts transmitting missing blocks]]		| starts transmitting missing blocks]]
	| X<---+ NON 2.05 M:0xa5 T:0xc9 ET=23 QB2:1/1/1024		| X<---+ NON 2.05 M:0xa5 T:0xc6 ET=23 QB2:1/1/1024
	|<---------+ NON 2.05 M:0xa6 T:0xc9 ET=23 QB2:3/0/1024		|<---------+ NON 2.05 M:0xa6 T:0xc6 ET=23 QB2:3/0/1024
	| ... |		| ... |
	[[NON_RECEIVE_TIMEOUT (client) delay expires]]		[[NON_RECEIVE_TIMEOUT (client) delay expires]]
	| [[Client realizes block is still missing and asks for		| [[Client realizes block is still missing and asks for
	| missing block]]		| missing block]]
	+--------->| NON FETCH /path M:0x5a T:0xca RT=31 QB1:0/1/1024\		+--------->| NON FETCH /path M:0x57 T:0xc7 RT=31 QB2:1/0/1024
	| | QB2:1/0/1024		| [[Server receives FETCH request for missing payload,
	+--------->| NON FETCH /path M:0x5b T:0xcb RT=31 QB1:1/1/1024\
	| | QB2:1/0/1024
	+--------->| NON FETCH /path M:0x5c T:0xcc RT=31 QB1:2/1/1024\
	| | QB2:1/0/1024
	+--------->| NON FETCH /path M:0x5d T:0xcd RT=31 QB1:3/0/1024\
	| | QB2:1/0/1024
	| [[Server received FETCH request,
	| starts transmitting missing block]]		| starts transmitting missing block]]
	|<---------+ NON 2.05 M:0xa7 T:0xcd ET=23 QB2:1/1/1024		|<---------+ NON 2.05 M:0xa7 T:0xc7 ET=23 QB2:1/1/1024
			[[Body has been received]]
			| ... |
			| [[Observe triggered]]
			|<---------+ NON 2.05 M:0xa8 T:0xc3 O:1337 ET=24 QB2:0/1/1024
			| X<---+ NON 2.05 M:0xa9 T:0xc3 O:1337 ET=24 QB2:1/1/1024
			|<---------+ NON 2.05 M:0xaa T:0xc3 O:1337 ET=24 QB2:2/0/1024
			[[NON_RECEIVE_TIMEOUT (client) delay expires]]
			| [[Client realizes block is still missing and asks for
			| missing block]]
			+--------->| NON FETCH /path M:0x58 T:0xc8 RT=31 QB2:1/0/1024
			| [[Server receives FETCH request for missing payload,
			| starts transmitting missing block]]
			|<---------+ NON 2.05 M:0xa7 T:0xc8 ET=23 QB2:1/1/1024
	[[Body has been received]]		[[Body has been received]]
	| ... |		| ... |
	Figure 15: Example of NON Request with Q-Block1 Option (Client		Figure 16: Example of NON Request with Q-Block1 Option (Client
	Recovery)		Recovery)
	10. IANA Considerations		10. IANA Considerations
	10.1. New CoAP Options		10.1. New CoAP Options
	IANA is requested to add the following entries to the "CoAP Option		IANA is requested to add the following entries to the "CoAP Option
	Numbers" sub-registry [Options]:		Numbers" sub-registry [Options]:
	+--------+------------------+-----------+		+--------+------------------+-----------+
	| Number | Name | Reference |		| Number | Name | Reference |
	+========+==================+===========+		+========+==================+===========+
	| TBA1 | Q-Block1 | [RFCXXXX] |		| TBA1 | Q-Block1 | [RFCXXXX] |
	| TBA2 | Q-Block2 | [RFCXXXX] |		| TBA2 | Q-Block2 | [RFCXXXX] |
	+--------+------------------+-----------+		+--------+------------------+-----------+
	Table 4: CoAP Q-Block1 and Q-Block2 Option Numbers		Table 5: CoAP Q-Block1 and Q-Block2 Option Numbers
	This document suggests 19 (TBA1) and 51 (TBA2) as a values to be		This document suggests 19 (TBA1) and 51 (TBA2) as values to be
	assigned for the new option numbers.		assigned for the new option numbers.
	10.2. New Media Type		10.2. New Media Type
	This document requests IANA to register the "application/missing-		This document requests IANA to register the "application/missing-
	blocks+cbor-seq" media type in the "Media Types" registry		blocks+cbor-seq" media type in the "Media Types" registry
	[IANA-MediaTypes]:		[IANA-MediaTypes]:
	Type name: application		Type name: application
	skipping to change at page 36, line 7 ¶		skipping to change at page 37, line 7 ¶
	Provisional registration? No		Provisional registration? No
	10.3. New Content Format		10.3. New Content Format
	This document requests IANA to register the CoAP Content-Format ID		This document requests IANA to register the CoAP Content-Format ID
	for the "application/missing-blocks+cbor-seq" media type in the "CoAP		for the "application/missing-blocks+cbor-seq" media type in the "CoAP
	Content-Formats" registry [Format]:		Content-Formats" registry [Format]:
	o Media Type: application/missing-blocks+cbor-seq		o Media Type: application/missing-blocks+cbor-seq
	o Encoding: -		o Encoding: -
	o Id: TBD3		o Id: TBA3
	o Reference: [RFCXXXX]		o Reference: [RFCXXXX]
			This document suggests 272 (TBA3) as a value to be assigned for the
			new content format number.
			10.4. New CoAP Signaling Option Number
			This document requests IANA to register the following option in the
			"CoAP Signaling Option Numbers" registry [CSM].
			+------------+--------+-----------------------+-----------+
			| Applies to | Number | Name | Reference |
			+============+========+=======================+===========+
			| 7.01 | TBA4 | Q-Block-Wise-Transfer | [RFCXXXX] |
			+------------+--------+-----------------------+-----------+
			Table 6: CoAP Signaling Option Codes
			This document suggests 8 (TBA4) as a value to be assigned for the new
			option number.
	11. Security Considerations		11. Security Considerations
	Security considerations discussed in Section 7 of [RFC7959] should be		Security considerations discussed in Section 7 of [RFC7959] should be
	taken into account.		taken into account.
	Security considerations discussed in Sections 11.3 and 11.4 of		Security considerations discussed in Sections 11.3 and 11.4 of
	[RFC7252] should be taken into account.		[RFC7252] should be taken into account.
	OSCORE provides end-to-end protection of all information that is not		OSCORE provides end-to-end protection of all information that is not
	required for proxy operations and requires that a security context is		required for proxy operations and requires that a security context is
	skipping to change at page 38, line 16 ¶		skipping to change at page 39, line 36 ¶
	Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,		Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
	<https://www.rfc-editor.org/info/rfc8742>.		<https://www.rfc-editor.org/info/rfc8742>.
	[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object		[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949,		Representation (CBOR)", STD 94, RFC 8949,
	DOI 10.17487/RFC8949, December 2020,		DOI 10.17487/RFC8949, December 2020,
	<https://www.rfc-editor.org/info/rfc8949>.		<https://www.rfc-editor.org/info/rfc8949>.
	13.2. Informative References		13.2. Informative References
	[Format] , <https://www.iana.org/assignments/core-parameters/core-		[CSM] "CoAP Signaling Option Numbers",
	parameters.xhtml#content-formats>.		<https://www.iana.org/assignments/core-parameters/core-
			parameters.xhtml#signaling-option-numbers>.
			[Format] "CoAP Content-Formats", <https://www.iana.org/assignments/
			core-parameters/core-parameters.xhtml#content-formats>.
	[I-D.bosh-dots-quick-blocks]		[I-D.bosh-dots-quick-blocks]
	Boucadair, M. and J. Shallow, "Distributed Denial-of-		Boucadair, M. and J. Shallow, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Signal Channel		Service Open Threat Signaling (DOTS) Signal Channel
	Configuration Attributes for Faster Block Transmission",		Configuration Attributes for Faster Block Transmission",
	draft-bosh-dots-quick-blocks-00 (work in progress),		draft-bosh-dots-quick-blocks-00 (work in progress),
	January 2021.		January 2021.
	[I-D.ietf-dots-telemetry]		[I-D.ietf-dots-telemetry]
	Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c.,		Boucadair, M., Reddy.K, T., Doron, E., chenmeiling, c.,
	and J. Shallow, "Distributed Denial-of-Service Open Threat		and J. Shallow, "Distributed Denial-of-Service Open Threat
	Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15		Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-15
	(work in progress), December 2020.		(work in progress), December 2020.
	[IANA-MediaTypes]		[IANA-MediaTypes]
	IANA, "Media Types",		IANA, "Media Types",
	<https://www.iana.org/assignments/media-types>.		<https://www.iana.org/assignments/media-types>.
	[Options] , <https://www.iana.org/assignments/core-parameters/core-		[Options] "CoAP Option Numbers", <https://www.iana.org/assignments/
	parameters.xhtml#option-numbers>.		core-parameters/core-parameters.xhtml#option-numbers>.
	[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,		[RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis,
	"Increasing TCP's Initial Window", RFC 6928,		"Increasing TCP's Initial Window", RFC 6928,
	DOI 10.17487/RFC6928, April 2013,		DOI 10.17487/RFC6928, April 2013,
	<https://www.rfc-editor.org/info/rfc6928>.		<https://www.rfc-editor.org/info/rfc6928>.
	[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data		[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
	Definition Language (CDDL): A Notational Convention to		Definition Language (CDDL): A Notational Convention to
	Express Concise Binary Object Representation (CBOR) and		Express Concise Binary Object Representation (CBOR) and
	JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,		JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
	June 2019, <https://www.rfc-editor.org/info/rfc8610>.		June 2019, <https://www.rfc-editor.org/info/rfc8610>.
	[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,		[RFC8782] Reddy.K, T., Ed., Boucadair, M., Ed., Patil, P.,
	Mortensen, A., and N. Teague, "Distributed Denial-of-		Mortensen, A., and N. Teague, "Distributed Denial-of-
	Service Open Threat Signaling (DOTS) Signal Channel		Service Open Threat Signaling (DOTS) Signal Channel
	Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,		Specification", RFC 8782, DOI 10.17487/RFC8782, May 2020,
	<https://www.rfc-editor.org/info/rfc8782>.		<https://www.rfc-editor.org/info/rfc8782>.
			[RFC8974] Hartke, K. and M. Richardson, "Extended Tokens and
			Stateless Clients in the Constrained Application Protocol
			(CoAP)", RFC 8974, DOI 10.17487/RFC8974, January 2021,
			<https://www.rfc-editor.org/info/rfc8974>.
	Appendix A. Examples with Confirmable Messages		Appendix A. Examples with Confirmable Messages
	These examples assume NSTART has been increased to at least 4.		These examples assume NSTART has been increased to at least 4.
	The notations provided in Figure 2 are used in the following		The notations provided in Figure 2 are used in the following
	subsections.		subsections.
	A.1. Q-Block1 Option		A.1. Q-Block1 Option
	Let's now consider the use Q-Block1 Option with a CON request as		Let's now consider the use Q-Block1 Option with a CON request as
	shown in Figure 16. All the blocks are acknowledged (ACK).		shown in Figure 17. All the blocks are acknowledged (ACK).
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024		+--------->| CON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024
	+--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024		+--------->| CON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024
	+--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024		+--------->| CON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
	+--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024		+--------->| CON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
	|<---------+ ACK 0.00 M:0x01		|<---------+ ACK 0.00 M:0x01
	|<---------+ ACK 0.00 M:0x02		|<---------+ ACK 0.00 M:0x02
	|<---------+ ACK 0.00 M:0x03		|<---------+ ACK 0.00 M:0x03
	|<---------+ ACK 2.04 M:0x04		|<---------+ ACK 2.04 M:0x04
	| |		| |
	Figure 16: Example of CON Request with Q-Block1 Option (Without Loss)		Figure 17: Example of CON Request with Q-Block1 Option (Without Loss)
	Now, suppose that a new body of data is to be sent but with some		Now, suppose that a new body of data is to be sent but with some
	blocks dropped in transmission as illustrated in Figure 17. The		blocks dropped in transmission as illustrated in Figure 18. The
	client will retry sending blocks for which no ACK was received.		client will retry sending blocks for which no ACK was received.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024		+--------->| CON PUT /path M:0x05 T:0xf4 RT=11 QB1:0/1/1024
	+--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024		+--->X | CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
	+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024		+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
	+--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024		+--------->| CON PUT /path M:0x08 T:0xf7 RT=11 QB1:3/1/1024
	|<---------+ ACK 0.00 M:0x05		|<---------+ ACK 0.00 M:0x05
	skipping to change at page 40, line 28 ¶		skipping to change at page 41, line 47 ¶
	+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024		+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
	|<---------+ ACK 0.00 M:0x06		|<---------+ ACK 0.00 M:0x06
	| ... |		| ... |
	[[ACK_TIMEOUT exponential backoff (client) delay expires]]		[[ACK_TIMEOUT exponential backoff (client) delay expires]]
	| [[Client retransmits associated packet]]		| [[Client retransmits associated packet]]
	+--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024		+--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
	| ... |		| ... |
	[[Either body transmission failure (acknowledge retry timeout)		[[Either body transmission failure (acknowledge retry timeout)
	or successfully transmitted.]]		or successfully transmitted.]]
	Figure 17: Example of CON Request with Q-Block1 Option (Blocks		Figure 18: Example of CON Request with Q-Block1 Option (Blocks
	Recovery)		Recovery)
	It is up to the implementation as to whether the application process		It is up to the implementation as to whether the application process
	stops trying to send this particular body of data on reaching		stops trying to send this particular body of data on reaching
	MAX_RETRANSMIT for any payload, or separately tries to initiate the		MAX_RETRANSMIT for any payload, or separately tries to initiate the
	new transmission of the payloads that have not been acknowledged		new transmission of the payloads that have not been acknowledged
	under these adverse traffic conditions.		under these adverse traffic conditions.
	If there is likely to be the possibility of network transient losses,		If there is likely to be the possibility of network transient losses,
	then the use of NON should be considered.		then the use of NON should be considered.
	A.2. Q-Block2 Option		A.2. Q-Block2 Option
	An example of the use of Q-Block2 Option with Confirmable messages is		An example of the use of Q-Block2 Option with Confirmable messages is
	shown in Figure 18.		shown in Figure 19.
	Client Server		Client Server
	| |		| |
	+--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024		+--------->| CON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024
	|<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024		|<---------+ ACK 2.05 M:0x01 T:0xf0 O:1234 ET=21 QB2:0/1/1024
	|<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024		|<---------+ ACK 2.05 M:0xe1 T:0xf0 O:1234 ET=21 QB2:1/1/1024
	|<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024		|<---------+ ACK 2.05 M:0xe2 T:0xf0 O:1234 ET=21 QB2:2/1/1024
	|<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024		|<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024
	| ... |		| ... |
	| [[Observe triggered]]		| [[Observe triggered]]
	skipping to change at page 41, line 44 ¶		skipping to change at page 43, line 44 ¶
	| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024		| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
	|--------->+ ACK 0.00 M:0xe9		|--------->+ ACK 0.00 M:0xe9
	| ... |		| ... |
	[[ACK_TIMEOUT exponential backoff (server) delay expires]]		[[ACK_TIMEOUT exponential backoff (server) delay expires]]
	| [[Server retransmits associated packet]]		| [[Server retransmits associated packet]]
	| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024		| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
	| ... |		| ... |
	[[Either body transmission failure (acknowledge retry timeout)		[[Either body transmission failure (acknowledge retry timeout)
	or successfully transmitted.]]		or successfully transmitted.]]
	Figure 18: Example of CON Notifications with Q-Block2 Option		Figure 19: Example of CON Notifications with Q-Block2 Option
	It is up to the implementation as to whether the application process		It is up to the implementation as to whether the application process
	stops trying to send this particular body of data on reaching		stops trying to send this particular body of data on reaching
	MAX_RETRANSMIT for any payload, or separately tries to initiate the		MAX_RETRANSMIT for any payload, or separately tries to initiate the
	new transmission of the payloads that have not been acknowledged		new transmission of the payloads that have not been acknowledged
	under these adverse traffic conditions.		under these adverse traffic conditions.
	If there is likely to be the possibility of network transient losses,		If there is likely to be the possibility of network transient losses,
	then the use of NON should be considered.		then the use of NON should be considered.
End of changes. 87 change blocks.
	205 lines changed or deleted		293 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/