Subject: [core] SenML FETCH/PATCH without globally unique names

From: Ari Keränen <[email-masked]>
Date: Wed, 6 Mar 2019 15:03:06 +0000

CoRE WG,

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".

SenML RFC has a requirement that all SenML names are globally unique 
[1]. This enables the SenML Packs to be easily moved between systems 
without knowing the context they were originally retrieved at.

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.

For example with LwM2M composite write using iPATCH, the content of the 
Patch Pack in JSON format could be as follows:

[{"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}]

(Here you have a LwM2M client with two instances of a IPSO temperature 
sensor, Object ID 3303, supporting following resources 5700: Sensor 
Value, 5601: Min Measure Value, 5602: Max Measured Value).

If we keep the same requirement as SenML Pack names, both "bn" field 
values would have to be prefixed with the LwM2M endpoint ID, e.g., 
"urn:dev:mac:0024befffe804ff1". This would consume a fair amount of 
bytes on wire.

Our suggestion is that we relax the requirement for the names in Patch 
Packs so that the names are, for example, "evaluated in the context of 
the target resource". That is, all base names could be automatically 
prefixed by the unique endpoint name and target resource path.

Comments welcome! This will be discussed in the CoRE interim in one hour.

Cheers,
Ari

[1] https://tools.ietf.org/html/rfc8428#section-4.2

---

From: Jim Schaad <[email-masked]>
Date: Wed, 6 Mar 2019 08:01:14 -0800

As long as it is defined as optional, I don't see a problem.  I would worry
about possible issues if it was forbidden.

Jim

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Ari Keränen
> Sent: Wednesday, March 6, 2019 7:03 AM
> To: core WG <[email-masked]>
> Subject: [core] SenML FETCH/PATCH without globally unique names
> 
> CoRE WG,
> 
> meeting was that it would be useful to be able to use PATCH payload names
> without the "globally unique prefix".
> 
> SenML RFC has a requirement that all SenML names are globally unique [1].
> This enables the SenML Packs to be easily moved between systems without
> knowing the context they were originally retrieved at.
> 
> [{"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}]
> 
> sensor, Object ID 3303, supporting following resources 5700: Sensor Value,
> 5601: Min Measure Value, 5602: Max Measured Value).
> 
> "urn:dev:mac:0024befffe804ff1". This would consume a fair amount of bytes
> on wire.
> 
Packs
> so that the names are, for example, "evaluated in the context of the
target
> resource". That is, all base names could be automatically prefixed by the
> unique endpoint name and target resource path.
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Mar 2019 18:08:20 +0100

> about possible issues if it was forbidden.

The problem with the state of the proposal so far is that it is not clear when it is invoked and when not.  I can’t look at a Patch document and say “oh that is using non-global names”.  So we need to work a bit on making it truly optional (as in both ends know whether it is in effect or not).

Grüße, Carsten

---

From: Christian Amsüss <[email-masked]>
Date: Wed, 6 Mar 2019 19:27:22 +0100

Hello Ari & WG,

On Wed, Mar 06, 2019 at 03:03:06PM +0000, Ari Keränen wrote:
> [...]

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