idnits 2.17.1 draft-leiba-rfc2119-update-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2119, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. (Using the creation date from RFC2119, updated by this document, for RFC5378 checks: 1997-03-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 09, 2017) is 2598 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCxxxx' is mentioned on line 133, but not defined Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Leiba 3 Internet-Draft Huawei Technologies 4 Updates: 2119 (if approved) March 09, 2017 5 Intended status: Best Current Practice 6 Expires: September 08, 2017 8 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 9 draft-leiba-rfc2119-update-02 11 Abstract 13 RFC 2119 specifies common key words that may be used in protocol 14 specifications. This document aims to reduce the ambiguity by 15 clarifying that only UPPERCASE usage of the key words have the 16 defined special meanings. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 08, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 1. Introduction 50 RFC 2119 specifies common key words, such as "MUST", "SHOULD", and 51 "MAY", that may be used in protocol specifications. It says that 52 those key words "are often capitalized," and that has caused 53 confusion about how to interpret non-capitalized words such as "must" 54 and "should". 56 This document updates RFC 2119 by clarifying that only UPPERCASE 57 usage of the key words have the defined special meanings. This 58 document will become part of BCP 14 when it is approved. [[RFC- 59 Editor: Please change the previous sentence to "This document is part 60 of BCP 14."]] 62 1.1. Some Notes for Reviewers (not for publication) 64 [[RFC-Editor: Please remove this section before publishing.]] 66 This update is intentionally small and focused, and quite 67 intentionally updates, but does not replace, RFC 2119. The author 68 considers it important to retain the reference to RFC 2119 because of 69 the general familiarity with the number, and to phase in the use of 70 "BCP 14". Note, though, that the References section uses the RFC 71 numbers, not the BCP number. This is because is needs to be clear 72 when a document has adopted this update, and the dual reference to 73 RFC 2119 *and* this document gives that clarity. 75 The point has been made by some that having case be significant to 76 the meanings of words is unusual and may be a bad idea. There is 77 specific concern about causing confusion to readers whose native 78 languages do not have a distinction between upper and lower case 79 (consider Chinese and Hebrew, for example). The author believes this 80 has been discussed and addressed, and that those maintaining this 81 point are in the rough. 83 There have been suggestions that while we're here we should consider 84 a broader BCP 14 update that also talks about proper use of the key 85 words, when they should not be used, avoiding overuse, and so on. 86 The author agrees, but thinks is best to keep that as a separate 87 effort, as coming to consensus on such an update is likely to be much 88 more difficult, and is likely to take much longer. 90 2. Clarifying Capitalization of Key Words 92 The following change is made to [RFC2119]: 94 === OLD === 95 In many standards track documents several words are used to signify 96 the requirements in the specification. These words are often 97 capitalized. This document defines these words as they should be 98 interpreted in IETF documents. Authors who follow these guidelines 99 should incorporate this phrase near the beginning of their document: 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119. 105 === NEW === 106 In many IETF documents several words, when they are in all capitals 107 as shown below, are used to signify the requirements in the 108 specification. Those capitalized words can bring significant clarity 109 and consistency to documents because their meanings are well defined. 110 This document defines how those words are interpreted in IETF 111 documents when the words are in all capitals. 113 o These words can be used as defined here, but using them is not 114 required. Specifically, normative text does not require the use 115 of these key words. They are used for clarity and consistency 116 when that is what's wanted, but a lot of normative text does not 117 use them, and is still normative. 119 o The words have the meanings specified herein only when they are in 120 all capitals. 122 o When these words are not capitalized, they have their normal 123 English meanings; this document has nothing to do with them. 125 Authors who follow these guidelines should incorporate this phrase 126 near the beginning of their document: 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 129 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 130 "MAY", and "OPTIONAL" in this document are to be interpreted as 131 described in BCP 14 [RFC2119],[RFCxxxx] when, and only when, they 132 appear in all capitals, as shown here. 134 === END === 136 [[RFC Editor: Please replace "RFCxxxx", above, with a reference to 137 this RFC number, and remove this note.]] 139 3. IANA Considerations 141 There are no IANA considerations for this document. 143 4. Security Considerations 145 This document is purely procedural, and there are no related security 146 considerations. 148 5. Normative References 150 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 151 Requirement Levels", BCP 14, RFC 2119, March 1997. 153 Author's Address 155 Barry Leiba 156 Huawei Technologies 158 Phone: +1 646 827 0648 159 Email: barryleiba@computer.org 160 URI: http://internetmessagingtechnology.org/