Major There is no way to set properties on the will message. This may have been discussed but on implementation it seems like a significant omission and asymmetry. Content type and payload format, are two examples of properties which would be very useful.
The behaviour of properties on retained messages appears to be unspecified. It could be interpreted that properties are not stored nor propagated, but that seems unlikely to be desirable. In the event of propagation, the behaviour of some properties such as the publication expiry interval, should be clarified. I suggest that the "time of receipt" for a retained message should be the time of receipt of the subscribe request which triggers it.
For option B (use a Publish Packet) the text added and modified in the spec would be
3.1.2.3 Connect Flags
The Connect Flags byte contains several parameters specifying the behavior of the MQTT connection. It also indicates the presence or absence of fields in the Payload.
Figure 3 4 - Connect Flag bits
Bit 7 6 5 4 3 2 1 0
User Password Reserved Reserved Reserved Will Clean Reserved
Name Flag Flag Flag Start
byte 8 X X 0 0 0 X X 0
The Server MUST validate that the reserved flag in the CONNECT packet is set to 0 [MQTT-3.1.2-3]. If the reserved flag is not 0 it is a Malformed Packet. Refer to section 4.13 for information about handling errors.
3.1.2.5 Will Flag
Position: bit 2 of the Connect Flags.
If the Will Flag is set to 1 this indicates that a Will Message MUST be stored on the Server and associated with the Session [MQTT-3.1.2-7]. The Will Message MUST be published after the Network Connection is subsequently closed and either the Will Delay Interval has elapsed or the Session ends, unless the Will Message has been deleted by the Server on receipt of a DISCONNECT packet with Reason Code 0x00 (Normal disconnection) or a new Network Connection for the ClientID is opened before the Will Delay Interval has elapsed [MQTT-3.1.2-8].
Situations in which the Will Message is published include, but are not limited to:
• An I/O error or network failure detected by the Server.
• The Client fails to communicate within the Keep Alive time.
• The Client closes the Network Connection without first sending a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection).
• The Server closes the Network Connection without first receiving a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection).
If the Will Flag is set to 1 the Will Message Field MUST be present in the Payload [MQTT-3.1.2-9]. 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 with a Reason Code of 0x00 (Normal disconnection) from the Client [MQTT-3.1.2-10].
[Continue with existing text after: The Server SHOULD publish]
Remove 3.1.2.6 Will QoS
Remove 3.1.2.7 Will Retain
Remove 3.1.3.2 Will Topic
All sections following these are renumbered. All references into section 3.* need to be validated and changed as required.
3.1.3 CONNECT Payload
The Payload of the CONNECT packet contains one or more fields, whose presence is determined by the flags in the Variable Header. These fields, if present, MUST appear in the order Client Identifier, Will Message Field, User Name, Password [MQTT-3.1.3-1].
3.1.3.5 Will Message Field
If the Will Flag is set to 1 the Will Message Field is the next field in the Payload. The Will Message Field defines the Application Message which is to be published as a Will Message as described in section 3.1.2.5. This field is in the same format at a PUBLISH packet as described in section 3.3 including the Fixed Header, the Variable Header, and the Payload. The length of the Will Message is determined using the Remaining Length in the Fixed Header plus the size of the Fixed Header.
The Will Message field MUST have the valid format of a PUBLISH packet as described in section 3.3 except that if the Packet Identifier exists, it MUST have the value 0.
The Will Message field MUST NOT contain the properties Subscription Identifier or Topic Alias. The DUP flag in the Will Message MUST be 0.
The Server MUST validate that the Will Message Field. If it is not valid, the Server MAY send a CONNACK with a Reason Code of 0x80 or greater as described in section 4.13 before closing the Network Connection.
The QoS and RETAIN fields in the PUBLISH Fixed Header MUST be used to publish the Will Message. The Will Message MUST be sent to the topic defined in the Will Message Field. All properties specified in the Will Message Field MUST be sent on the Will Message when it is published.
The PUBLISH Actions defined in section 3.3.4 are performed at the time that the Will Message is published and not at the time the CONNECT packet is processed. Regardless of the QoS in the Will Message Field, no response is sent.
These are the spec change proposals for Option C (Add a Will Properties field in the CONNECT payload)
2.2.2 Properties
The last field in the Variable Header of the CONNECT, CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBACK, DISCONNECT, and AUTH packet is a set of Properties. In the CONNECT packet a set of Properties exists as the Will Properties field within the Payload.
The set of Properties is composed of a Property Length followed by the Properties.
3.1.2.5 Will Flag
…
• The Server closes the Network Connection without first receiving a DISCONNECT packet with a Reason Code 0x00 (Normal disconnection).
If the Will Flag is set to 1 then Will Properties, Will Topic, and Will Message Field MUST be present in the Payload [MQTT-3.1.2-9]. 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 with a Reason Code of 0x00 (Normal disconnection) from the Client [MQTT-3.1.2-10].
[Continue with existing text after: The Server SHOULD publish]
3.1.3 CONNECT Payload
The Payload of the CONNECT packet contains one or more fields, whose presence is determined by the flags in the Variable Header. These fields, if present, MUST appear in the order Client Identifier, Will Properties, Will Topic, Will Message Field, User Name, Password [MQTT-3.1.3-1].
3.1.3.4 Will Properties
If the Will Flag is set to 1, the Will Properties is the next field in the Payload. The Will Properties consists of a Property Length and 0 or more Properties. The Server MUST send all Will Properties unaltered in the Will Message when it publishes the Will Message.
2.1.3.4.1 Property Length
The length of the Properties in the Will Properties encoded as a Variable Byte Integer.
3.1.3.4.2 Payload Format Indicator
1 (0x01) Byte, Identifier of the Payload Format Indicator.
Followed by the value of the Payload Format Indicator, either of:
• 0 (0x00) Byte Indicates that the Will Message is unspecified bytes, which is equivalent to not sending a Payload Format Indicator.
• 1 (0x01) Byte Indicates that the Will Message is UTF-8 Encoded Character Data. The UTF-8 data in the Payload MUST be well-formed UTF-8 as defined by the Unicode specification [Unicode] and restated in RFC 3629 [RFC3629].
It is a Protocol Error to include the Payload Format Indicator more than once. The Server MAY validate that the Will Message is of the format indicated, and if it is not send a CONNACK with the Reason Code of 0x99 (Payload format invalid) as described in section 4.13.
2.1.3.4.3 Publication Expiry Interval
2 (0x02) Byte, Identifier of the Publication Expiry Interval.
Followed by the Four Byte Integer representing the Publication Expiry Interval. It is a Protocol Error to include the Publication Expiry Interval more than once.
If present, the Four Byte value is the lifetime of the Will Message in seconds abd us sent as the Publication Expiry Interval when the Server publishes the Will Message..
If absent, no Publication Expiry Interval is sent when the Server publishes the Will Message.
2.1.3.4.4 Content Type
3 (0x03) Identifier of the Content Type.
Followed by a UTF-8 Encoded String describing the content of the Will Message. It is a Protocol Error to include the Content Type more than once. The value of the Content Type is defined by the sending and receiving application.
2.1.3.4.5 Response Topic
8 (0x08) Byte, Identifier of the Response Topic.
Followed by a UTF-8 Encoded String which is used as the Topic Name for a response message. The Response Topic MUST be a UTF-8 Encoded String as defined in section 1.5.4 [MQTT-3.3.2-13]. The Response Topic MUST NOT contain wildcard characters [MQTT-3.3.2-14]. It is a Protocol Error to include the Response Topic more than once. The presence of a Response Topic identifies the Message as a Request.
Refer to section 4.10 for more information about Request / Response.
2.1.3.4.6 Correlation Data
9 (0x09) Byte, Identifier of the Correlation Data.
Followed by Binary Data. The Correlation Data is used by the sender of the Request Message to identify which request the Response Message is for when it is received. It is a Protocol Error to include Correlation Data more than once. If the Correlation Data is not present, the Requester does not require any correlation data.
The value of the Correlation Data only has meaning to the sender of the Request Message and receiver of the Response Message.
Refer to section 4.10 for more information about Request / Response
2.1.3.4.7 User Property
38 (0x26) Byte, Identifier of the User Property.
Followed by a UTF-8 String Pair. The User Property is allowed to appear multiple times to represent multiple name, value pairs. The same name is allowed to appear more than once.
The Server MUST maintain the order of User Properties when publishing the Will Message [MQTT-3.3.2-18].
Non-normative comment
This property is intended to provide a means of transferring application layer name-value tags whose meaning and interpretation are known only by the application programs responsible for sending and receiving them.
At the 2017-10-12 MQTT TC it was decided to hold a ballot to choose which option. The ballot ended OptionA=2, OptionC=9.
At the 2017-10-19 MQTT Option C was accepted as the resolution.
Issue included in MQTTv5.0 CS01 December 25, 2017
For option A (add properties to CONNECT) the text added to the spec would be:
3.1.2.11.12 Payload Format Indicator
1 (0x01) Byte, Identifier of the Payload Format Indicator.
Followed by the value of the Payload Format Indicator, either of:
• 0 (0x00) Byte Indicates that the Will Message is unspecified bytes, which is equivalent to not sending a Payload Format Indicator.
• 1 (0x01) Byte Indicates that the Will Message is UTF-8 Encoded Character Data. The UTF-8 data in the Payload MUST be well-formed UTF-8 as defined by the Unicode specification [Unicode] and restated in RFC 3629 [RFC3629].
A Server MUST send the Payload Format Indicator unaltered when it publishes the Will Message [MQTT-3.1.2-34]. The Server MAY validate that the Will Message is of the format indicated, and if it is not send a CONNACK with the Reason Code of 0x99 (Payload format invalid) as described in section 4.13.
3.1.2.11.13 Publication Expiry Interval
2 (0x02) Byte, Identifier of the Publication Expiry Interval.
Followed by the Four Byte Integer representing the Publication Expiry Interval.
If present, the Four Byte value is the lifetime of the Will Message in seconds. The Server MUST send the Publication Expiry Interval when it publishes the Will Message [MQTT-3.1.2-35].
If absent, no Publication Expiry Interval is sent when the Server publishes the Will Message.
3.1.2.11.14 Content Type
3 (0x03) Identifier of the Content Type.
Followed by a UTF-8 Encoded String describing the content of the Will Message. It is a Protocol Error to include the Content Type more than once. The value of the Content Type is defined by the sending and receiving application.
A Server MUST send the Content Type unaltered when it publishes the Will Message [MQTT-3.1.2-36].
Non-normative comment
The UTF-8 Encoded String may use a MIME content type string to describe the contents of the Will Message. However, since the sending and receiving applications are responsible for the definition and interpretation of the string, MQTT performs no validation of the string except to ensure it is a valid UTF-8 Encoded String.
3.1.2.11.15 Will User Property
29 (0x1D) Byte, Identifier of the Will User Property.
Followed by a UTF-8 String Pair. The User Property is allowed to appear multiple times to represent multiple name, value pairs. The same name is allowed to appear more than once.
The Server MUST send each Will User Property as a User Propertiy when ist publishes the Will Message [MQTT-3.1.2-37]. The Server MUST maintain the order of Will User Properties when publishing the Will Message [MQTT-3.1.2-38].
Non-normative comment
This property is intended to provide a means of transferring application layer name-value tags whose meaning and interpretation are known only by the application programs responsible for sending and receiving them.