Major WD11 Notes.
Line 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.
PN: Hang on - this is either something that we require to happen (so it's normative) or it isn't,
in which case it's out of scope for this spec. I would choose the latter.
AB:I take your point. However, we have not said whether the state associated with the 3.1.1 client
is the same state as that associated with the 5.0 client, and consequently what expiry interval it has.
Leaving that open could lead to some divergent implementations.
KB:This really is just one possible implementation of multi version support.
It would make as much sense to say that a session is never shared between two versions of the spec.
I would recommend dropping this comments,
but as non-normative I do not care too much.
Line 1442
If a Server has not sent a Maximum QoS, and receives a QoS > 0 PUBLISH
packet and that QoS level exceeds its capabilities it MUST reply with a
PUBACK or PUBREC with the Return Code 0x9B (QoS not supported).
In the case of QoS 2 messages, the Server MUST process the subsequent
PUBREL packet and issue a PUBCOMP to complete the protocol flow.
AB: This should go. The server should declare its maximum Qos on connect,
not change its mind later.
RG:Agreed that this paragraph should be deleted.
Normative statements are not indexed for now.
Line 1447
Non-Normative comment
A Client is not required to support reception or transmission of QoS 1
or QoS 2 PUBLISH packets.
If this is the case, the Client simply restricts the maximum QoS field
in any SUBSCRIBE commands it sends to a value it can support.
AB:This is not true if the publication is unsolicited.
RG:This is also pointed out by Brian in MQTT-372 and the statement is very unclear.
May be we should get rid of this as well.
Line 1575
If the Client sends a Request Response Information with a value 1,
the Server MAY send the Response Information in the CONNACK.
AB: There seems to be a lot pf scope for interoperability problems here.
For example, if the clients uses this to form the reply to topic
and the server does not send it or if the server has authorized
a specific pattern for reply topics but the client does not request it.
It seems like the server should simply mandate that the
Reply Info is used whether or not it was asked for by the client.
KB:The whole area of Reply Info is very ugly.
However,
this is the compromise which allowed us to complete Request/Response.
The client may request it, and if so the server may respond with it,
and the contents are not defined other than being a string.
We can change the words if that would help,
but changing the concept is a core change.