Uploaded image for project: 'OASIS Message Queuing Telemetry Transport (MQTT) TC'
  1. OASIS Message Queuing Telemetry Transport (MQTT) TC
  2. MQTT-285

Subscribe options for retained messages

    XMLWordPrintable

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 5
    • Fix Version/s: 5, wd08
    • Component/s: core
    • Labels:
      None
    • Proposal:
      Hide

      In the Subscription Options byte in SUBSCRIBE, define bit 3 as RetainAsPublished. If this bit is set, when a message is published due to this subscription, the RETAIN flag in the PUBLISH is set RETAIN equal to the value of the RETAIN in the messages as received. (Non normative) A common use of this is for bridging where it is important to know whether the sender intended this to be a retained message.

      In the Subscription Options byte in SUBSCRIBE, define bits 4 and 5 with the values
      0 = Send retained messages at subscribe
      1 = Only send retained messages for a new subscription
      2 = Do not send retained messages on subscribe
      3 = malformed packet

      (Non normative) A common use of this is for bridging where we do not want to send the retained messages across the bridge as we are also sending the original retain bits. This is also useful to control whether to send retained messages in the case of a re-subscribe which is done in the case of connecting to an existing session where we are uncertain of the state of the subscriptions.

      Show
      In the Subscription Options byte in SUBSCRIBE, define bit 3 as RetainAsPublished. If this bit is set, when a message is published due to this subscription, the RETAIN flag in the PUBLISH is set RETAIN equal to the value of the RETAIN in the messages as received. (Non normative) A common use of this is for bridging where it is important to know whether the sender intended this to be a retained message. In the Subscription Options byte in SUBSCRIBE, define bits 4 and 5 with the values 0 = Send retained messages at subscribe 1 = Only send retained messages for a new subscription 2 = Do not send retained messages on subscribe 3 = malformed packet (Non normative) A common use of this is for bridging where we do not want to send the retained messages across the bridge as we are also sending the original retain bits. This is also useful to control whether to send retained messages in the case of a re-subscribe which is done in the case of connecting to an existing session where we are uncertain of the state of the subscriptions.

      Description

      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

        Attachments

          Activity

            People

            • Assignee:
              ken.borgendale Ken Borgendale (Inactive)
              Reporter:
              ken.borgendale Ken Borgendale (Inactive)
            • Watchers:
              4 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved: