Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

Additional work related to #32

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

Additional work related to #31

• Additional work related to #37
• In addition, create/complete the 'Sparkplug_Payload_A.adoc' reference doc

In Section 8, Item 1 - this statement is incorrect:

1. Only the Host Primary Application(s) should have the permission to issue commands to end devices.

Expand on required QoS levels for all Sparkplug message types. Sparkplug requires that all *BIRTH, *DATA, and *CMD messages must be sent on QoS0.

The Sparkplug B protobuf definition only provides uint32 and uint64 types in the one-of value groups. Signed integers are forced in and out of those fields using casting which is not always obvious to implement depending on the programming language.

Additionally, sending any negative value, even small ones, immediately expands the line-size of those fields to the maximum 4 or 8 bytes.

On the next revision of the protobuf definition, I think the one-of value groups should be expanded to also provide either int32/int64 values or sint32/sint64 values. Using these should reduce the amount of casting required to get signed value in and out of the payloads. Additionally, the "sint" versions will allow small signed integers like "-1" to only take one byte of line-size data, although I am unsure if using those versions is easy in all application languages.

This is regarding: http://dev.eclipse.org/ipzilla/show_bug.cgi?id=22396

Now that this contribution has been approved, we will need to make an
adjustment to the file headers for the content. It is correct that the
documentation that is produced by this code is licensed under the Eclipse
Foundation Specification License, as noted in the Sparkplug.adoc file; however,
the code itself that generates the specification docs is to be licensed under
the EPL-2.0 license as the EFSL applies to the generated documentation only.

Please review the attachment and ensure that all of the file headers are
showing the EPL-2.0 license as outlined here:

https://www.eclipse.org/projects/tools/documentation.php?id=iot.sparkplug

It seems like it would be good to have a simple clean way of sending an array of integers or floating point numbers (or any basic scalar type) without the expense of a template or a data set. Similar to the "bytes" type, but with other base types besides a byte.

In section 16.7 the document indicates DDEATH has a payload with an incrementing sequence # (I suspect this to be correct).

Then in section 17.8 it declares the payload to empty.

Additional work related to #32

Additional work related to #31

It looks like someone went overboard with a find and replace and "Sparkplug™" is everywhere in the spec, including protobuf definitions and topic names, among other places it's not likely intended:

syntax = "proto2";

package org.eclipse.tahu.protobuf;

option java_package         = "org.eclipse.tahu.protobuf";

option java_outer_classname = "Sparkplug™BProto";

message Payload {

...truncated...

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

As we port the Sparkplug specification to the new format we should create a 'converted' doc that we can use to remove content to denote what portions of the original spec have been moved to the new form.

Every time anyone copies portions from the old form of the spec to the new chapter based form the corresponding text in the 'converted' doc should be removed.

Using this method, we should be able to easily/quickly see what content has not been copied over. Some may never be copied over but this will make it easy to audit what maybe should still be moved over. After this conversion is complete the converted doc can be deleted.

I converted chapter 5 from the original specification and found items that may be missing, addressed in another section, or not completed yet. Here are the sections:

• MQTT Enabled Device Session Establishment
• MQTT Application Node Session Establishment
• Data Publish
• Commands

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

7.2 NDATA Section mentions: "RBE or time based metric EoN"
7.4 DDATA Section mentions only Report by Exception.

Clarify whether both RBE or time based reporting are allowed.

Reword the specification to reflect this.

Complete the Chapter 7 (Security) section 'Implementation Notes' of the Sparkplug Spec. This section didn't exist in the original spec, was added when the TOC was created and needs to be updated to complete Chapter 7 (Security).

Additional work related to #31

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

Review and cleanup SparkplugB metric properties. There is at least one discrepancy in the spec defined metric properties: 'is_historical' has instead been implemented as 'isHistorical'. This should be fixed and the other metric properties should be reviewed and updated if appropriate.

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

There should be three profiles at this point:
edge
host
primary host

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.

I think we need to define how Sparkplug relates to MQTT 5.0, not just 3.1.1. The 5.0 standard has been published for almost two years now and will see increasing adoption.

I don't think there need be any substantive changes to be able to use MQTT 5.0, as it is a superset of 3.1.1, so all it will amount to is saying that Sparkplug will work with both, and that when MQTT is referred to, it can mean either version.

It's possible that if any specific MQTT functionality is mentioned the terminology may differ between 5.0 and 3.1.1 but so far I've not noticed any. Retained messages, for instance, remain the same.

The "clean session" flag is one difference in MQTT 5.0 - it becomes the clean start flag combined with the session expiry interval. But I don't think "clean session" is mentioned anyway.

The biggest impact might be on the TCK, if we need to ensure it works on both versions.

After talking with our mentor, Ivar Grimstad, we should follow the Jakarta specification method of ensuring coverage for the TCK. Here are some links that show some of the various tooling in action in Jakarta:

https://github.com/kevto/tck-coverage/issues/1
https://beanvalidation.org/2.0/tck/
https://hibernate.atlassian.net/browse/BVAL-502?oldIssueView=true
https://github.com/eclipse-ee4j/beanvalidation-spec

Copy and correct the relevant portions of specification/Sparkplug.adoc to this new chapter based form of the specification document.