MQTT-SN Feature: Topic Registration

A. Add a new Identifier/Value pair for CONNECT (section 3.1.2)
Byte 34 (0x22) Identifier of the Maximum Alias. Followed by the Two Byte Integer representing the Maximum Alias value. It is a protocol error to include the Maximum Alias value more than once.
This value indicates the highest value that the Client is willing to accept as a Topic Alias sent by the Server. The Client can use this value to limit the number of topic aliases that it is willing to hold on this Connection. A value of 0 indicates that the Client does not accept any Topic Aliases on this connection.
If this value is Identifier/Value pair is not present the client MUST act as if its value is zero.

B. Add a new Identifier/Value pair for CONNACK (section 3.2.2)
Byte 34 (0x22) Identifier of the Maximum Alias. Followed by the Two Byte Integer representing the Maximum Alias value. It is a protocol error to include the Maximum Alias value more than once.
This value indicates the highest value that the Server is willing to accept as a Topic Alias sent by the Client. The Server can use this value to limit the number of topic aliases that it is willing to hold on this Connection. A value of 0 indicates that the Server does not accept any Topic Aliases on this connection.
If this value is Identifier/Value pair is not present the client MUST act as if its value is zero.

C. Replace the paragraph in wd-06 section 3.3.2.1
Current text:
"To avoid repeating the same Topic Name in successive PUBLISH Packets the sender can use a zero-length Topic Name to mean the same Topic Name as was used with the previous PUBLISH packet flowing on the TCP connection. The zero length UTF-8 String representing the Topic Name consists of two zero bytes only."

Replacement text:
"A Topic Name might be quite long, and to reduce the size of the PUBLISH packet the sender can use a Topic Alias instead. The Topic Alias is described in section 3.2.2.x and in general it is shorter than the the full Topic Name. If it provides a Topic Alias the sender is permitted to supply a zero-length String, consisting of two zero bytes only, for the Topic Name. "

D. Add a new identifier/value pair to section 3.3.2 called Topic Alias

"3 (0x03) Byte, Identifier of the Topic Alias. Followed by the Two Byte Integer representing the Topic Alias
A Topic Alias is an integer value that can be used to identify the Topic, instead of including the full Topic Name. This reduces the size of the PUBLISH packet, and is of use if Topic Names are lengthy and the same Topic Names are used repetitively within a given Connection.

If a Topic Alias has been established at the receiver a sender is permitted to send a PUBLISH packet that contains that Topic Alias and supplying a zero-length String in place of the Topic Name. The receiver then treats the incoming PUBLISH as if it had contained the full Topic Name corresponding to the alias.

The Sender decides whether to use an alias and gets to choose the alias value. It establishes an alias by including a non-zero length Topic Name and a Topic Alias value in the PUBLISH packet. When it receives a packet like this the Receiver processes the packet as normal, but it also records the mapping of Topic Alias to full Topic Name.

A Sender is permitted to send a subsequent PUBLISH in the same session that has the same Topic Alias value and a different Topic Name. If it does this the Topic Alias is remapped to the Topic Name in this subsequent packet.

Like Packet Identifiers, Topic Alias mappings are scoped to the MQTT Connection and last only for the lifetime of that Connection. A receiver MUST NOT carry forward any Topic Alias mappings from one Connection to another.

A Topic Alias of 0 is not permitted. A Sender MUST NOT send a PUBLISH packet containing a Topic Alias which has the value 0.

A Client MUST NOT send a PUBLISH packet with a Topic Alias whose value exceeds the Maximum Alias value returned by the Server in the CONNACK packet.

A Server MUST NOT send a PUBLISH packet with a Topic Alias whose value exceeds the Maximum Alias value sent by the Client in the CONNECT packet.

A Server MUST accept all Topic Alias values greater than 0 and less than or equal to the Maximum Alias value that it returned in the CONNACK packet.

A Client MUST accept all Topic Alias values greater than 0 and less than or equal to the Maximum Alias value that it sent in the CONNECT packet.

The Topic Alias mappings used by the Client and Server are independent from each other. Thus when a Client sends a PUBLISH containing a Topic Alias value of 1 to a Server and the Server sends a PUBLISH with a Topic Alias value of 1 to that Client they will in general refer be referring to different Topics. "

E. Add new paragraphs at the end of section 3.3.5 Actions

The receiver MUST reject a PUBLISH packet if it has a zero-length String in the Topic Name field and does not contain a Topic Alias. In the case of a QoS 1 or QoS 2 PUBLISH the receiver sends a No Topic return code on the PUBACK or PUBREL response.

If the PUBLISH packet contains a Topic Alias, the Receiver processes it as follows:

a) A Topic Alias value of zero is treated as a Protocol Error.

b) If the receiver has already established a mapping for the Topic Alias then
    - If the packet has a zero-length String in the Topic Name field, the receiver processes it using the Topic Name that corresponds to the Topic Alias
    - If the packet contains a non-zero length Topic Name, the receiver processes the packet using that Topic Name and updates its mapping for the Topic Alias to point to the Topic Name from the incoming packet

b) If the Receiver doesn't already have a mapping for this Topic Alias
    - If the packet has a zero-length String in the Topic Name field, the receiver MUST reject it. In the case of a QoS 1 or QoS 2 PUBLISH the receiver sends a No Topic return code in the PUBACK or PUBREL response.
    - If the packet contains a non-zero length Topic Name, the receiver processes the packet using that Topic Name and in addition it adds the Topic Alias to its list of established Topic Alias mappings, provided that it is less than or equal to the Maximum Alias supported by the receiver for this connection. The Alias mapping is added even if publishing of the Application Message itself fails.
    - If the Topic Alias exceeds the Maximum Alias, the receiver still processes the packet using the Topic Name from the packet, but does not add the Topic Alias mapping to its list. In the case of a QoS 1 or QoS 2 PUBLISH it sends an Alias Not Accepted return code on the PUBACK or PUBREL response.

F. Add the following return codes to Tables 3.4 PUBACK Return codes and 3.5 PUBREC Return codes

17 0x11 Alias Not Accepted The requested Topic Alias was too large
136 0x88 No Topic No Topic Name given, or Topic Alias was invalid

G. Revert the bulleted list in 4.7.3 back to the 3.1.1 version

Specifically this means :
1. "All Topic Filters MUST be at least one character long " goes back to being "All Topic Names and Topic Filters MUST be at least one character long [MQTT-4.7.3-1]"
2. Remove "If a Topic Name containing zero characters is received, then the most recent Topic Name received containing at least one character, on the same TCP connection is used in its place. "
3. Remove "It is a protocol error to send only PUBLISH packets containing Topic Names containing zero characters on a TCP connection. "

The Proposal is updated to address the points agreed at the Face to Face meeting:

• Maximum Alias value is now the highest alias that can be used, rather than a count of the total number of aliases that can be used.
• There are separate Maximum Alias values for Client and Server
• A Topic Alias of zero is invalid.
• An Alias is established, even if processing of the publish itself fails.

Changes to be considered in further JIRAs:

• Changing the name from Topic Alias to something else
• Changes to the error handling, (NAK vs connection dropping) including what happens if the Topic Alias value is bad, but the rest of the PUBLISH is ok