Great catch Simon!
I agree with your approach as consistent with MQTT5.
I am anyway scared about the fact that the âProtocol Versionâ in CONNECT is represented over 1 byte and in PUBLISH-1 is represented over 2 bits.
I propose the following 2 options to have a future-proof solution:
Option 1 (Packet type 2 bits flag extension):
00 means MQTT-SN v1.2 01 means MQTT-SN v2 10 is reserved 11 means there is a following dedicated byte providing the âProtocol Versionâ
Option 2 (Packet type refactoring)
PUBLISH 0x0C (MQTT-SN v2) PUBLISHv1_2 0x1E (MQTT-SN v1.2)
Bye
Davide
From: Simon Johnson <
thesii@gmail.com>
Sent: Sunday, January 8, 2023 11:31 AM
To:
mqtt-sn@lists.oasis-open.org Cc: Ian Craggs <
icraggs@gmail.com>;
tara.walker@microsoft.com; Davide Lenzarini <
davide.lenzarini@u-blox.com>
Subject: Re: Packet Type Field Change
**** This is an EXTERNAL email. It was sent from outside of u-blox. ****
ERRATUM: That should be bits 7 & 6 for the flags and 5 - 0 for packet type
On Sun, 8 Jan 2023 at 10:13, Simon Johnson <
thesii@gmail.com > wrote:
Good morning folks,
I have been working with PUBLISH -1 in v2. I have found a flaw with the new packet type layouts. Presently you can PUBLISH -1 without a session, and it is the SESSION that determines the protocol version you have decided to use. Without
a session, the GATEWAY has no mechanism to determine the version of the PUBLISH packet to use to decode it. So to maintain the ability for a GW to support both protocol versions, we must have a mechanism in the PUBLISH packet to note protocol version WITHOUT
adding any further bytes.
I was looking, the packet type field seems to be a great chance to squeeze some more space out of - in a similar fashion to tt5, so we coolocate a generic flags field in bits 1 & 0, using 6 bits of space (7-2) for packet type (64 available
types - we currently use ~30) so plenty of growing room - then the 2 new flags can be used for flags on the message without needing a new flags field. In the case of PUBLISH this can be protocol version, but also it could be used for a few other types specifying
and using only 1 or 2 flags saving space elsewhere. I feel this is a fundamental enough issue to warrant this change - and give us further flexibility for saving space elsewhere.
I still havn't gained access to the ticketing system, but will press OASIS next week and raise a ticket when I can. I'm happy to create a WD version (25) with just this change applied to all the message types this week for review.
Further, Davide, I have made the changes to the doc RE: network connection and will submit WD 24 this coming week.
Best,
Si