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

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 May 2011 17:14:19 +0200

There is no need to do HEAD in CoAP.

A HTTP-to-CoAP mapper can map HTTP HEAD to CoAP GET.

Of course you can argue that this is not very efficient.
I would argue that HEAD is not used enough to make optimizing this worthwhile at all.
If you have numbers to the contrary, I'd like to hear them.
(If you want to optimize it a bit, send a Block2 with SZX=0.)

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Fri, 06 May 2011 11:54:26 -0400

The use case is HTTP HEAD into a COAP network to determine the size of a 
resource.

Determien the size of a resource

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 May 2011 18:20:54 +0200

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

---

From: Thomas Herbst <[email-masked]>
Date: Fri, 6 May 2011 11:39:30 -0700

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?

tom

On 5/6/11 9:20 AM, "Carsten Bormann" <[email-masked]> wrote:

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 May 2011 23:46:37 +0200

> information about the size of a payload before making the request for that

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

---

From: Likepeng <[email-masked]>
Date: Sat, 07 May 2011 02:56:08 +0000

>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
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Carsten Bormann [[email-masked]]
发送时间: 2011年5月7日 5:46
到: Thomas Herbst
Cc: core
主题: Re: [core] Suggestions re: how to implement HEAD semantics within  COAP?

Gruesse, Carsten

---

From: Paul Duffy <[email-masked]>
Date: Sat, 07 May 2011 00:27:13 -0400

> Can you explain the use case for "HTTP HEAD into a COAP network to determine the size of a resource"?

The example is probably better expressed in the opposite direction.

A COAP based element needing to determine the size of a large resource 
before loading it from an HTTP network.

---

From: "Charles Palmer" <[email-masked]>
Date: Sat, 7 May 2011 11:25:58 +0100

I guess the Size option from draft-li-core-coap-size-option-00 could be extended such that a CoAP GET request including Size=0 is treated as a request to get the size of the resource representation (but not the resource payload) and so could be translated to and from an HTTP HEAD (and could return Content-Length to a CoAP requester).

-----Original Message-----
From: [email-masked] on behalf of Paul Duffy
Sent: Sat 07/05/2011 05:27
To: Carsten Bormann
Cc: core
Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP?

--------------------------------
Onzo is a limited company number 06097997 registered in England & Wales. The    
registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.

This email message may contain confidential and/or privileged information, and
is intended solely for the addressee(s). If you have received this email in     
error, please notify Onzo immediately. Unauthorised copying, disclosure or 
distribution of the material in this email is forbidden.
--------------------------------

---

From: Likepeng <[email-masked]>
Date: Sun, 08 May 2011 06:00:47 +0000

> I guess the Size option from draft-li-core-coap-size-option-00 could be extended such that a CoAP GET request including Size=0 is treated as a request to get the size of the resource representation…

Good suggestion. I will add this in -01, if there are no other opinions.

Thanks,

Kind Regards

Kepeng

________________________________
发件人: [email-masked] [[email-masked]] 代表 Charles Palmer [[email-masked]]
发送时间: 2011年5月7日 18:25
到: [email-masked]; Carsten Bormann
Cc: core
主题: Re: [core] Suggestions re: how to implement HEAD semantics within COAP?

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 8 May 2011 14:01:00 +0200

A couple of observations:

-- The Size Option is defined to be Elective.  That means that any usage in a request to influence the semantics of GET will also be Elective.  I think that is OK, but it calls for some additional thought.

-- Size has a similar dependency on the method that Block had before we split it in Block1/Block2.  That need not be a problem (the old Block was fine for its intended area of application), but it also means that there will be no way to provide the new semantics for controlling the responses of PUT/POST.  Probably also OK.

Generally, using the same option with two different semantics depending on its context (here: indication of the full size of a block-wise transfer vs. controlling the size of the block) requires a lot of care to ensure this doesn't bite back.  Note that the Block2 option already can control the size of the payload slice coming back from a GET; maybe we want to extend that option with the new semantics instead of Size.  I'm not sure.

Also, reading -00, I cannot reconcile

   If the Size option is specified it MUST be accurate at that time, and
   MUST 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 ...

The point of a MUST is to give one of the parties in a protocol something that this party can rely on.
The second paragraph takes the reliability of this property away again, so is appears there is no useful effect from the MUST.
If that train of thought is correct, the MUST *should* be a SHOULD.

Finally, it's probably important to consider that HTTP has developed chunked transfer-coding precisely to enable the start of a transfer *without* knowing the size in advance.  We should not expect our constrained nodes to be able do better than HTTP end-points here, so:

   The Size option is not expected to be included for small resources
   that can easily be carried in a single MTU, but SHOULD be included
   for resources larger than that.

... the SHOULD here clearly is qualified by the availability of the size.  E.g., I wouldn't want to read this as "a CoAP to HTTP mapper SHOULD retrieve the entire resource representation from HTTP if that is provided in chunked transfer-coding, in order to have a size estimate" -- instead, many mappers will best (unless there is a cached value) omit the size option.

Gruesse, Carsten

---

From: Likepeng <[email-masked]>
Date: Mon, 09 May 2011 03:24:07 +0000

Thanks for the review.

> Generally, using the same option with two different semantics depending on its context (here: indication of the full size of a block-wise transfer vs. controlling the size of the block) requires a lot of care to ensure this doesn't bite back.

They use different options, so it would be fine. That is, Size option to indicate the whole size of the resource payload, but SZX field in Block option to indicate the block size.

> If that train of thought is correct, the MUST *should* be a SHOULD.

Agree, will change it in -01.

> ..the SHOULD here clearly is qualified by the availability of the size

Will change it to "..but SHOULD be included for resources larger than that, if the size information is available."

Kind Regards
Kepeng
-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Sunday, May 08, 2011 8:01 PM
To: Likepeng
Cc: Charles Palmer; [email-masked]; core
Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP?

Gruesse, Carsten