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