All line numbers refer to WD20
A. Clarify the Topic wildcard question as follows
i) Change 260/1 "A Topic Filter may include wildcard characters." to "A Topic Filter can include wildcard characters." This is just to reduce the number of lower case "may"s
ii) Change 1154 "The Topic Filters are UTF-8 encoded strings, which MAY contain special wildcard characters to represent a set of topics, see Section 4.7.1." to
"The Topic Filters are UTF-8 encoded strings. "The Topic Filters are UTF-8 encoded strings. A Server SHOULD support Topic filters that contain the wildcard characters defined in Section 4.7.1. If it chooses not to support topic filters that contain wildcard characters it MUST reject any Subscription request whose filter contains them"."
iii) Change 1530 "A subscription’s Topic Filter may contain special wildcard characters, which allow you to subscribe to multiple topics at once." to "A subscription’s Topic Filter can contain special wildcard characters, which allow you to subscribe to multiple topics at once." As for i)
B. Reword some other MAY statements
i) 502. "It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY discard it at any time." Change this to "It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY choose to discard it at any time." This makes it sound more like an optional feature.
ii) 816 "Note that a Server MAY choose to disconnect a Client that it determines to be inactive or non-responsive at any time, regardless of the Keep Alive value provided by that Client." Change this to "Note that a Server is permitted to disconnect a Client...". This one is a bit of a grey area, but it sounds like a right that we would want any server to have, rather than an optional feature that some servers might choose to support.
iii) 1184 "The Server MAY start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK Packet." Change to "The Server is permitted to start sending...". Same rationale as for ii)
iv) 1630 "The topic resource may be either predefined in the Server by an administrator or it may be dynamically created by the Server when it receives the first subscription or an Application Message with that Topic Name. The Server may also use a security component to selectively authorize actions on the topic resource for a given Client." This text is currently in a non-normative comment but it seems to me that it might have a bearing on interoperability. I propose moving it out of the non-normative comment and using MAY instead of may.
C. Replace lower case may throughout the document with appropriate alternatives ("can", "could", "might")
43 "At least once", where messages are assured to arrive but duplicates may occur. (replace with "can")
861 A Client implementation may provide a convenience method to generate a random ClientId. (replace with "could")
1381 Normal operation of the Client of Server may mean that stored state is lost or corrupted because of administrator action, hardware failure or software failure. (replace with "could")
1384 For example the server may determine that based on external knowledge, a message or messages can no longer be delivered to any current or future client.(replace with "might")
1393 Change this to say "For example, a user wishing to gather electricity meter readings may decide that they need to use QoS 1 messages because they need to protect the readings against loss over the network, however they may have determined that the power supply is sufficiently reliable that the data in the Client and Server can be stored in volatile memory without too much risk of its loss."
1538 Topic level separators may appear anywhere in a Topic Filter or Topic Name (replace with "can")
1650 Devices may be compromised Use "could"
1651 Data at rest in Clients and Servers may be accessible. Use "might"
1652 Protocol behaviors may have side effects (e.g., 'timing attacks') Use "could"
1654 Communications may be intercepted, altered, re-routed or disclosed Use "could"
1668 In addition to technical security issues there may also be geographic...Use "could"
1673 An implementation may want to provide conformance with specific industry security standards such as NIST Cyber Security Framework [NISTCSF] ... use "might"
1698 Implementations passing authentication data in clear text, obfuscating such data elements or requiring no authentication data should be aware this may give rise to Man-in-the-Middle and replay attacks. Use"can"
1722 An implementation may allow for authentication where the credentials are flowed in an Application Message from the Server to the Client. Use "might"
1740 An application may independently encrypt the contents of its Application Messages. Use "might"
1744 Client and Server implementations may provide encrypted storage for data at rest Use "can"
1757 Client and Server implementations using TLS [RFC5246] may choose to provide capabilities to check Certificate Revocation Lists (CRLs [RFC5280])...Use "can"
1801 Some MQTT implementations may make use of alternative secured tunnels (e.g. SSH) through the use of SOCKS. Use "could"
1804 implementations should be aware that SOCKS authentication may occur in plain-text use "might"
1807 Implementers and solution designers may wish to consider security as a set of profiles - use "might"
1819 TLS [RFC5246] Client authentication may be used in addition to – or in place of – MQTT Client authentication as provided by the Username and Password fields. Use "can"
1836 WebSocket binary frames are used. A single frame may contain multiple or partial MQTT Control Packets... Use "can"
Bug
Major