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

Simon Bernard <contact@simonbernard.eu> Tue, 29 June 2021 10:13 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 8E3EA3A2E50 for <core@ietfa.amsl.com>; Tue, 29 Jun 2021 03:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.225
X-Spam-Level:
X-Spam-Status: No, score=-2.225 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, T_SPF_TEMPERROR=0.01, 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 641jpgRrV69r for <core@ietfa.amsl.com>; Tue, 29 Jun 2021 03:13:41 -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 4FC523A2E4C for <core@ietf.org>; Tue, 29 Jun 2021 03:13:40 -0700 (PDT)
Received: from mxplan6.mail.ovh.net (unknown [10.109.146.170]) by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 37C0DB13E5F7; Tue, 29 Jun 2021 12:13:39 +0200 (CEST)
Received: from simonbernard.eu (37.59.142.95) 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 12:13:38 +0200
Authentication-Results: garm.ovh; auth=pass (GARM-95G001bdb97ab5-60c5-4bd4-9cf8-d9f031731961, 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: <af03579d-e6e8-0b9e-5ef9-b65e2562e100@simonbernard.eu>
Date: Tue, 29 Jun 2021 12:13:36 +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="------------5FD1D537C80EF07C77FB4F48"
Content-Language: en-US
X-Originating-IP: [37.59.142.95]
X-ClientProxiedBy: DAG7EX2.mxp6.local (172.16.2.62) To DAG3EX2.mxp6.local (172.16.2.22)
X-Ovh-Tracer-GUID: 2203c85a-c40c-41cc-b48d-0e544e183491
X-Ovh-Tracer-Id: 17461018707691976858
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduledrfeehiedguddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtghisegrtderredtfeejnecuhfhrohhmpefuihhmohhnuceuvghrnhgrrhguuceotghonhhtrggtthesshhimhhonhgsvghrnhgrrhgurdgvuheqnecuggftrfgrthhtvghrnhepfedvffehfeegheffieegueetieekfeelvefhvdfgvdffvefhhffhjedvteethfegnecuffhomhgrihhnpehivghtfhdrohhrghenucfkpheptddrtddrtddrtddpfeejrdehledrudegvddrleehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepmhigphhlrghniedrmhgrihhlrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegtohhnthgrtghtsehsihhmohhnsggvrhhnrghrugdrvghupdhrtghpthhtohepshhuphhjphhsqdhivghtfhesjhhpshhhrghllhhofidrtghomh
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5JFnfzNbpBBcx5W2No2SPOVIX1k>
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 10:13:48 -0000

Hi Jon,

   Another question related to this topic (FETCH + Observe)

   For an Active Cancel Observe request, RFC7641 says 
(https://datatracker.ietf.org/doc/html/rfc7641#section-3.6):

>     In some circumstances, it may be desirable to cancel an observation
>     and release the resources allocated by the server to it more eagerly.
>     In this case, a client MAY explicitly deregister by issuing a GET
>     request that has the Token field set to the token of the observation
>     to be cancelled and includes an Observe Option with the value set to
>     1 (deregister).  All other options MUST be identical to those in the
>     registration request except for the set of ETag Options.  When the
>     server receives such a request, it will remove any matching entry
>     from the list of observers and process the GET request as usual.

In case of usage of FETCH with payload. Should we also sent the payload 
used to establish the observe relation in this "cancel request" ?

Simon

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
>