[OASIS Issue Tracker] (MQTT-498) No way to set properties on will message. Property behaviour on retained messages unspecified

[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=67175#comment-67175 ] 

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

1. I suggest we say that there is no way to set any properties on a will message.

2. I would say that the properties of a retained message (other than the transient property Topic Alias) must be forwarded with the message, and thus they must be stored with the retained message to be able to forward them.  I am not sure we need to say this but I do not see a problem in doing so.

3. We need to clarify that the meaning of a zero length retained message means that the payload is zero bytes, regardless of whether any properties exist.

4. I do think we need to explicitly document the meaning of message expiry for retained messages.  The most useful meaning is that when a the current retained message for a topic expires, it is removed from the store and there is no retained message for that topic.

> No way to set properties on will message. Property behaviour on retained messages unspecified
> ---------------------------------------------------------------------------------------------
>
>                 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)