Possible actions:

trawl doc to ensure permissive use of 'may' and RFC 2119 optional use of MAY clauses are valid.

The TC will to review cases where may --> MAY or MAY --> may

Consider substituting 'may' with terms such as 'can' or 'might' where this will add clarity.

I have reviewed all the instances of MAY and may. See https://www.oasis-open.org/apps/org/workgroup/mqtt/email/archives/201402/msg00118.html

TC accept proposal, TC call 20.03.2013

As per TC call today, modified Section A ii) A Server MAY support --> A Server SHOULD support ...

Working on this issue in WD-22

A. Clarify the Topic wildcard question as follows
===================================
1)
Before - "A Topic Filter may include wildcard characters."
After - "A Topic Filter can include wildcard characters."

2)
Before - "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."
After - "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"

3)
Before - "A subscription’s Topic Filter may contain special wildcard characters, which allow you to subscribe to multiple topics at once."
After - "A subscription’s Topic Filter can contain special wildcard characters, which allow you to subscribe to multiple topics at once."

B. Reword some other MAY statements
============================

1)
Before - "It SHOULD store the new QoS 0 message as the new retained message for that topic, but MAY discard it at any time."
After - "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."

2)
Before - "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."
After - "Note that a Server is permitted 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."

3)
Before - "The Server MAY start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK Packet."
After - "The Server is permitted to start sending PUBLISH packets matching the Subscription before the Server sends the SUBACK Packet."

4)
Before - "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."
After - "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."

C. Replace lower case may throughout the document with appropriate alternatives ("can", "could", "might")
===============================================================================

1)

Before - "At least once", where messages are assured to arrive but duplicates may occur.
After - "At least once", where messages are assured to arrive but duplicates can occur.

2)

Before - A Client implementation may provide a convenience method to generate a random ClientId.
After - A Client implementation could provide a convenience method to generate a random ClientId.

3)

Before - 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.
After - Normal operation of the Client of Server could mean that stored state is lost or corrupted because of administrator action, hardware failure or software failure.

4)

Before - 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.
After - For example the server might determine that based on external knowledge, a message or messages can no longer be delivered to any current or future client.

5)

Before - 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 decide 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.
After - 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.

6)

Before - Topic level separators may appear anywhere in a Topic Filter or Topic Name
After - Topic level separators can appear anywhere in a Topic Filter or Topic Name.

7)

Before - Devices may be compromised
After - Devices could be compomised

8)

Before - Data at rest in Clients and Servers may be accessible
After - Data at rest in Clients and Servers might be accessible

9)

Before - Protocol behaviors may have side effects (e.g., 'timing attacks')
After - Protocol behaviors could have side effects (e.g., 'timing attacks')

10)

Before - Communications may be intercepted, altered, re-routed or disclosed
After - Communications could be intercepted, altered, re-routed or disclosed

11)

Before - In addition to technical security issues there may also be geographic (e.g. European SafeHarbour [USEUSAFEHARB])
After - In addition to technical security issues there could also be geographic (e.g. European SafeHarbour [USEUSAFEHARB])

12)

Before - An implementation may want to provide conformance with specific industry security standards such as NIST Cyber Security Framework [NISTCSF],
After - An implementation might want to provide conformance with specific industry security standards such as NIST Cyber Security Framework [NISTCSF],

13)

Before - 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.
After - Implementations passing authentication data in clear text, obfuscating such data elements or requiring no authentication data should be aware this can give rise to Man-in-the-Middle and replay attacks.

14)

Before - An implementation may allow for authentication where the credentials are sent in an Application Message from the Server to the Client.
After - An implementation might allow for authentication where the credentials are sent in an Application Message from the Server to the Client.

15)

Before - An application may independently encrypt the contents of its Application Messages.
After - An application might independently encrypt the contents of its Application Messages.

16)

Before - Client and Server implementations may provide encrypted storage for data at rest such as Application Messages stored as part of a Session.
After - Client and Server implementations can provide encrypted storage for data at rest such as Application Messages stored as part of a Session.

17)

Before - Client and Server implementations using TLS [RFC5246] may choose to provide capabilities to check Certificate Revocation Lists (CRLs [RFC5280]) and Online Certificate Status Protocol (OSCP) [RFC6960] to prevent revoked certificates from being used.
After - Client and Server implementations using TLS [RFC5246] can choose to provide capabilities to check Certificate Revocation Lists (CRLs [RFC5280]) and Online Certificate Status Protocol (OSCP) [RFC6960] to prevent revoked certificates from being used.

18)
Before - Some MQTT implementations may make use of alternative secured tunnels (e.g. SSH) through the use of SOCKS.
After - Some MQTT implementations could make use of alternative secured tunnels (e.g. SSH) through the use of SOCKS.

19)

Before - implementations should be aware that SOCKS authentication may occur in plain-text and so should avoid using the same credentials for connection to a MQTT Server.
After - implementations should be aware that SOCKS authentication might occur in plain-text and so should avoid using the same credentials for connection to a MQTT Server.

20)

Before - Implementers and solution designers may wish to consider security as a set of profiles which can be applied to the MQTT protocol.
After - Implementers and solution designers might wish to consider security as a set of profiles which can be applied to the MQTT protocol.

21)

Before - 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.
After - TLS [RFC5246] Client authentication can be used in addition to – or in place of – MQTT Client authentication as provided by the Username and Password fields.

22) No update is needed as WebSocket section is changed in WD-21 and there is no MAY in the explanation

fixed in WD-22