In the MQTT specification there are connect flags which governs the retention and state on server and client.
The clean session specification suggests:
3.1.2.4 Clean Session Position: bit 1 of the Connect Flags byte.
This bit specifies the handling of the Session state. The Client and Server can store Session state to enable reliable messaging to continue across a sequence of Network Connections. This bit is used to control the lifetime of the Session state.
If CleanSession is set to 0, the Server MUST resume communications with the Client based on state from the current Session (as identified by the Client identifier). If there is no Session associated with the Client identifier the Server MUST create a new Session. The Client and Server MUST store the Session after the Client and Server are disconnected [MQTT-3.1.2-4].
After the disconnection of a Session that had CleanSession set to 0, the Server MUST store further QoS 1 and QoS 2 messages that match any subscriptions that the client had at the time of disconnection as part of the Session state
So, whenever client is connecting again after a disconnect the broker would relay all QoS-1 and QoS-2 messages which are not acknowledged. So, broker has a state. And to maintain the state for every client, the server would use some database for retention. Is there a way to give Time to Live for these messages state (which the server would store). How to tell broker to drop (i.e, not to relay) any messages which is older than; let say 5 days.
Basically, we want to use clean session = 0 with QoS-1; but how to clear broker state with old messages? Don't want to receive older messages than 5 days, even when unacknowledged.
MQTT 5.0 allows setting a Message Expiry Interval for publish.
https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901112
3.3.2.3.3 Message Expiry Interval
2 (0x02) Byte, Identifier of the Message Expiry Interval.
Followed by the Four Byte Integer representing the Message Expiry Interval.
If present, the Four Byte value is the lifetime of the Application Message in seconds. If the Message Expiry Interval has passed and the Server has not managed to start onward delivery to a matching subscriber, then it MUST delete the copy of the message for that subscriber [MQTT-3.3.2-5].
If absent, the Application Message does not expire.
The PUBLISH packet sent to a Client by the Server MUST contain a Message Expiry Interval set to the received value minus the time that the Application Message has been waiting in the Server [MQTT-3.3.2-6]. Refer to section 4.1 for details and limitations of stored state.