OASIS Message Queuing Telemetry Transport (MQTT) TCIcon indicating the project type

OASIS Message Queuing Telemetry Transport (MQTT) TC

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

Topic name has an upper length limit of 32,767 characters ?

    Details

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

      The Topic name MAY be any string which can be encoded as UTF-8 up to 65535 bytes in length.

      Show
      The Topic name MAY be any string which can be encoded as UTF-8 up to 65535 bytes in length.

      Description

      Snippet from Section 2.2 of v3.1 specification.
      ---------------------------------------------------------------
      The topic name is a UTF-encoded string. See the section on MQTT and UTF-8 for more information. Topic name has an upper length limit of 32,767 characters.

      Snippet in Appendix A -
      --------------------------------
      The following principles apply to the construction and content of a topic tree:
      > The length is limited to 64k but within that there are no limits to the number of
      levels in a topic tree.

      Should the topic length on PUBLISH command be restricted to 32,767 characters ?

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          Hide
          Permalink
          raphcohn Raphael Cohen (Inactive) added a comment -

          What are the impacts on making it 2^16? Are there any clients or existing brokers which explicitly create buffers as 2^15?

          Show
          raphcohn Raphael Cohen (Inactive) added a comment - What are the impacts on making it 2^16? Are there any clients or existing brokers which explicitly create buffers as 2^15?
          Hide
          Permalink
          ragupta2 Rahul Gupta (Inactive) added a comment -

          There is a interesting thread on this subject from Dan Anderson, Nick and Roger

          https://groups.google.com/forum/?fromgroups#!topic/mqtt/7GpQm1ZxI2M

          Show
          ragupta2 Rahul Gupta (Inactive) added a comment - There is a interesting thread on this subject from Dan Anderson, Nick and Roger https://groups.google.com/forum/?fromgroups#!topic/mqtt/7GpQm1ZxI2M
          Hide
          Permalink
          peterniblett Peter Niblett (Inactive) added a comment -

          There's clearly inconsistency between the words in 2.2 and Appendix A which we need to resolve.

          There's a hard upper limit of 65535 bytes because of the two byte length field that precedes the UTF-8 string. The reference to characters rather than bytes in 2.2 is interesting. It's either
          a) A hangover from an earlier spec in which the field was single-byte ASCII characters (in which case the intent was to limit you to 32767 bytes)
          b) An attempt to specify 65535 bytes based on an assumption that the UTF-8 characters would be at most 2 bytes long. As they can be three or four bytes long, you could theoretically exceed 65535 bytes and still be under 32767 characters.

          So taken literally, an implementation today would have to be able to cope with 65535 bytes anyway.

          I think we should remove the limit, leaving just the implicit limit of 65535 bytes imposed by the length prefix.

          Show
          peterniblett Peter Niblett (Inactive) added a comment - There's clearly inconsistency between the words in 2.2 and Appendix A which we need to resolve. There's a hard upper limit of 65535 bytes because of the two byte length field that precedes the UTF-8 string. The reference to characters rather than bytes in 2.2 is interesting. It's either a) A hangover from an earlier spec in which the field was single-byte ASCII characters (in which case the intent was to limit you to 32767 bytes) b) An attempt to specify 65535 bytes based on an assumption that the UTF-8 characters would be at most 2 bytes long. As they can be three or four bytes long, you could theoretically exceed 65535 bytes and still be under 32767 characters. So taken literally, an implementation today would have to be able to cope with 65535 bytes anyway. I think we should remove the limit, leaving just the implicit limit of 65535 bytes imposed by the length prefix.
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          Discussed on TC Meeting (23.05.2013): Assigned to Rahul to remove limit of 32767 bytes from 2.2 (Topic Name)

          Show
          coppen Richard Coppen (Inactive) added a comment - Discussed on TC Meeting (23.05.2013): Assigned to Rahul to remove limit of 32767 bytes from 2.2 (Topic Name)
          Hide
          Permalink
          ragupta2 Rahul Gupta (Inactive) added a comment -

          updated section 3.3.2.1 in WD-04
          ----------------------------------------------

          The Topic name MUST be a string which can be encoded as UTF-8 up to 65535 bytes in length. The Topic name MUST not contain wildcard characters. When received by a client that subscribed using wildcard characters, this string is the absolute topic specified by the originating publisher and not the subscription string used by the client.

          Show
          ragupta2 Rahul Gupta (Inactive) added a comment - updated section 3.3.2.1 in WD-04 ---------------------------------------------- The Topic name MUST be a string which can be encoded as UTF-8 up to 65535 bytes in length. The Topic name MUST not contain wildcard characters. When received by a client that subscribed using wildcard characters, this string is the absolute topic specified by the originating publisher and not the subscription string used by the client.
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          See WD04 Line 806
          Scheduled for review at next TC call (06.06.2013)

          Show
          coppen Richard Coppen (Inactive) added a comment - See WD04 Line 806 Scheduled for review at next TC call (06.06.2013)
          Hide
          Permalink
          coppen Richard Coppen (Inactive) added a comment -

          closed following TC call 06.06.2013

          Show
          coppen Richard Coppen (Inactive) added a comment - closed following TC call 06.06.2013

            People

            • Assignee:
              ragupta2 Rahul Gupta (Inactive)
              Reporter:
              ragupta2 Rahul Gupta (Inactive)
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: