Subject: [core] I-D Action: draft-ietf-core-block-05.txt

From: [email-masked]
Date: Thu, 12 Jan 2012 15:29:54 -0800

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

	Title           : Blockwise transfers in CoAP
	Author(s)       : Carsten Bormann
                          Zach Shelby
	Filename        : draft-ietf-core-block-05.txt
	Pages           : 27
	Date            : 2012-01-12

   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 URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-core-block-05.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-core-block-05.txt

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 13 Jan 2012 00:44:26 +0100

A day late (the old draft expired 15.5 hours ago, oops):

Here is the Friday 13th edition of -block.  
I hope that is not too scary :-)

block-05 is trying to solve the editorial problems (#169).
No technical changes are intended from the July 11th version, -04.

Please read this version again and indicate whether this is still near-unreadable.
The draft is now deliberately preferring redundancy over unreadable terseness.
This blew up the actual specification part (section 2) to 7 pages.  
Oh well, it is still a very simple mechanism.

If we want to, we can fix the small remaining technical issues #170 and #171 in the next couple of days when we have the editorial stuff behind us.

Enjoy!

Grüße, Carsten

On Jan 13, 2012, at 00:29, [email-masked] wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 20 Jan 2012 14:30:56 +0000

Dear Carsten, all,

I would say the readability is improved, as intended. Below some remarks on the new text:

Questions
- Table 1: should a length of 0 B be possible for both options? I would assume a zero-length Block1/Block2 option value is possible and then it indicates the default value of 0.
- section 2.1 "(The block size given is irrelevant if M is unset)."
  Isn't a correct SZX required e.g. for a stateless server, even if M is unset? At least all the examples set the SZX when M=0 the same as the previous blocks in the same sequence.

Minor items
- section 1 "process loads the lower layers with" -> maybe "burdens" is better here; "loads" has some other technical connotations that may confuse a reader at this point.
- section 2 "limit the size datagrams" -> size of datagrams
- section 2 mentions "6LoWPAN" -> informative reference needed maybe?
- section 2 "still this size will be given as the block size even for the final block." -> a bit unclear. Maybe "still the chosen power-of-two block size will be specified in the size field of the Block option that accompanies the final block" is better?

Best regards,
Esko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Friday 13 January 2012 0:44
To: [email-masked] WG
Subject: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-05.txt)

Enjoy!

Grüße, Carsten

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 21 Jan 2012 16:05:43 +0100

On Jan 20, 2012, at 15:30, Dijk, Esko wrote:

> Dear Carsten, all,
> 
> I would say the readability is improved, as intended.

Thanks.

> - Table 1: should a length of 0 B be possible for both options? I would assume a zero-length Block1/Block2 option value is possible and then it indicates the default value of 0.

The design of CoAP tries to follow one principle that is important for improving interoperability and minimizing code complexity:
There should be as few ways to say the same thing as possible.

Adding a way to explicitly send the default value would violate this for no apparent gain.
If you want the default value, just don't send the option.

>  Isn't a correct SZX required e.g. for a stateless server, even if M is unset? At least all the examples set the SZX when M=0 the same as the previous blocks in the same sequence.

Yes, and the text actually is wrong (SZX is not irrelevant at all as it is still used to scale the block number into a byte offset).
Good you noticed this.  I changed it to:

     SZX does not govern the payload size if M is unset.

> - section 2 "still this size will be given as the block size even for the final block." -> a bit unclear. Maybe "still the chosen power-of-two block size will be specified in the size field of the…

I have submitted a -06 with these editorial changes.
Thank you!

Grüße, Carsten

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 23 Jan 2012 10:21:45 +0000

Thanks,

> If you want the default value, just don't send the option.

I agree, rather not two ways to say the same thing.
It's an interesting design then, that a client has no way to _not_ use a Block Option in a request. Ok for me.

Btw is there (or should there be) some mention that Block1 and Block2 MUST be included at most once in a CoAP message?

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Saturday 21 January 2012 16:06
To: Dijk, Esko
Cc: [email-masked] WG
Subject: Re: [core] New version of Block spec (Re: I-D Action: draft-ietf-core-block-05.txt)

Thanks.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 23 Jan 2012 14:57:31 +0100

> Btw is there (or should there be) some mention that Block1 and Block2 MUST be included at most once in a CoAP message?

core-coap says:

5.4.4.  Repeating Options

   Each definition of an option specifies whether it is defined to occur
   only at most once or whether it can occur multiple times.

So we indeed need to say something.

Now on page 7:

   […]
   (or the message rejected); therefore it is identified as a critical
   option.  It MUST NOT occur more than once.
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In SVN.  Will be in -07.

Thanks!

Grüße, Carsten