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

Carsten Bormann <cabo@tzi.org> Fri, 06 May 2011 21:46 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9396E0852 for <core@ietfa.amsl.com>; Fri, 6 May 2011 14:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.22
X-Spam-Level:
X-Spam-Status: No, score=-106.22 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUEfDoQxoHZd for <core@ietfa.amsl.com>; Fri, 6 May 2011 14:46:53 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 75FA7E079C for <core@ietf.org>; Fri, 6 May 2011 14:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p46Lkdt8003710; Fri, 6 May 2011 23:46:39 +0200 (CEST)
Received: from [192.168.217.101] (p5B3E6398.dip.t-dialin.net [91.62.99.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B2658994; Fri, 6 May 2011 23:46:38 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <C9E98E13.A74D%therbst@silverspringnet.com>
Date: Fri, 06 May 2011 23:46:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <FE8FCF1B-02E5-4328-9DD5-B487A237C0DF@tzi.org>
References: <C9E98E13.A74D%therbst@silverspringnet.com>
To: Thomas Herbst <therbst@silverspringnet.com>
X-Mailer: Apple Mail (2.1084)
Cc: core <core@ietf.org>
Subject: Re: [core] Suggestions re: how to implement HEAD semantics within COAP?
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/core>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2011 21:46:54 -0000

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