I-D Action: draft-ietf-core-block-21.txt

internet-drafts@ietf.org Fri, 08 July 2016 22:46 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action: draft-ietf-core-block-21.txt
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160708224601.32079.31903.idtracker@ietfa.amsl.com>
Date: Fri, 08 Jul 2016 15:46:01 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/i-d-announce/HfWQUp7CkB5No5hSlXj2Db88VQM>
Cc: core@ietf.org
Reply-To: internet-drafts@ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Constrained RESTful Environments of the IETF.

        Title           : Block-wise transfers in CoAP
        Authors         : Carsten Bormann
                          Zach Shelby
	Filename        : draft-ietf-core-block-21.txt
	Pages           : 35
	Date            : 2016-07-08

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 -- 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.

   A CoAP implementation that does not support these options generally
   is limited in the size of the representations that can be exchanged.
   There is therefore an expectation that the Block options are very
   widely implemented in CoAP implementations, which is why this
   specification is listed as "updating" RFC 7252.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-core-block/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-core-block-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-21


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

I-D Action: draft-ietf-core-block-21.txt internet-drafts