Open egekorkan opened 1 year ago
What do you think @relu91 ?
Thank you, @egekorkan, I was actually about to open a similar issue :)
What do you think @relu91 ?
I thought of introducing that element when I worked on the ontology revamp. However, I did not introduce it because the whole ontology was tailored to version 3.1.1. Moreover, I questioned myself if it made sense to have a version tag OR two different ontologies to describe the different protocol features. The problem with two different ontologies is that we are going to have some duplicated terms... but it solves the versioning issue nicely. I don't have a clear answer yet but I am eager to know what you think about these two possible approaches.
As far as I have understood, an MQTT 5.0 broker would not have an issue if an MQTT 3.1.1 client connects to it so the additional features would not be breaking change. If this is indeed possible. More importantly, given that we would use the same URI scheme for 3.1.1. or 5.0 even if we have different ontologies, we would need a way to indicate the version I think.
I'd also be in favor of adding a mqv:version
field, as, for example, in the Dart ecosystem you have two different implementations for MQTT 3 and MQTT 5. So being able to differentiate between the two versions would be very nice. Would it be possible to define the version "globally" by the way, i.e., for the whole TD? Or do you need to provide an override of the default for each form?
Furthermore, should it also be possible to also indicate MQTT version 3.1 (besides version 3.1.1)?
More importantly, given that we would use the same URI scheme for 3.1.1. or 5.0 even if we have different ontologies, we would need a way to indicate the version I think.
I was actually thinking to use two different URI schemes pointing to two different ontologies. It would solve this:
Would it be possible to define the version "globally" by the way,
But I mostly agree with you that is overkill.
Based on the the different MQTT versions available on various platforms it might make sense to be able to indicate the version used.
Anyhow, based on the claim that
MQTT 5 is designed to be backwards compatible with MQTT 3.1.1 to some extent
I am not sure if is really a use-case per se. I see it more as "nice to have".
Currently, the MQTT binding does not specify which version to be used. I think we should be able to describe that and also give a default value in case it is not specified.
I propose:
mqv:version
which can have value "3.1.1" or "5.0"