Re: [core] draft coap-size

[Likepeng <[e-mail]>]

Hello Salvatore,

> I support the definition of the Size option as I think it is a useful option to be used in conjunction with Block. 
> About the inclusion/merge of it in Block draft I don't care.

Thanks for the review and the support. 
I would prefer to be merged with Block draft, but if the WG decides to be separate, that is also fine to me.

>1) In section 2.2 
>   The GET request including Size=0 is treated as a request to get the
>   size of the resource representation (but not the resource payload).
>this is a duplication as you can already obtain the size of the resource using the Link Forma "sz" attribute.

Yes, but the resource size got from "sz" attribute is not accurate.

>more the above paragraph is not fully consistent with the sentence in Section 4.2
>   For a GET request, if it includes an empty Size option, the Size
>   option MUST be included in the response.
>the above sentence does not specify if the response include the actual resource representation or not.

The response needs to include the actual resource representation for the indicated block number.
I will fix the text. 

>2) the following two paragraphs in Section 2.2 are not completely clear at least to me:

>   If the Size option is specified it SHOULD be accurate at that time,
>   and SHOULD NOT be an estimate.

>   But due to the dynamic change of the resource data, the Size may not
>   be accurate.  If the value of Size option is not the same as the
>   actual transmitted data, the recipient MUST take the size of the
>   actual transmitted data as accurate, and ignore the Size option.  In
>   case that the recipient gets all the data but it is still smaller
>   than the announced Size, the recipient SHOULD stop the transmission.
>   If the recipient finds out the transmitted data reaches the Size
>   limit, and there's more data left, the recipient SHOULD continue to
>  transmit the remaining data.

I mean, for the dynamic data, during the transmission, the resource size may be changed.

I can revise the text to say:
If the Size option is specified, it MUST be accurate at that time.

And remove the second paragraph, because it is more like the implementation recommendation or strategy.

Kind Regards
Kepeng

发件人: [e-mail] [[e-mail]] 代表 Salvatore Loreto [[e-mail]]
发送时间: 2011年11月6日 2:40
到: [e-mail]; [e-mail]
主题: [core] draft coap-size


Hi there

I have read the 02 version of the draft 
and I support the definition of the Size option as I think it is a useful option to be used in conjunction with Block.
About the inclusion/merge of it in Block draft I don't care.

some comments on the draft:

1) In section 2.2 


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

this is a duplication as you can already obtain the size of the resource using the Link Forma "sz" attribute.

more the above paragraph is not fully consistent with the sentence in Section 4.2


   For a GET request, if it includes an empty Size option, the Size
   option MUST be included in the response.

the above sentence does not specify if the response include the actual resource representation or not.


2) the following two paragraphs in Section 2.2 are not completely clear at least to me:


   If the Size option is specified it SHOULD be accurate at that time,
   and SHOULD NOT be an estimate.


   But due to the dynamic change of the resource data, the Size may not
   be accurate.  If the value of Size option is not the same as the
   actual transmitted data, the recipient MUST take the size of the
   actual transmitted data as accurate, and ignore the Size option.  In
   case that the recipient gets all the data but it is still smaller
   than the announced Size, the recipient SHOULD stop the transmission.
   If the recipient finds out the transmitted data reaches the Size
   limit, and there's more data left, the recipient SHOULD continue to
   transmit the remaining data.
 
cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com