These comments have pointed out that there are several places where we should tidy up and tighten the wording related to the Will Message. There are currently several normative statements to be found both in sections 3.1.2.5 and 3.14.4 and an additional statement (which doesn't contain the word MUST and so isn't labelled as normative) in 3.1.3.3.
1. The first normative statement is [MQTT-3.1.2.8] which can be found in section 3.1.2.5. This currently says
"If the Will Flag is set to 1 this indicates that a Will Message MUST be published by the Server when the Server detects that the Client is disconnected for any reason other than the Client flowing a DISCONNECT Packet".
While the meaning of this seems reasonably clear, there are some issues with it:
i) It's clear that no Will Message is sent if it is the server that performs the disconnection when it receives the DISCONNECT, but in 3.14.4 we state that "After sending a DISCONNECT Packet the Client MUST close the Network Connection". Now we don't want a Will Message when this happens either, but in this case it's not really the flowing of the DISCONNECT that causes the loss of the connection, but rather it is a decision of the client application that causes both the DISCONNECT to be flowed and the network connection to be closed. A small point maybe, but it manifests itself at the server in Michael's question 3, where he asks what happens if the server detects the dropped connection before it sees the DISCONNECT packet.
ii) It's not entirely clear what should happen in a race condition where a server is in the process of shutting down (and thus disconnecting the clients itself) when one of them sends a DISCONNECT
iii) It's a bit redundant to talk here about situations when the Will Message isn't published because we subsequently talk (in two places) about how the Will Message gets discarded when a DISCONNECT is processed. So it can't be published if it has been discarded.
To address these we propose to change statement 3.1.2-8 to emphasise the positive bit (the bit about storing the Will Message and publishing it) while still acknowledging that it might have been discarded by the time the network connection actually ends.
Change Statement 3.1.2-8 as follows:
>>If the Will Flag is set to 1 this indicates that a Will Message MUST be stored and subsequently published when the network connection is closed unless the Will Message has been deleted by the Server on receipt of a DISCONNECT Packet [MQTT-3.1.2-8]. Situations in which the Will Message is published include, but are not limited to:<<
---------------------------------------------------
2. The next change is a minor editorial change to [MQTT-3.1.2.10]. This currently says
"The will message MUST be removed from the stored Session state in the Server once it has been published or the Server has received a DISCONNECT packet from the Client. If the Will Flag is set to 0, no will message is published[MQTT-3.1.2.10]
The second sentence (about what happens if the Will Flag is 0) is a separate thought and should not be part of the [MQTT-3.1.2.10] statement. It's really a statement of the obvious rather than a normative statement because if there is no Will Message then it clearly can't be published.
So we propose to modify 3.1.2-10 to move that second sentence out of it:
>>The Will Message MUST be removed from the stored Session state in the Server once it has been published or the Server has received a DISCONNECT packet from the Client. [MQTT-3.1.2-10] If the Will Flag is set to 0, no will message is published.<<
----------------------------------------------------
3. Question 4 from Michael asks what happens if the server shuts down. While this is largely covered by [MQTT-3.1.2-8] there is the question of what happens if it has to shut down before it is able to start publishing the Will Messages.
We propose to add the following normative statement to cover this case as the last line before Section 3.1.2.6:
>> The Server SHOULD publish Will Messages promptly. In the case of a Server shutdown or failure the server MAY defer publication of Will Messages until a subsequent restart. If this happens there might be a delay between the time the server experienced failure and a Will message being published. <<
-----------------------------------------------------
4. Section 3.1.3.3 contains a restatement of the old [MQTT-3.1.2-8] text:
"The Will Message defines the Application Message that is to be published to the Will Topic if the Client is disconnected for any reason other than the Client sending a DISCONNECT Packet."
To keep this consistent with the new text in 3.1.2.5 we propose to replace it with a reference to that section as follows:
>>The Will Message defines the Application Message that is to be published to the Will Topic as described in 3.1.2.5<<
------------------------------------------------------
5. Section 3.14.4 (Disconnect response) currently contains another normative statement referring to the Will Message
"On receipt of DISCONNECT the Server MUST discard the Will Message without publishing it [MQTT-3.14.4-3], see Section 3.1.2.5. "
This duplicates part of [MQTT-3.1.2.10] (see above) and it's not good style to have two normative statements saying the same thing. On the other hand it is useful to be able to refer to the discarding of the Will Message at this point.
So we propose to remove the highlighting and the normative statement tag [MQTT-3.14.4-3] and reword it slightly to refer back to the place where the real normative statement can be found:
line 1381: Remove "MUST" change "discard" to "Discards" remove conformance statement label [MQTT-3.14.4-3] thus removing highligher marks.... Replace "see Section 3.1.2.5" with "as described in Section 3.1.2.5"
------------------------------------------------------
6. Minor editorial... Section 3.1.2.7 "Will Retain" would benefit from an introductory sentence
Under 3.1.2.7 "Will Retain" add >> This bit specifies if the Will Message is to be Retained when it is published<<
Major