[OASIS Issue Tracker] (MQTT-498) No way to set properties on will message

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/MQTT-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=67728#comment-67728 ] 

Ken Borgendale commented on MQTT-498:
-------------------------------------

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.



> No way to set properties on will message
> ----------------------------------------
>
>                 Key: MQTT-498
>                 URL: https://issues.oasis-open.org/browse/MQTT-498
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 5, CSD01
>            Reporter: Ian Craggs
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)