MQTT Protocol in transport parameters and DNS-SD advertisement?

[garethsb]

In my understanding MQTT brokers may support several protocols - the 'MQTT' protocol over TCP, a TLS protocol for secure comms, or variants on top of (Secure) WebSocket.

We have "destination_host" and "destination_port" (or the source variants for a Receiver) in the IS-05 MQTT transport params, but that doesn't indicate the protocol.

Similarly, Transport - MQTT - Broker discovery mentions the broker will be advertised via DNS-SD, but there's no indication of any TXT records that might allow the protocol to be discovered.

I'm also not sure whether the MQTT version needs to be specified, e.g. Version 3.1.1 vs. Version 5.0?

[garethsb]

I found a nice summary of the differences between MQTT versions here: https://github.com/mqtt/mqtt.github.io/wiki/Differences-between-3.1.1-and-5.0

It does sound as if it could be important to know which version is being used.

[garethsb]

https://blog.codecentric.de/en/2017/11/hello-mqtt-version-5-0/ says MQTT 5.0 (protocol 5) is not backwards compatible with MQTT v3.1.1 (protocol 4). (MQTT v3.1 was protocol 3.)

[garethsb]

Similarly, Transport - MQTT - Broker discovery mentions the broker will be advertised via DNS-SD, but there's no indication of any TXT records that might allow the protocol to be discovered.

Note that the IANA Service Name and Transport Protocol Port Number Registry already has entries for the service names mqtt (implying _mqtt._tcp I think) and secure-mqtt. The earliest registration from IBM alludes to TXT records but not for protocol, etc. only topics.

I also found there was an action in OASIS MQTT-203 to register the informally supported URL schemes like mqtt:// and mqtts:// with IANA, but that seems to have petered out.

[garethsb]

From MQTT Version 3.1.1 - Section 3.1.2.2 Protocol Level, the client indicates the protocol level and "The Server MUST respond to the CONNECT Packet with a CONNACK return code 0x01 (unacceptable protocol level) and then disconnect the Client if the Protocol Level is not supported by the Server."

I am slightly aghast that the equivalent sentence in MQTT 5.0, says "Reason Code 0x84 (Unsupported Protocol Version)"! They changed all the numbering!

However, at least it appears an MQTT Version 3.1.1 client basically has to treat any non-zero code as fatal error...

So, while there are opportunities for connection failure due to protocol level, the feeling in the group call today is that therefore we do not need to indicate the protocol level supported by the MQTT client of IS-07 Senders/Receivers in transport parameters. A client may choose to try its preferred protocol version first (e.g. MQTT 5.0) and retry if necessary.

[garethsb]

As for whether secure comms needs to be indicated in some way, the consensus on the group call today was that for now if the Connection API is being accessed via HTTPS, then secure connection with the MQTT broker via the indicated "destination_port" is assumed.

However, this has not answered the question as to whether secure comms should be indicated in the _nmos-mqtt._tcp DNS-SD advertisement. My feeling is that you might want to advertise both secure and insecure brokers. @mjeras, what is your opinion on this?

(Nor did we cover whether it is necessary to add something to identify whether "destination_port" - or the port in the DNS-SD advertisement - might be for MQTT-over-WebSocket for example. At the moment I think we have to assume it is only either MQTT or MQTT-with-TLS, right?)

[mjeras]

I agree that we would leave out the MQTT protocol version out of the specification and leave it to the clients and servers to agree on a supported version.
Also agreed that securing of the transports should follow the securing of the API (https implies use of wss and secure mqtt)
As far as DNS-SD is concerned, I would have the TXT record and put "mqtt" and "mqtts" in it as protocol (would worry about those not being IANA registered in that place)
And I would go with the assumption of MQTT or MQTT over TLS for this release. We could always expand it in some future version if needed, but I think keeping it relatively simple at this stage would be good..

[garethsb]

I agree that we would leave out the MQTT protocol version out of the specification and leave it to the clients and servers to agree on a supported version.

Thanks.

Also agreed that securing of the transports should follow the securing of the API (https implies use of wss and secure mqtt)

Thanks, OK. (Not a problem for WebSocket as the "connection_uri" has a scheme.)

As far as DNS-SD is concerned, I would have the TXT record and put "mqtt" and "mqtts" in it as protocol (would worry about those not being IANA registered in that place)

I.e. TXT record, api_proto=mqtt or api_proto=mqtts?

OK.

And I would go with the assumption of MQTT or MQTT over TLS for this release. We could always expand it in some future version if needed, but I think keeping it relatively simple at this stage would be good..

Agreed! Thanks.

[garethsb]

@mjeras, on reflection, I do wonder if we should revisit this:

Also agreed that securing of the transports should follow the securing of the API (https implies use of secure mqtt)

Adding the MQTT protocol to the transport params explicitly gives us most clarity and most flexibility. It's also easy for an implementation to add the constraint that only allow one value.

See AMWA-TV/is-05#80 (comment) for a proposal.

[garethsb]

Closed by AMWA-TV/is-04#101 and related doc updates here in #57.