[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-145) MAY/may contain inconsistent usage - 1 known, others need researching
[ https://tools.oasis-open.org/issues/browse/MQTT-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Niblett updated MQTT-145:
-------------------------------
Proposal:
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 MAY 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"
was:Correct the conflict between MAY and may for wildcards and review other uses of MAY and may to eliminate other conflicts.
> MAY/may contain inconsistent usage - 1 known, others need researching
> ---------------------------------------------------------------------
>
> Key: MQTT-145
> URL: https://tools.oasis-open.org/issues/browse/MQTT-145
> Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.1
> Environment: Keywords
> Reporter: Patrick Durusau
>
> Section 3.8.3 Payload reads in part:
> *****
> 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.
> *****
> Whereas 4.7.1 reads:
> *****
> A subscription's Topic Filter *may* contain special wildcard characters, which allow you to subscribe to multiple topics at once.
> *****
> The difference between "MAY" and "may" for interoperability is substantial:
> Under RFC2119, MAY is defined as:
> *****
> MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)
> *****
> So the first "MAY" has an interoperability requirement between applications that support or don't support the use of wildcards to select sets of topics.
> However, that interoperability requirement is *lost* in 4.7.1, which uses the lowercase "may," according to The RFC Style Guide, http://www.rfc-editor.org/rfc-style-guide/rfc-style, which reads in part:
> *****
> To simply specify a necessary logical relationship, the normal lower-case words should be used. On the other hand, if the capitalized words are used in a document, choose and use them carefully and consistently.
> *****
> The short version: MAY requires interoperability, may does not require interoperability.
> I mention this because the specification uses MAY 21 times and may 39 times. I suggest that you carefully compare all uses of MAY/may to eliminate further conflicts like this one.
--
This message was sent by Atlassian JIRA
(v6.1.1#6155)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]