[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=67764#comment-67764 ]
Ken Borgendale commented on MQTT-498:
-------------------------------------
2.2.2 Properties
The last field in the Variable Header of the CONNECT, CONNACK, PUBLISH, PUBACK, PUBREC, PUBREL, PUBCOMP, SUBSCRIBE, SUBACK, UNSUBACK, DISCONNECT, and AUTH packet is a set of Properties. In the CONNECT packet a set of Properties exists as the Will Properties field within the Payload.
The set of Properties is composed of a Property Length followed by the Properties.
3.1.2.5 Will Flag
…
• 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 then Will Properties, Will Topic, and 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]
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 Properties, Will Topic, Will Message Field, User Name, Password [MQTT-3.1.3-1].
3.1.3.4 Will Properties
If the Will Flag is set to 1, the Will Properties is the next field in the Payload. The Will Properties consists of a Property Length and 0 or more Properties. The Server MUST send all Will Properties unaltered in the Will Message when it publishes the Will Message.
2.1.3.4.1 Property Length
The length of the Properties in the Will Properties encoded as a Variable Byte Integer.
3.1.3.4.2 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].
It is a Protocol Error to include the Payload Format Indicator more than once. 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.
2.1.3.4.3 Publication Expiry Interval
2 (0x02) Byte, Identifier of the Publication Expiry Interval.
Followed by the Four Byte Integer representing the Publication Expiry Interval. It is a Protocol Error to include the Publication Expiry Interval more than once.
If present, the Four Byte value is the lifetime of the Will Message in seconds abd us sent as the Publication Expiry Interval when the Server publishes the Will Message..
If absent, no Publication Expiry Interval is sent when the Server publishes the Will Message.
2.1.3.4.4 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.
2.1.3.4.5 Response Topic
8 (0x08) Byte, Identifier of the Response Topic.
Followed by a UTF-8 Encoded String which is used as the Topic Name for a response message. The Response Topic MUST be a UTF-8 Encoded String as defined in section 1.5.4 [MQTT-3.3.2-13]. The Response Topic MUST NOT contain wildcard characters [MQTT-3.3.2-14]. It is a Protocol Error to include the Response Topic more than once. The presence of a Response Topic identifies the Message as a Request.
Refer to section 4.10 for more information about Request / Response.
2.1.3.4.6 Correlation Data
9 (0x09) Byte, Identifier of the Correlation Data.
Followed by Binary Data. The Correlation Data is used by the sender of the Request Message to identify which request the Response Message is for when it is received. It is a Protocol Error to include Correlation Data more than once. If the Correlation Data is not present, the Requester does not require any correlation data.
The value of the Correlation Data only has meaning to the sender of the Request Message and receiver of the Response Message.
Refer to section 4.10 for more information about Request / Response
2.1.3.4.7 User Property
38 (0x26) Byte, Identifier of the 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 maintain the order of User Properties when publishing the Will Message [MQTT-3.3.2-18].
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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]