I think there are some other loose ends on error handling for topic registration (which I'm trying to distill).

1.) First among these is that we really need to specify very clearly when the topic<> token registration and replacement of the token with the topic take place. Some examples: using QoS 2 delivery Method A, QoS 0 and 1 messages may overtake of QoS 2 messages. So it is possible that a QoS 2 message that establishes the topic mapping may arrive at the receiver later than subsequently send QoS 0 or 1 messages sent using a topic token. This can be avoided by saying that for either Method A or B, the registration of the topic token occurs when the PUBLISH arrives (and not when the PUBREC is sent or the PUBREL is received) or several race conditions occur. For example, if you're in the middle of performing the token>topic replacement on the receive side AND another PUBLISH arrives which alters that mapping, there is a race condition. It also means we have to specify that the original topic (and not the token) needs to be on unacknowledged message queue.

2.) I would also broaden your statement above that any condition that causes the topic registration to fail at the receiver must close the transport connection, or the Sending mapping will not match the receiving mapping, causing delivery to the wrong topic, or interleaving of unrelated data streams.

3.) We are now contemplating discarding packets in some cases (e.g. if A server knows the message is too big for the receiver, especially with QoS 0). This would break the integrity of the topic mapping.

I imagine there are others as well.

Commenting Ed's 1 and 3.

The Topic Alias is part of the PUBLISH packet, not PUBREC, PUBREL etc. and I thought that the procedures in MQTT-269 make it clear that the registration of the alias is done by the receiver when it receives the PUBLISH, and not at any later date.

Note that the connection used by client 1 to publish messages to a server is completely decoupled from the connection used by that server to forward publications to a second clients 2. When the server receives a PUBLISH from client 1 it substitutes the true topic name in place of the alias used by topic 1, when it forwards it on to client 2 it may choose to use an alias instead of the full topic name.. but if it does so it will be an alias established by the server in order to talk to client 2, and so won't necessarily be the same as the alias that was used by client 1.

A server is allowed to forward a QoS 0 message ahead of a QoS 2 on the same topic. If it wants to do this and use a Topic Alias it has to make sure it establishes it with the first message that it sends regardless of the QoS (or more precisely if it sends a message to a client that doesn't have a full topic name then it has to have made sure that it previously sent a message that established the alias).

Now let's consider just the QoS 0 message case. Suppose client 1 publishes a stream of QoS 0 messages to the server on a single topic, and the server forwards them to client 2. Suppose client 1 uses the first PUBLISH to establish the alias. It's important that the server records the alias even if it then decides it's going to discard the payload and not forward it to anyone else. That's because client 1 is going to be using that alias on its subsequent PUBLISH packets, and the server might want to forward them.

It is very important to note that the Topic Alias id/value pair on publish exists only from sender to receiver and is not forwarded with the message. This is different from other id/value pairs on publish which are forwarded. We might needs words to say that the receiver MUST NOT forward a topic alias.

Issue included in MQTTv5.0 CS01 December 25, 2017