Re: [core] I-D Action: draft-ietf-core-block-20.txt

This update contains changes that address the IESG DISCUSS and COMMENT
ballots.

This SHOULD all be editorial in nature, but please do have a look
whether I unintentionally changed anything substantive.
(Note that we continue to be in IESG processing, so we are mainly
addressing IESG comments, but if you find anything that is broken, we
need to know before the RFC is published.)

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20

Grüße, Carsten

internet-drafts@ietf.org wrote:
> 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-20.txt
> 	Pages           : 34
> 	Date            : 2016-04-29
> 
> 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.
> 
> 
> 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-20
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-core-block-20
> 
> 
> 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/
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> 