draft-ietf-core-new-block-00.txt		draft-ietf-core-new-block-01.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: February 19, 2021 August 18, 2020		Expires: March 27, 2021 September 23, 2020
	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-00		draft-ietf-core-new-block-01
	Abstract		Abstract
	This document specifies new Constrained Application Protocol (CoAP)		This document specifies alternate Constrained Application Protocol
	Block-Wise transfer options: Block3 and Block4 Options.		(CoAP) Block-Wise transfer options: Quick-Block1 and Quick-Block2
			Options.
	These options are similar to the CoAP Block1 and Block2 Options, but		These options are similar to the CoAP Block1 and Block2 Options, not
	enable faster transmission rates for large amounts of data with less		a replacement for them, but do enable faster transmission rates for
	packet interchanges as well as supporting faster recovery should any		large amounts of data with less packet interchanges as well as
	of the blocks get lost in transmission.		supporting faster recovery should any of the blocks get lost in
			transmission.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 February 19, 2021.		This Internet-Draft will expire on March 27, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Existing CoAP Block-Wise Transfer Options . . . . . . . . 2		1.1. Existing CoAP Block-Wise Transfer Options . . . . . . . . 3
	1.2. New CoAP Block-Wise Transfer Options . . . . . . . . . . 3		1.2. Alternative CoAP Block-Wise Transfer Options . . . . . . 3
	1.3. New CoAP Response Code . . . . . . . . . . . . . . . . . 4		1.3. An Updated CoAP Response Code . . . . . . . . . . . . . . 4
	1.4. Applicability Scope . . . . . . . . . . . . . . . . . . . 4		1.4. Applicability Scope . . . . . . . . . . . . . . . . . . . 5
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. The Block3 and Block4 Options . . . . . . . . . . . . . . . . 5		3. The Quick-Block1 and Quick-Block2 Options . . . . . . . . . . 6
	3.1. Properties of Block3 and Block4 Options . . . . . . . . . 5		3.1. Properties of Quick-Block1 and Quick-Block2 Options . . . 6
	3.2. Structure of Block3 and Block4 Options . . . . . . . . . 6		3.2. Structure of Quick-Block1 and Quick-Block2 Options . . . 7
	3.3. Using the Block3 Option . . . . . . . . . . . . . . . . . 7		3.3. Using the Quick-Block1 Option . . . . . . . . . . . . . . 8
	3.4. Using the Block 4 Option . . . . . . . . . . . . . . . . 9		3.4. Using the Quick-Block2 Option . . . . . . . . . . . . . . 9
	3.5. Working with Observe and Block4 Options . . . . . . . . . 11		3.5. Working with Observe and Quick-Block2 Options . . . . . . 10
	3.6. Working with Size1 and Size2 Options . . . . . . . . . . 11		3.6. Working with Size1 and Size2 Options . . . . . . . . . . 11
	3.7. Use of Block3 and Block4 Options Together . . . . . . . . 11		3.7. Use of Quick-Block1 and Quick-Block2 Options Together . . 11
	4. TBA3 (Missing Payloads) Response Code . . . . . . . . . . . . 11		4. The Use of 4.08 (Request Entity Incomplete) Response Code . . 11
	5. Caching Considerations . . . . . . . . . . . . . . . . . . . 12		5. The Use of Tokens . . . . . . . . . . . . . . . . . . . . . . 12
	6. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 13		6. Congestion Control . . . . . . . . . . . . . . . . . . . . . 12
	7. Examples of Selective Block Recovery . . . . . . . . . . . . 13		7. Caching Considerations . . . . . . . . . . . . . . . . . . . 13
	7.1. Block3 Option: Non-Confirmable Example . . . . . . . . . 13		8. HTTP-Mapping Considerations . . . . . . . . . . . . . . . . . 14
	7.2. Block4 Option: Non-Confirmable Example . . . . . . . . . 15		9. Examples of Selective Block Recovery . . . . . . . . . . . . 14
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		9.1. Quick-Block1 Option: Non-Confirmable Example . . . . . . 15
	8.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 16		9.2. Quick-Block2 Option: Non-Confirmable Example . . . . . . 16
	8.2. New CoAP Response Code . . . . . . . . . . . . . . . . . 17		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8.3. New Content Format . . . . . . . . . . . . . . . . . . . 17		10.1. New CoAP Options . . . . . . . . . . . . . . . . . . . . 18
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 17		10.2. New Content Format . . . . . . . . . . . . . . . . . . . 19
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		11. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	11.1. Normative References . . . . . . . . . . . . . . . . . . 18		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	11.2. Informative References . . . . . . . . . . . . . . . . . 19		13.1. Normative References . . . . . . . . . . . . . . . . . . 19
	Appendix A. Examples with Confirmable Messages . . . . . . . . . 19		13.2. Informative References . . . . . . . . . . . . . . . . . 20
	A.1. Block3 Option . . . . . . . . . . . . . . . . . . . . . . 20		Appendix A. Examples with Confirmable Messages . . . . . . . . . 21
	A.2. Block4 Option . . . . . . . . . . . . . . . . . . . . . . 21		A.1. Quick-Block1 Option . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		A.2. Quick-Block2 Option . . . . . . . . . . . . . . . . . . . 23
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	1.1. Existing CoAP Block-Wise Transfer Options		1.1. Existing CoAP Block-Wise Transfer Options
	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 further updated by [RFC8323] for use over TCP, TLS,		fragmentation and further updated by [RFC8323] for use over TCP, TLS,
	and Websockets.		and Websockets.
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 23 ¶
	and Websockets.		and Websockets.
	The CoAP Block1 and Block2 Options work well in environments where		The CoAP Block1 and Block2 Options work well in environments where
	there are no or minimal packet losses. These options operate		there are no or minimal packet losses. These options operate
	synchronously where each block has to be requested and can only ask		synchronously where each block has to be requested and can only ask
	for (or send) the next block when the request for the previous block		for (or send) the next block when the request for the previous block
	has completed. Packet, and hence block transmission rate, is		has completed. Packet, and hence block transmission rate, is
	controlled by Round Trip Times (RTTs).		controlled by Round Trip Times (RTTs).
	There is a requirement for these blocks of data to be transmitted at		There is a requirement for these blocks of data to be transmitted at
	higher rates under network conditions where there may be transient		higher rates under network conditions where there may be asymmetrical
	packet loss. An example is when a network is subject to a		transient packet loss. An example is when a network is subject to a
	Distributed Denial of Service (DDoS) attack and there is a need for		Distributed Denial of Service (DDoS) attack and there is a need for
	DDoS mitigation agents relying upon CoAP to communicate with each		DDoS mitigation agents relying upon CoAP to communicate with each
	other (e.g., [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959]		other (e.g., [I-D.ietf-dots-telemetry]). As a reminder, [RFC7959]
	recommends use of Confirmable (CON) responses to handle potential		recommends use of Confirmable (CON) responses to handle potential
	packet loss; which does not work with a flooded pipe DDoS situation.		packet loss; which does not work with a flooded pipe DDoS situation.
	1.2. New CoAP Block-Wise Transfer Options		1.2. Alternative CoAP Block-Wise Transfer Options
	This document introduces the CoAP Block3 and Block4 Options. These		This document introduces the CoAP Quick-Block1 and Quick-Block2
	options are similar in operation to the CoAP Block1 and Block2		Options. These options are similar in operation to the CoAP Block1
	Options respectively, but enable faster transmissions of sets of		and Block2 Options respectively, they are not a replacement for them,
	blocks of data with less packet interchanges as well as supporting		but have the following benefits:
	faster recovery should any of the Blocks get lost in transmission.
			o They can operate in environments where packet loss is highly
			asymmetrical.
			o They enable faster transmissions of sets of blocks of data with
			less packet interchanges.
			o They support faster recovery should any of the Blocks get lost in
			transmission.
			There are the following disadvantages over using CoAP Block 1 and
			Block2 Options:
			o Loss of lock-stepping so payloads are not always received in the
			correct (block ascending) order.
			o Additional congestion control measures need to be put in place.
	Using Non-confirmable (NON) messages, the faster transmissions occur		Using Non-confirmable (NON) messages, the faster transmissions occur
	as all the Blocks can be transmitted serially (as are IP fragmented		as all the Blocks can be transmitted serially (as are IP fragmented
	packets) without having to wait for an acknowledgement or next		packets) without having to wait for an acknowledgement or next
	request from the remote CoAP peer. Recovery of missing Blocks is		request from the remote CoAP peer. Recovery of missing Blocks is
	faster in that multiple missing Blocks can be requested in a single		faster in that multiple missing Blocks can be requested in a single
	CoAP packet.		CoAP packet. Even if there is asymmetrical packet loss, a body can
			still be sent and received by the peer whether the body compromises
			of a single or multiple payloads assuming no recovery is required.
	Note that the same performance benefits can be applied to Confirmable		Note that the same performance benefits can be applied to Confirmable
	messages if the value of NSTART is increased from 1 (Section 4.7 of		messages if the value of NSTART is increased from 1 (Section 4.7 of
	[RFC7252]). Some sample examples with Confirmable messages are		[RFC7252]). However, the asymmetrical packet loss is not a benefit
	provided in Appendix A.		here. Some sample examples with Confirmable messages are provided in
			Appendix A.
	There is little, if any, benefit of using these options with CoAP		There is little, if any, benefit of using these options with CoAP
	running over a reliable connection [RFC8323]. In this case, there is		running over a reliable connection [RFC8323]. In this case, there is
	no differentiation between Confirmable and NON as they are not used.		no differentiation between Confirmable and NON as they are not used.
	A CoAP endpoint can acknowledge all or a subset of the blocks.		A CoAP endpoint can acknowledge all or a subset of the blocks.
	Concretely, the receiving CoAP endpoint informs the CoAP endpoint		Concretely, the receiving CoAP endpoint informs the CoAP endpoint
	sender either successful receipt or reports on all blocks in the body		sender either successful receipt or reports on all blocks in the body
	that have been not yet been received. The CoAP endpoint sender will		that have been not yet been received. The CoAP endpoint sender will
	then retransmit only the blocks that have been lost in transmission.		then retransmit only the blocks that have been lost in transmission.
	Block3 and Block4 Options are used instead of Block1 and Block2		Quick-Block1 and Quick-Block2 Options can be used instead of Block1
	Options respectively because the transmission semantics and usage		and Block2 Options respectively when the different transmission
	have changed.		semantics are required. If the option is not supported by a peer,
			then transmissions can fall back to using Block1 and Block2
			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].
	1.3. New CoAP Response Code		1.3. An Updated CoAP Response Code
	This document defines a new CoAP Response Code (Section 5.9 of		This document updates the 4.08 (Request Entity Incomplete) by
	[RFC7252]), called TBA3 (Missing payloads), to report on payloads		defining an additional message format for reporting on payloads using
	using the Block3 Option that are not received by the server.		the Quick-Block1 Option that are not received by the server.
	See Section 4 for more details.		See Section 4 for more details.
	1.4. Applicability Scope		1.4. Applicability Scope
	The mechanism specified in the document includes guards to prevent a		The block-wise transfer specified in [RFC7959] covers the general
	CoAP agent from overloading the network by adopting an aggressive		case, but falls short in situations where packet loss is highly
	sending rate. These guards MUST be followed in addition to the		asymmetrical. The mechanism specified in the document provides
	existing CoAP congestion control as specified in Section 4.7 of		roughly similar features to the Block1/Block2 Options. It provides
	[RFC7252].		additional properties that are tailored towards the intended use
			case. Concretely, this mechanism primarily targets applications such
			as DDoS Open Threat Signaling (DOTS) that can't use Confirmable (CON)
			responses to handle potential packet loss and that support
			application-specific mechanisms to assess whether the remote peer is
			able to handle the messages sent by a CoAP endpoint (e.g., DOTS
			heartbeats in Section 4.7 of [RFC8782]).
	This mechanism primarily targets applications such as DDoS Open		The mechanism includes guards to prevent a CoAP agent from
	Threat Signaling (DOTS) that can't use Confirmable (CON) responses to		overloading the network by adopting an aggressive sending rate.
	handle potential packet loss and that support application-specific		These guards MUST be followed in addition to the existing CoAP
	mechanisms to assess whether the remote peer is able to handle the		congestion control as specified in Section 4.7 of [RFC7252]. See
	messages sent by a CoAP endpoint (e.g., DOTS heartbeats in		Section 6 for more details.
	Section 4.7 of [RFC8782]).
			This mechanism is not intended for general CoAP usage, and any use
			outside the intended use case should be carefully weighed against the
			loss of interoperability with generic CoAP applications. It is hoped
			that the experience gained with this mechanism can feed future
			extensions of the block-wise mechanism that will both generally
			applicable and serve this particular use case.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119][RFC8174] when, and only when, they appear in all		14 [RFC2119][RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	Readers should be familiar with the terms and concepts defined in		Readers should be familiar with the terms and concepts defined in
	[RFC7252].		[RFC7252].
	The terms "payload" and "body" are defined in [RFC7959]. The term		The terms "payload" and "body" are defined in [RFC7959]. The term
	"payload" is thus used for the content of a single CoAP message		"payload" is thus used for the content of a single CoAP message
	(i.e., a single block being transferred), while the term "body" is		(i.e., a single block being transferred), while the term "body" is
	used for the entire resource representation that is being transferred		used for the entire resource representation that is being transferred
	in a block-wise fashion.		in a block-wise fashion.
	3. The Block3 and Block4 Options		3. The Quick-Block1 and Quick-Block2 Options
	3.1. Properties of Block3 and Block4 Options		3.1. Properties of Quick-Block1 and Quick-Block2 Options
	The properties of Block3 and Block4 Options are shown in Table 1.		The properties of Quick-Block1 and Quick-Block2 Options are shown in
	The formatting of this table follows the one used in Table 4 of		Table 1. The formatting of this table follows the one used in
	[RFC7252] (Section 5.10). The C, U, N, and R columns indicate the		Table 4 of [RFC7252] (Section 5.10). The C, U, N, and R columns
	properties Critical, Unsafe, NoCacheKey, and Repeatable defined in		indicate the properties Critical, Unsafe, NoCacheKey, and Repeatable
	Section 5.4 of [RFC7252]. Only C column is marked for the Block3		defined in Section 5.4 of [RFC7252]. Only C and U columns are marked
	Option. Only C and R columns are marked for the Block4 Option.		for the Quick-Block1 Option. C, U, and R columns are marked for the
			Quick-Block2 Option.
	+--------+---+---+---+---+-----------+--------+--------+---------+		+--------+---+---+---+---+--------------+--------+--------+---------+
	| Number | C | U | N | R | Name | Format | Length | Default |		| Number | C | U | N | R | Name | Format | Length | Default |
	+========+===+===+===+===+===========+========+========+=========+		+========+===+===+===+===+==============+========+========+=========+
	| TBA1 | x | | | | Block3 | uint | 0-3 | (none) |		| TBA1 | x | x | | | Quick-Block1 | uint | 0-3 | (none) |
	| TBA2 | x | | | x | Block4 | uint | 0-3 | (none) |		| TBA2 | x | x | | x | Quick-Block2 | uint | 0-3 | (none) |
	+--------+---+---+---+---+-----------+--------+--------+---------+		+--------+---+---+---+---+--------------+--------+--------+---------+
	Table 1: CoAP Block3 and Block4 Option Properties		Table 1: CoAP Quick-Block1 and Quick-Block2 Option Properties
	The Block3 and Block4 Options can be present in both the request and		The Quick-Block1 and Quick-Block2 Options can be present in both the
	response messages. The Block3 Option pertains to the request payload		request and response messages. The Quick-Block1 Option pertains to
	and the Block4 Option pertains to the response payload. The Content-		the request payload and the Quick-Block2 Option pertains to the
	Format Option applies to the body, not to the payload (i.e., it must		response payload. The Content-Format Option applies to the body, not
	be the same for all payloads of the same body).		to the payload (i.e., it must be the same for all payloads of the
			same body).
	Block3 is useful with the payload-bearing POST, PUT, PATCH, and		Quick-Block1 Option is useful with the payload-bearing POST, PUT,
	iPATCH requests and their responses (2.01 and 2.04). Block4 Option		PATCH, and iPATCH requests and their responses (2.01 and 2.04).
	is useful with GET, POST, PUT, FETCH, PATCH, and iPATCH requests and
	their payload-bearing responses (2.01, 2.03, 2.04, and 2.05)
	(Section 5.5 of [RFC7252]).
	To indicate support for Block4 responses, the CoAP client MUST		Quick-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
	include the Block4 Option in a GET or similar requests so that the		iPATCH requests and their payload-bearing responses (2.01, 2.03,
	server knows that the client supports this Block4 functionality		2.04, and 2.05) (Section 5.5 of [RFC7252]).
	should it needs to send back a body that spans multiple payloads.
			To indicate support for Quick-Block2 responses, the CoAP client MUST
			include the Quick-Block2 Option in a GET or similar request, or the
			Quick-Block2 Option in a PUT or similar request, so that the server
			knows that the client supports this Quick-Block2 functionality should
			it needs to send back a body that spans multiple payloads.
	Otherwise, the server would use the Block2 Option (if supported) to		Otherwise, the server would use the Block2 Option (if supported) to
	send back a message body that is too large to fit into a single IP		send back a message body that is too large to fit into a single IP
	packet [RFC7959].		packet [RFC7959].
	If Block3 Option is present in a request or Block4 Option in a		If Quick-Block1 Option is present in a request or Quick-Block2 Option
	response (i.e., in that message to the payload of which it pertains),		in a response (i.e., in that message to the payload of which it
	it indicates a block-wise transfer and describes how this specific		pertains), it indicates a block-wise transfer and describes how this
	block-wise payload forms part of the entire body being transferred.		specific block-wise payload forms part of the entire body being
	If it is present in the opposite direction, it provides additional		transferred. If it is present in the opposite direction, it provides
	control on how that payload will be formed or was processed.		additional control on how that payload will be formed or was
			processed.
	Implementation of Block3 (or Block4) Option is intended to be
	optional. However, when it is present in a CoAP message, it MUST be
	processed (or the message rejected). Therefore, Block3 and Block4
	Options are identified as Critical options.
	The Block3 and Block4 Options are safe to forward. That is, a CoAP		Implementation of the Quick-Block1 and Quick-Block2 Options is
	proxy that does not understand the Block3 (or Block4) Option should		intended to be optional. However, when it is present in a CoAP
	forward the option on.		message, it MUST be processed (or the message rejected). Therefore,
			Quick-Block1 and Quick-Block2 Options are identified as Critical
			options.
	The Block4 Option is repeatable when requesting re-transmission of		The Quick-Block1 and Quick-Block2 Options are unsafe to forward.
	missing Blocks, but not otherwise. Except that case, any request		That is, a CoAP proxy that does not understand the Quick-Block1 (or
	carrying multiple Block3 (or Block4) Options MUST be handled		Quick-Block2) Option MUST reject the request or response that uses
	following the procedure specified in Section 5.4.5 of [RFC7252].		either option.
	PROBING_RATE parameter in CoAP indicates the average data rate that		The Quick-Block2 Option is repeatable when requesting re-transmission
	must not be exceeded by a CoAP endpoint in sending to a peer endpoint		of missing Blocks, but not otherwise. Except that case, any request
	that does not respond. The body of blocks will be subjected to		carrying multiple Quick-Block1 (or Quick-Block2) Options MUST be
	PROBING_RATE (Section 4.7 of [RFC7252]).		handled following the procedure specified in Section 5.4.5 of
			[RFC7252].
	The Block3 and Block4 Options, like the Block1 and Block2 Options,		The Quick-Block1 and Quick-Block2 Options, like the Block1 and Block2
	are both a class E and a class U in terms of OSCORE processing (see		Options, are both a class E and a class U in terms of OSCORE
	Section 4.1 of [RFC8613]): The Block3 (or Block4) Option MAY be an		processing (see Section 4.1 of [RFC8613]): The Quick-Block1 (or
	Inner or Outer option. The Inner and Outer values are therefore		Quick-Block2) Option MAY be an Inner or Outer option. The Inner and
	independent of each other. The Inner option is encrypted and		Outer values are therefore independent of each other. The Inner
	integrity protected between clients and servers, and provides message		option is encrypted and integrity protected between clients and
	body identification in case of end-to-end fragmentation of requests.		servers, and provides message body identification in case of end-to-
	The Outer option is visible to proxies and labels message bodies in		end fragmentation of requests. The Outer option is visible to
	case of hop-by-hop fragmentation of requests.		proxies and labels message bodies in case of hop-by-hop fragmentation
			of requests.
	3.2. Structure of Block3 and Block4 Options		3.2. Structure of Quick-Block1 and Quick-Block2 Options
	The structure of Block3 and Block4 Options follows the structure		The structure of Quick-Block1 and Quick-Block2 Options follows the
	defined in Section 2.2 of [RFC7959].		structure defined in Section 2.2 of [RFC7959].
	There is no default value for the Block3 and Block4 Options. Absence		There is no default value for the Quick-Block1 and Quick-Block2
	of one of these options is equivalent to an option value of 0 with		Options. Absence of one of these options is equivalent to an option
	respect to the value of block number (NUM) and more bit (M) that		value of 0 with respect to the value of block number (NUM) and more
	could be given in the option, i.e., it indicates that the current		bit (M) that could be given in the option, i.e., it indicates that
	block is the first and only block of the transfer (block number is		the current block is the first and only block of the transfer (block
	set to 0, M is unset). However, in contrast to the explicit value 0,		number is set to 0, M is unset). However, in contrast to the
	which would indicate a size of the block (SZX) of 0, and thus a size		explicit value 0, which would indicate a size of the block (SZX) of
	value of 16 bytes, there is no specific explicit size implied by the		0, and thus a size value of 16 bytes, there is no specific explicit
	absence of the option -- the size is left unspecified. (As for any		size implied by the absence of the option -- the size is left
	uint, the explicit value 0 is efficiently indicated by a zero-length		unspecified. (As for any uint, the explicit value 0 is efficiently
	option; this, therefore, is different in semantics from the absence		indicated by a zero-length option; this, therefore, is different in
	of the option).		semantics from the absence of the option).
	3.3. Using the Block3 Option		3.3. Using the Quick-Block1 Option
	The Block3 Option is used when the client wants to send a large		The Quick-Block1 Option is used when the client wants to send a large
	amount of data to the server using the POST, PUT, PATCH, or iPATCH		amount of data to the server using the POST, PUT, PATCH, or iPATCH
	methods where the data and headers do not fit into a single packet.		methods where the data and headers do not fit into a single packet.
	When Block3 Option is used, the client MUST include Request-Tag		When Quick-Block1 Option is used, the client MUST include a single
	Option [I-D.ietf-core-echo-request-tag]. The Request-Tag value MUST		Request-Tag Option [I-D.ietf-core-echo-request-tag]. The Request-Tag
	be the same for all of the blocks in the body of data that is being		value MUST be the same for all of the blocks in the body of data that
	transferred. It is also used to identify a particular block that		is being transferred. It is also used to identify a particular block
	needs to be re-transmitted. The Request-Tag is opaque in nature, but		of a body that needs to be re-transmitted. The Request-Tag is opaque
	it is RECOMMENDED that the client treats it as an unsigned integer of		in nature, but it is RECOMMENDED that the client treats it as an
	8 bytes in length. An implementation may want to consider limiting		unsigned integer of 8 bytes in length. An implementation may want to
	this to 4 bytes to reduce packet overhead size. The server still		consider limiting this to 4 bytes to reduce packet overhead size.
	treats it as an opaque entity. The Request-Tag value MUST be		The server still treats it as an opaque entity. The Request-Tag
	different for distinct bodies or sets of blocks of data and SHOULD be		value MUST be different for distinct bodies or sets of blocks of data
	incremented whenever a new body of data is being transmitted for a		and SHOULD be incremented whenever a new body of data is being
	CoAP session between peers. The initial Request-Tag value SHOULD be		transmitted for a CoAP session between peers. The initial Request-
	randomly generated by the client.		Tag value SHOULD be randomly generated by the client.
	The client sends all the individual payloads of the body using Block3
	and Request-Tag Options, only expecting a response when all the
	payloads have been sent. It is RECOMMENDED that after transmission
	of every set of MAX_PAYLOADS payloads of a single body, a delay is
	introduced of ACK_TIMEOUT (Section 4.8.2 of [RFC7252]) before the
	next set of payload transmissions to manage potential congestion
	issues. MAX_PAYLOADS should be configurable with a default value of
	10.
	Note: The default value is chosen for reasons similar to those
	discussed in Section 5 of [RFC6928].
	For NON transmissions, it is permissible, but not required, to send
	the ultimate payload of a MAX_PAYLOADS set as a Confirmable packet.
	If a Confirmable packet is used, then the client MUST wait for the
	ACK to be returned before sending the next set of payloads, which can
	be in time terms less than the ACK_TIMEOUT delay.
	Also, for NON transmissions, it is permissible, but not required, to
	send a Confirmable packet for the final payload of a body (that is, M
	bit unset). If a Confirmable packet is used, then the client MUST
	wait for the 2.01 (Created) or 2.04 (Changed) Response Codes to be
	returned for successful transmission, or TBA3 (Missing Payloads)
	Response Code to then resend the missing blocks (if any).
	With NON transmission, the server acknowledges receipt of all of the
	payloads that make up the body or can respond at any time during the
	receipt of the payloads to acknowledge that some of the payloads have
	arrived, but others are missing. It is RECOMMENDED that, unless
	there are receipt issues, the server only responds when the final
	payload (i.e., M bit unset) is received.
	For Confirmable transmission, the server MUST continue to acknowledge		For Confirmable transmission, the server MUST continue to acknowledge
	each packet. NSTART will also need to be increased from the default		each packet. NSTART will also need to be increased from the default
	(1) to get faster transmission rates.		(1) to get faster transmission rates.
	Tokens MUST be included. Each individual payload of the body MUST		Each individual payload of the body is treated as a new request.
	have a different Token value.
	A 2.01 (Created) or 2.04 (Changed) Response Code indicates successful		A 2.01 (Created) or 2.04 (Changed) Response Code indicates successful
	receipt of the entire body. The 2.31 (Continue) Response Code MUST		receipt of the entire body. The 2.31 (Continue) Response Code MUST
	NOT be used.		NOT be used.
			The 2.31 (Continue) Response is not used.
	A 4.00 (Bad Request) Response Code MUST be returned if the request		A 4.00 (Bad Request) Response Code MUST be returned if the request
	does not include a Request-Tag Option but does include a Block3		does not include a Request-Tag Option but does include a Quick-Block1
	option.		option.
	A 4.02 (Bad Option) Response Code MUST be returned if the server does		A 4.02 (Bad Option) Response Code MUST be returned if the server does
	not support the Block3 Option.		not support the Quick-Block1 Option.
	Use of 4.08 (Request Entity Incomplete) Response Code is discouraged
	when using Block3 Option because packets may arrive out of sequence;
	TBA3 (Missing Payloads) Response Code (Section 4) SHOULD be used
	instead. However, 4.08 (Request Entity Incomplete) Response Code is
	still valid to reject a Content-Format mismatch.
	A 4.13 (Request Entity Too Large) Response Code can be returned under		A 4.13 (Request Entity Too Large) Response Code can be returned under
	similar conditions to those discussed in Section 2.9.3 of [RFC7959].		similar conditions to those discussed in Section 2.9.3 of [RFC7959].
	A TBA3 (Missing Payloads) Response Code indicates that some of the		A 4.08 (Request Entity Incomplete) Response Code returned without
	payloads are missing and need to be resent. The client then re-		Content-Type "application/missing-blocks+cbor-seq" (Section 10.2) is
	transmits the missing payloads using the Request-Tag and Block3 to		handled as in Section 2.9.2 [RFC7959].
	specify the block number, SZX, and M bit as appropriate. The
	Request-Tag value to use is determined from the payload of the TBA3
	(Missing Payloads) Response Code. If the client dos not recognize
	the Request-Tag, the client can ignore this response. As discussed
	above, the sending of the list of missing blocks is subject to
	MAX_PAYLOADS.
	If the server has not received the final payload (i.e., a block with		A 4.08 (Request Entity Incomplete) Response Code returned with
	M bit unset), but one or other payloads have been received, it SHOULD		Content-Type "application/missing-blocks+cbor-seq" indicates that
	wait for up to MAX_TRANSMIT_SPAN (Section 4.8.2 of [RFC7252]) before		some of the payloads are missing and need to be resent. The client
	sending the TBA3 (Missing Payloads) Response Code. However, this		then re-transmits the missing payloads using the Request-Tag and
	timer MAY be reduced to two times ACK_TIMEOUT before sending a TBA3		Quick-Block1 to specify the block number, SZX, and M bit as
	(Missing Payloads) Response Code to cover the situation where		appropriate. The Request-Tag value to use is determined from the
	MAX_PAYLOADS has been triggered by the client causing a break in		payload of the 4.08 (Request Entity Incomplete) Response Code. If
	transmission.		the client does not recognize the Request-Tag, the client can ignore
			this response.
	In all cases, multiple TBA3 (Missing Payloads) Response Codes are		If the server has not received all the payloads of a body, but one or
	traffic limited by PROBING_RATE.		more payloads have been received, it SHOULD wait for up to
			MAX_TRANSMIT_SPAN (Section 4.8.2 of [RFC7252]) before sending the
			4.08 (Request Entity Incomplete) Response Code. However, this time
			MAY be reduced to two times ACK_TIMEOUT before sending a 4.08
			(Request Entity Incomplete) Response Code to cover the situation
			where MAX_PAYLOADS has been triggered by the client causing a break
			in transmission.
	If the client transmits a new body of data with a new Request-Tag to		If the client transmits a new body of data with a new Request-Tag to
	the same resource on a server, the server MUST remove any partially		the same resource on a server, the server MUST remove any partially
	received body held for a previous Request-Tag for that resource.		received body held for a previous Request-Tag for that resource.
	If the server receives a duplicate block with the same Request-Tag,		If the server receives a duplicate block with the same Request-Tag,
	it SHOULD silently ignore the packet.		it SHOULD silently ignore the packet.
	A server SHOULD only maintain a partial body (missing payloads) for		A server SHOULD only maintain a partial body (missing payloads) for
	up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).		up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]).
	3.4. Using the Block 4 Option		3.4. Using the Quick-Block2 Option
	Support for the receipt of Block4 Option by the client is indicated
	by using the Block4 Option in the GET, POST, PUT, FETCH, PATCH or
	iPATCH request. If the Block4 Option is not included in the request,
	the server MUST NOT send data using the Block4 Option, but can use
	Block2 if supported instead.
	In a request, the Block4 MUST always have the M bit set to 0.		In a request, for block number 0, the M bit unset indicates the
			entire body is requested. If the M bit is set for block number 0,
			this indicates that this is a repeat request. Otherwise for a
			request, the Quick-Block2 Option MUST always have the M bit unset.
	The payloads sent back from the server as a response MUST all have		The payloads sent back from the server as a response MUST all have
	the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The		the same ETag (Section 5.10.6 of [RFC7252]) for the same body. The
	server MUST NOT use the same ETag value for different representations		server MUST NOT use the same ETag value for different representations
	of a resource.		of a resource.
	The sending of the payloads is subject to MAX_PAYLOADS. If
	MAX_PAYLOADS is exceeded, the server MUST introduce an ACK_TIMEOUT
	delay before transmitting the next set of payloads.
	The ETag is opaque in nature, but it is RECOMMENDED that the server		The ETag is opaque in nature, but it is RECOMMENDED that the server
	treats it as an unsigned integer of 8 bytes in length. An		treats it 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 client still treats it as an opaque		reduce packet overhead size. The client still treats it as an opaque
	entity. The ETag value MUST be different for distinct bodies or sets		entity. The ETag value MUST be different for distinct bodies or sets
	of blocks of data and SHOULD be incremented whenever a new body of		of blocks of data and SHOULD be incremented whenever a new body of
	data is being transmitted for a CoAP session between peers. The		data is being transmitted for a CoAP session between peers. The
	initial ETag value SHOULD be randomly generated by the server.		initial ETag value SHOULD be randomly generated by the server.
	For NON transmission, it is permissible, but not required, to send
	the ultimate payload of a MAX_PAYLOADS set as a Confirmable packet.
	If a Confirmable packet is used, then the server MUST wait for the
	ACK to be received before sending the next set of payloads, which can
	be in time terms less than the ACK_TIMEOUT delay.
	Also, for NON transmission, it is permissible, but not required, to
	send a Confirmable packet for the final payload of a body (i.e., M
	bit unset). If a Confirmable packet is used, the server MUST wait
	for the ACK to be returned for successful transmission.
	If the client detects that some of the payloads are missing, the		If the client detects that some of the payloads are missing, the
	missing payloads are requested by issuing a new GET, POST, PUT,		missing payloads are requested by issuing a new GET, POST, PUT,
	FETCH, PATCH, or iPATCH request that contains one or more Block4		FETCH, PATCH, or iPATCH request that contains one or more Quick-
	Options that define the missing blocks. A new Token value MUST be		Block2 Options that define the missing blocks.
	used for this request. The rate of requests for missing blocks is
	subject to PROBING_RATE. The ETag Option MUST NOT be used in the
	request as the server could respond with a 2.03 (Valid Response) with
	no payload. If the server responds with a different ETag Option
	value (as the resource representation has changed), then the client
	SHOULD drop all the payloads for the current body that are no longer
	valid.
	The client may elect to request the missing blocks or just ignore the		The ETag Option MUST NOT be used in the request as the server could
	partial body.		respond with a 2.03 (Valid Response) with no payload. If the server
			responds with a different ETag Option value (as the resource
			representation has changed), then the client SHOULD drop all the
			payloads for the current body that are no longer valid.
	All the payload responses to a specific GET, POST, PUT, FETCH, PATCH,		The client may elect to request the missing blocks or just ignore the
	or iPATCH request MUST have the same Token value as in the request.		partial body. It SHOULD wait for up to MAX_TRANSMIT_SPAN
			(Section 4.8.2 of [RFC7252]) before issuing a GET, POST, PUT, FETCH,
			PATCH, or iPATCH request for the missing blocks. However, this time
			MAY be reduced to two times ACK_TIMEOUT before sending the request to
			cover the situation where MAX_PAYLOADS has been triggered by the
			server causing a break in transmission.
	With NON transmission, the client only needs to indicate that some of		With NON transmission, the client only needs to indicate that some of
	the payloads are missing by issuing a GET, POST, PUT, FETCH, PATCH,		the payloads are missing by issuing a GET, POST, PUT, FETCH, PATCH,
	or iPATCH request for the missing blocks.		or iPATCH request for the missing blocks.
	For Confirmable transmission, the client SHOULD continue to		For Confirmable transmission, the client SHOULD continue to
	acknowledge each packet as well as issuing a separate GET, POST, PUT,		acknowledge each packet as well as issuing a separate GET, POST, PUT,
	FETCH, PATCH, or iPATCH for the missing blocks. NSTART will also		FETCH, PATCH, or iPATCH for the missing blocks.
	need to be increased from the default (1) to get faster transmission
	rates.
	If the server transmits a new body of data (e.g., a triggered		If the server transmits a new body of data (e.g., a triggered
	Observe) with a new ETag to the same client with the same Token		Observe) with a new ETag to the same client as an additional
	value, the client MUST remove any partially received body held for a		response, the client MUST remove any partially received body held for
	previous ETag for that Token.		a previous ETag.
	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 EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) or as defined by		up to EXCHANGE_LIFETIME (Section 4.8.2 of [RFC7252]) or as defined by
	the Max-Age Option whichever is the less.		the Max-Age Option whichever is the less.
	3.5. Working with Observe and Block4 Options		3.5. Working with Observe and Quick-Block2 Options
	As the blocks of the body are sent without waiting for		As the blocks of the body are sent without waiting for
	acknowledgement of the individual blocks, the Observe value [RFC7641]		acknowledgement of the individual blocks, the Observe value [RFC7641]
	MUST be the same for all the blocks of the same body.		MUST be the same for all the blocks of the same body.
	Likewise, the Tokens MUST all have the same value for all the blocks		If the client requests missing blocks, this is treated as a new
	of the same body. This is so that if any of the blocks get lost		request. The Observe value may change but MUST still be reported.
	during transmission (including the first one), the receiving CoAP		If the ETag value changes then the previously received partial body
	endpoint can take the appropriate decisions as to how to continue		should be destroyed and the whole body re-requested.
	(implementation specific).
	If the client requests missing blocks, the client MUST use a
	different Token; all repeated missing blocks for that new request
	MUST use the new Token.
	3.6. Working with Size1 and Size2 Options		3.6. Working with 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.
	It is RECOMMENDED that the Size1 Option is used with the Block3		The Size1 or Size2 option values MUST exactly represent the size of
	Option. It is also RECOMMENDED that the Size2 Option is used with		the data on the body so that any missing data can easily be
	the Block4 Option.		determined.
			The Size1 Option MUST be used with the Quick-Block1 Option when used
			in a request. The Size2 Option MUST be used with the Quick-Block2
			Option when 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 have the same value.		of the body and MUST have the same value.
	3.7. Use of Block3 and Block4 Options Together		3.7. Use of Quick-Block1 and Quick-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 Block3 substituted for Block1 and Block4 for Block2.		[RFC7959] with Quick-Block1 substituted for Block1 and Quick-Block2
			for Block2.
	4. TBA3 (Missing Payloads) Response Code		4. The Use of 4.08 (Request Entity Incomplete) Response Code
	TBA3 (Missing Payloads) Response Code is a new client error status		4.08 (Request Entity Incomplete) Response Code has a new Content-Type
	code (Section 5.9.2 of [RFC7252]) used to indicate that the server		"application/missing-blocks+cbor-seq" used to indicate that the
	has not received all of the blocks of the request body that it needs		server has not received all of the blocks of the request body that it
	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.
	The data payload of the TBA3 (Missing Payloads) Response Code is		The data payload of the 4.08 (Request Entity Incomplete) Response
	encoded as a CBOR Sequence [RFC8742]. First is CBOR encoded Request-		Code is encoded as a CBOR Sequence [RFC8742]. First is CBOR encoded
	Tag followed by 1 or more missing CBOR encoded missing block numbers.		Request-Tag followed by 1 or more missing CBOR encoded missing block
			numbers. The missing block numbers MUST be unique in each 4.08
	The missing block numbers MUST be unique per TBA3 (Missing Payloads)		(Request Entity Incomplete) when created by the server; the client
	when created by the server; the client SHOULD drop any duplicates in		SHOULD drop any duplicates in the same 4.08 (Request Entity
	the same TBA3 (Missing Payloads) message.		Incomplete) message.
	The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used		The Content-Format Option (Section 5.10.3 of [RFC7252]) MUST be used
	in the TBA3 (Missing Payloads) Response Code. It MUST be set to		in the 4.08 (Request Entity Incomplete) Response Code. It MUST be
	"application/missing-blocks+cbor-seq" (see Section 8.3).		set to "application/missing-blocks+cbor-seq" (see Section 10.2).
	The Concise Data Definition Language [RFC8610] for the data		The Concise Data Definition Language [RFC8610] for the data
	describing these missing blocks is as follows:		describing these missing blocks is as follows:
	TBA3-payload = (request-tag, missing-block-list)		payload = {request-tag, missing-block-list}
	; A copy of the opaque Request-Tag value		; A copy of the opaque Request-Tag value
	request-tag = bstr		request-tag = bstr
	missing-block-list = [1 * missing-block-number]		missing-block-list = [1 * missing-block-number]
	; A unique block number not received		; A unique block number not received
	missing-block-number = uint		missing-block-number = uint
	Figure 1: Structure of the Missing Blocks Payload		Figure 1: Structure of the Missing Blocks Payload
	If the size of the TBA3 (Missing Payloads) response packet is larger		If the size of the 4.08 (Request Entity Incomplete) response packet
	than that defined by Section 4.6 [RFC7252], then the number of		is larger than that defined by Section 4.6 [RFC7252], then the number
	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 necessary, multiple TBA3 (Missing Payloads)		single packet. If this is the case, then the server can send
	Response Codes can be sent back; each covering a Request-Tag and a		subsequent 4.08 (Request Entity Incomplete) responses containing the
	unique set of missing blocks. The same Token can be used for the		missing blocks on receipt of a new request providing a missing
	multiple TBA3 (missing Payloads) if this is the case.		payload with the same Request-Tag.
	5. Caching Considerations		5. The Use of Tokens
	The Block3 and Block4 Options are part of the cache key. As such, a		Each new request MUST use a unique Token (Section 4 of
	CoAP proxy that does not understand the Block3 and Block4 Options		[I-D.ietf-core-echo-request-tag]). Additional responses may use the
	must follow the recommendations in Section 5.7.1 of [RFC7252] for		same Token.
	caching.
	This specification does not require a proxy to obtain the complete		6. Congestion Control
	representation before it serves parts of it to the client.
	Otherwise, the considerations discussed in Section 2.10 of [RFC7959]
	apply for the Block3 and Block4 Options (with Block3 substituted for
	Block1 and Block4 substituted for Block2) for proxies that support
	Block3 and Block4 Options.
	A proxy that supports Block4 Option MUST be prepared to receive a GET		PROBING_RATE parameter in CoAP indicates the average data rate that
	or similar message indicating one or more missing blocks. The proxy		must not be exceeded by a CoAP endpoint in sending to a peer endpoint
	can serve from its cache missing blocks that are available in its		that does not respond. The body of blocks will be subjected to
	cache in a set as a server would send all the Block4s. If one or		PROBING_RATE (Section 4.7 of [RFC7252]).
	more requested blocks are not available in the cache, the proxy
	SHOULD update the GET request by removing the blocks that it can
	serve from the cache, and then forward on the request to the next
	hop.
	Alternatively, the original request unmodified (from the missing		Each NON 4.08 (Request Entity Incomplete) Response Codes is subjected
	block perspective) MAY be forwarded on to the server. All the		to PROBING_RATE.
	responses are then passed back to the client with the cache getting
	updated.		Each NON GET or similar request using Quick-Block2 Option is
			subjected to PROBING_RATE.
			As the sending of many payloads of a single body may itself cause
			congestion, it is RECOMMENDED that after transmission of every set of
			MAX_PAYLOADS payloads of a single body, a delay is introduced of
			ACK_TIMEOUT (Section 4.8.2 of [RFC7252]) before the next set of
			payload transmissions to manage potential congestion issues.
			MAX_PAYLOADS should be configurable with a default value of 10.
			Note: The default value is chosen for reasons similar to those
			discussed in Section 5 of [RFC6928].
			For NON transmissions, it is permissible, but not required, to send
			the ultimate payload of a MAX_PAYLOADS set as a Confirmable packet.
			If a Confirmable packet is used, then the transmitting peer MUST wait
			for the ACK to be returned before sending the next set of payloads,
			which can be in time terms less than the ACK_TIMEOUT delay.
			Also, for NON transmissions, it is permissible, but not required, to
			send a Confirmable packet for the final payload of a body (that is, M
			bit unset). If a Confirmable packet is used, then the transmitting
			peer MUST wait for the appropriate response to be returned for
			successful transmission, or respond to requests for the missing
			blocks (if any).
			The sending of the set of missing blocks is subject to MAX_PAYLOADS.
			7. Caching Considerations
			Caching block based information is not straight forward in a proxy.
			For Quick-Block1 and Quick-Block2 Options, it is expected that the
			proxy will reassemble the body (using any appropriate recovery
			options for packet loss) before passing on the body to the
			appropriate CoAP endpoint. The onward transmission of the body does
			not require the use of the Quick-Block1 or Quick-Block2 Options.
			This means that the proxy must fully support the Quick-Block1 and
			Quick-Block2 Options.
			How the body is cached in the initial CoAP client (Quick-Block1) or
			ultimate CoAP server (Quick-Block2) is implementation specific.
			As the entire body is being cached in the proxy, the Quick-Block1 and
			Quick-Block2 Options are not part of the cache key.
			For Quick-Block2 responses, the ETag Option value is associated with
			the data (and onward transmitted to the CoAP client), but is not part
			of the cache key.
			For requests with Quick-Block1 Option, the Request-Tag Option is
			associated with the build up of the body from successive payloads,
			but is not part of the cache key. For the onward transmission of the
			body using CoAP, a new Request-Tag SHOULD be generated and used.
			It is possible that two or more CoAP clients are concurrently
			updating the same resource through a common proxy to the same CoAP
			server using Quick-Block1 (or Block1) Option. If this is the case,
			the first client to complete building the body causes that body to
			start transmitting to the CoAP server with an appropriate Request-Tag
			value. When the next client completes building the body, any
			existing partial body transmission to the CoAP server is terminated
			and the new body representation transmission starts with a new
			Request-Tag value.
			A proxy that supports Quick-Block2 Option MUST be prepared to receive
			a GET or similar message indicating one or more missing blocks. The
			proxy will serve from its cache the missing blocks that are available
			in its cache in the same way a server would send all the appropriate
			Quick-Block2s. If the cache key matching body is not available in
			the cache, the proxy MUST request the entire body from the CoAP
			server using the information in the cache key.
	How long a CoAP endpoint (or proxy) keeps the body in its cache is		How long a CoAP endpoint (or proxy) keeps the body in its cache is
	implementation specific (e.g., it may be based on Max-Age).		implementation specific (e.g., it may be based on Max-Age).
	6. HTTP-Mapping Considerations		8. HTTP-Mapping Considerations
	As a reminder, the basic normative requirements on HTTP/CoAP mappings		As a reminder, the basic normative requirements on HTTP/CoAP mappings
	are defined in Section 10 of [RFC7252]. The implementation		are defined in Section 10 of [RFC7252]. The implementation
	guidelines for HTTP/CoAP mappings are elaborated in [RFC8075].		guidelines for HTTP/CoAP mappings are elaborated in [RFC8075].
	The rules defined in Section 5 of [RFC7959] are to be followed.		The rules defined in Section 5 of [RFC7959] are to be followed.
	7. Examples of Selective Block Recovery		9. Examples of Selective Block Recovery
	This section provides some sample flows to illustrate the use of		This section provides some sample flows to illustrate the use of
	Block3 and Block4 Options. Figure 2 lists the conventions that are		Quick-Block1 and Quick-Block2 Options. Figure 2 lists the
	used in the following subsections.		conventions that are used in the following subsections.
	T: Token value		T: Token value
	O: Observe Option value		O: Observe Option value
	M: Message ID		M: Message ID
	RT: Request-Tag		RT: Request-Tag
	ET: ETag		ET: ETag
	B3: Block3 Option values NUM/More/SZX		QB1: Quick-Block1 Option values NUM/More/SZX
	B4: Block3 Option values NUM/More/SZX		QB2: Quick-Block2 Option values NUM/More/SZX
	\: Trimming long lines		\: Trimming long lines
	[[]]: Comments		[[]]: Comments
	-->X: Message loss		-->X: Message loss
	X<--: Message loss		X<--: Message loss
	Figure 2: Notations Used in the Figures		Figure 2: Notations Used in the Figures
	7.1. Block3 Option: Non-Confirmable Example		9.1. Quick-Block1 Option: Non-Confirmable Example
	Figure 3 depicts an example of a NON PUT request conveying Block3		Figure 3 depicts an example of a NON PUT request conveying Quick-
	Option. All the blocks are received by the server.		Block1 Option. All the blocks are received by the server.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| NON PUT /path M:0x01 T:0xf0 RT=10 B3:0/1/1024		+--------->| NON PUT /path M:0x01 T:0xf0 RT=10 QB1:0/1/1024
	+--------->| NON PUT /path M:0x02 T:0xf1 RT=10 B3:1/1/1024		+--------->| NON PUT /path M:0x02 T:0xf1 RT=10 QB1:1/1/1024
	+--------->| NON PUT /path M:0x03 T:0xf2 RT=10 B3:2/1/1024		+--------->| NON PUT /path M:0x03 T:0xf2 RT=10 QB1:2/1/1024
	+--------->| NON PUT /path M:0x04 T:0xf3 RT=10 B3:3/0/1024		+--------->| NON PUT /path M:0x04 T:0xf3 RT=10 QB1:3/0/1024
	|<---------+ NON 2.04 M:0xf1 T:0xf3		|<---------+ NON 2.04 M:0xf1 T:0xf3
	...		...
	Figure 3: Example of NON Request with Block3 Option (Without Loss)		Figure 3: Example of NON Request with Quick-Block1 Option (Without
			Loss)
	Consider now a scenario where a new body of data is to be sent by the		Consider now a scenario where a new body of data is to be sent by the
	client, but some blocks are dropped in transmission as illustrated in		client, but some blocks are dropped in transmission as illustrated in
	Figure 4.		Figure 4.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| NON PUT /path M:0x05 T:0xe0 RT=11 B3:0/1/1024		+--------->| NON PUT /path M:0x05 T:0xe0 RT=11 QB1:0/1/1024
	+--->X | NON PUT /path M:0x06 T:0xe1 RT=11 B3:1/1/1024		+--->X | NON PUT /path M:0x06 T:0xe1 RT=11 QB1:1/1/1024
	+--->X | NON PUT /path M:0x07 T:0xe2 RT=11 B3:2/1/1024		+--->X | NON PUT /path M:0x07 T:0xe2 RT=11 QB1:2/1/1024
	+--------->| NON PUT /path M:0x08 T:0xe3 RT=11 B3:3/0/1024		+--------->| NON PUT /path M:0x08 T:0xe3 RT=11 QB1:3/0/1024
	| |		| |
	...		...
	Figure 4: Example of NON Request with Block3 Option (With Loss)		Figure 4: Example of NON Request with Quick-Block1 Option (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 ones in one go (Figure 5). It does so by indicating which		missing ones in one go (Figure 5). It does so by indicating which
	blocks have been received in the data portion of the response.		blocks have been received in the data portion of the response.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	...		...
	|<---------+ NON TBA3 M:0xf2 T:0xe3 [Missing 1,2 for RT=11]		|<---------+ NON 4.08 M:0xf2 T:0xe3 [Missing 1,2 for RT=11]
	+--------->| NON PUT /path M:0x09 T:0xe4 RT=11 B3:1/1/1024		+--------->| NON PUT /path M:0x09 T:0xe4 RT=11 QB1:1/1/1024
	+--->X | NON PUT /path M:0x0a T:0xe5 RT=11 B3:2/1/1024		+--->X | NON PUT /path M:0x0a T:0xe5 RT=11 QB1:2/1/1024
	| |		| |
	|<---------+ NON TBA3 M:0xf3 T:0xe4 [Missing 2 for RT=11]		|<---------+ NON 4.08 M:0xf3 T:0xe4 [Missing 2 for RT=11]
	+--------->| NON PUT /path M:0x0b T:0xe6 RT=11 B3:2/1/1024		+--------->| NON PUT /path M:0x0b T:0xe6 RT=11 QB1:2/1/1024
	|<---------+ NON 2.04 M:0xf4 T:0xe6		|<---------+ NON 2.04 M:0xf4 T:0xe6
	| |		| |
	...		...
	Figure 5: Example of NON Request with Block3 Option (Blocks Recovery)		Figure 5: Example of NON Request with Quick-Block1 Option (Blocks
			Recovery)
	Under high levels of traffic loss, the client can elect not to retry		Under high levels of traffic loss, the client can elect not to retry
	sending missing blocks of data. This decision is implementation		sending missing blocks of data. This decision is implementation
	specific.		specific.
	7.2. Block4 Option: Non-Confirmable Example		9.2. Quick-Block2 Option: Non-Confirmable Example
	Figure 6 illustrates the example of Block4 Option. The client sends		Figure 6 illustrates the example of Quick-Block2 Option. The client
	a NON GET carrying an Observe and a Block4 Options. The Block4		sends a NON GET carrying an Observe and a Quick-Block2 Options. The
	Option indicates a size hint (1024 bytes). This request is replied		Quick-Block2 Option indicates a size hint (1024 bytes). This request
	by the server using four (4) blocks that are transmitted to the		is replied by the server using four (4) blocks that are transmitted
	client without any loss. Each of these blocks carries a Block4		to the client without any loss. Each of these blocks carries a
	Option. The same process is repeated when an Observe is triggered,		Quick-Block2 Option. The same process is repeated when an Observe is
	but no loss is experienced by any of the notification blocks.		triggered, but no loss is experienced by any of the notification
			blocks.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| NON GET /path M:0x01 T:0xf0 O:0 B4:0/0/1024		+--------->| NON GET /path M:0x01 T:0xf0 O:0 QB2:0/0/1024
	|<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 ET=21 B4:0/1/1024		|<---------+ NON 2.05 M:0xf1 T:0xf0 O:1234 ET=21 QB2:0/1/1024
	|<---------+ NON 2.05 M:0xf2 T:0xf0 O:1234 ET=21 B4:1/1/1024		|<---------+ NON 2.05 M:0xf2 T:0xf0 O:1234 ET=21 QB2:1/1/1024
	|<---------+ NON 2.05 M:0xf3 T:0xf0 O:1234 ET=21 B4:2/1/1024		|<---------+ NON 2.05 M:0xf3 T:0xf0 O:1234 ET=21 QB2:2/1/1024
	|<---------+ NON 2.05 M:0xf4 T:0xf0 O:1234 ET=21 B4:3/0/1024		|<---------+ NON 2.05 M:0xf4 T:0xf0 O:1234 ET=21 QB2:3/0/1024
	...
	[[Observe triggered]]
	|<---------+ NON 2.05 M:0xf5 T:0xf0 O:1235 ET=22 B4:0/1/1024
	|<---------+ NON 2.05 M:0xf6 T:0xf0 O:1235 ET=22 B4:1/1/1024
	|<---------+ NON 2.05 M:0xf7 T:0xf0 O:1235 ET=22 B4:2/1/1024
	|<---------+ NON 2.05 M:0xf8 T:0xf0 O:1235 ET=22 B4:3/0/1024
	...		...
			[[Observe triggered]]
			|<---------+ NON 2.05 M:0xf5 T:0xf0 O:1235 ET=22 QB2:0/1/1024
			|<---------+ NON 2.05 M:0xf6 T:0xf0 O:1235 ET=22 QB2:1/1/1024
			|<---------+ NON 2.05 M:0xf7 T:0xf0 O:1235 ET=22 QB2:2/1/1024
			|<---------+ NON 2.05 M:0xf8 T:0xf0 O:1235 ET=22 QB2:3/0/1024
			...
	Figure 6: Example of NON Notifications with Block4 Option (Without		Figure 6: Example of NON Notifications with Quick-Block2 Option
	Loss)		(Without Loss)
	Figure 7 shows the example of an Observe that is triggered but for		Figure 7 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 request their retransmission. It does so by		missing blocks and request their retransmission. It does so by
	indicating the blocks that were successfully received.		indicating the blocks that were successfully received.
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	...		...
	[[Observe triggered]]		[[Observe triggered]]
	|<---------+ NON 2.05 M:0xf9 T:0xf0 O:1236 ET=23 B4:0/1/1024		|<---------+ NON 2.05 M:0xf9 T:0xf0 O:1236 ET=23 QB2:0/1/1024
	| X<---+ NON 2.05 M:0xfa T:0xf0 O:1236 ET=23 B4:1/1/1024		| X<---+ NON 2.05 M:0xfa T:0xf0 O:1236 ET=23 QB2:1/1/1024
	| X<---+ NON 2.05 M:0xfb T:0xf0 O:1236 ET=23 B4:2/1/1024		| X<---+ NON 2.05 M:0xfb T:0xf0 O:1236 ET=23 QB2:2/1/1024
	|<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 ET=23 B4:3/0/1024		|<---------+ NON 2.05 M:0xfc T:0xf0 O:1236 ET=23 QB2:3/0/1024
	| |		| |
	[[Client realizes blocks are missing and asks for the missing		[[Client realizes blocks are missing and asks for the missing
	ones in one go]]		ones in one go]]
	+--------->| NON GET /path M:0x02 T:0xf1 B4:1/0/1024\		+--------->| NON GET /path M:0x02 T:0xf1 QB2:1/0/1024\
	| | B4:2/0/1024		| | QB2:2/0/1024
	| X<---+ NON 2.05 M:0xfd T:0xf1 ET=23 B4:1/1/1024		| X<---+ NON 2.05 M:0xfd T:0xf1 ET=23 QB2:1/1/1024
	|<---------+ NON 2.05 M:0xfe T:0xf1 ET=23 B4:2/1/1024		|<---------+ NON 2.05 M:0xfe T:0xf1 ET=23 QB2:2/1/1024
	| |		| |
	[[Get the final missing block]]		[[Get the final missing block]]
	+--------->| NON GET /path M:0x03 T:0xf2 B4:1/0/1024		+--------->| NON GET /path M:0x03 T:0xf2 QB2:1/0/1024
	|<---------+ NON 2.05 M:0xff T:0xf2 ET=23 B4:1/1/1024		|<---------+ NON 2.05 M:0xff T:0xf2 ET=23 QB2:1/1/1024
	...		...
	Figure 7: Example of NON Notifications with Block4 Option (Blocks		Figure 7: Example of NON Notifications with Quick-Block2 Option
	Recovery)		(Blocks Recovery)
	Under high levels of traffic loss, the client can elect not to retry		Under high levels of traffic loss, the client can elect not to retry
	getting missing blocks of data. This decision is implementation		getting missing blocks of data. This decision is implementation
	specific.		specific.
	8. IANA Considerations		10. IANA Considerations
	8.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 available at https://www.iana.org/assignments/		Numbers" sub-registry [Options]:
	core-parameters/core-parameters.xhtml#option-numbers:
	+--------+------------------+-----------+		+--------+------------------+-----------+
	| Number | Name | Reference |		| Number | Name | Reference |
	+========+==================+===========+		+========+==================+===========+
	| TBA1 | Block3 | [RFCXXXX] |		| TBA1 | Quick-Block1 | [RFCXXXX] |
	| TBA2 | Block4 | [RFCXXXX] |		| TBA2 | Quick-Block2 | [RFCXXXX] |
	+--------+------------------+-----------+		+--------+------------------+-----------+
	Table 2: CoAP Block3 and Block4 Option Numbers		Table 2: CoAP Quick-Block1 and Quick-Block2 Option Numbers
	This document suggests 21 (TBA1) and 25 (TBA2) as a values to be		This document suggests 19 (TBA1) and 51 (TBA2) as a values to be
	assigned for the new option numbers.		assigned for the new option numbers.
	8.2. New CoAP Response Code		10.2. New Content Format
	IANA is requested to add the following entry to the "CoAP Response
	Codes" sub-registry available at https://www.iana.org/assignments/
	core-parameters/core-parameters.xhtml#response-codes:
	+------+------------------+-----------+
	| Code | Description | Reference |
	+======+==================+===========+
	| TBA3 | Missing Payloads | [RFCXXXX] |
	+------+------------------+-----------+
	Table 3: New CoAP Response Code
	This document suggests 4.19 (TBA3) as a value to be assigned for the
	new Response Code.
	8.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 available at		Content-Formats" registry [Format]:
	https://www.iana.org/assignments/core-parameters/core-
	parameters.xhtml#content-formats:
	o Media Type: application/missing-blocks+cbor-seq		o Media Type: application/missing-blocks+cbor-seq
	o Encoding: -		o Encoding: -
	o Id: TBD4		o Id: TBD3
	o Reference: [RFCXXXX]		o Reference: [RFCXXXX]
	9. Security Considerations		11. Security Considerations
	Security considerations discussed in Section 9 of [RFC7959] should be		Security considerations discussed in Section 9 of [RFC7959] should be
	taken into account.		taken into account.
	Security considerations related to the use of Request-Tag are		Security considerations related to the use of Request-Tag are
	discussed in Section 5 of [I-D.ietf-core-echo-request-tag].		discussed in Section 5 of [I-D.ietf-core-echo-request-tag].
	10. Acknowledgements		12. Acknowledgements
	Thanks to Achim Kraus and Jim Schaad for the comments on the mailing		Thanks to Achim Kraus and Jim Schaad for the comments on the mailing
	list.		list.
	Special thanks to Christian Amsuess and Carsten Bormann for their		Special thanks to Christian Amsuess and Carsten Bormann for their
	suggestions and several reviews, which improved this specification		suggestions and several reviews, which improved this specification
	significantly.		significantly.
	Some text from [RFC7959] is reused for readers convenience.		Some text from [RFC7959] is reused for readers convenience.
	11. References		13. References
	11.1. Normative References		13.1. Normative References
	[I-D.ietf-core-echo-request-tag]		[I-D.ietf-core-echo-request-tag]
	Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,		Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo,
	Request-Tag, and Token Processing", draft-ietf-core-echo-		Request-Tag, and Token Processing", draft-ietf-core-echo-
	request-tag-10 (work in progress), July 2020.		request-tag-10 (work in progress), July 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 19, line 20 ¶		skipping to change at page 20, line 45 ¶
	[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,		[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
	"Object Security for Constrained RESTful Environments		"Object Security for Constrained RESTful Environments
	(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,		(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
	<https://www.rfc-editor.org/info/rfc8613>.		<https://www.rfc-editor.org/info/rfc8613>.
	[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)		[RFC8742] Bormann, C., "Concise Binary Object Representation (CBOR)
	Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,		Sequences", RFC 8742, DOI 10.17487/RFC8742, February 2020,
	<https://www.rfc-editor.org/info/rfc8742>.		<https://www.rfc-editor.org/info/rfc8742>.
	11.2. Informative References		13.2. Informative References
			[Format] , <https://www.iana.org/assignments/core-parameters/core-
			parameters.xhtml#content-formats>.
	[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-11		Signaling (DOTS) Telemetry", draft-ietf-dots-telemetry-11
	(work in progress), July 2020.		(work in progress), July 2020.
			[Options] , <https://www.iana.org/assignments/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>.
	skipping to change at page 20, line 5 ¶		skipping to change at page 21, line 38 ¶
	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>.
	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. Block3 Option		A.1. Quick-Block1 Option
	Let's now consider the use Block3 Option with a CON request as shown		Let's now consider the use Quick-Block1 Option with a CON request as
	in Figure 8. All the blocks are acknowledged (ACK).		shown in Figure 8. All the blocks are acknowledged (ACK).
	CoAP CoAP		CoAP CoAP
	Client Server		Client Server
	| |		| |
	+--------->| CON PUT /path M:0x01 T:0xf0 RT=10 B3: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 B3: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 B3: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 B3: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 0.00 M:0x04		|<---------+ ACK 2.04 M:0x04
	Figure 8: Example of CON Request with Block3 Option (Without Loss)		Figure 8: Example of CON Request with Quick-Block1 Option (Without
			Loss)
	Now, suppose that a new body of data is to sent but with some blocks		Now, suppose that a new body of data is to sent but with some blocks
	dropped in transmission as illustrated in Figure 9. The client will		dropped in transmission as illustrated in Figure 9. The client will
	retry sending blocks for which no ACK was received.		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 B3: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 B3: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 B3: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 B3: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
	|<---------+ ACK 0.00 M:0x08		|<---------+ ACK 0.00 M:0x08
	| |		| |
	[[The client retries sending packets not acknowledged]]		[[The client retries sending packets not acknowledged]]
	+--------->| CON PUT /path M:0x06 T:0xf5 RT=11 B3:1/1/1024		+--------->| CON PUT /path M:0x06 T:0xf5 RT=11 QB1:1/1/1024
	+--->X | CON PUT /path M:0x07 T:0xf6 RT=11 B3: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
	| |		| |
	[[The client retransmits messages not acknowledged		[[The client retransmits messages not acknowledged
	(exponential backoff)]]		(exponential backoff)]]
	+--->? | CON PUT /path M:0x07 T:0xf6 RT=11 B3:2/1/1024		+--->? | CON PUT /path M:0x07 T:0xf6 RT=11 QB1:2/1/1024
	| |		| |
	[[Either transmission failure (acknowledge retry timeout)		[[Either transmission failure (acknowledge retry timeout)
	or successfully transmitted.]]		or successfully transmitted.]]
	Figure 9: Example of CON Request with Block3 Option (Blocks Recovery)		Figure 9: Example of CON Request with Quick-Block1 Option (Blocks
			Recovery)
	It is implementation dependent as to whether a CoAP session is		It is implementation dependent as to whether a CoAP session is
	terminated following acknowledge retry timeout, or whether the CoAP		terminated following acknowledge retry timeout, or whether the CoAP
	session continues to be used under such adverse traffic conditions.		session continues to be used under such 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-confirmable traffic should be considered.		then the use of Non-confirmable traffic should be considered.
	A.2. Block4 Option		A.2. Quick-Block2 Option
	An example of the use of Block4 Option with Confirmable messages is		An example of the use of Quick-Block2 Option with Confirmable
	shown in Figure 10.		messages is shown in Figure 10.
	Client Server		Client Server
	| |		| |
	+--------->| CON GET /path M:0x01 T:0xf0 O:0 B4: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 B4: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 B4: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 B4: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 B4:3/0/1024		|<---------+ ACK 2.05 M:0xe3 T:0xf0 O:1234 ET=21 QB2:3/0/1024
			...
			[[Observe triggered]]
			|<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 QB2:0/1/1024
			|<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 QB2:1/1/1024
			|<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 QB2:2/1/1024
			|<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 QB2:3/0/1024
			|--------->+ ACK 0.00 M:0xe4
			|--------->+ ACK 0.00 M:0xe5
			|--------->+ ACK 0.00 M:0xe6
			|--------->+ ACK 0.00 M:0xe7
	...		...
	[[Observe triggered]]		[[Observe triggered]]
	|<---------+ CON 2.05 M:0xe4 T:0xf0 O:1235 ET=22 B4:0/1/1024		|<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 QB2:0/1/1024
	|<---------+ CON 2.05 M:0xe5 T:0xf0 O:1235 ET=22 B4:1/1/1024		| X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
	|<---------+ CON 2.05 M:0xe6 T:0xf0 O:1235 ET=22 B4:2/1/1024		| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
	|<---------+ CON 2.05 M:0xe7 T:0xf0 O:1235 ET=22 B4:3/0/1024		|<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 QB2:3/0/1024
	|--------->+ ACK 0.00 M:0xe4		|--------->+ ACK 0.00 M:0xe8
	|--------->+ ACK 0.00 M:0xe5		|--------->+ ACK 0.00 M:0xeb
	|--------->+ ACK 0.00 M:0xe6		| |
	|--------->+ ACK 0.00 M:0xe7		[[Server retransmits messages not acknowledged]]
	...		|<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 QB2:1/1/1024
	[[Observe triggered]]		| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
	|<---------+ CON 2.05 M:0xe8 T:0xf0 O:1236 ET=23 B4:0/1/1024		|--------->+ ACK 0.00 M:0xe9
	| X<---+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 B4:1/1/1024		| |
	| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 B4:2/1/1024		[[Server retransmits messages not acknowledged
	|<---------+ CON 2.05 M:0xeb T:0xf0 O:1236 ET=23 B4:3/0/1024		(exponential backoff)]]
	|--------->+ ACK 0.00 M:0xe8		| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 QB2:2/1/1024
	|--------->+ ACK 0.00 M:0xeb		| |
	| |		[[Either transmission failure (acknowledge retry timeout)
	[[Server retransmits messages not acknowledged]]		or successfully transmitted.]]
	|<---------+ CON 2.05 M:0xe9 T:0xf0 O:1236 ET=23 B4:1/1/1024
	| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 B4:2/1/1024
	|--------->+ ACK 0.00 M:0xe9
	| |
	[[Server retransmits messages not acknowledged
	(exponential backoff)]]
	| X<---+ CON 2.05 M:0xea T:0xf0 O:1236 ET=23 B4:2/1/1024
	| |
	[[Either transmission failure (acknowledge retry timeout)
	or successfully transmitted.]]
	Figure 10: Example of CON Notifications with Block4 Option		Figure 10: Example of CON Notifications with Quick-Block2 Option
	It is implementation-dependent as to whether a CoAP session is		It is implementation-dependent as to whether a CoAP session is
	terminated following acknowledge retry timeout, or whether the CoAP		terminated following acknowledge retry timeout, or whether the CoAP
	session continues to be used under such adverse traffic conditions.		session continues to be used under such 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-confirmable traffic should be considered.		then the use of Non-confirmable traffic should be considered.
	Authors' Addresses		Authors' Addresses
End of changes. 118 change blocks.
	498 lines changed or deleted		533 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/