Subject: [core] draft-ietf-core-block-08 - size request

From: Jeroen Hoebeke <[email-masked]>
Date: Wed, 28 Mar 2012 22:13:45 +0200

Dear WG,

After giving the block draft a final reading, I discovered one minor issue that is not clear to me:

How does the server need to behave upon the reception of a size request?
- does it send back an empty response with a size option that gives the size estimate of the response? In this case, what is the response when the server does not support this option?
or
- does it send back a response with a size option giving the size estimate of the response, but with a payload already containing the first block?

It would be good to add the desired behavior to the description of the size request to avoid confusion.

Kind regards,
Jeroen

---

From: Likepeng <[email-masked]>
Date: Thu, 29 Mar 2012 09:08:00 +0000

Hi,

>-(1) does it send back an empty response with a size option that gives the size estimate of the response? In this case, what is the response when the server does not support this option?
>or
>-(2) does it send back a response with a size option giving the size estimate of the response, but with a payload already containing the first block?

We can differentiate these two cases by giving the Size a zero value or not. Here is the text from Block draft:

   o  in a request, to ask the server to provide a size estimate in the
      response ("size request").  For this usage, the value MUST be set
      to 0.

So, if Size=0, that means case 1. If Size option is empty, that means case 2.

>It would be good to add the desired behavior to the description of the size request to avoid confusion.

Agree, we should add some texts to clarify the situation. I propose to take some texts (or change it a little bit) from the Size draft to Block draft.

Here is the text from draft-li-core-coap-size-option-02.txt:

   The GET request including Size=0 is treated as a request to get the
   size of the resource representation (but not the resource payload).

   The GET request including an empty Size option is treated as a
   request to get the size of the resource representation with the
   resource payload.

   The Size option SHOULD be included for resources larger than a single
   PDU, if the Size information is available.  And it MAY be included
   for resources smaller than a single MTU.

   The Size option SHOULD be used in a POST/PUT request in the first
   Block1 Option message.  If the recipient is not capable to receive the
   data with the indicated size, the recipient MUST return a 4.13
   (Request Entity Too Large) response code to the requester, and the
   data transmission is avoided, so that the cost of the actual data
   transmission is saved.

   For a GET request with Block2, if it includes an empty Size option, the Size
   option MUST be included in the response.  If the GET request includes
   a Block2 option, the Size option SHOULD be included in the first Block2
   response.  In other cases the GET response MAY contain a Size option.

Kind Regards

Kepeng

________________________________
发件人: [email-masked] [[email-masked]] 代表 Jeroen Hoebeke [[email-masked]]
发送时间: 2012年3月29日 4:13
到: core WG
主题: [core] draft-ietf-core-block-08 - size request

Dear WG,

Kind regards,
Jeroen

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Mar 2012 11:24:15 +0200

> So, if Size=0, that means case 1. If Size option is empty, that means case 2.

Size is a uint.  Empty is zero.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 29 Mar 2012 11:39:48 +0200

On Mar 28, 2012, at 22:13, Jeroen Hoebeke wrote:

> - does it send back an empty response with a size option that gives the size estimate of the response?

No.  Is there text that suggests that?

> In this case, what is the response when the server does not support this option?

It is elective, so in this case, the result is exactly as if it had not been sent.

> - does it send back a response with a size option giving the size estimate of the response, but with a payload already containing the first block?

Yes.

If you want to keep this small, use a block size of 16 (szx = 0).

> It would be good to add the desired behavior to the description of the size request to avoid confusion.

Do you have a proposed text change?
Maybe we can add something like:

# Apart from conveying/asking for size information, the Size option has no other effect on the processing of the request or response.

Grüße, Carsten

---

From: Jeroen Hoebeke <[email-masked]>
Date: Thu, 29 Mar 2012 12:59:49 +0200

Hi Carsten,

> No.  Is there text that suggests that?

Only the name 'size request' and absence of further clarification in the text, made me think it could mean a pure size request, resulting in a response without payload and with size option.
> # Apart from conveying/asking for size information, the Size option has no other effect on the processing of the request or response.

This is clear. Maybe also add:
If the clients wants to minimize the size of the payload in the resulting response, it should add a Block2 option to the request with a small block size.

Kind regards,
Jeroen