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

Jon Shallow <supjps-ietf@jpshallow.com> Tue, 29 June 2021 12:15 UTC

Return-Path: <supjps-ietf@jpshallow.com>
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 C6FA03A3271 for <core@ietfa.amsl.com>; Tue, 29 Jun 2021 05:15:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 uW7cFZMUMk5K for <core@ietfa.amsl.com>; Tue, 29 Jun 2021 05:15:30 -0700 (PDT)
Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 ED89F3A3270 for <core@ietf.org>; Tue, 29 Jun 2021 05:15:29 -0700 (PDT)
Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from <jon.shallow@jpshallow.com>) id 1lyCeD-0004FW-2I; Tue, 29 Jun 2021 13:15:25 +0100
From: "Jon Shallow" <supjps-ietf@jpshallow.com>
To: "'Simon Bernard'" <contact@simonbernard.eu>, <core@ietf.org>
References: <ffb046bf-ba0b-61de-5a8f-8e35a0440fc1@simonbernard.eu> <013501d76ccb$8e2be040$aa83a0c0$@jpshallow.com> <af03579d-e6e8-0b9e-5ef9-b65e2562e100@simonbernard.eu>
In-Reply-To: <af03579d-e6e8-0b9e-5ef9-b65e2562e100@simonbernard.eu>
Date: Tue, 29 Jun 2021 13:15:36 +0100
Message-ID: <01a601d76ce0$7795f770$66c1e650$@jpshallow.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A7_01D76CE8.D95D93C0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQICowpRfhMxcn6CYMw9eR2mIOGlfQIXqNQbAnRGGO6qsBrR4A==
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/iJPpWyGa7t3ivSXQkYUHmDjVp44>
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 12:15:35 -0000

Hi Simon,

 

Yes, because it is a part of the cache-key, you also need to send the payload as well for the Observe cancel is my understanding.

 

Regard

 

Jon

 

From: Simon Bernard [mailto: contact@simonbernard.eu] 
Sent: 29 June 2021 11:14
To: Jon Shallow; core@ietf.org
Subject: Re: [core] More precision about CoAP Observe with FETCH

 

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 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