draft-ietf-core-block-16.txt		draft-ietf-core-block-17.txt
	CoRE Working Group C. Bormann		CoRE Working Group C. Bormann
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Standards Track Z. Shelby, Ed.		Intended status: Standards Track Z. Shelby, Ed.
	Expires: April 30, 2015 ARM		Expires: September 10, 2015 ARM
	October 27, 2014		March 09, 2015
	Blockwise transfers in CoAP		Block-wise transfers in CoAP
	draft-ietf-core-block-16		draft-ietf-core-block-17
	Abstract		Abstract
	CoAP is a RESTful transfer protocol for constrained nodes and		CoAP is a RESTful transfer protocol for constrained nodes and
	networks. Basic CoAP messages work well for the small payloads we		networks. Basic CoAP messages work well for the small payloads we
	expect from temperature sensors, light switches, and similar		expect from temperature sensors, light switches, and similar
	building-automation devices. Occasionally, however, applications		building-automation devices. Occasionally, however, applications
	will need to transfer larger payloads -- for instance, for firmware		will need to transfer larger payloads -- for instance, for firmware
	updates. With HTTP, TCP does the grunt work of slicing large		updates. With HTTP, TCP does the grunt work of slicing large
	payloads up into multiple packets and ensuring that they all arrive		payloads up into multiple packets and ensuring that they all arrive
	skipping to change at page 2, line 10		skipping to change at page 2, line 10
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 April 30, 2015.		This Internet-Draft will expire on September 10, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 2, line 36		skipping to change at page 2, line 36
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Block-wise transfers . . . . . . . . . . . . . . . . . . . . 5		2. Block-wise transfers . . . . . . . . . . . . . . . . . . . . 5
	2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 5		2.1. The Block2 and Block1 Options . . . . . . . . . . . . . . 5
	2.2. Structure of a Block Option . . . . . . . . . . . . . . . 6		2.2. Structure of a Block Option . . . . . . . . . . . . . . . 6
	2.3. Block Options in Requests and Responses . . . . . . . . . 8		2.3. Block Options in Requests and Responses . . . . . . . . . 8
	2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 10		2.4. Using the Block2 Option . . . . . . . . . . . . . . . . . 10
	2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 12		2.5. Using the Block1 Option . . . . . . . . . . . . . . . . . 12
	2.6. Combining Blockwise Transfers with the Observe Option . . 13		2.6. Combining Block-wise Transfers with the Observe Option . 13
	2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 14		2.7. Combining Block1 and Block2 . . . . . . . . . . . . . . . 14
	2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 14		2.8. Combining Block2 with Multicast . . . . . . . . . . . . . 14
	2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 14		2.9. Response Codes . . . . . . . . . . . . . . . . . . . . . 14
	2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 15		2.9.1. 2.31 Continue . . . . . . . . . . . . . . . . . . . . 15
	2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 15		2.9.2. 4.08 Request Entity Incomplete . . . . . . . . . . . 15
	2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 15		2.9.3. 4.13 Request Entity Too Large . . . . . . . . . . . . 15
	2.10. Caching Considerations . . . . . . . . . . . . . . . . . 15		2.10. Caching Considerations . . . . . . . . . . . . . . . . . 15
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 16		3.1. Block2 Examples . . . . . . . . . . . . . . . . . . . . . 16
	3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 20		3.2. Block1 Examples . . . . . . . . . . . . . . . . . . . . . 20
	skipping to change at page 12, line 32		skipping to change at page 12, line 32
	To counter the effects of adaptation layer fragmentation on packet		To counter the effects of adaptation layer fragmentation on packet
	delivery probability, a client may want to give up retransmitting a		delivery probability, a client may want to give up retransmitting a
	request with a relatively large payload even before MAX_RETRANSMIT		request with a relatively large payload even before MAX_RETRANSMIT
	has been reached, and try restating the request as a block-wise		has been reached, and try restating the request as a block-wise
	transfer with a smaller payload. Note that this new attempt is then		transfer with a smaller payload. Note that this new attempt is then
	a new message-layer transaction and requires a new Message ID.		a new message-layer transaction and requires a new Message ID.
	(Because of the uncertainty whether the request or the		(Because of the uncertainty whether the request or the
	acknowledgement was lost, this strategy is useful mostly for		acknowledgement was lost, this strategy is useful mostly for
	idempotent requests.)		idempotent requests.)
	In a blockwise transfer of a request payload (e.g., a PUT or POST)		In a block-wise transfer of a request payload (e.g., a PUT or POST)
	that is intended to be implemented in an atomic fashion at the		that is intended to be implemented in an atomic fashion at the
	server, the actual creation/replacement takes place at the time the		server, the actual creation/replacement takes place at the time the
	final block, i.e. a block with the M bit unset in the Block1 Option,		final block, i.e. a block with the M bit unset in the Block1 Option,
	is received. In this case, all success responses to non-final blocks		is received. In this case, all success responses to non-final blocks
	carry the response code 2.31 (Continue, Section 2.9.1). If not all		carry the response code 2.31 (Continue, Section 2.9.1). If not all
	previous blocks are available at the server at the time of processing		previous blocks are available at the server at the time of processing
	the final block, the transfer fails and error code 4.08 (Request		the final block, the transfer fails and error code 4.08 (Request
	Entity Incomplete, Section 2.9.2) MUST be returned. A server MAY		Entity Incomplete, Section 2.9.2) MUST be returned. A server MAY
	also return a 4.08 error code for any (final or non-final) Block1		also return a 4.08 error code for any (final or non-final) Block1
	transfer that is not in sequence; clients that do not have specific		transfer that is not in sequence; clients that do not have specific
	skipping to change at page 13, line 24		skipping to change at page 13, line 24
	The Block1 option provides no way for a single endpoint to perform		The Block1 option provides no way for a single endpoint to perform
	multiple concurrently proceeding block-wise request payload transfer		multiple concurrently proceeding block-wise request payload transfer
	(e.g., PUT or POST) operations to the same resource. Starting a new		(e.g., PUT or POST) operations to the same resource. Starting a new
	block-wise sequence of requests to the same resource (before an old		block-wise sequence of requests to the same resource (before an old
	sequence from the same endpoint was finished) simply overwrites the		sequence from the same endpoint was finished) simply overwrites the
	context the server may still be keeping. (This is probably exactly		context the server may still be keeping. (This is probably exactly
	what one wants in this case - the client may simply have restarted		what one wants in this case - the client may simply have restarted
	and lost its knowledge of the previous sequence.)		and lost its knowledge of the previous sequence.)
	2.6. Combining Blockwise Transfers with the Observe Option		2.6. Combining Block-wise Transfers with the Observe Option
	The Observe Option provides a way for a client to be notified about		The Observe Option provides a way for a client to be notified about
	changes over time of a resource [I-D.ietf-core-observe]. Resources		changes over time of a resource [I-D.ietf-core-observe]. Resources
	observed by clients may be larger than can be comfortably processed		observed by clients may be larger than can be comfortably processed
	or transferred in one CoAP message. The following rules apply to the		or transferred in one CoAP message. The following rules apply to the
	combination of blockwise transfers with notifications.		combination of block-wise transfers with notifications.
	Observation relationships always apply to an entire resource; the		Observation relationships always apply to an entire resource; the
	Block2 option does not provide a way to observe a single block of a		Block2 option does not provide a way to observe a single block of a
	resource.		resource.
	As with basic GET transfers, the client can indicate its desired		As with basic GET transfers, the client can indicate its desired
	block size in a Block2 Option in the GET request establishing or		block size in a Block2 Option in the GET request establishing or
	renewing the observation relationship. If the server supports		renewing the observation relationship. If the server supports block-
	blockwise transfers, it SHOULD take note of the block size and apply		wise transfers, it SHOULD take note of the block size and apply it as
	it as a maximum size to all notifications/responses resulting from		a maximum size to all notifications/responses resulting from the GET
	the GET request (until the client is removed from the list of		request (until the client is removed from the list of observers or
	observers or the entry in that list is updated by the server		the entry in that list is updated by the server receiving a new GET
	receiving a new GET request for the resource from the client).		request for the resource from the client).
	When sending a 2.05 (Content) notification, the server only sends the		When sending a 2.05 (Content) notification, the server only sends the
	first block of the representation. The client retrieves the rest of		first block of the representation. The client retrieves the rest of
	the representation as if it had caused this first response by a GET		the representation as if it had caused this first response by a GET
	request, i.e., by using additional GET requests with Block2 options		request, i.e., by using additional GET requests with Block2 options
	containing NUM values greater than zero. (This results in the		containing NUM values greater than zero. (This results in the
	transfer of the entire representation, even if only some of the		transfer of the entire representation, even if only some of the
	blocks have changed with respect to a previous notification.)		blocks have changed with respect to a previous notification.)
	As with other dynamically changing resources, to ensure that the		As with other dynamically changing resources, to ensure that the
	blocks being reassembled are from the same version of the		blocks being reassembled are from the same version of the
	skipping to change at page 17, line 19		skipping to change at page 17, line 19
	| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |		| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
	| |		| |
	| CON [MID=1235], GET, /status, 2:1/0/128 ------> |		| CON [MID=1235], GET, /status, 2:1/0/128 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 |		| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 |
	| |		| |
	| CON [MID=1236], GET, /status, 2:2/0/128 ------> |		| CON [MID=1236], GET, /status, 2:2/0/128 ------> |
	| |		| |
	| <------ ACK [MID=1236], 2.05 Content, 2:2/0/128 |		| <------ ACK [MID=1236], 2.05 Content, 2:2/0/128 |
	Figure 2: Simple blockwise GET		Figure 2: Simple block-wise GET
	In the second example (Figure 3), the client anticipates the		In the second example (Figure 3), the client anticipates the block-
	blockwise transfer (e.g., because of a size indication in the link-		wise transfer (e.g., because of a size indication in the link-format
	format description [RFC6690]) and sends a block size proposal. All		description [RFC6690]) and sends a block size proposal. All ACK
	ACK messages except for the last carry 64 bytes of payload; the last		messages except for the last carry 64 bytes of payload; the last one
	one carries between 1 and 64 bytes.		carries between 1 and 64 bytes.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	| CON [MID=1234], GET, /status, 2:0/0/64 ------> |		| CON [MID=1234], GET, /status, 2:0/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1234], 2.05 Content, 2:0/1/64 |		| <------ ACK [MID=1234], 2.05 Content, 2:0/1/64 |
	| |		| |
	| CON [MID=1235], GET, /status, 2:1/0/64 ------> |		| CON [MID=1235], GET, /status, 2:1/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.05 Content, 2:1/1/64 |		| <------ ACK [MID=1235], 2.05 Content, 2:1/1/64 |
	skipping to change at page 17, line 47		skipping to change at page 17, line 47
	: ... :		: ... :
	: :		: :
	| CON [MID=1238], GET, /status, 2:4/0/64 ------> |		| CON [MID=1238], GET, /status, 2:4/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1238], 2.05 Content, 2:4/1/64 |		| <------ ACK [MID=1238], 2.05 Content, 2:4/1/64 |
	| |		| |
	| CON [MID=1239], GET, /status, 2:5/0/64 ------> |		| CON [MID=1239], GET, /status, 2:5/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1239], 2.05 Content, 2:5/0/64 |		| <------ ACK [MID=1239], 2.05 Content, 2:5/0/64 |
	Figure 3: Blockwise GET with early negotiation		Figure 3: Block-wise GET with early negotiation
	In the third example (Figure 4), the client is surprised by the need		In the third example (Figure 4), the client is surprised by the need
	for a blockwise transfer, and unhappy with the size chosen		for a block-wise transfer, and unhappy with the size chosen
	unilaterally by the server. As it did not send a size proposal		unilaterally by the server. As it did not send a size proposal
	initially, the negotiation only influences the size from the second		initially, the negotiation only influences the size from the second
	message exchange onward. Since the client already obtained both the		message exchange onward. Since the client already obtained both the
	first and second 64-byte block in the first 128-byte exchange, it		first and second 64-byte block in the first 128-byte exchange, it
	goes on requesting the third 64-byte block ("2/0/64"). None of this		goes on requesting the third 64-byte block ("2/0/64"). None of this
	is (or needs to be) understood by the server, which simply responds		is (or needs to be) understood by the server, which simply responds
	to the requests as it best can.		to the requests as it best can.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	skipping to change at page 18, line 32		skipping to change at page 18, line 32
	| <------ ACK [MID=1236], 2.05 Content, 2:3/1/64 |		| <------ ACK [MID=1236], 2.05 Content, 2:3/1/64 |
	| |		| |
	| CON [MID=1237], GET, /status, 2:4/0/64 ------> |		| CON [MID=1237], GET, /status, 2:4/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1237], 2.05 Content, 2:4/1/64 |		| <------ ACK [MID=1237], 2.05 Content, 2:4/1/64 |
	| |		| |
	| CON [MID=1238], GET, /status, 2:5/0/64 ------> |		| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |		| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
	Figure 4: Blockwise GET with late negotiation		Figure 4: Block-wise GET with late negotiation
	In all these (and the following) cases, retransmissions are handled		In all these (and the following) cases, retransmissions are handled
	by the CoAP message exchange layer, so they don't influence the block		by the CoAP message exchange layer, so they don't influence the block
	operations (Figure 5, Figure 6).		operations (Figure 5, Figure 6).
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	| CON [MID=1234], GET, /status ------> |		| CON [MID=1234], GET, /status ------> |
	| |		| |
	| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |		| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
	skipping to change at page 19, line 25		skipping to change at page 19, line 25
	| CON [MID=1235], GET, /status, 2:2/0/64 ------> |		| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |		| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
	: :		: :
	: ... :		: ... :
	: :		: :
	| CON [MID=1238], GET, /status, 2:5/0/64 ------> |		| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |		| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
	Figure 5: Blockwise GET with late negotiation and lost CON		Figure 5: Block-wise GET with late negotiation and lost CON
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	| CON [MID=1234], GET, /status ------> |		| CON [MID=1234], GET, /status ------> |
	| |		| |
	| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |		| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
	| |		| |
	| CON [MID=1235], GET, /status, 2:2/0/64 ------> |		| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
	| |		| |
	| //////////////////////////////////tent, 2:2/1/64 |		| //////////////////////////////////tent, 2:2/1/64 |
	skipping to change at page 19, line 49		skipping to change at page 19, line 49
	| CON [MID=1235], GET, /status, 2:2/0/64 ------> |		| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |		| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
	: :		: :
	: ... :		: ... :
	: :		: :
	| CON [MID=1238], GET, /status, 2:5/0/64 ------> |		| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |		| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
	Figure 6: Blockwise GET with late negotiation and lost ACK		Figure 6: Block-wise GET with late negotiation and lost ACK
	3.2. Block1 Examples		3.2. Block1 Examples
	The following examples demonstrate a PUT exchange; a POST exchange		The following examples demonstrate a PUT exchange; a POST exchange
	looks the same, with different requirements on atomicity/idempotence.		looks the same, with different requirements on atomicity/idempotence.
	Note that, similar to GET, the responses to the requests that have a		Note that, similar to GET, the responses to the requests that have a
	more bit in the request Block1 Option are provisional and carry the		more bit in the request Block1 Option are provisional and carry the
	response code 2.31 (Continue); only the final response tells the		response code 2.31 (Continue); only the final response tells the
	client that the PUT did succeed.		client that the PUT did succeed.
	skipping to change at page 20, line 28		skipping to change at page 20, line 28
	| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |		| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
	| |		| |
	| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |		| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |		| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
	| |		| |
	| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |		| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
	| |		| |
	| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |		| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
	Figure 7: Simple atomic blockwise PUT		Figure 7: Simple atomic block-wise PUT
	A stateless server that simply builds/updates the resource in place		A stateless server that simply builds/updates the resource in place
	(statelessly) may indicate this by not setting the more bit in the		(statelessly) may indicate this by not setting the more bit in the
	response (Figure 8); in this case, the response codes are valid		response (Figure 8); in this case, the response codes are valid
	separately for each block being updated. This is of course only an		separately for each block being updated. This is of course only an
	acceptable behavior of the server if the potential inconsistency		acceptable behavior of the server if the potential inconsistency
	present during the run of the message exchange sequence does not lead		present during the run of the message exchange sequence does not lead
	to problems, e.g. because the resource being created or changed is		to problems, e.g. because the resource being created or changed is
	not yet or not currently in use.		not yet or not currently in use.
	skipping to change at page 21, line 19		skipping to change at page 21, line 19
	| <------ ACK [MID=1234], 2.04 Changed, 1:0/0/128 |		| <------ ACK [MID=1234], 2.04 Changed, 1:0/0/128 |
	| |		| |
	| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |		| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.04 Changed, 1:1/0/128 |		| <------ ACK [MID=1235], 2.04 Changed, 1:1/0/128 |
	| |		| |
	| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |		| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
	| |		| |
	| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |		| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
	Figure 8: Simple stateless blockwise PUT		Figure 8: Simple stateless block-wise PUT
	Finally, a server receiving a blockwise PUT or POST may want to		Finally, a server receiving a block-wise PUT or POST may want to
	indicate a smaller block size preference (Figure 9). In this case,		indicate a smaller block size preference (Figure 9). In this case,
	the client SHOULD continue with a smaller block size; if it does, it		the client SHOULD continue with a smaller block size; if it does, it
	MUST adjust the block number to properly count in that smaller size.		MUST adjust the block number to properly count in that smaller size.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |		| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
	| |		| |
	| <------ ACK [MID=1234], 2.04 Changed, 1:0/1/32 |		| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/32 |
	| |		| |
	| CON [MID=1235], PUT, /options, 1:4/1/32 ------> |		| CON [MID=1235], PUT, /options, 1:4/1/32 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.04 Changed, 1:4/1/32 |		| <------ ACK [MID=1235], 2.31 Continue, 1:4/1/32 |
	| |		| |
	| CON [MID=1236], PUT, /options, 1:5/1/32 ------> |		| CON [MID=1236], PUT, /options, 1:5/1/32 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.04 Changed, 1:5/1/32 |		| <------ ACK [MID=1235], 2.31 Continue, 1:5/1/32 |
	| |		| |
	| CON [MID=1237], PUT, /options, 1:6/0/32 ------> |		| CON [MID=1237], PUT, /options, 1:6/0/32 ------> |
	| |		| |
	| <------ ACK [MID=1236], 2.04 Changed, 1:6/0/32 |		| <------ ACK [MID=1236], 2.04 Changed, 1:6/0/32 |
	Figure 9: Simple atomic blockwise PUT with negotiation		Figure 9: Simple atomic block-wise PUT with negotiation
	3.3. Combining Block1 and Block2		3.3. Combining Block1 and Block2
	Block options may be used in both directions of a single exchange.		Block options may be used in both directions of a single exchange.
	The following example demonstrates a blockwise POST request,		The following example demonstrates a block-wise POST request,
	resulting in a separate blockwise response.		resulting in a separate block-wise response.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |		| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
	| |		| |
	| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |		| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
	| |		| |
	| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |		| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |		| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
	skipping to change at page 22, line 33		skipping to change at page 22, line 33
	| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/128 |		| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/128 |
	| |		| |
	| CON [MID=1238], POST, /soap, 2:2/0/128 ------> |		| CON [MID=1238], POST, /soap, 2:2/0/128 ------> |
	| |		| |
	| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/128 |		| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/128 |
	| |		| |
	| CON [MID=1239], POST, /soap, 2:3/0/128 ------> |		| CON [MID=1239], POST, /soap, 2:3/0/128 ------> |
	| |		| |
	| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/128 |		| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/128 |
	Figure 10: Atomic blockwise POST with blockwise response		Figure 10: Atomic block-wise POST with block-wise response
	This model does provide for early negotiation input to the Block2		This model does provide for early negotiation input to the Block2
	blockwise transfer, as shown below.		block-wise transfer, as shown below.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |		| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
	| |		| |
	| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |		| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
	| |		| |
	| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |		| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
	| |		| |
	| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |		| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
	skipping to change at page 23, line 32		skipping to change at page 23, line 32
	| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/64 |		| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/64 |
	| |		| |
	| CON [MID=1238], POST, /soap, 2:2/0/64 ------> |		| CON [MID=1238], POST, /soap, 2:2/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/64 |		| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/64 |
	| |		| |
	| CON [MID=1239], POST, /soap, 2:3/0/64 ------> |		| CON [MID=1239], POST, /soap, 2:3/0/64 ------> |
	| |		| |
	| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/64 |		| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/64 |
	Figure 11: Atomic blockwise POST with blockwise response, early		Figure 11: Atomic block-wise POST with block-wise response, early
	negotiation		negotiation
	3.4. Combining Observe and Block2		3.4. Combining Observe and Block2
	In the following example, the server first sends a direct response		In the following example, the server first sends a direct response
	(Observe sequence number 62350) to the initial GET request (the		(Observe sequence number 62350) to the initial GET request (the
	resulting blockwise transfer is as in Figure 4 and has therefore been		resulting block-wise transfer is as in Figure 4 and has therefore
	left out). The second transfer is started by a 2.05 notification		been left out). The second transfer is started by a 2.05
	that contains just the first block (Observe sequence number 62354);		notification that contains just the first block (Observe sequence
	the client then goes on to obtain the rest of the blocks.		number 62354); the client then goes on to obtain the rest of the
			blocks.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	+----->| Header: GET 0x41011636		+----->| Header: GET 0x41011636
	| GET | Token: 0xfb		| GET | Token: 0xfb
	| | Uri-Path: status-icon		| | Uri-Path: status-icon
	| | Observe: (empty)		| | Observe: (empty)
	| |		| |
	|<-----+ Header: 2.05 0x61451636		|<-----+ Header: 2.05 0x61451636
	| 2.05 | Token: 0xfb		| 2.05 | Token: 0xfb
	skipping to change at page 24, line 46		skipping to change at page 24, line 47
	| GET | Token: 0xfc		| GET | Token: 0xfc
	| | Uri-Path: status-icon		| | Uri-Path: status-icon
	| | Block2: 2/0/128		| | Block2: 2/0/128
	| |		| |
	|<-----+ Header: 2.05 0x61451638		|<-----+ Header: 2.05 0x61451638
	| 2.05 | Token: 0xfc		| 2.05 | Token: 0xfc
	| | Block2: 2/0/128		| | Block2: 2/0/128
	| | ETag: 6f00f392		| | ETag: 6f00f392
	| | Payload: [53 bytes]		| | Payload: [53 bytes]
	Figure 12: Observe sequence with blockwise response		Figure 12: Observe sequence with block-wise response
	(Note that the choice of token 0xfc in this examples is arbitrary;		(Note that the choice of token 0xfc in this examples is arbitrary;
	tokens are just shown in this example to illustrate that the requests		tokens are just shown in this example to illustrate that the requests
	for additional blocks cannot make use of the token of the Observation		for additional blocks cannot make use of the token of the Observation
	relationship. As a general comment on tokens, there is no other		relationship. As a general comment on tokens, there is no other
	mention of tokens in this document, as blockwise transfers handle		mention of tokens in this document, as block-wise transfers handle
	tokens like any other CoAP exchange. As usual the client is free to		tokens like any other CoAP exchange. As usual the client is free to
	choose tokens for each exchange as it likes.)		choose tokens for each exchange as it likes.)
	In the following example, the client also uses early negotiation to		In the following example, the client also uses early negotiation to
	limit the block size to 64 bytes.		limit the block size to 64 bytes.
	CLIENT SERVER		CLIENT SERVER
	| |		| |
	+----->| Header: GET 0x41011636		+----->| Header: GET 0x41011636
	| GET | Token: 0xfb		| GET | Token: 0xfb
	skipping to change at page 27, line 30		skipping to change at page 27, line 30
	+-----+---+---+---+---+-------+--------+--------+---------+		+-----+---+---+---+---+-------+--------+--------+---------+
	| 60 | | | x | | Size1 | uint | 0-4 | (none) |		| 60 | | | x | | Size1 | uint | 0-4 | (none) |
	| | | | | | | | | |		| | | | | | | | | |
	| 28 | | | x | | Size2 | uint | 0-4 | (none) |		| 28 | | | x | | Size2 | uint | 0-4 | (none) |
	+-----+---+---+---+---+-------+--------+--------+---------+		+-----+---+---+---+---+-------+--------+--------+---------+
	Table 2: Size Option Numbers		Table 2: Size Option Numbers
	Implementation Notes:		Implementation Notes:
	o As a quality of implementation consideration, blockwise transfers		o As a quality of implementation consideration, block-wise transfers
	for which the total size considerably exceeds the size of one		for which the total size considerably exceeds the size of one
	block are expected to include size indications, whenever those can		block are expected to include size indications, whenever those can
	be provided without undue effort (preferably with the first block		be provided without undue effort (preferably with the first block
	exchanged). If the size estimate does not change, the indication		exchanged). If the size estimate does not change, the indication
	does not need to be repeated for every block.		does not need to be repeated for every block.
	o The end of a blockwise transfer is governed by the M bits in the		o The end of a block-wise transfer is governed by the M bits in the
	Block Options, _not_ by exhausting the size estimates exchanged.		Block Options, _not_ by exhausting the size estimates exchanged.
	o As usual for an option of type uint, the value 0 is best expressed		o As usual for an option of type uint, the value 0 is best expressed
	as an empty option (0 bytes). There is no default value for		as an empty option (0 bytes). There is no default value for
	either Size Option.		either Size Option.
	o The Size Options are neither critical nor unsafe, and are marked		o The Size Options are neither critical nor unsafe, and are marked
	as No-Cache-Key.		as No-Cache-Key.
	5. HTTP Mapping Considerations		5. HTTP Mapping Considerations
	skipping to change at page 30, line 25		skipping to change at page 30, line 25
	adversary sends a Block1 (e.g., PUT) block with a high block number:		adversary sends a Block1 (e.g., PUT) block with a high block number:
	A naive implementation might exhaust its resources by creating a huge		A naive implementation might exhaust its resources by creating a huge
	resource representation.		resource representation.
	Misleading size indications may be used by an attacker to induce		Misleading size indications may be used by an attacker to induce
	buffer overflows in poor implementations, for which the usual		buffer overflows in poor implementations, for which the usual
	considerations apply.		considerations apply.
	7.1. Mitigating Resource Exhaustion Attacks		7.1. Mitigating Resource Exhaustion Attacks
	Certain blockwise requests may induce the server to create state,		Certain block-wise requests may induce the server to create state,
	e.g. to create a snapshot for the blockwise GET of a fast-changing		e.g. to create a snapshot for the block-wise GET of a fast-changing
	resource to enable consistent access to the same version of a		resource to enable consistent access to the same version of a
	resource for all blocks, or to create temporary resource		resource for all blocks, or to create temporary resource
	representations that are collected until pressed into service by a		representations that are collected until pressed into service by a
	final PUT or POST with the more bit unset. All mechanisms that		final PUT or POST with the more bit unset. All mechanisms that
	induce a server to create state that cannot simply be cleaned up		induce a server to create state that cannot simply be cleaned up
	create opportunities for denial-of-service attacks. Servers SHOULD		create opportunities for denial-of-service attacks. Servers SHOULD
	avoid being subject to resource exhaustion based on state created by		avoid being subject to resource exhaustion based on state created by
	untrusted sources. But even if this is done, the mitigation may		untrusted sources. But even if this is done, the mitigation may
	cause a denial-of-service to a legitimate request when it is drowned		cause a denial-of-service to a legitimate request when it is drowned
	out by other state-creating requests. Wherever possible, servers		out by other state-creating requests. Wherever possible, servers
	skipping to change at page 30, line 48		skipping to change at page 30, line 48
	untrusted sources, e.g. by using stateless approaches.		untrusted sources, e.g. by using stateless approaches.
	Performing segmentation at the application layer is almost always		Performing segmentation at the application layer is almost always
	better in this respect than at the transport layer or lower (IP		better in this respect than at the transport layer or lower (IP
	fragmentation, adaptation layer fragmentation), for instance because		fragmentation, adaptation layer fragmentation), for instance because
	there is application layer semantics that can be used for mitigation		there is application layer semantics that can be used for mitigation
	or because lower layers provide security associations that can		or because lower layers provide security associations that can
	prevent attacks. However, it is less common to apply timeouts and		prevent attacks. However, it is less common to apply timeouts and
	keepalive mechanisms at the application layer than at lower layers.		keepalive mechanisms at the application layer than at lower layers.
	Servers MAY want to clean up accumulated state by timing it out (cf.		Servers MAY want to clean up accumulated state by timing it out (cf.
	response code 4.08), and clients SHOULD be prepared to run blockwise		response code 4.08), and clients SHOULD be prepared to run block-wise
	transfers in an expedient way to minimize the likelihood of running		transfers in an expedient way to minimize the likelihood of running
	into such a timeout.		into such a timeout.
	7.2. Mitigating Amplification Attacks		7.2. Mitigating Amplification Attacks
	[RFC7252] discusses the susceptibility of CoAP end-points for use in		[RFC7252] discusses the susceptibility of CoAP end-points for use in
	amplification attacks.		amplification attacks.
	A CoAP server can reduce the amount of amplification it provides to		A CoAP server can reduce the amount of amplification it provides to
	an attacker by offering large resource representations only in		an attacker by offering large resource representations only in
	skipping to change at page 31, line 44		skipping to change at page 31, line 44
	some of the text describing the interaction of Block2 with Observe.		some of the text describing the interaction of Block2 with Observe.
	Matthias Kovatsch provided a number of significant simplifications of		Matthias Kovatsch provided a number of significant simplifications of
	the protocol.		the protocol.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-core-observe]		[I-D.ietf-core-observe]
	Hartke, K., "Observing Resources in CoAP", draft-ietf-		Hartke, K., "Observing Resources in CoAP", draft-ietf-
	core-observe-14 (work in progress), June 2014.		core-observe-16 (work in progress), December 2014.
	[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, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252, June 2014.		Application Protocol (CoAP)", RFC 7252, June 2014.
	9.2. Informative References		9.2. Informative References
	[REST] Fielding, R., "Architectural Styles and the Design of		[REST] Fielding, R., "Architectural Styles and the Design of
End of changes. 35 change blocks.
	51 lines changed or deleted		52 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/