Affects Version/s: 5, wd11
Fix Version/s: wd12
Line 1047. The WD-12 level of the specification no longer mentions
interoperation of Session Expiry with the Version 3.1.1 specification.
Line 1442. WD-12 has no 0x9B return code other than on DISCONNECT.
The server can set maximum on CONNACK, it can't change to
not supporting it later on. Added a sentence to
PUBLISH allowing the client to send 0x9B on DISCONNECT
in response to an unsolicited PUBLISH with a QoS greater
than its maximum.
Line 1575. No change required.Line 1047. The WD-12 level of the specification no longer mentions interoperation of Session Expiry with the Version 3.1.1 specification. Line 1442. WD-12 has no 0x9B return code other than on DISCONNECT. The server can set maximum on CONNACK, it can't change to not supporting it later on. Added a sentence to PUBLISH allowing the client to send 0x9B on DISCONNECT in response to an unsolicited PUBLISH with a QoS greater than its maximum. Line 1575. No change required.
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.
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.
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.
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.
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.