OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

mqtt message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (MQTT-486) RFC 2119 scan for MAYs


    [ https://issues.oasis-open.org/browse/MQTT-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=66671#comment-66671 ] 

Brian Raymor commented on MQTT-486:
-----------------------------------

Per my conversation with Bill Cox during the 6/22 TC call about the interpretation of uppercase/lowercase key words, please review RFC8174 which updates and clarifies RFC2119:

https://tools.ietf.org/html/rfc8174

   RFC 2119 specifies common key words that may be used in protocol
   specifications.  This document aims to reduce the ambiguity by
   clarifying that only UPPERCASE usage of the key words have the
   defined special meanings.


   o  When these words are not capitalized, they have their normal
      English meanings and are not affected by this document.

   Authors who follow these guidelines should incorporate this phrase
   near the beginning of their document:

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here.

We may want to use this reference and update the related phrase.

> RFC 2119 scan for MAYs
> ----------------------
>
>                 Key: MQTT-486
>                 URL: https://issues.oasis-open.org/browse/MQTT-486
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Bug
>          Components: core
>    Affects Versions: wd14
>            Reporter: Peter Niblett
>
> I have scanned WD14 for all cases of may or MAY.  This is the list of occurrences that I found that I think are problematic.  There are a number of lower case mays in Non-Normative text, and I am ignoring most of them here.
> 1. Lower case mays which should be upper case MAYs
> None
> 2. Lower case mays which aren't RFC 2119 MAYs. For the avoidance of doubt I recommend these get changed to an alternative, as shown in the proposal
> - 3.3.2.3.8
> - 3.4.2.1,  3.5.2.1,  3.6.2.1, 3.7.2.1, 3.14.2.1
> - 3.5.2.2.3, 3.6.2.2.3, 3.7.2.2.3, 3.9.2.1.3, 3.11.2.1.3, 3.14.2.2.4, 3.15.2.2.4 (User Property)
> - 4.4 footnote
> - 4.10.1
> - 4.13.2
> 3. Upper case MAYs which should not be. 
> - 3.14 "The Client or Server MAY send a DISCONNECT packet before closing the Network Connection".  This is borderline, but it's not really an optional implementation thing, so I think this could be a "can"
> -----------------------
> In passing, one thing I found a bit surprising was "The Server MAY check that the contents of the CONNECT packet meet any further restrictions" in 3.1.4. This is ok regarding RFC 2119, but it means that, for example, a server that doesn't like the Will Topic can choose to ignore it and reply with a 0 return code, so the client is none the wiser



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]