Re: [core] Dynlink observation attributes

Michael Koster <> Tue, 06 November 2018 08:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA60D12D4E9 for <>; Tue, 6 Nov 2018 00:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fn51THPaHPcg for <>; Tue, 6 Nov 2018 00:06:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B25E3128A5C for <>; Tue, 6 Nov 2018 00:06:01 -0800 (PST)
Received: by with SMTP id f24so10614103otl.5 for <>; Tue, 06 Nov 2018 00:06:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TjJ9SU2lds+wu9h99kPzHKmDXTuyzbmYP9KFlPip9ps=; b=cZn9tw7ejNevTwq1ndEZEqg1S3ZGBrqQSoKvmVGxuWOUxIb0j/tD0yL5HaMLUcPN9c mR2LbzdxsBK4jbGKWL1ykGVmF3qJlDeYLidBYAPen52pgKMGqMDNisbb7UHOulAvnjEN fhclH8H4i4VKFPDTswmwHdK+FwvvAyrhJp/LVa2OSURVzODAk7pqONNAnPREM2GEQ0TY MMtoi6mQD+OefgXJQE+7+FYc9dSddoG55yT6Zvp/BDlQtpoAzvH6e0iECPsvxDJGvo8s Pi2P8gtgUevSya6kKp+lBjWP3juBJUae/mnG0L7MIz7FSIz+PW8CiEZDxRGhym+72dhh /hRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TjJ9SU2lds+wu9h99kPzHKmDXTuyzbmYP9KFlPip9ps=; b=L/jUEckb3gToD2Sb2us1ATosxLk0kg/MlsoLpebiBkUUcrKr5pxErdE8+XDXsi6NSC uMcgr3jTyrZYgBVHCEKY6Gw0rnLHtn9lz+GXXCZOjKQeuc7G10/QDQ5FsGEr3W8GtIgI u7u3iBl+Nke1rmvWIWJRT/psqxO5VSOgAVG9xnw/mr5M6dUM4RdxCtygJ5YFmUpvowlM pSpAhscquEyssoJASJEnfozeBrhwVVQlcZtkDoLFJiYtd194S1h/bk9CJZsKCjLwUPYH W0tbA+I2BSOgX9gsBrq2hmgVi+l9ps8FTIS0A6qfrztiuj5rDpPnUwUafmum/8RI6xnB UQHQ==
X-Gm-Message-State: AGRZ1gIpHY7QhOQQ7UsFlyzXVCCUSPYSMQcDVTyPUJ6Wdf0QPahAWva6 ZHzmMv4IdkIVLvKCHrgnmFbyQg==
X-Google-Smtp-Source: AJdET5f2j3YNq0HZ59KU79rtU/GTuuEcC9UgZUNi4EuDHWrJtQoxPWz+uVYVjZ4Eid8PXlZ1rjOLxQ==
X-Received: by 2002:a9d:3d0:: with SMTP id f74mr14805183otf.52.1541491560816; Tue, 06 Nov 2018 00:06:00 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id t132-v6sm141775oih.37.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Nov 2018 00:06:00 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Michael Koster <>
In-Reply-To: <>
Date: Tue, 6 Nov 2018 00:05:57 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= <>, Bill Silverajan <>, "" <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
Subject: Re: [core] Dynlink observation attributes
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Nov 2018 08:06:05 -0000

Hi Christian,

I have finally read through these notes again and thought through the questions, and I have some comments as well as some general re-think.

I am convinced that we need to support observe attributes as query parameters to an observe request, and include them in the request caching. This makes sense as an application pattern and as a sub-pattern for dynlinks (below).

The modified URI may be thought of as a newly defined resource that exposes a coarser grained dynamic representation of the same variable indicated by the other URI parameters. I haven't fully thought through the caching issue with etags and lifetimes, but it seems like there will be ony one set of parameters feeding any given cached resource. The notifications should be cacheable.

I am also convinced that the idea of storing parameters on PUT and returning them on GET is hard to work out, and I agree we need to rethink that part. I believe we were trying to find a way to make the parameters themselves readable but there are other ways to support this, like in a dynlink.

On that, I believe that the use of target attributes in a dynlink is quite reasonable if we consider that the target of the link is always the source of the transfer when rel=boundto, and that we always use the observe mechanism as an architectural model => they are always observe attributes, and they apply to the target of the link which is hte source of the transfer.

The "native" case is simply an optimization and not an architecture permutation. A practical implementation may re-use the observe mechanism for local transers. 

Note that using a dynlink makes the observe parameters visible and gives the observe relationship an affordance.

Note also that the "bind" attribute is not strictly needed if we apply these other constraints, as you point out. We may always assume observe as an architectural model. This can be generalized to allow the link to be stored anywhere that a client function can be implemented, especially useful if we don't want to modify existing servers. 

Not sure if we need polling but if we do, it's probably not the same relation as "boundto". The transfer would likely be from source to target like rel=polls, as in "target polls context". Only one attribute of poll interval could be supported, and of course the others could be modeled on observers of the target resource after the polling, using the algorithm. 

Many of your text comments can be resolved if we make these simplifications. 

We do not need to include the dysfunctional LWM2M "empty put with query" method at all, or maybe as an appendix and negative example.

In the draft we can describe the observe attribute first, then describe the use in dynlinks, then describe a link table example implementation. I think a lot of the confusion can be alleviated this way, and we can focus on preferred patterns.

Does this make sense? I could write up a rough strawman draft with the changes.

This also tracks my implementation approach. I have a third method of storing the parameters as static variables for the resource, but that's mostly a refactoring optimization of the binding table where there is only one destination e.g. LPWAN link to a device.

Does this all make sense?


> On Sep 26, 2018, at 9:35 AM, Christian Amsüss <> wrote:
> 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
> case.
> 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]:
>> 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
> Christian
> -- 
> This may seem a bit weird, but that's okay, because it is weird.
>  -- perldata(1) about perl variables
> _______________________________________________
> core mailing list