draft-ietf-core-block-18.txt		draft-ietf-core-block-19.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: March 17, 2016 ARM		Expires: September 22, 2016 ARM
	September 14, 2015		March 21, 2016
	Block-wise transfers in CoAP		Block-wise transfers in CoAP
	draft-ietf-core-block-18		draft-ietf-core-block-19
	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 March 17, 2016.		This Internet-Draft will expire on September 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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 50 ¶		skipping to change at page 2, line 50 ¶
	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
	3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 21		3.3. Combining Block1 and Block2 . . . . . . . . . . . . . . . 21
	3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 23		3.4. Combining Observe and Block2 . . . . . . . . . . . . . . 23
	4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 26		4. The Size2 and Size1 Options . . . . . . . . . . . . . . . . . 26
	5. HTTP Mapping Considerations . . . . . . . . . . . . . . . . . 27		5. HTTP Mapping Considerations . . . . . . . . . . . . . . . . . 28
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 29		7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 30		7.1. Mitigating Resource Exhaustion Attacks . . . . . . . . . 30
	7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 31		7.2. Mitigating Amplification Attacks . . . . . . . . . . . . 31
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	9.1. Normative References . . . . . . . . . . . . . . . . . . 31		9.1. Normative References . . . . . . . . . . . . . . . . . . 32
	9.2. Informative References . . . . . . . . . . . . . . . . . 32		9.2. Informative References . . . . . . . . . . . . . . . . . 32
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
	1. Introduction		1. Introduction
	The work on Constrained RESTful Environments (CoRE) aims at realizing		The work on Constrained RESTful Environments (CoRE) aims at realizing
	the REST architecture in a suitable form for the most constrained		the REST architecture in a suitable form for the most constrained
	nodes (such as microcontrollers with limited RAM and ROM [RFC7228])		nodes (such as microcontrollers with limited RAM and ROM [RFC7228])
	and networks (such as 6LoWPAN, [RFC4944]) [RFC7252]. The CoAP		and networks (such as 6LoWPAN, [RFC4944]) [RFC7252]. The CoAP
	protocol is intended to provide RESTful [REST] services not unlike		protocol is intended to provide RESTful [REST] services not unlike
	HTTP [RFC7230], while reducing the complexity of implementation as		HTTP [RFC7230], while reducing the complexity of implementation as
	well as the size of packets exchanged in order to make these services		well as the size of packets exchanged in order to make these services
	skipping to change at page 5, line 22 ¶		skipping to change at page 5, line 22 ¶
	o by the desire to avoid IP fragmentation (MTU of 1280 for IPv6)		o by the desire to avoid IP fragmentation (MTU of 1280 for IPv6)
	o by the desire to avoid adaptation layer fragmentation (60-80 bytes		o by the desire to avoid adaptation layer fragmentation (60-80 bytes
	for 6LoWPAN [RFC4919])		for 6LoWPAN [RFC4919])
	When a resource representation is larger than can be comfortably		When a resource representation is larger than can be comfortably
	transferred in the payload of a single CoAP datagram, a Block option		transferred in the payload of a single CoAP datagram, a Block option
	can be used to indicate a block-wise transfer. As payloads can be		can be used to indicate a block-wise transfer. As payloads can be
	sent both with requests and with responses, this specification		sent both with requests and with responses, this specification
	provides two separate options for each direction of payload transfer.		provides two separate options for each direction of payload transfer.
	In identifying these options, we use the number 1 to refer to the		In naming these options (for block-wise transfers as well as in
			Section 4), we use the number 1 ("Block1", "Size1") to refer to the
	transfer of the resource representation that pertains to the request,		transfer of the resource representation that pertains to the request,
	and the number 2 to refer to the transfer of the resource		and the number 2 ("Block2", "Size2") to refer to the transfer of the
	representation for the response.		resource representation for the response.
	In the following, the term "payload" will be used for the actual		In the following, the term "payload" will be used for the actual
	content of a single CoAP message, i.e. a single block being		content of a single CoAP message, i.e. a single block being
	transferred, while the term "body" will be used for the entire		transferred, while the term "body" will be used for the entire
	resource representation that is being transferred in a block-wise		resource representation that is being transferred in a block-wise
	fashion. The Content-Format option applies to the body, not to the		fashion. The Content-Format option applies to the body, not to the
	payload, in particular the boundaries between the blocks may be in		payload, in particular the boundaries between the blocks may be in
	places that are not separating whole units in terms of the structure,		places that are not separating whole units in terms of the structure,
	encoding, or content-coding used by the Content-Format.		encoding, or content-coding used by the Content-Format.
	skipping to change at page 13, line 27 ¶		skipping to change at page 13, line 27 ¶
	(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 Block-wise 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 [RFC7641]. Resources observed by
	observed by clients may be larger than can be comfortably processed		clients may be larger than can be comfortably processed or
	or transferred in one CoAP message. The following rules apply to the		transferred in one CoAP message. The following rules apply to the
	combination of block-wise 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 block-		renewing the observation relationship. If the server supports block-
	wise transfers, it SHOULD take note of the block size and apply it as		wise transfers, it SHOULD take note of the block size and apply it as
	skipping to change at page 16, line 32 ¶		skipping to change at page 16, line 32 ¶
	retransmissions, and examples for the operation of the block size		retransmissions, and examples for the operation of the block size
	negotiation.		negotiation.
	In all these examples, a Block option is shown in a decomposed way		In all these examples, a Block option is shown in a decomposed way
	indicating the kind of Block option (1 or 2) followed by a colon, and		indicating the kind of Block option (1 or 2) followed by a colon, and
	then the block number (NUM), more bit (M), and block size exponent		then the block number (NUM), more bit (M), and block size exponent
	(2**(SZX+4)) separated by slashes. E.g., a Block2 Option value of 33		(2**(SZX+4)) separated by slashes. E.g., a Block2 Option value of 33
	would be shown as 2:2/0/32), or a Block1 Option value of 59 would be		would be shown as 2:2/0/32), or a Block1 Option value of 59 would be
	shown as 1:3/1/128.		shown as 1:3/1/128.
			As in [RFC7252], "MID" is used as an abbreviation of "Message ID".
	3.1. Block2 Examples		3.1. Block2 Examples
	The first example (Figure 2) shows a GET request that is split into		The first example (Figure 2) shows a GET request that is split into
	three blocks. The server proposes a block size of 128, and the		three blocks. The server proposes a block size of 128, and the
	client agrees. The first two ACKs contain 128 bytes of payload each,		client agrees. The first two ACKs contain a payload of 128 bytes
	and third ACK contains between 1 and 128 bytes.		each, and the third ACK contains a payload between 1 and 128 bytes.
	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: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 |
	skipping to change at page 26, line 33 ¶		skipping to change at page 26, line 33 ¶
	In many cases when transferring a large resource representation block		In many cases when transferring a large resource representation block
	by block, it is advantageous to know the total size early in the		by block, it is advantageous to know the total size early in the
	process. Some indication may be available from the maximum size		process. Some indication may be available from the maximum size
	estimate attribute "sz" provided in a resource description [RFC6690].		estimate attribute "sz" provided in a resource description [RFC6690].
	However, the size may vary dynamically, so a more up-to-date		However, the size may vary dynamically, so a more up-to-date
	indication may be useful.		indication may be useful.
	This specification defines two CoAP Options, Size1 for indicating the		This specification defines two CoAP Options, Size1 for indicating the
	size of the representation transferred in requests, and Size2 for		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.
	(Size1 is already defined in [RFC7252] for the narrow case of		(Size1 has already been defined in Section 5.10.9 of [RFC7252] to
			provide "size information about the resource representation in a
			request", however that section only details the narrow case of
	indicating in 4.13 responses the maximum size of request payload that		indicating in 4.13 responses the maximum size of request payload that
	the server is able and willing to handle.)		the server is able and willing to handle. The present specification
			provides details about its use as a request option as well.)
	The Size2 Option may be used for two purposes:		The Size2 Option may be used for two purposes:
	o in a request, to ask the server to provide a size estimate along		o in a request, to ask the server to provide a size estimate along
	with the usual response ("size request"). For this usage, the		with the usual response ("size request"). For this usage, the
	value MUST be set to 0.		value MUST be set to 0.
	o in a response carrying a Block2 Option, to indicate the current		o in a response carrying a Block2 Option, to indicate the current
	estimate the server has of the total size of the resource		estimate the server has of the total size of the resource
	representation, measured in bytes ("size indication").		representation, measured in bytes ("size indication").
	skipping to change at page 30, line 12 ¶		skipping to change at page 30, line 18 ¶
	from IP fragmentation and TCP segmentation; CoAP does not add		from IP fragmentation and TCP segmentation; CoAP does not add
	fundamentally new considerations.		fundamentally new considerations.
	Where access to a resource is only granted to clients making use of		Where access to a resource is only granted to clients making use of
	specific security associations, all blocks of that resource MUST be		specific security associations, all blocks of that resource MUST be
	subject to the same security checks; it MUST NOT be possible for		subject to the same security checks; it MUST NOT be possible for
	unprotected exchanges to influence blocks of an otherwise protected		unprotected exchanges to influence blocks of an otherwise protected
	resource. As a related consideration, where object security is		resource. As a related consideration, where object security is
	employed, PUT/POST should be implemented in the atomic fashion,		employed, PUT/POST should be implemented in the atomic fashion,
	unless the object security operation is performed on each access and		unless the object security operation is performed on each access and
	the creation of unusable resources can be tolerated.		the creation of unusable resources can be tolerated. Future end-to-
			end security mechanisms that may be added to CoAP itself may have
			related security considerations, this includes considerations about
			caching of blocks in clients and in proxies (see Section 2.10 and
			Section 5 for different strategies in performing this caching); these
			security considerations will need to be described in the
			specifications of those mechanisms.
	A stateless server might be susceptible to an attack where the		A stateless server might be susceptible to an attack where the
	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.
	skipping to change at page 31, line 30 ¶		skipping to change at page 31, line 42 ¶
	the [RFC7252] authors, and via many CoRE WG discussions.		the [RFC7252] authors, and via many CoRE WG discussions.
	Charles Palmer provided extensive editorial comments to a previous		Charles Palmer provided extensive editorial comments to a previous
	version of this draft, some of which the authors hope to have covered		version of this draft, some of which the authors hope to have covered
	in this version. Esko Dijk reviewed a more recent version, leading		in this version. Esko Dijk reviewed a more recent version, leading
	to a number of further editorial improvements, a solution to the 4.13		to a number of further editorial improvements, a solution to the 4.13
	ambiguity problem, and the section about combining Block and		ambiguity problem, and the section about combining Block and
	multicast. Markus Becker proposed getting rid of an ill-conceived		multicast. Markus Becker proposed getting rid of an ill-conceived
	default value for the Block2 and Block1 options. Peter Bigot		default value for the Block2 and Block1 options. Peter Bigot
	insisted on a more systematic coverage of the options and response		insisted on a more systematic coverage of the options and response
	code.		code. Qin Wu provided a review for the IETF Operational directorate,
			and Goeran Selander commented on the security considerations.
	Kepeng Li, Linyi Tian, and Barry Leiba wrote up an early version of		Kepeng Li, Linyi Tian, and Barry Leiba wrote up an early version of
	the Size Option, which has informed this draft. Klaus Hartke wrote		the Size Option, which has informed this draft. Klaus Hartke wrote
	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]
	Hartke, K., "Observing Resources in CoAP", draft-ietf-
	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, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[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, DOI 10.17487/		Application Protocol (CoAP)", RFC 7252,
	RFC7252, June 2014,		DOI 10.17487/RFC7252, June 2014,
	<http://www.rfc-editor.org/info/rfc7252>.		<http://www.rfc-editor.org/info/rfc7252>.
			[RFC7641] Hartke, K., "Observing Resources in the Constrained
			Application Protocol (CoAP)", RFC 7641,
			DOI 10.17487/RFC7641, September 2015,
			<http://www.rfc-editor.org/info/rfc7641>.
	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
	Network-based Software Architectures", Ph.D. Dissertation,		Network-based Software Architectures", Ph.D. Dissertation,
	University of California, Irvine, 2000,		University of California, Irvine, 2000,
	<http://www.ics.uci.edu/~fielding/pubs/dissertation/		<http://www.ics.uci.edu/~fielding/pubs/dissertation/
	fielding_dissertation.pdf>.		fielding_dissertation.pdf>.
	[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6		[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):		over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals", RFC		Overview, Assumptions, Problem Statement, and Goals",
	4919, DOI 10.17487/RFC4919, August 2007,		RFC 4919, DOI 10.17487/RFC4919, August 2007,
	<http://www.rfc-editor.org/info/rfc4919>.		<http://www.rfc-editor.org/info/rfc4919>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4		"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,		Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<http://www.rfc-editor.org/info/rfc4944>.		<http://www.rfc-editor.org/info/rfc4944>.
	[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link		[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
	Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,		Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
	<http://www.rfc-editor.org/info/rfc6690>.		<http://www.rfc-editor.org/info/rfc6690>.
	[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for		[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
	Constrained-Node Networks", RFC 7228, DOI 10.17487/		Constrained-Node Networks", RFC 7228,
	RFC7228, May 2014,		DOI 10.17487/RFC7228, May 2014,
	<http://www.rfc-editor.org/info/rfc7228>.		<http://www.rfc-editor.org/info/rfc7228>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing", RFC		Protocol (HTTP/1.1): Message Syntax and Routing",
	7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7230>.		<http://www.rfc-editor.org/info/rfc7230>.
	[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
	"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",		"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
	RFC 7233, DOI 10.17487/RFC7233, June 2014,		RFC 7233, DOI 10.17487/RFC7233, June 2014,
	<http://www.rfc-editor.org/info/rfc7233>.		<http://www.rfc-editor.org/info/rfc7233>.
	Authors' Addresses		Authors' Addresses
	Carsten Bormann		Carsten Bormann
	Universitaet Bremen TZI		Universitaet Bremen TZI
	Postfach 330440		Postfach 330440
	Bremen D-28359		Bremen D-28359
	Germany		Germany
	Phone: +49-421-218-63921		Phone: +49-421-218-63921
	Email: cabo@tzi.org		Email: cabo@tzi.org
	Zach Shelby (editor)		Zach Shelby (editor)
End of changes. 24 change blocks.
	35 lines changed or deleted		50 lines changed or added
This html diff was produced by rfcdiff 1.44. The latest version is available from http://tools.ietf.org/tools/rfcdiff/