[core] Review of core-interfaces-12
Christian M. Amsüss <christian@amsuess.com> Mon, 23 July 2018 09:56 UTC
Return-Path: <christian@amsuess.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 49919130DEB; Mon, 23 Jul 2018 02:56:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.921
X-Spam-Level:
X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979] autolearn=no 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 mcEh3po8CrJM; Mon, 23 Jul 2018 02:56:02 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FC49130DE8; Mon, 23 Jul 2018 02:56:01 -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 F14B140936; Mon, 23 Jul 2018 11:55:58 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 550B026; Mon, 23 Jul 2018 11:55:57 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:41a6:be99:4801:9fb1]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id EBCA479; Mon, 23 Jul 2018 11:55:56 +0200 (CEST)
Received: (nullmailer pid 21372 invoked by uid 1000); Mon, 23 Jul 2018 09:55:56 -0000
Date: Mon, 23 Jul 2018 11:55:56 +0200
From: "Christian M. Amsüss" <christian@amsuess.com>
To: Core WG mailing list <core@ietf.org>, draft-ietf-core-interfaces@ietf.org
Cc: draft-keranen-core-senml-fetch@ietf.org
Message-ID: <20180723095555.GA5571@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM"
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5GCJ-j4WAeIvW8-L-xEhkSjS19w>
Subject: [core] Review of core-interfaces-12
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 23 Jul 2018 09:56:04 -0000
Hello core-interfaces authors, these are my views on core-interfaces-12 as promised in London: Gradual reveal and RFC6690 ========================== What are the supposed semantics of the links in examples 3 and 4 of 3.6? If, being fetched from a collection at /coll/, they are * </coll/temp>;anchor="/coll/" and </coll/temp>;anchor="/sen/", respectively, then you're not using RFC6690 link format but Modernized Link Format as described in resource-directory; if they are * </coll/temp>;rt="temperature" and </sen/temp>;anchor="/sen/", then you're using the mental model I had of RFC6690 before Jim discovered in London that RFC6690 Section 2.1 says Origin with a capital O. My recommendation is to explicitly use a RFC8288 compatible interpretation by saying that all link-format documents on the core interfaces are to be interpreted as Modernized Link Format (better names still welcome) as described in resource-directory. (The second best option IMO would be to follow RFC6690 to the letter and have all links relative to the host root directory aka Origin). SenML and base names ==================== The SenML components appear to assume that the Base Name (bn) is implied to be the obtained document's URI; this is no longer the case since SenML -08[1]. Thus, a batch (like the example in 4.2) would need to have a "bn":"coap://example.com/s/" attribute in its first entry. Linked batches can not have their requested URI in that place (as SenML rules are only about string concatenation; if applications think in URIs, they must accomodate that), so their bn must be "coap://example.com". Thus, appending "/s/light" gives a good URI again. [1]: Until -07, it said that "If the object is a representation resulting from the request of a URI [RFC3986], then in the absence of the Base Name attribute, this URI is used as the default value of Base Name. Assorted ======== * Updating links with merge-patch and PATCH ("Links in the collection MAY be"): Is this fully thought through? In RD we decided to delay that part until someone figures out how to correctly manipulate parts of a collection. The approach of putting query filtering in is interesting, but doesn't paint a full picture to me. With query filtering, can I delete a single link from an lb using `DELETE /linkedbatch/?href=/s/1`? Is the client in a linked batch supposed to provide any attributes to the links? (If not, what changes warranting a merge-patch can there be made other than adding and removing links?) * 3.7: Whether a collection implements link filtering should be discoverable in some way IMO. How about additional if="core.filter" on those that do? If that is not get advertised, the least that should be done is to say that query parameters MUST be ignored by collections if querying is not supported. (As it is with .well-known/core: Support is optional, but if a GET /.well-known/core?rt=foo comes along and the server can't filter, it does the safe thing and returns the complete set.) That's for reading; PUT/POSTing to a filtered query without filter support should be 4.02 Bad Option. * Actuators: Is every actuator supposed to support some POSTs? If not, I'd put the POST in Table 2 as optional. Similarly: May an actuator be write-only, and return Method not supported to a GET? * Security considerations: A linked batch can write to arbitrary resources on the server; considerations say something about whether it's the creator of the link batch or the writer who needs to have authority to write to linked resources. (It's a bit like with dynlinks, with only moderate mitigation by foreign links being forbidden. Writing </firmware> to a linked batch and then putting a large application/octet-stream there can still go very bad.) Do I read this right? ===================== might be illustrated or made more explicit * 3.5 query filtering (when applied to the items): I like this idea; as I understand, I could do on a batch /b/1/ containing <light1>;rt="some.rgb";if="core.a", <light2>;rt="some.rgb";if="core.a", <light3>;rt="some.dimmer";if="core.a" do a PUT /b/1/?rt=some.rgb, payload #ffff00, which would set all the RGB leds to yellow but leave light3 unaffected? * In the example of Figure 1, if I did not want to reveal all the /a/ subresources in a step, would there be anything wrong in saying it's if="core.b core.ll"? (Just to verify our common understanding of the text). Small stuff =========== * "with a Link List /d containing": It's /d/ in the above example * 3.4 mentions link-format+json, it should probably do the same with link-format+cbor The overall document, esp. having batches, parameters and actuators, has been stable for quite some time, so I expect that the remaining details (above and hopefully from other reviewers) can be worked out swiftly fo finally release this document. I'd suggest it to be reviewed by authors of SenML fetch/patch; it appears to me that there is some overlap to be considered. Best regards Christian -- I shouldn't have written all those tank programs. -- Kevin Flynn
- [core] Review of core-interfaces-12 Christian M. Amsüss