Null packet identifier rejected

[Juerd]

Mosquitto now (tested with 1.6.1) seems to require a non-null packet identifier for SUBSCRIBE messages. In previous versions (at least up to 1.5.8) it would allow \0\0.

The MQTT 3.1.1 specification says:

SUBSCRIBE, UNSUBSCRIBE, and PUBLISH (in cases where QoS > 0) Control Packets MUST contain a non-zero 16-bit Packet Identifier [MQTT-2.3.1-1].

However, mosquitto enforces this requirement for any QoS, instead of only where QoS > 0. I believe this is a bug. It certainly causes incompatibility with existing lazily implemented libraries (e.g. Juerd/Net-MQTT-Simple#6), and even though it's easy enough to work around, I think the old behavior of mosquitto was better because it more closely matched the MQTT 3.1.1 specification.

[ralight]

I believe your interpretation of the spec to be incorrect. I believe it is stating that SUBSCRIBE and UNSUBSCRIBE packets (which are always QoS 1) must contain a non-zero identifier. In addition PUBLISH packets which contain a packet identifier (i.e. those that are QoS > 0) must use a non-zero identifier. For PUBLISH packets using QoS=0, the packet identifier value is not important because it is not part of the packet.

If you refer back to version 3.1 of the spec the intention is much clearer (message ID and packet identifier are the same thing):

Do not use Message ID 0. It is reserved as an invalid Message ID.

Mosquitto is now stricter in some situations (as you have seen), in accordance with the mandatory statement

Unless stated otherwise, if either the Server or Client encounters a protocol violation,
it MUST close the Network Connection on which it received that Control Packet which
caused the protocol violation [MQTT-4.8.0-1].

From my point of view that means this is a "not a bug", unless you can provide better reasons to the contrary. I'm afraid in this situation appealing to Postel's law won't work.

[Juerd]

Thanks for explaining how to read the specification; indeed with your clarification in mind, I see that "in cases where" in 2.3.1 was only meant to apply to PUBLISH, not to each of the three preceding message types. Table 2.5 further confirms your interpretation.

I'm sorry to have wasted your time :)

(Regarding Postel's law, a case could be made for bugward compatibility, but I completely agree that it is fair and less of a maintenance burden to decide otherwise.)

[ralight]

Not a problem, I'd prefer to have things checked than not. Plus it was easier writing that explanation than many bugs I've needed to fix.