Re: [mqtt-comment] Comments on mqtt-v3.1.1-cos01

[Richard J Coppen <COPPEN@uk.ibm.com>]

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

Richard




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:

https://github.com/mqtt/mqtt.github.io/wiki/Differences-between-3.1.0-and-3.1.1

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 3.3.1.3 - 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 3.3.1.3, 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 
3.1.3.1) 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: http://lists.oasis-open.org/archives/mqtt-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/mqtt
Join OASIS: http://www.oasis-open.org/join/



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