MQTT5 Specification Updates

[stevenhartley]

The following PRs shall be used to capture and record the TODO items discussed during #75 that did not make it into the merge, items such as:

• Renaming the spec to mqtt5.adoc given the spec is targeted for MQTT5 and not MQTT3.1 or other versions
• Topics when used as D2D transport vs a uE transport
• Should the specifications be split in two (D2D vs uE)?
• More items

[devkelley]

I can take on this item

[matthewd0123]

One question that I want to ask regarding MQTT specifically is about the UPayload encoding in the MQTT Message. So, if I understand the requirements correct, we want to serialize/encode the payload value itself instead of the entire UPayload. If that's the case, how should we carry the UPayloadFormat inside the MQTT Message? Right now in up-client-mqtt5-python, I'm serializing the entire UPayload. But, if that's not proper, I would be able to encode each payload based on its format, but would need to know the format when the message is received on the other side.

[stevenhartley]

One question that I want to ask regarding MQTT specifically is about the UPayload encoding in the MQTT Message. So, if I understand the requirements correct, we want to serialize/encode the payload value itself instead of the entire UPayload. If that's the case, how should we carry the UPayloadFormat inside the MQTT Message? Right now in up-client-mqtt5-python, I'm serializing the entire UPayload. But, if that's not proper, I would be able to encode each payload based on its format, but would need to know the format when the message is received on the other side.

MQTT5 supports binary payload so that means we send UPayload serialized to bytes as-is (not base64 encoded or stuffed in json or anything else).

[stevenhartley]

changes for 1.5.8 have been merged