Major WD11 Notes.
660 1.5.6 Binary Data
663 Where used the data consists only of the data portion of the field,
This is unnecessary.
666 1.5.7 UTF-8 String Pair
667 A UTF-8 String pair
Should be UTF-8 String Pair
668 . The first string serves as the name, and the second string contains the value.
should be:
The first string is the name, and the second string is the value.
680 1.7 Editing convention etc.
Should be moved to before 1.5 Data representation
813 3 MQTT Control Packets
815 3.1 CONNECT - Connection Request
824 Will Topic, Will Message, User Name and Password.
All but the Client identifier are optional and their
We should not use the word "optional" use something else.
Will messages etc are not OPTIONAL, they MUST be supported.
eg use:All but the Client Identifier can be omitted.
831 This is the length of the Variable Header plus the length of the Payload
encoded as a Variable Byte Integer.
should be:
This is the length of the Variable Header plus the length of the Payload.
It is encoded as a Variable Byte Integer.
835 The Variable Header for the CONNECT Packet contains the following fields in the order:
Protocol Name, Protocol Level, Connect Flags, Keep Alive, Property Length, and Properties.
The rules for encoding Properties are described in section 2.2.3.
Should be:
The Variable Header for the CONNECT Packet contains the following fields in this order:
Protocol Name, Protocol Level, Connect Flags, Keep Alive, Property Length, and Properties.
The rules for encoding Properties are described in section 2.2.3.
Redefine "Property Length, and Properties" to be Properies throuought the spec
so it includes the length. section 3.2.1 Properties needs to be clear that the term "Properties"
means the Properties and their length, and that a length of 0 means that there are no properties.
844 A Server which supports multiple protocols uses the Protocol Name
to verify that it has received a CONNECT packet.
If the Server does not want to process the data and wishes
to reveal that it is an MQTT Server it MAY send a CONNACK packet with Return Code of 0x84
(Unsupported Protocol Version)
as described in section 4.13 Handling errors, and then close the Network Connection.
Should be:
The protocol name MUST be the UTF-8 String "MQTT".
If the Server does not want to accept the CONNECT, and wishes to reveal
that it is an MQTT Server it MAY send a CONNACK packet with Return Code of 0x84
(Unsupported Protocol Version),
and then it MUST close the Network Connection.
857 A Server which supports multiple versions of the MQTT protocol uses the
Protocol Version to verify that it has received a
Version 5 CONNECT packet. If the Protocol Version is not 5 and the
Server does not want to process the data, the Server MAY send
a CONNACK packet with Return Code 0x84 (Unsupported Protocol Version)
as described in section 4.13 Handling errors,
and then close the Network Connection.
Should be:
A Server which supports multiple versions of the MQTT protocol uses the
Protocol Version to determine which version of MQTT the Client is using.
If the Protocol Version is not 5 and the
Server does not want to accept the CONNECT packet, the Server MAY send
a CONNACK packet with Return Code 0x84 (Unsupported Protocol Version)
and then MUST close the Network Connection.
865 the . [space to next letter] format seems to change
Session state is introduced as "Session State" and then referred to as "Session state"
866 the reserved flag is not zero
Should be;
the reserved flag is not 0
866 Refer to section 4.13
Should be:
Refer to section 4.13.1
881 If the Will Flag is set to 1 this indicates that,
if the CONNECT packet is accepted, a Will Message MUST
should be;
If the Will Flag is set to 1 this indicates that a Will Message MUST
844 deleted by the Server on receipt of a DISCONNECT packet with Return Code 0x00 (Success)
or 0x04 (Disconnect with Will Message) [MQTT-3.1.2-4].
The 0x04 should go. (the will is published).
Also delete 0x04 on lines 889 and 891.
922 3.1.2.7 Will Retain
928 If the Will Flag is set to 1:
" If Will Retain is set to 0, the Server MUST publish the Will Message as a non-retained message. [MQTT-3.1.2-12]
" If Will Retain is set to 1, the Server MUST publish the Will Message as a retained message. [MQTT-3.1.2-13]
The conformance clauses need to contain "If the Will Flag is set to 1:"
938 3.1.2.9 Password Flag
Add a non normative comment to say that you can now send password with no user name
unlke in 3.1.1.
975 3.1.2.11 Property Length
Shoulkd look like...
3.1.2.11 Properties
3.1.2.11.1 Property Length
3.1.2.11.2 Session Expiry interval
etc.
985 3.1.2.12.1 Session State
Should be in section 4 and refered to from elsewhere. except for ...
986 The Client and Server are required to store Session state so that reliable
messaging can continue across a sequence of Network Connections.
After the Network Connection is closed and the Session Expiry Interval
has elapsed without a new connection being made, the Client and Server
MUST delete the Session state they hold [MQTT-3.1.2-21].
Belongs with Session Expiry.
See the change to Session Present checking on CONNACK .
It should become:
The Client and Server MUST store Session state so that reliable
messaging can continue across a sequence of Network Connections.
If a Network Connection is closed and the Session Expiry Interval
has elapsed without a new connection being made, the Client and Server
are allowed to delete the Session state they hold [MQTT-3.1.2-21].
986 If a new Network Connection is made before the Session has expired,
the Server MUST resume communications with the Client based on state from
the current Session (as identified by the Client identifier) [MQTT-3.1.2-22].
If there is no Session associated with the Client identifier the
Server MUST create a new Session [MQTT-3.1.2-23]. The Client and Server MUST store
the Session after the Network Connection is closed [MQTT-3.1.2-24].
Should be in Clean Start as:
If Clean Start is set to 0 before a Session has expired,
the Server MUST resume communications with the Client based on state
from the current Session (as identified by the Client identifier) [MQTT-3.1.2-22].
If there is no Session associated with the Client identifier the
Server MUST create a new Session [MQTT-3.1.2-23].
And the following should be added to the Session state paragraph in section 4.
The Client and Server MUST store the Session
after the Network Connection is closed [MQTT-3.1.2-24].
1029 Non-Normative comment
Typically, a Client will always connect using the same Session Expiry Interval.
The choice will depend on the application. A Client that has its Session Expiry
Interval always set to 0 will not receive old Application Messages and has to
subscribe afresh to any topics that it is interested in each time it connects.
A Client using a non-zero Session Expiry Interval will receive all QoS 1 or QoS 2
messages that were published while it was disconnected provided that its Session has not expired.
Recast this to describe the session expiry zero transient case.
The other cases are described in the next non normative comments. eg.
A Client that only wants to process messages while connected will set the Session Expiry
Interval set to 0. It will not receive Application Messages published before it connected and has to
subscribe afresh to any topics that it is interested in each time it connects.
1047 Non-Normative comment
If the Client connects using this protocol,
then reconnects using the MQTT V3.1.1 protocol using CleanStart 0
before the Session has expired, the Session state is kept indefinitely.
This should go. While helpful, it's an unusual case to downgrage back to
V3.1.1 and hence might confuse the reader.
1110 It is the responsibility of the application to select a suitable Maximum packet size value if it
should be:
It is the responsibility of the application to select a suitable Maximum Packet Size value if it
1125 but other Clients can receive it, the Server can choose either discard the message without sending the
message to any of the Clients, or send the message to one of the Clients that can receive it.
Should be:
but other Clients can receive it, the Server can choose either to discard the message without sending the
message to any of the Clients, or to send the message to one of the Clients that can receive it.
1178 UTF-8 String
Followed by a UTF-8 string pair.
1286 being used to serve
"used to process" avoids the double use of serve
1309 3.2 CONNACK - Connect acknowledgement
1333 Bit 0 (SP1) is the Session Present Flag.
Not sure what the SP^1 means
1337 If the Server accepts a connection with Session Expiry Interval set to 0
Should be:
If the Server accepts a connection with Clean Start set to 1
1341 If the Server accepts a connection with non-zero Session Expiry Interval,
Should be:
If the Server accepts a connection with Clean Start set to 0,
1349 view about whether there is already stored Session state.
Should be Session State ?
1351 Once the initial setup of a Session is complete,
a Client with stored Session state will expect the
Server to maintain its stored Session state.
If the value of Session Present received by the Client
from the Server is not as expected,
the Client can choose whether to proceed with the
Session or to close the Network Connection.
The Client can discard the Session state on both Client and Server by
sending a DISCONNECT packet with Session Expiry set to 0.
Should be:
The session Present flag allows the Client to validate that the Session state
is as expected.
If the value of Session Present received by the Client
is 1 when it expected 0, the Client MUST disconnect.
It can then then reconnect using Clean Start set to 1.
If the value of Session Present received by the Client
is 0 when it expected 1, the Client MUST delete its Session state
if it wishes to continue with the connection.
1453 Followed by a Byte field. If present,
Is there double space between . and If ?
1608 3.3 PUBLISH - Publish message
1740 A Server MUST send the Payload Format Indicator unaltered to all subscribers
receiving the publication [MQTT-3.3.2-4].
The receiver MUST validate that the Payload is of the format indicated,
and if it is not send a PUBACK, PUBREC, or DISCONNECT with Return Code of 0x99
(Payload format invalid) as described in section 4.13 [MQTT-3.3.2-5].
So both clients and server MUST validate that the string is correct UTF-8!
This should be a MAY validate.
1805 Refer to section 4.10 for more information about how Request / Response works."
is in several places. It sounds a bit ugly. Can we can say:
Refer to section 4.10 for more information on Request / Response."
1964 3.4 PUBACK - Publish acknowledgement
1981 Byte 3 in the Variable Header is the PACK Return Code.
Should be:
Byte 3 in the Variable Header is the PUBACK Return Code.
1986 If the Server does not know if there are any matching subscribers,
it MUST use the 0x00 (Success) Return Code [MQTT-3.4.2-1].
If the server wants to use the minumum packet size with remaining length 2
is it allowed to imply rc=0x00?
Use:
If the Server wishes to inform the Client that thre are no matching subscribers,
it MAY use the 0x10 (No matching subscribers)
as an altrnative to 0x00 (Success) [MQTT-3.4.2-1].
1986 The payload format does not match the specified Payload Format Indicator.
Can the receiver send DISCONNECT rc 0x99 and disconnect in place of PUBACK and PUBREC rc 0x99?
1989 The Return Code 0x00 (Success) may be sent by using a Remaining Length of 2.
This should say:
The Return Code 0x00 (Success) and no properies may be sent by using a Remaining Length of 2.
Also applies to other packets.
1997 String is a human readable string designed for diagnostics and SHOULD NOT be parsed by the receiver.
This is not testable instead we should say:
String is a human readable string designed for diagnostics it is not intended be parsed by the receiver.
2006 The sender MUST NOT send this property if it would increase the size of the
PUBACK beyond the Maximum Packet Size specified by the session partner
This is true for all packets, EG Publish.
Does this really mean that the sender must still send the PUBACK but without the property.
What if the property is doing something useful?
The sender might prefer to disconnect and sort out the small packet size.
A better way to handle this is to allow the sender to send
CONNACK, PUBACK, PUBREC, PUBCOMP, SUBACK, UNSUBACK, DISCONNECT 0x??
(Maximum Packet size too small).
so that it can inform the publisher that it needs to send a large packet but cannot.
2014 3.5 PUBREC - Publish received (QoS 2 delivery part 1)
2037 If the Server is does not know if there are any matching subscribers,
it MUST use the 0x00 (Success) Return Code
See comment on PUBACK line 1986. If disconnected the sender MUST reconnect and resend the
PUBLISH, which will have to succeed so that t ccan free up the PacketId.
2037 This might indicate a mismatch in the session state between the Client and Server.
This is a failure of this PUBACK, but might mean that the previous use of the packet id
succeeded. We should be clear that if the sender believes that the session state is
good, then it needs to continue the protocol and send PUBREL.
2037 The payload format does not match the specified Payload Format Indicator
See comment on PUBACK line 1986.
2040 The Return Code 0x00 (Success) may be sent by using a Remaining Length of 2.
See comment on PUBREC line 1989.
2030 Bit 3 of the Subscription Options represent Retain As Published option.
Should say:
Bit 3 of the Subscription Options represents the Retain As Published option.
3.8 SUBSCRIBE - Subscribe request
2236 If there are no retained messages matching the Topic Filter all of these values act the same.
Add a comma:
If there are no retained messages matching the Topic Filter, all of these values act the same.
2258 Add a note.
RAP means Retain as Published.
NL means No Local.
2420 3.9 SUBACK - Subscribe acknowledgement
2440 If the Remaining Length is less than 4, there is no Property Length and the value of 0 is used.
Should be:
If the Remaining Length is less than 3 there are no Properties.
2453 The sender MUST NOT send this property if it would
increase the size of the SUBACK beyond
the Maximum Packet Size specified by the session partner [MQTT-3.9.2-2].
A better way to handle this is to allow the sender to send DISCONNECT 0x??
so that it can inform the subscriber that it needs to send a large packet but cannot.
2530 3.11 UNSUBACK - Unsubscribe acknowledgement
2550 If the Remaining Length is less than 4 there is no Property Length and the value of 0 is used.
Should be:
If the Remaining Length is less than 3 there are no Properties.
2576 3.12 PINGREQ - PING request
2583 This packet is used in Keep Alive processing. Refer to section 0 for more details.
Replace section 0 with the correct section number.
2597 3.13 PINGRESP - PING response
2601 This packet is used in Keep Alive processing. Refer to section 0 for more details.
Insert the correct section number.