We discussed this extensively in MQTT-16. My understanding is the same as Al's, namely we decided that a topic name with a leading $ is never matched by a topic filter with a leading + or #, regardless of whether the server has defined any $xxx topics or not.

I think the reason it doesn't have a MUST in it was simply to make it look better as an English statement. However we need to clarify this as the fact that Section 4.2.7 starts off with a MAY and this statement is included in an apparently subordinate 4.2.7.1 makes it look as if it might only apply in cases where the server has defined $xxx topics.

Incidentally this shows one of the problems of "hanging paragraphs" (see mqtt-142). If the bit saying the server MAY define $xxx was in 4.2.7.1 and the bit about subscription matching was in 4.2.7.2 then it would be more obvious that they are independent

I certainly was one of those who read the text in the subordinate section as being under the MAY in the superior section. I agree that the text as it exists is a bit confusing.

The significant problem in defining this as a MUST is dealing with the MQTT version. An MQTT connection has a version, but topic matching involves multiple connections: a publishing connection, a connection which creates a subscription, and a connection which consumes from a subscription. These could be at differing MQTT versions. If we agree that the normative language here is confined to cases where the involved connections are all at V3.1.1 then making this a strict rule is OK. This is one of the few cases where conformance deals with multiple connections and therefore multiple possible versions.

My preference is to say that an MQTT Server MAY define topics starting with $, and SHOULD NOT match such defined topics with a leading wildcard. This would allow us to continue the current $SYS rules for V3.1 and honor the $ rule for V3.1.1. The alternative is to define mixtures of connection versions as being outside the scope of this spec.

TC approve Jira proposal TC call 27.03.2014