[OASIS Issue Tracker] (MQTT-285) Subscribe options for retained messages

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ https://issues.oasis-open.org/browse/MQTT-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Borgendale updated MQTT-285:
--------------------------------

    Proposal: 
3.3.1.3 RETAIN

If the RETAIN flag is set to 1, in a PUBLISH Packet sent by a Client to a Server, the Server MUST store the Application Message and its QoS, so that it can be delivered to future subscribers whose subscriptions match its topic name [MQTT-3.3.1-5]. When a new subscription is established with the NoSendRetain flag set to 0, the last retained message, if any, on each matching topic name MUST be sent to the subscriber [MQTT-3.3.1-6].  When a new subscription is established with the NoSendRetain flag set to 1 a retained message MUST NOT be sent.  If the Server receives a QoS 0 message with the RETAIN flag set to 1 it MUST discard any message previously retained for that topic. It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time - if this happens there will be no retained message for that topic [MQTT-3.3.1-7]. See Section 4.1 for more information on storing state.

When sending a PUBLISH Packet to a Client the Server MUST set the RETAIN flag to 1 if a message is sent as a result of a new subscription being made by a Client  with the RetainAsPublished flag set to 0[MQTT-3.3.1-8]. It MUST set the RETAIN flag to 0 when a PUBLISH Packet is sent to a Client because it matches an established subscription regardless of how the flag was set in the message it received if the subscription was created with the RetainAsPublished flag set to 0 [MQTT-3.3.1-9].  For any subscription which was created with the RetainAsPublished flag set to 1, the Server MUST set the RETAIN flag to the same value as the RETAIN flag in the message it received.

Non normative comment
Setting the RetainAsPublished and/or NoSendRetained flags to 1 is useful for cases such as a bridge Client which sends on messages to another Server.  The NoSendRetained flag set to 1 can also be used for an application that only wants to receive change notifications.

3.8.3 Payload
The upper 3 bits of the Requested QoS byte are not used in the current version of the protocol. They are reserved for future use. The Server MUST treat a SUBSCRIBE packet as malformed and close the Network Connection if any of Reserved bits in the payload are non-zero, or QoS is not 0,1 or 2 [MQTT-3-8.3-4].
Bit 3 of the Requested QoS byte is defined as the NoSendRetain flag.  If the value is 0, matching retained messages, if any, are sent when the subscription is established.  If this value is 1, no matching retained messages are sent.
Bit 4 of the Requested QoS byte is defined as the RetainAsPublished flag.  If the value is 0, the Server sets the RETAIN flag when a message is published to the Client based on whether the message came from the retained store.  If the value is 1, the Server sets the RETAIN flag when a message is published to the Client equal to the RETAIN flag it received.  See section 3.3.1.3 for details of the handling of the RETAIN flag.



  was:
Add two new flags in the QoS flag of SUBSCRIBE
- NoRetain - Do not send messages with are retained at the time of the subscription.  Only messages which arrive after the subscription are sent.
- RetainAsPublished - Set the retain flag on an outgoing PUBLISH to the retain flag in the received message.


> Subscribe options for retained messages
> ---------------------------------------
>
>                 Key: MQTT-285
>                 URL: https://issues.oasis-open.org/browse/MQTT-285
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: New Feature
>          Components: futures
>    Affects Versions: 5
>            Reporter: Ken Borgendale
>            Assignee: Ken Borgendale
>
> This issue came up when reviewing MQTT-235 (nolocal) as it affects the bridge use case along with others.
> The current setting of the retain flag on PUBLISH and the handling of retained messages on SUBSCRIBE is normally correct when the client really is a subscribing client, it is not correct behavior when the client is going to forward the message on in a bridge or filter use case.
> There are two issues here
> 1. In some case the subscriber does not want to get any messages which are retained at the time of the subscription.
> 2. If the subscriber is going to re-publish the message it needs to know if the messages was published with the retain flag, rather than that it came from a retained source



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)