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: Re: [mqtt-comment] Comments on mqtt-v3.1.1-cos01

Hi Nicholas,

Many thanks for your feedback and comments on the MQTT 3.1.1 Candidate OASIS Specification.
I have raised a Jira issue for each of your comments (MQTT 238 - 246) for the TC to evaluate. You can track these via the following links.

Comment 1: https://issues.oasis-open.org/browse/MQTT-238
Comment 2: https://issues.oasis-open.org/browse/MQTT-239
Comment 3: https://issues.oasis-open.org/browse/MQTT-240
Comment 4: https://issues.oasis-open.org/browse/MQTT-241
Comment 5: https://issues.oasis-open.org/browse/MQTT-242
Comment 6: https://issues.oasis-open.org/browse/MQTT-243
Comment 7: https://issues.oasis-open.org/browse/MQTT-244
Comment 8: https://issues.oasis-open.org/browse/MQTT-245
Comment 9: https://issues.oasis-open.org/browse/MQTT-246

Many thanks


From:        Nicholas Humfrey <njh@aelius.com>
To:        mqtt-comment@lists.oasis-open.org
Date:        12/08/2014 19:10
Subject:        [mqtt-comment] Comments on mqtt-v3.1.1-cos01
Sent by:        <mqtt-comment@lists.oasis-open.org>

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

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

This publicly archived list offers a means to provide input to the
OASIS Message Queuing Telemetry Transport (MQTT) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: mqtt-comment-subscribe@lists.oasis-open.org
Unsubscribe: mqtt-comment-unsubscribe@lists.oasis-open.org
List help: mqtt-comment-help@lists.oasis-open.org
List archive:
Feedback License:
List Guidelines:

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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