Re: [core] More precision about CoAP Observe with FETCH

Simon Bernard <contact@simonbernard.eu> Tue, 29 June 2021 09:58 UTC

Return-Path: <contact@simonbernard.eu>
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 E24263A2D7F for <core@ietfa.amsl.com>; Tue, 29 Jun 2021 02:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level:
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.338, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPex1AFZ2Lxp for <core@ietfa.amsl.com>; Tue, 29 Jun 2021 02:58:02 -0700 (PDT)
Received: from smtpout1.mo529.mail-out.ovh.net (smtpout1.mo529.mail-out.ovh.net [178.32.125.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B062C3A2DA5 for <core@ietf.org>; Tue, 29 Jun 2021 02:57:57 -0700 (PDT)
Received: from mxplan6.mail.ovh.net (unknown [10.109.156.3]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 7BB31B13D4AE; Tue, 29 Jun 2021 11:57:54 +0200 (CEST)
Received: from simonbernard.eu (37.59.142.96) by DAG3EX2.mxp6.local (172.16.2.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.10; Tue, 29 Jun 2021 11:57:53 +0200
Authentication-Results: garm.ovh; auth=pass (GARM-96R0016d9b4aaa-3370-44c5-9c4d-76a3cebc5b21, 41D70A9821A63A1868E3E232E7381517373EE788) smtp.auth=contact@simonbernard.eu
X-OVh-ClientIp: 91.174.163.99
To: Jon Shallow <supjps-ietf@jpshallow.com>, <core@ietf.org>
References: <ffb046bf-ba0b-61de-5a8f-8e35a0440fc1@simonbernard.eu> <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com>
From: Simon Bernard <contact@simonbernard.eu>
Message-ID: <6c9eed0f-7d66-812b-abd8-111162c0e7b3@simonbernard.eu>
Date: Tue, 29 Jun 2021 11:57:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0
MIME-Version: 1.0
In-Reply-To: <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com>
Content-Type: multipart/alternative; boundary="------------7B2457A49FD63164CD9E02D0"
Content-Language: en-US
X-Originating-IP: [37.59.142.96]
X-ClientProxiedBy: DAG3EX1.mxp6.local (172.16.2.21) To DAG3EX2.mxp6.local (172.16.2.22)
X-Ovh-Tracer-GUID: e5bdc3af-51b6-4ccb-81f4-bf6425719a1f
X-Ovh-Tracer-Id: 17195306330418657434
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeehiedguddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtghisegrtderredtfeejnecuhfhrohhmpefuihhmohhnuceuvghrnhgrrhguuceotghonhhtrggtthesshhimhhonhgsvghrnhgrrhgurdgvuheqnecuggftrfgrthhtvghrnhepfedvffehfeegheffieegueetieekfeelvefhvdfgvdffvefhhffhjedvteethfegnecuffhomhgrihhnpehivghtfhdrohhrghenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddrleeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepmhigphhlrghniedrmhgrihhlrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegtohhnthgrtghtsehsihhmohhnsggvrhhnrghrugdrvghupdhrtghpthhtohepshhuphhjphhsqdhivghtfhesjhhpshhhrghllhhofidrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/axDI68CSvLf6uEBsZU7a2vNbh1M>
Subject: Re: [core] More precision about CoAP Observe with FETCH
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 29 Jun 2021 09:58:07 -0000

Thx a lot for this clarification.

Le 29/06/2021 à 11:45, Jon Shallow a écrit :
>
> Hi Simon,
>
> As per https://datatracker.ietf.org/doc/html/rfc8132#section-2 
> <https://datatracker.ietf.org/doc/html/rfc8132#section-2> the FEETCH 
> request body is a part of the cache key.
>
>    Depending on the response code as defined by [RFC7252 
> <https://datatracker.ietf.org/doc/html/rfc7252>], the response
>
>    to a FETCH request is cacheable; the request body is part of the
>
>    cache key.  Specifically, 2.05 (Content) response codes (the
>
>    responses for which are cacheable) are a typical way to respond to a
>
>    FETCH request.  (Note that this aspect differs markedly from
>
>    [HTTP-SEARCH 
> <https://datatracker.ietf.org/doc/html/rfc8132#ref-HTTP-SEARCH>] and 
> also that caches that cannot use the request
>
>    payload as part of the cache key will not be able to cache responses
>
>    to FETCH requests at all.)  The Max-Age option in the response has
>
>    equivalent semantics to its use in a GET.
>
> So, different payloads would create different cache keys and hence 
> individually be unique.
>
> Regards
>
> Jon
>
> *From:*Simon Bernard [mailto: contact@simonbernard.eu]
> *Sent:* 29 June 2021 10:19
> *To:* core@ietf.org WG
> *Subject:* [core] More precision about CoAP Observe with FETCH
>
> Hi all,
>
>   The PATCH and FETCH Methods for the Constrained Application Protocol 
> (CoAP) (RFC8132 <https://datatracker.ietf.org/doc/html/rfc8132>) says 
> that FETCH can be used with RFC7641 
> <https://datatracker.ietf.org/doc/html/rfc7641> (Observing Resources 
> in CoAP)
>
>     2.4 <https://datatracker.ietf.org/doc/html/rfc8132#section-2.4>. 
>     Working with Observe
>
>         The Observe option [RFC7641  <https://datatracker.ietf.org/doc/html/rfc7641>] can be used with a FETCH request as it
>
>         can be used with a GET request
>
>   But "CoAP Observe" seems to be designed with a "GET without payload" 
> in mind.
>   E.g. it says :
>
>     3.1 <https://datatracker.ietf.org/doc/html/rfc7641#section-3.1>.
>      Request
>
>         A client registers its interest in a resource by issuing a GET
>
>         request with an Observe Option set to 0 (register).  If the server
>
>         returns a 2.xx response that includes an Observe Option as well, the
>
>         server has successfully added an entry with the client endpoint and
>
>         request token to the list of observers of the target resource, and
>
>         the client will be notified of changes to the resource state.
>
>         Like a fresh response can be used to satisfy a request without
>
>         contacting the server, the stream of updates resulting from one
>
>         observation request can be used to satisfy another (observation or
>
>         normal GET) request if the target resource is the same.*A client*
>
>     *   MUST aggregate such requests and MUST NOT register more than
>     once for*
>
>     *   the same target resource.  The target resource is identified
>     by all*
>
>     *   options in the request that are part of the Cache-Key. This
>     includes,*
>
>     *   for example, the full request URI and the Accept Option.*   
>
> The target resource is not identified by the payload.  So 2 FETCH 
> requests on same resource with 2 different payload seem to not be 
> allowed ?
>
> Is it intended or just an oversight ? if this is intended, is there 
> any particular reason about this ?
>
> Simon
>