Re: [core] Suggestions re: how to implement HEAD semantics within COAP?

> There is also a proposal to provide an Option for CoAP to carry size information, draft-li-core-coap-size-option-00.txt -- we haven't had a discussion yet on whether this Option should be standardized or not.
>If size is indeed needed, Kepeng's draft may be the way to go.

Yes, people who have interest on this issue can review my draft and provide feedback:
 http://tools.ietf.org/id/draft-li-core-coap-size-option-00.txt

Thanks,
Kind Regards
Kepeng
________________________________________
发件人: core-bounces@ietf.org [core-bounces@ietf.org] 代表 Carsten Bormann [cabo@tzi.org]
发送时间: 2011年5月7日 5:46
到: Thomas Herbst
Cc: core
主题: Re: [core] Suggestions re: how to implement HEAD semantics within  COAP?

On May 6, 2011, at 20:39, Thomas Herbst wrote:

> Carsten -
>
> Are you suggesting there is no value in a constrained device having
> information about the size of a payload before making the request for that
> payload?

No, I'm not suggesting that -- that's exactly why link-format has the sz attribute.
There is also a proposal to provide an Option for CoAP to carry size information, draft-li-core-coap-size-option-00.txt -- we haven't had a discussion yet on whether this Option should be standardized or not.

I'm just not seeing that many HEAD requests out there outside link checkers/crawlers/performance monitors.

I this specific context, I'm trying to understand the use-case where somebody from the HTTP side (non-/less-constrained) would want to request through to the CoAP side to get a representation size first, instead of simply getting the resource representation.

Is it worth spending energy on supporting a HEAD-style request in CoAP?
So far, all indications have been that GET does what's needed, as CoAP resource representations are small.
If they aren't, you are getting the first block only (which is helped with Block2(SZX=0)); this contains crucial information such as Content-Type, just not size.
If size is indeed needed, Kepeng's draft may be the way to go.
But there never seemed to be a need for an outright HEAD in CoAP; this would be irrelevant optimization.
That's why I'm asking for use-cases -- theoretical needs are irrelevant for justifying the additional complexity.

Gruesse, Carsten

>
> tom
>
> On 5/6/11 9:20 AM, "Carsten Bormann" <cabo@tzi.org> wrote:
>
>> On May 6, 2011, at 17:54, Paul Duffy wrote:
>>
>>> The use case is HTTP HEAD into a COAP network to determine the size of
>>> a resource.
>>
>> HTTP HEAD gives you a content-length only if HTTP GET would have given
>> you a content-length.
>> So this usage of HTTP HEAD is a bit on thin ice on the HTTP side already.
>>
>> Can you explain the use case for "HTTP HEAD into a COAP network to
>> determine the size of a resource"?
>> Why would you ever want to do that?
>> And does this use case occur often enough to warrant any optimization?
>>
>> Gruesse, Carsten
>>
>> _______________________________________________
>> 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