[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=65664#comment-65664 ]
Richard Coppen commented on MQTT-416:
-------------------------------------
Editing with Andy and we got to line 1349
> 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]