OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Andrew Banks commented on MQTT-498:
-----------------------------------

Proposal discussed at 21 September TC.

Replace the current will message in the CONNECT packet with a PUBLISH packet 
embedded in the CONNECT packet in the same place.
The separate Will Topic is removed.
A single Will flag in the connect packet indicates the presence or absence of the Will PUBLISH Packet. 
The separate Will Qos and WillRetain flags must be set to zero.

The Connect packet becomes:

1 CONNECT Fixed Header, unchanged.

2 CONNECT Variable Header.
        1 Protocol Name, unchanged.
        2 Protocol version, unchanged.
        3 Connect Flags
          1 User Name Flag, unchanged.
          2 Password Flag, unchanged.
          3 Reserved MUST be 0 (Was Will Retain).
          4 Reserved MUST be 0 (Was Will QoS).
          5 Will Flag, 0 if no Will PUBLISH packet is present or 1 if the Will PUBLISH packet is present.
          6 Clean Start, unchanged.
          7 Reserved, unchanged.

        5 Keep Alive, unchanged.
        6 CONNECT Properties, unchanged.

3 CONNECT Payload
        1 Client Identifier (ClientID), unchanged.
         
        2 Will Topic, never present.
        3 Will Message, never present.

        2 Will PUBLISH Packet 
               Fixed header MQTT Control Packet type (3). Dup flag MUST be zero. Qos and Retain are the Will Qos and Will Retain.
               Remaining Length used to determine the length of the Will PUBLISH packet.
               Variable Header, 
                 Topic Name, The Will Topic name. 
                 No Packet Identifier, MUST not be present, even if Will Qos > 0. 
                 Properties, of the will message.
               Payload of the Will message.

        4 User name, unchanged.
        5 Password, unchanged.


The server MUST validate the Will PUBLISH packet as part of validating the CONNECT packet
it cannot defer validating it to the time the will message is published. If the PUBLISH 
packet within the CONNECT packet is malformed this results in the 129
0x81 Malformed Packet return code in CONNACK as usual.

Connack return codes:
 144 0x90 Will Topic Name invalid (Was "Topic Name invalid")
     The Will Topic Name is not malformed, but is not accepted by this Server.
 155 0x9B Will QoS not supported (Was "QoS not supported")
     The Server does not support the QoS set in Will PUBLISH packet.


Remain unchanged. 

And we should add:
160 0xA0 Will payload format invalid
    The Will payload format does not match the specified Will Payload Format Indicator.


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]