OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments on mqtt-v3.1.1-cos01

Dear MQTT TC members,

I have been meaning to read through the draft MQTT specification in detail for quite some time and have finally made time to do so. My comments related to version mqtt-v3.1.1-cos01.pdf of the document.

Overall I am very pleased with the increased clarity and readability of the new document. My only concern is that the length of the document is slightly intimidating for a 'light weight' protocol. Do you have any plans to publish a separate primer?

1) I noticed that the previous version of the specification is listed in the references (MQTTV31) but it not actually mentioned in the text anywhere. My reason for looking it up is that it would be extremely useful to have a list of differences between versions 3.1.1 and 3.1.0 of the specification. I started compiling my own list on the mqtt.org wiki:


2) I was quite surprised to discover that an additional byte had been inserted in front of the return code byte in the Connack packet type, making it harder to maintain backwards compatibility. Given that the fixed header flags have now been made specific to the packet type, what was the reason for not using one of those? It seems like an expensive break in the existing protocol for a minor new feature? Particularly when there has been effort to preserve other less useful features of the protocol, such as setting flag bit 1 in the fixed header of a Subscribe packet.

3) There is no mention of TCP port 1883 in the document. I would expect to see something about it in the Non normative comment of section 4.2. Section 5.1 provides the statement "SHOULD use TCP port 8883". I find it odd that Section 6 provides much stronger wording around WebSockets, than section 4.2 provides around TCP.

4) While comparing the differenced between the previous version of the specification, I noticed that it is no longer possible to send a password without a username. I thought that this was quite a useful (albeit unintentional?) feature of the protocol, which could be used to send API keys, OAuth tokens, or other secrets, without requiring a (fake/unused) username. It could also be used to provide a password for a client id, without an additional username.

5) Section - line 753 states "This flag is only used on the PUBLISH Packet" - is this statement still relevant when the fixed header has been made into generic numbered bits? There isn't a similar sentence for for the Dup flag.

6) Also in section, I found the language used confusing - I don't think it is clear that messages with any QoS should be retained, not just QoS 0.

7) The wording around the characters allowed in client ids (section is slightly confusing - particularly as the 'MAY' clause is likely to lead to incompatible implementations. I would like to see '-' appearing in the list of required characters - as RFC952 specifies for host names.

8) I do wish that leading and trailing slashes were forbidden. I think topic names should either have structure and semantic meaning, or not. The half-way house of 'use the topic name however you want' and slashes being significant for pattern-matching is confusing.

9) I am not sure what the sentence on line 446 means. A little more detail would be useful.

Thanks for all of your hard work in preparing this specification.

Nicholas Humfrey

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]