[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=67753#comment-67753 ]
Ken Borgendale commented on MQTT-498:
-------------------------------------
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.
> 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]