[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (MQTT-145) MAY/may contain inconsistent usage - 1 known, others need researching
[ http://tools.oasis-open.org/issues/browse/MQTT-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Coppen updated MQTT-145: -------------------------------- Affects Version/s: 3.1.1 Component/s: core 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. > MAY/may contain inconsistent usage - 1 known, others need researching > --------------------------------------------------------------------- > > Key: MQTT-145 > URL: http://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 is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]