Subject: [core] draft coap-size

From: Salvatore Loreto <[email-masked]>
Date: Sat, 5 Nov 2011 19:40:56 +0100

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

---

From: Likepeng <[email-masked]>
Date: Sat, 05 Nov 2011 20:28:36 +0000

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. 

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.

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

>  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

发件人: [email-masked] [[email-masked]] 代表 Salvatore Loreto [[email-masked]]
发送时间: 2011年11月6日 2:40
到: [email-masked]; [email-masked]
主题: [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.

1) In section 2.2 

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

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:

 
cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 6 Nov 2011 12:08:55 +0100

Hi,

thanks for answering my questions, see more in line below

cheers

-- 
Salvatore Loreto
www.sloreto.com

> The response needs to include the actual resource representation for the indicated block number.

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

> 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

---

From: TianLinyi <[email-masked]>
Date: Sun, 06 Nov 2011 13:31:41 +0000

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. 

We may need a new mechanism to indicate the current transferred block is no longer valid a new transaction is needed. 

Cheers,
Linyi

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Salvatore Loreto [[email-masked]]
发送时间: 2011年11月6日 19:08
到: Likepeng
Cc: [email-masked]
主题: Re: [core] draft coap-size

Hi,

cheers

--
Salvatore Loreto
www.sloreto.com

Cheers
/Sal

>    transmit the remaining data.

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

---

From: Likepeng <[email-masked]>
Date: Mon, 07 Nov 2011 10:02:15 +0000

Hi Salvatore,

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

>and consistent in all the spec.

Sure.

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

Hi,

cheers

--
Salvatore Loreto
www.sloreto.com

Cheers
/Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 7 Nov 2011 15:52:57 +0100

> Size option will be sent in the first block request.

is it still a possibility to send a GET request including only an empty
Size option?
and if it is so, what would be the right behavior for this possibility

Salvatore

--
Salvatore Loreto
www.sloreto.com

---

From: Likepeng <[email-masked]>
Date: Mon, 07 Nov 2011 15:29:47 +0000

Hi,

> is it still a possibility to send a GET request including only an empty Size option?  and if it is so, what would be the right behavior for this possibility.

Yes, if the GET request includes only an empty Size option without Block option, the server returns the size of the resource representation with the resource payload. 

If the resource size is bigger than one PDU, the response will contain the size of the resource and the first Block data.

So the GET processing is the same as the previous Block behavior.

To make a summary:
1. GET with Size option, without Block option:
a) Size=0, only returns size info, no payload;
b) Size is empty, returns size info, if size<PDU, returns the whole payload; if size>PDU, returns first Block;
c) Size has a value other than 0, this case is not specified in the draft. In the mailing list, there was a propoal to use this to indicate the maximum accepted size (or something similar).

2. GET with Size option, with Block option:
a) Size=0, only returns size info, no payload; this case is not specified in the draft, because I hope to add only the minimized functionality to the Block draft.
b) Size is empty, returns size info, if size<PDU, returns the whole payload; if size>PDU, returns first Block;
c) Size has a value other than 0,  this case is not specified in the draft.

3. GET without Size option:
a) If size>PDU, Size option SHOULD be included in the response.
b) If size<PDU, Size option MAY be included in the response. In this case, size is the same as the Content-Length option indicated in misc-09 draft. 

Hope it clarifies.

Thanks,
Kind Regards
Kepeng

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 8 Nov 2011 11:36:17 +0100

> b) If size<PDU, Size option MAY be included in the response. In this case, size is the same as the Content-Length option indicated in misc-09 draft.
Hi Kepeng

yes your answer clarify what you have in mind, but I think that we 
should be more careful defining the right behavior

for option #3
IMO GET without Size option must follow what specified in the 
draft-ietf-core-coap-08
a sensor can not discriminate if the GET is arriving from a client that 
understand the Size option, but didn't include it
vs a GET that is arriving from a "legacy" CoAP sensor

cheers
Sal

---

From: Likepeng <[email-masked]>
Date: Wed, 09 Nov 2011 04:59:51 +0000

Hi Salvatore,

> IMO GET without Size option must follow what specified in the draft-ietf-core-coap-08.

Yes, that is why we design this option as Elective option.

> a sensor can not discriminate if the GET is arriving from a client that understand the Size option, but didn't include it vs a GET that is arriving from a "legacy" CoAP sensor.

This is a good consideration. I think the server does not need to distinguish the two situations. The behavior for the server will be the same.

1. A GET is from a client does not understand the Size option, if the server sends the Size information acording to the principle as indicated in the draft, the client will just ignore it after receiving it. Because Size option is defined as Elective option.

2. A GET is from a client understands the Size option, if the server sends the Size information according to the principle as indicated in the draft, the client can understand the Size option correctly.

Thanks,
Kind Regards
Kepeng

---

From: ma yc <[email-masked]>
Date: Thu, 10 Nov 2011 11:45:59 +0800

Hi, Linyi

please see in line.

Thank you.
Regards
Yuanchen

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

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?