%% You should probably cite rfc7959 instead of this I-D. @techreport{ietf-core-block-11, number = {draft-ietf-core-block-11}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-ietf-core-block/11/}, author = {Carsten Bormann and Zach Shelby}, title = {{Blockwise transfers in CoAP}}, pagetotal = 29, year = 2013, month = mar, day = 30, abstract = {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 -\textbackslash{}u002D 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. The present revision -11 fixes one example and adds the text and examples about the Block/Observe interaction, taken from -observe. It also adds a couple of formatting bugs from the new xml2rfc. The "grand rewrite" is next.}, }