[core] Designs to resolve streaming issues in SenML

["Cullen Jennings (fluffy)" <[e-mail]>]

The changes we made to SenML to support streaming in the -02 version raised many issues for lots of people. In the end, one of the biggest problems is it forces all things receiving SenML to support streaming. 

I have an alternative design for streaming that I think addresses the issues raised and I would like the WG to think about two alternative designs for SenML and give me some direction on which one to use. 

The first design is the current -02 design with simple fixes and is in draft draft-jennings-core-senml-03

The second design is the new design I am proposing and is in draft-jennings-core-senml-04. It many way it moves back to be much closer to what was in -01 than what is in -02. 

The drafts can be found at 

https://datatracker.ietf.org/doc/draft-jennings-core-senml/03/

and 

https://datatracker.ietf.org/doc/draft-jennings-core-senml/04/


Practically speaking the differences are not that much between the two but they do resolve a bunch of the issue. Let me discuss this in terms of the JSON representation and the rest of the representations mirror that.  In the new design measurements are put in JSON object as always. The object are put in array to represent a series of measurements. The objects can also have the base values right in the object and the base values apply to all the things in the object and any future objects in the array. 

Here is an example of something that is not a stream in both old and new design.

OLD 

[{"bn": "urn:dev:mac:0024befffe804ff1/"},
 [ { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
   { "n": "current", "t": 0, "u": "A", "v": 1.2 } ]
]

NEW

[{"bn": "urn:dev:mac:0024befffe804ff1/"},
 { "n": "voltage", "t": 0, "u": "V", "v": 120.1 },
 { "n": "current", "t": 0, "u": "A", "v": 1.2 } 
]

Note the old design has an array with a base object, followed by a second array of measurements. The new design just has an single array and the first object happens to only have base values that apply to future object in the array. 

This could also be sent as

[
    {
	"t": 0, 
      	"n": "voltage", 
	"u": "V", 
     	"bn": "urn:dev:mac:0024befffe804ff1/",
	"v": 120.1
   },
   { 
	"n": "current", 
	"t": 0, 
	"u": "A", 
	"v": 1.2 
   } 
]

Here is an example of streaming with old and new design 

OLD 

[{"bn": "http://[2001:db8::1]",
  "bt": 1320067464,
  "bu": "%RH"},
 [ { "v": 21.2, "t": 0 },
   { "v": 21.3, "t": 10 },
   { "v": 21.4, "t": 20 },
   { "v": 21.4, "t": 30 },
   { "v": 21.5, "t": 40 },
   { "v": 21.5, "t": 50 },
   { "v": 21.5, "t": 60 },
   { "v": 21.6, "t": 70 },
   { "v": 21.7, "t": 80 },
   { "v": 21.5, "t": 90 },
...

NEW 

[ {"bn": "http://[2001:db8::1]",
  "bt": 1320067464,
  "bu": "%RH"},
   { "v": 21.2, "t": 0 },
   { "v": 21.3, "t": 10 },
   { "v": 21.4, "t": 20 },
   { "v": 21.4, "t": 30 },
   { "v": 21.5, "t": 40 },
   { "v": 21.5, "t": 50 },
   { "v": 21.5, "t": 60 },
   { "v": 21.6, "t": 70 },
   { "v": 21.7, "t": 80 },
   { "v": 21.5, "t": 90 },
...


The draft does not have it yet but an applications that supports receiving streaming is written is a substantially different way that one that does not. I think the best way to deal with this is simply use a different mine type for streaming ( calls it senml_stream for now but send me suggestions on name for it). That way it can be clearly indicated and negotiated in existing transport protocols. 

Appreciate any thoughts people have on pro / cons of the -03 design vs -04 design.