Review / TEST spec chapter 3 rest

[anyflow]

• [MQTT-3.6.1-1]
  Bits 3,2,1 and 0 of the fixed header in the PUBREL Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection.
• [MQTT-3.8.1-1]
  Bits 3,2,1 and 0 of the fixed header of the SUBSCRIBE Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection.
• [MQTT-3.8.3-1]
  The Topic Filters in a SUBSCRIBE packet payload MUST be UTF-8 encoded strings as defined in Section 1.5.3.
• [MQTT-3.8.3-2]
  If the Server chooses not to support topic filters that contain wildcard characters it MUST reject any Subscription request whose filter contains them.
• [MQTT-3.8.3-3]
  The payload of a SUBSCRIBE packet MUST contain at least one Topic Filter / QoS pair. A SUBSCRIBE packet with no payload is a protocol violation.
• [MQTT-3-8.3-4]
  The Server MUST treat a SUBSCRIBE packet as malformed and close the Network Connection if any of Reserved bits in the payload are non-zero, or QoS is not 0,1 or 2.
• [MQTT-3.8.4-1]
  When the Server receives a SUBSCRIBE Packet from a Client, the Server MUST respond with a SUBACK Packet.
• [MQTT-3.8.4-2]
  The SUBACK Packet MUST have the same Packet Identifier as the SUBSCRIBE Packet that it is acknowledging.
• [MQTT-3.8.4-3]
  If a Server receives a SUBSCRIBE Packet containing a Topic Filter that is identical to an existing Subscription’s Topic Filter then it MUST completely replace that existing Subscription with a new Subscription. The Topic Filter in the new Subscription will be identical to that in the previous Subscription, although its maximum QoS value could be different. Any existing retained messages matching the Topic Filter MUST be re-sent, but the flow of publications MUST NOT be interrupted.
• [MQTT-3.8.4-4]
  If a Server receives a SUBSCRIBE packet that contains multiple Topic Filters it MUST handle that packet as if it had received a sequence of multiple SUBSCRIBE packets, except that it combines their responses into a single SUBACK response.
• [MQTT-3.8.4-5]
  The SUBACK Packet sent by the Server to the Client MUST contain a return code for each Topic Filter/QoS pair. This return code MUST either show the maximum QoS that was granted for that Subscription or indicate that the subscription failed.
• [MQTT-3.8.4-6]
  The Server might grant a lower maximum QoS than the subscriber requested. The QoS of Payload Messages sent in response to a Subscription MUST be the minimum of the QoS of the originally published message and the maximum QoS granted by the Server. The server is permitted to send duplicate copies of a message to a subscriber in the case where the original message was published with QoS 1 and the maximum QoS granted was QoS 0.
• [MQTT-3.9.3-1]
  The order of return codes in the SUBACK Packet MUST match the order of Topic Filters in the SUBSCRIBE Packet.
• [MQTT-3.9.3-2]
  SUBACK return codes other than 0x00, 0x01, 0x02 and 0x80 are reserved and MUST NOT be used.
• [MQTT-3.10.1-1]
  Bits 3,2,1 and 0 of the fixed header of the UNSUBSCRIBE Control Packet are reserved and MUST be set to 0,0,1 and 0 respectively. The Server MUST treat any other value as malformed and close the Network Connection.
• [MQTT-3.10.3-1]
  The Topic Filters in an UNSUBSCRIBE packet MUST be UTF-8 encoded strings as defined in Section 1.5.3, packed contiguously.
• [MQTT-3.10.3-2]
  The Payload of an UNSUBSCRIBE packet MUST contain at least one Topic Filter. An UNSUBSCRIBE packet with no payload is a protocol violation.
• [MQTT-3.10.4-1]
  The Topic Filters (whether they contain wildcards or not) supplied in an UNSUBSCRIBE packet MUST be compared character-by-character with the current set of Topic Filters held by the Server for the Client. If any filter matches exactly then its owning Subscription is deleted, otherwise no additional processing occurs.
• [MQTT-3.10.4-2]
  If a Server deletes a Subscription It MUST stop adding any new messages for delivery to the Client.
• [MQTT-3.10.4-3]
  If a Server deletes a Subscription It MUST complete the delivery of any QoS 1 or QoS 2 messages which it has started to send to the Client.
• [MQTT-3.10.4-4]
  The Server MUST respond to an UNSUBSUBCRIBE request by sending an UNSUBACK packet. The UNSUBACK Packet MUST have the same Packet Identifier as the UNSUBSCRIBE Packet.
• [MQTT-3.10.4-5]
  Even where no Topic Subscriptions are deleted, the Server MUST respond with an UNSUBACK.
• [MQTT-3.10.4-6]
  If a Server receives an UNSUBSCRIBE packet that contains multiple Topic Filters it MUST handle that packet as if it had received a sequence of multiple UNSUBSCRIBE packets, except that it sends just one UNSUBACK response.
• [MQTT-3.12.4-1]
  The Server MUST send a PINGRESP Packet in response to a PINGREQ packet.
• [MQTT-3.14.1-1]
  The Server MUST validate that reserved bits are set to zero and disconnect the Client if they are not zero.
• [MQTT-3.14.4-1]
  After sending a DISCONNECT Packet the Client MUST close the Network Connection.
• [MQTT-3.14.4-2]
  After sending a DISCONNECT Packet the Client MUST NOT send any more Control Packets on that Network Connection.
• [MQTT-3.14.4-3]
  On receipt of DISCONNECT the Server MUST discard any Will Message associated with the current connection without publishing it, as described in Section 3.1.2.5.