Re: [core] 答复: draft coap-size

Hi, Linyi

please see in line.

Thank you.
Regards
Yuanchen

在 2011年11月6日 下午9:31，TianLinyi <tianlinyi@huawei.com> 写道：
> Hi, all
>
> I believe the size option should be used in case the data is not changing during the whole transaction. If it changes, the previously transferred block may be useless. This happens regardingless whether the size option is accurate or not.
>
> For example, if the coap server is capturing a video when you initial the block tranfer at 18:00 GMT you get a video until that time. Even though the video is growing you will only get that snapshot. When you initial a new block transfer you will get a new one.

I am not sure about this scenario.

You plan to use CoAP to carry video as payload?
In current CoAP spec the media type does not
include the media stream. Do you intend to
add new media type or i miss something?

>
> We may need a new mechanism to indicate the current transferred block is no longer valid a new transaction is needed.
>
> Cheers,
> Linyi
>
> ________________________________________
> 发件人: core-bounces@ietf.org [core-bounces@ietf.org] 代表 Salvatore Loreto [salvatore.loreto@ericsson.com]
> 发送时间: 2011年11月6日 19:08
> 到: Likepeng
> Cc: core@ietf.org
> 主题: 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
>>
>> 发件人: core-bounces@ietf.org [core-bounces@ietf.org] 代表 Salvatore Loreto [salvatore.loreto@ericsson.com]
>> 发送时间: 2011年11月6日 2:40
>> 到: core@ietf.org; draft-li-core-coap-size-option@tools.ietf.org
>> 主题: [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
>>
>
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>