[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]