XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 3.1.1
    • Fix Version/s: 3.1.1
    • Component/s: edits
    • Labels:
      None
    • Resolution:
      Hide

      Fixed in WD17

      Show
      Fixed in WD17

      Description

      1) [MQTT-2.1.2-5] used to say "The value of the Dup flag from an incoming PUBLISH packet MUST NOT be propagated ... " but this was a bit misleading as it could be read to say you are never allowed to send the same value on the outbound value - and of course in many cases you would, so we changed "MUST NOT be" to "is not". To compensate for this would could change the "is" in the second sentence to "MUST be", i.e.

      The value of the Dup flag from an incoming PUBLISH packet is not propagated when the PUBLISH Packet is sent to subscribers by the Server. The Dup flag in the outgoing PUBLISH packet MUST BE set independently of the Dup flag in the incoming PUBLISH packet. [MQTT-2.1.2-5].

      2). What [MQTT-2.1.2-8] is trying to say is that if you start off with a QoS 1 or 2 retained message on a topic and then send a QoS 0 retained message to that topic, it MUST delete the previous retained message, regardless for how long it actually retains the QoS 0 message. Taken to the limit, the implementation may choose not to retain the QoS 0 message at all, but must at least delete the previous retained message. The text in the spec came from issue MQTT-10, and you must have interpreted it as a MUST-like normative statement when assigning it a number.

      How about the following editorial clarification?

      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 discard it at any time. If this happens there will be no retained message for that topic. [MQTT-2.1.2-8]

      Existing:

      The UTF-8 encoded sequence 0xEF 0xBB 0xBF is always to be interpreted to mean U+FEFF ("ZERO WIDTH NO-BREAK SPACE") wherever it appears in a string and must never be skipped over or stripped off by a packet receiver.

      Suggested:

      The UTF-8 encoded sequence 0xEF 0xBB 0xBF is always to be interpreted to mean U+FEFF ("ZERO WIDTH NO-BREAK SPACE") wherever it appears in a string and MUST NOT be skipped over or stripped off by a packet receiver.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              andrew_banks Andrew Banks (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: