Skip to main content

Minutes interim-2021-core-06: Wed 16:00

Meeting Minutes Constrained RESTful Environments (core) WG
Title Minutes interim-2021-core-06: Wed 16:00
State Active
Other versions plain text
Last updated 2021-05-26

# CoRE Virtual interim - 2021-05-26 - 14:00 UTC


* Marco Tiloca, RISE
* Jaime Jiménez, Ericsson

## Remote instructions


Minute takers: Jaime, Marco
Jabber scribes:

## Participants

1. Rikard Höglund, RISE
2. Thomas Fossati, arm
3. Jaime Jiménez, Ericsson
4. Klaus Hartke, Ericsson
5. Peter Yee, AKAYLA
6. Christian Amsüss, Generally Awesome Inc.
7. Marco Tiloca, RISE
8. Michael Koster
9. Francesca Palombini, Ericsson
10. Carsten Bormann, TZI
11. Ari Keränen, Ericsson
12. Oliver Fed, Borchert (part)
13. Doug Montgomery (part)
14. Niklas Widell
15. Alan Soloway, Qualcomm

*[MT]: Marco Tiloca
*[JJ]: Jaime Jiménez
*[FP]: Francesca Palombini
*[CB]: Carsten Bormann
*[CA]: Christian Amsüss
*[KH]: Klaus Hartke
*[RH]: Rikard Höglund
*[TF]: Thomas Fossati
*[DN]: David Navarro
*[GS]: Göran Selander
*[BS]: Bilhanan Silverajan
*[AS]: Alan Soloway
*[MR]: Michael Richardson
*[AK]: Ari Keränen
*[MJK]: Michael Koster
*[JM]: John Mattsson
*[NW]: Niklas Widell

## Agenda

### Note Well

