[core] Dynlink observation attributes

Christian Amsüss <christian@amsuess.com> Wed, 26 September 2018 16:35 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E1C84130EE5 for <core@ietfa.amsl.com>; Wed, 26 Sep 2018 09:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id L_2ofZ9WxTLz for <core@ietfa.amsl.com>; Wed, 26 Sep 2018 09:35:56 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5F512958B for <core@ietf.org>; Wed, 26 Sep 2018 09:35:56 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 589BF41937; Wed, 26 Sep 2018 18:35:54 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com []) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 4B7AB6C; Wed, 26 Sep 2018 18:35:53 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2361219; Wed, 26 Sep 2018 18:35:53 +0200 (CEST)
Received: (nullmailer pid 19902 invoked by uid 1000); Wed, 26 Sep 2018 16:35:52 -0000
Date: Wed, 26 Sep 2018 18:35:52 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Michael Koster <michael.koster@smartthings.com>
Cc: core@ietf.org
Message-ID: <20180926163552.GA18946@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/jA_zWgxgd01fvwiTIgAyZTTb5HY>
Subject: [core] Dynlink observation attributes
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: Wed, 26 Sep 2018 16:36:00 -0000

Hello Michael,

as suggested in today's interim meeting, I'd like to get the discussion
on observation attributes going again.

To me, the takewaway point of today was that there can be various ways
of expressing the observation attributes; that we're happy with what the
attributes can do and their semantics, but that the current way of
persistently PUT parameters on a link is not ideal for the general use

I've left the bulk of my original mail below because I still think it
gets across the message (though some may be preaching to the choir given
the above), and stripped unrelated points into a separate thread:

> Observation attributes
> ======================
> I'd like to refer back to one of my earlierst mails on this mailing
> list at [CA2013]. The answer to "why not just observe
> </temp?pmin=10&pmax=60&st=1> as it was in earlier drafts" about caching
> was not really satisfying, given that this scheme breaks caching just as
> the original but just worse (previously, a cache would just not have a
> response ready; now, it sees an observation and thinks the value is
> current where it's actually from an observation to a client that's not
> interested in details).
> The way of PUTting empty values onto query-parameter identified
> resources is incompatible with multiple observations.
> Moreover, its use is unclear to me from reading it. The sentence "These
> query parameters MUST be treated as resources that are read using GET
> and updated using PUT" seems to indicate that they are used like this:
> | GET /temp?pmin
> | 2.05 Content
> | Payload: "0"
> (or however undefined is expressed there)
> | PUT /temp?pmin
> | Payload: "10"
> | 2.04 Changed
> But "Multiple parameters MAY be updated at the same time by including
> the values in the query string of a PUT" makes it sound like it should
> be
> | PUT /temp?pmin=10&pmax=20
> | empty payload
> | 2.04 Changed
> -- are both permissible? And if only the latter: How is this accessed
> with GET? Examples might help, but explicit words would be good too.
> Another open question is how to turn those limits off again. Would I
> just DELETE the <?pmin> resources? 
> This was all a whole lot clearer when one could observer
> | GET /temp?pmin=10&pmax=20
> and have those limits per observation without any new state introduced
> to the server -- a behavior I would still prefer to see there.
> [CA2013]: http://ietf.org/mail-archive/web/core/current/msg04270.html
> Observation attributes in bindings
> ==================================
> There are two components in this document I percieve as relatively
> separate -- the link bindings, and the limiting attributes.
> Link bindings work well on their own.
> With in-query observation attributes, there would not be any need to
> define the attributes additionally as link attributes (where, judging
> from RD discussions, it can be confusing to have both).
> Especially troublesome about the attributes is that they are not target
> attributes, but link attributes. (All other common attributes in
> link-format documents are target attributes, with the exception of
> anchor= and rel=/rev= which are core to the web linking model). That
> means that using other web link formats (eg. CoRAL, RDF; don't know
> about HSML) will have a hard time expressing those. I think that
> non-target link attributes should be limited to data that is meaningful
> on the web linking level and not for arbitrary attributes.

One closing throught: In implementations, we're often thinking of
everything that has the same path as the same resource, and query
parameters just giving details on it. CoAP's REST model does not know
this distinction -- /temp is something different than /temp?pmin=10, and
only because we said </temp>;if="core.s" we can conclude that it's
related to the /temp?pmin=10 resource.

Let us stick with this, and call /temp?pmin=10 a view on /temp, like
through a lens that blurs an image.

Best regards

This may seem a bit weird, but that's okay, because it is weird.
  -- perldata(1) about perl variables