Re: [core] draft coap-size

[Likepeng <[e-mail]>]

Hi Salvatore,

>so you mean that a GET request including an empty Size option (or a
>Size=0) will always include some payload
>(i.e. the first block of the resource representation) or what...

If the GET request only includes Block option, server will return the indicated Block.

If the GET request includes Block option and an empty Size option (or Size=0), the
server will return the Size of the whole resource and the requested Block. Usually the
Size option will be sent in the first block request.

So, in this way, the added Size option will not affact the normal block behavior.

If this sounds reasonable, I will revise the draft to make it clear.

>I am OK with whatever you decide, but that should be clear in the text
>and consistent in all the spec.

Sure.

Thanks,
Kind Regards
Kepeng
________________________________________
发件人: Salvatore Loreto [[e-mail]]
发送时间: 2011年11月6日 19:08
到: Likepeng
Cc: [e-mail]
主题: Re: [core] draft coap-size

Hi,

thanks for answering my questions, see more in line below

cheers

--
Salvatore Loreto
www.sloreto.com



On 11/5/11 9:28 PM, Likepeng wrote:
> 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.

so you mean that a GET request including an empty Size option (or a
Size=0) will always include some payload
(i.e. the first block of the resource representation) or what...

I am OK with whatever you decide, but that should be clear in the text
and consistent in all the spec

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

I don't think is an implementation recommendation,
IMO it should completely clear what happens when the Size changes during
a transfer (i.e. GET request)
for example the server could include in one of the answer transferring
one of the blocks the new Size...
however it is not clear when the Size changes if the changes in the
resource are only at the end of it...
it can also happen that the changes have effected some of the blocks
already transmitted
so what would be the behavior in this case


Cheers
/Sal

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