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

Richard

From:      
 Nicholas Humfrey <>

To:      
 

Date:      
 12/08/2014 19:10

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

Sent by:    
   <>

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: 

Unsubscribe: 

List help: 

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