Inconsistent short topic types

[JochenWilhelmyTomTom]

Hi!

I have seen that inconsistent topic types (normal/short) are used. When subscribing, a normal topic is used. When then something is published, a short topic is used. This should be made consistent, maybe configurable with a flag if either normal or short topics should be used. A simple custom client may choose to support only one or the other.

Here, topic id 8 is assigned to the topic named "in":

20211227 191907.200   SUBSCRIBE   0001  <---  MyClient                            07 12 20 00 01 69 6E
20211227 191907.200   SUBSCRIBE   0001  ===>  MyClient                            82 07 00 01 00 02 69 6E 01
20211227 191907.201   SUBACK      0001  <===  MyClient                            90 03 00 01 01
20211227 191907.201   SUBACK      0001  --->  MyClient                            08 13 20 00 08 00 01 00

When something is published, a short topic is used:

20211227 191944.923   PUBLISH           <===  MyClient                            30 05 00 02 69 6E 31
20211227 191944.923   PUBLISH           --->  MyClient                            08 0C 02 69 6E 00 00 31

[campescassiano]

From client-side, what I have seen is that I can start publishing using either normal or short topics. If I use a short topic I must either (1) have the topic-id pre-defined at Gateway side, or (2) I must first register the topic via REGISTER packet, so the Gateway sends me back the topic-id to be used.

And, about the "inconsistency", I think makes not much sense to publish using the topic-string, and the Gateway forwarding it to the subscribed ones using the topic-string also. One of the core proposals of the MQTT-SN is to reduce data transmission. So, it makes more sense that the Gateway is doing so by forwarding the published messages using the topic-id instead of the topic-string.