Remember that the [note well](
applies, for [IPR]( but also for [WG
processes]( and [code of
conduct]( Try to be nice.

### Bluesheets / Jabber & Minutes / Agenda bashing

Fill the "Participants" list and other info above.

### CoRAL



KH: HREF has now a proposal for a new CBOR compact serialization on -04

KH: Looking for new implementors to see if the draft text is sufficient for
developers. WGLC to come soon.

KH: We might want to reach out to communities using URIs (HTTP) to see what to
do before or during WGLC.

TF: How many implementations needed?
KH: Me, CA, CB, ... if we can have one more that would help.
TF: I promised to provide one.
KH: That'd be great.

CB: more examples needed for implementors.
KH: Ideally we should have draft + companion repository, so that implementors
can use our test vectors. Hard to implement this right without test vectors.
CA: What is hard to implement, pure CRI parts or the conversion to URIs? KH:
All of the above



KH: Lots of open issues
Most on compression and semantics of CoRAL documents.

KH: CoRAL is being used in other docs. We might not want to rush CoRAL but to
move it forward in few steps, adopt them, get insights, make changes to CoRAL,
adopt them, etc.

KH: Two implementations available.

* Syntax and semantics (most of the Github issues).
* Names (compact identifiers) and their negotiation.
* FETCH and PATCH operations, different approaches to evaluate
* Shapes and components --- Initial to-be documents were started, also on
design patterns such as "collection" and "configuration" (see CoAP pub-sub and
ACE Group Manager for Group OSCORE). * Provenance and trust --- C receives a
CoRAL document from server A, including info on resources in a server B; should
C trust those statements from A? Generally depending on the application.
Something to better look into, e.g. through COSE signing of the full CoRAL
document, or through assertions in the request. A typical example is the
Resource Directory. * Formats and representations --- JSON; Text; conversion
to/from RFC 6690 Link Format.

KH: Good to prioritize negotiation and shapes; those may just end up in also
addressing syntax and semantics.

CB: The recent discussion on tossed URIs is somehow related too. A "thrown out"
URI should really come together with the intent for it, having in mind the
audience is constrained devices. *

TF: And also keep in mind the security context needed for URI dereferencing.
Should this go at the application layer too, or is it orthogonal input?

CA: The application should have a say, but we need a good general model.

### Relation between CoRAL and SDF

JJ: Thoughts about looking for comparisons between SDF and CoRAL, and how they
can work togeter.

MJK: This is interesting; let's use the expressiveness of CoRAL for SDF
definitions. Especially for link relation, observe and pub-sub. That would well
describe an API in a self-contained way.

CB: How does ASDF describe data shapes? We can extend it to use CoRAL
structured information.

MJK: The common collection shape might help.

KH: SDF allows to describe classes of things. CoRAL is a representation format.
For CoRAL to be useful for SDF, where does SDF need CoRAL? E.g., representing
temperature sensors. But they would likely not use CoRAL to talk to each other
(already using OCF, LwM2M, ...). It's maybe about a cloud-based API, e.g. for
homes, so the homeowner can for instance query the device.

OpenAPI  GraphQL  CoRAL-based REST API
   \      |      /
    \     |     /
     \    |    /
   | Northbound |
   | Southbound |
     /    |   \
    /     |    \
   /      |     \
LwM2M    OCF    ...

MJK: To identify a room you need additional vocabulary. You can indicate a
location, and use link relation e.g. to say what device type it is.

KH: Based on experience with a MSc Thesis on a northbound interface, it's
interesting to derive a CoRAL-based API from SDF files. Similarly thinking of a
southbound interface, you can think of producing CoRAL shapes from SDF files.

CA: A converter can be used by non-constrained applications to interact with
constrained devices with CoRAL.

MJK: We can think of how a toolchain of this kind would work.

JJ: Would be good to see an example. Start from a CoRAL-based REST API, then
interacting with OCF or LwM2M from the same SDF instance.

MJK: Yes, especially if we use a standardized CoRAL shape/pattern.

JJ: There used to be Carsten's coffee machine as example.

MJK: That was represented in SDF.

KH: Need to bring it up again.

JJ: Probably this? (slide 4)

**SDF Example with CoRAL interactions**

JJ: We had some early ideas (see below) that can lead to an example (always
helpful); can also be shared on the list.

  "namespace": {
    "api": "",
    "ipso" : "",
    "saref" : ""
  "defaultNamespace": "api",

  "sdfInstances": {
    "room1" : {
      "sdfInstanceOf": "api:#/sdfObject/Room/",
      "sdfProperty" : {
      "sdfRelations" : {
        "adjacentTo" : "#/sdfInstances/room2"
    "room2" : {
      "sdfInstanceOf": "api:#/sdfObject/Room/",
      "sdfProperty" : {
      "sdfRelations" : {
        "saref:adjacentTo" : "#/sdfInstances/room1",
        "saref:iscontainedIn": "#/sdfInstances/sensor1"
    "sensor1" : {
      "sdfInstanceOf": "ipso:#/sdfObject/Temperature/",
      "sdfRelations": {
        "saref:iscontainedIn": "#/sdfInstances/room2"


1. Client knows entry point for discovery <> gets
collection resource of SDF instances.

-> GET

<- 200 OK
   Content-Type: application/coral

   contains </room1>
   contains </room2>
   contains </sensor1>

2. Discovers `room2` and gets current value.

-> GET

<- 200 OK
   Content-Type: application/coral

   adjacentTo </room1>
   contains </sensor1>
   action-on </actuator1>

2. (or 3 depending on case) Discovers `sensor1` and gets back instance of IPSO
temperature sensor, with the relation to other resources (using saref ontology
in this case) and a description of the possible  interactions (Sensor_Value
with the location where to get the current value, units, resetting Min and Max
by oding POST)

-> GET

<- 200 OK
   Content-Type: application/coral

   #using ipsotemperatursensor =

   instanceOf <>
   iscontainedIn </room2>

   ipsotemperatursensor:Sensor_Value </sensor1/value>
   ipsotemperatursensor:Sensor_Units "Cel" {
     change -> </sensor1/sensor_units> []
   ipsotemperatursensor:Reset_Min_and_Max_Measured_Values -> </sensor1/reset> []