[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-416) Notes on WD11
[ https://issues.oasis-open.org/browse/MQTT-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65483#comment-65483 ]
Ken Borgendale commented on MQTT-416:
-------------------------------------
The order of section 1 came from the template, and I would rather not update it at this point. It is commonly not possible to read the spec fully in order.
I fixed double spaces between sentences (and elsewhere) globally in the document.
The Property Length is shown as a separate item in the variable header as each allowed property has its own section. I strongly suggest we keep this as is.
I also disagree strongly with putting the properties as H5 level items.
881 The Will Message is only stored if the CONNECT is accepted, and thus the existing text is correct.
Changing the language that we send an ACK without the reason code or properties if it is too large is a core change. This is the behavior agreed to in the TC.
The correct reference for error handling is to section 4.13 which is the section on handling errors.
> Notes on WD11
> -------------
>
> Key: MQTT-416
> URL: https://issues.oasis-open.org/browse/MQTT-416
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Bug
> Affects Versions: 5, wd11
> Reporter: Andrew Banks
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]