Re: [core] SenML FETCH/PATCH without globally unique names
Christian Amsüss <christian@amsuess.com> Wed, 06 March 2019 18:27 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 B57DA129A87 for <core@ietfa.amsl.com>; Wed, 6 Mar 2019 10:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7aiS4eqXevIX for <core@ietfa.amsl.com>; Wed, 6 Mar 2019 10:27:29 -0800 (PST)
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 E938F130FE5 for <core@ietf.org>; Wed, 6 Mar 2019 10:27:28 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 5B55442ED1; Wed, 6 Mar 2019 19:27:25 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id A15C036; Wed, 6 Mar 2019 19:27:23 +0100 (CET)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 6EE346A; Wed, 6 Mar 2019 19:27:23 +0100 (CET)
Received: (nullmailer pid 13829 invoked by uid 1000); Wed, 06 Mar 2019 18:27:23 -0000
Date: Wed, 06 Mar 2019 19:27:22 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Ari Keränen <ari.keranen@ericsson.com>
Cc: core WG <core@ietf.org>
Message-ID: <20190306182721.GA12162@hephaistos.amsuess.com>
References: <bd978d78-bc3a-b1a4-af9f-7ea336d23d38@ericsson.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ew6BAiZeqk4r7MaW"
Content-Disposition: inline
In-Reply-To: <bd978d78-bc3a-b1a4-af9f-7ea336d23d38@ericsson.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/24ge5si92uMLKatDKjfp2dvIvlI>
Subject: Re: [core] SenML FETCH/PATCH without globally unique names
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, 06 Mar 2019 18:27:32 -0000
Hello Ari & WG, On Wed, Mar 06, 2019 at 03:03:06PM +0000, Ari Keränen wrote: > One issue on SenML FETCH/PATCH that came up during the joint IETF / OMA > meeting was that it would be useful to be able to use PATCH payload > names without the "globally unique prefix". > > [...] > > However, when SenML (i)PATCH is applied, the context is always known by > the receiver since the receiver is hosting the resources that are being > patched. as pointed out in today's interim, I think that makes it hard for the server to tell whether the client is thinking strings (nothing to prefix) or URIs (please prefix canonical(?) URI). I'd suggest the addition of an extension that makes the desired prefixing explicit: [{"bprefix-uribase_": true, "bn":"/3303/0/", "n":"5700","v":22.4}, {"n":"5601","v":12.2}, {"n":"5602","v":34.2}, {"bn":"/3303/1/", "n":"5700","v":18.2}, {"n":"5601","v":9.2}, {"n":"5602","v":27.2}] This would set the name of all records where it's set (by virtue of having a "b", or being a document property that can only sit in the first record) to be prefixed with the Base URI according to RFC 3986 Section 5.1. (Or resolved-relative-to, I don't care any more; good choices of URIs make this moot). Applications that Know What They're Doing (like LwM2M PATCHing) can set this, and by virtue of the trailing underscore, an application that doesn't have a well-established base URI can't use that. The extension would be independent of the used method, so could be used in a PUT or even GET as well. (In a semi-related note, I'm not 100% sure that the Base URI of a PATCH payload is actually the request's URI because RFC3986 talks of the "URI used to *retrieve* the entity"; who feels qualified to answer this?) An easy alternative would be the introduction of a static prefix by the same extension mechanism ({"bprefix_": "urn:dev:..."}) that effectively builds a two-level base name. Not simple, but would achieve the same compression for large messages. BR Christian -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
- [core] SenML FETCH/PATCH without globally unique … Ari Keränen
- Re: [core] SenML FETCH/PATCH without globally uni… Jim Schaad
- Re: [core] SenML FETCH/PATCH without globally uni… Carsten Bormann
- Re: [core] SenML FETCH/PATCH without globally uni… Christian Amsüss