i) At the moment we don't have any normative requirements on underlying transport protocols.
That looks a bit odd, but I am ok with that (I think this was a decision we made in 3.1.1).
However TLS and WebSocket are listed as Normative references
>>>TLS is now a non normative reference. Websocket is normative because we
>>>specify some constraints on how it is used.
ii) 4.10.2 (determining a response topic) is shown as Non-Normative,
but I think it makes sense to have it Normative,
as it includes the statement that the Response Info property is OPTIONAL.
>>>The OPTIONAL response info on CONNACK is now part of the normative definition of the property,
>>>The description in 4.10.2 is still non normative.
iii)4.11 (Server redirection) includes Normative language,
e.g. "the Server MAY also send a Server Reference to indicate the location of the
Server or Servers the Client SHOULD use.".
However the format of Server Reference is vendor-specific,
so I don't see how we can make normative statements about it.
>>> This requires a TC decision to change this to MUST.
3. Error handling on QoS 2.
i) We don't say anything about errors in 4.3.3.
Should the sender abandon the flow if it gets an error on PUBREC?
ii) When does a packet id become available for reuse if an error occurs?
>>> 4.3.3 says
The Packet Identifier becomes available for reuse
once the sender has received the PUBCOMP packet or a PUBREL with a Return Code
of 0x80 or greater.
iii) What is the meaning of 0x91 - Packet identifier in use? When should it be used,
and what should you do if you receive a packet that contains it?
>>>> I added
Non-Normative comment
For Return Code 0x91 (Packet identifier in use),
the response to this is either to try to fix the state,
or to reset the Session state by connecting using Clean Start set to 1,
or to decide if the Client or Server implementations are defective.
4. Flow control paragraph
Simplify description
>>>>> This now reads as:
4.9 Flow Control
Clients and Servers control the number of unacknowledged PUBLISH packets they
receive by using a Receive Maximum value as described in section 3.1.2.14 and
3.2.2.5. The Receive Maximum establishes a send quota which is used to limit
the number of PUBLISH QOS > 0 packets which can be sent without receiving an
PUBACK (for QoS 1) or PUBCOMP (for QoS 2). The PUBACK and PUBCOMP replenish
the quota in the manner described below.
The Client or Server MUST set its initial send quota to a non-zero value not
exceeding the Receive Maximum [MQTT-4.9.0-1].
Each time the Client or Server sends a PUBLISH packet at QoS > 0, it
decrements the send quota. If the send quota reaches zero, the Client
or Server MUST NOT send any more PUBLISH packets with QoS > 0 [MQTT-4.9.0-2].
It MAY continue to send PUBLISH packets with QoS 0, or it MAY choose
to suspend sending these as well. The Client and Server MUST continue
to process and respond to all other MQTT Control Packets even if the quota
is zero [MQTT-4.9.0-3].
Each time a PUBACK or PUBCOMP packet is received,
the send quota is incremented by 1. The increment is applied regardless of
whether the PUBACK or PUBCOMP carried an error code.
The send quota is not incremented if it is already equal to the
initial send quota. The attempt to increment above the initial
send quota might be caused by the retransmission of a PUBREL packet
after a new Network Connection is established.
Refer to section 3.3.4 for a description of how Clients
and Servers react if they are sent more PUBLISH packets
than the Receive Maximum allows.
The send quota and Receive Maximum value are not preserved across
Network Connections, and are re-initialized with each new Network Connection
as described above. They are not part of the session state.
Major