Sign in
Version 5.4.0, 2014-04-22
Report a bug

Blockwise transfers in CoAP

Document type: Expired Internet-Draft (core WG)
Document stream: IETF
Last updated: 2014-04-24 (latest revision 2013-10-21)
Intended RFC status: Proposed Standard
Other versions: (expired, archived): plain text, pdf, html

IETF State: WG Document Oct 2013
Document shepherd: No shepherd assigned

IESG State: Expired (IESG: Dead)
Responsible AD: Barry Leiba
Send notices to:,

This Internet-Draft is no longer active. Unofficial copies of old Internet-Drafts can be found here:


CoAP is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for the small payloads we expect from temperature sensors, light switches, and similar building-automation devices. Occasionally, however, applications will need to transfer larger payloads -- for instance, for firmware updates. With HTTP, TCP does the grunt work of slicing large payloads up into multiple packets and ensuring that they all arrive and are handled in the right order. CoAP is based on datagram transports such as UDP or DTLS, which limits the maximum size of resource representations that can be transferred without too much fragmentation. Although UDP supports larger payloads through IP fragmentation, it is limited to 64 KiB and, more importantly, doesn't really work well for constrained applications and networks. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options, for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. In summary, the Block options provide a minimal way to transfer larger representations in a block-wise fashion.


Carsten Bormann <>
Zach Shelby <>

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid)