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

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

In my code at least, putting in a full PUBLISH packet for the will would be a bunch of code, mostly because I still need to support the existing way it works for MQTTv3.1 and MQTTv3.1.1.  On the other hand I have all of the code to parse a PUBLISH packet, so at worst I need to duplicate parts of it.

Where does the Will Delay property go?  On the CONNECT or on the will PUBLISH ?

Do we allow Topic Alias to be in the will PUBLISH?  This is somewhat problematic as we return the allowed Topic Alias count on CONNACK.

Doing this implicitly raises the max length of the will message payload which is currently limited to 64KB.  I guess the server could still enforce any limit it likes as it has not yer told the client the MaxPacketSize.  

> 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)