< draft-leiba-rfc2119-update-00.txt		draft-leiba-rfc2119-update-01.txt >
	Network Working Group B. Leiba		Network Working Group B. Leiba
	Internet-Draft Huawei Technologies		Internet-Draft Huawei Technologies
	Updates: 2119 (if approved) August 09, 2016		Updates: 2119 (if approved) February 06, 2017
	Intended status: Best Current Practice		Intended status: Best Current Practice
	Expires: February 08, 2017		Expires: August 08, 2017
	Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words		Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
	draft-leiba-rfc2119-update-00		draft-leiba-rfc2119-update-01
	Abstract		Abstract
	RFC 2119 specifies common key words that may be used in protocol		RFC 2119 specifies common key words that may be used in protocol
	specifications. This document aims to reduce the ambiguity by		specifications. This document aims to reduce the ambiguity by
	clarifying that only UPPERCASE usage of the key words have the		clarifying that only UPPERCASE usage of the key words have the
	defined special meanings, and by deprecating some versions of the key		defined special meanings.
	words.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 08, 2017.		This Internet-Draft will expire on August 08, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents (http://trustee.ietf.org/		Provisions Relating to IETF Documents (http://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document. Code Components		and restrictions with respect to this document. Code Components
	extracted from this document must include Simplified BSD License text		extracted from this document must include Simplified BSD License text
	as described in Section 4.e of the Trust Legal Provisions and are		as described in Section 4.e of the Trust Legal Provisions and are
	provided without warranty as described in the Simplified BSD License.		provided without warranty as described in the Simplified BSD License.
	1. Introduction		1. Introduction
	RFC 2119 specifies common key words, such as "MUST", "SHOULD", and		RFC 2119 specifies common key words, such as "MUST", "SHOULD", and
	"MAY", that may be used in protocol specifications. It says that		"MAY", that may be used in protocol specifications. It says that
	those key words "are often capitalized," and that has caused		those key words "are often capitalized," and that has caused
	confusion about how to interpret non-capitalized words such as "must"		confusion about how to interpret non-capitalized words such as "must"
	and "should".		and "should".
	This document updates RFC 2119 by clarifying that only UPPERCASE		This document updates RFC 2119 by clarifying that only UPPERCASE
	usage of the key words have the defined special meanings. It also		usage of the key words have the defined special meanings. This
	reduces wording conflicts by deprecating some synonymous key words.		document will become part of BCP 14 when it is approved. [[RFC-
	This document will become part of BCP 14 when it is approved. [[RFC-
	Editor: Please change the previous sentence to "This document is part		Editor: Please change the previous sentence to "This document is part
	of BCP 14."]]		of BCP 14."]]
	1.1. Some Notes for Reviewers (not for publication)		1.1. Some Notes for Reviewers (not for publication)
	[[RFC-Editor: Please remove this section before publishing.]]		[[RFC-Editor: Please remove this section before publishing.]]
	This update is intentionally small and focused, and quite		This update is intentionally small and focused, and quite
	intentionally updates, but does not replace, RFC 2119. The author		intentionally updates, but does not replace, RFC 2119. The author
	considers it important to retain the reference to RFC 2119 because of		considers it important to retain the reference to RFC 2119 because of
	skipping to change at page 2, line 36 ¶		skipping to change at page 2, line 35 ¶
	numbers, not the BCP number. This is because is needs to be clear		numbers, not the BCP number. This is because is needs to be clear
	when a document has adopted this update, and the dual reference to		when a document has adopted this update, and the dual reference to
	RFC 2119 *and* this document gives that clarity.		RFC 2119 *and* this document gives that clarity.
	The point has been made by some that having case be significant to		The point has been made by some that having case be significant to
	the meanings of words is unusual and may be a bad idea. There is		the meanings of words is unusual and may be a bad idea. There is
	specific concern about causing confusion to readers whose native		specific concern about causing confusion to readers whose native
	languages do not have a distinction between upper and lower case		languages do not have a distinction between upper and lower case
	(consider Chinese and Hebrew, for example). The author believes this		(consider Chinese and Hebrew, for example). The author believes this
	has been discussed and addressed, and that those maintaining this		has been discussed and addressed, and that those maintaining this
	point are in the rough. That said, it may still be worth continuing		point are in the rough.
	the discussion a bit.
	There have been suggestions that while we're here we should consider		There have been suggestions that while we're here we should consider
	a broader BCP 14 update that also talks about proper use of the key		a broader BCP 14 update that also talks about proper use of the key
	words, when they should not be used, avoiding overuse, and so on.		words, when they should not be used, avoiding overuse, and so on.
	The author agrees, but thinks is best to keep that as a separate		The author agrees, but thinks is best to keep that as a separate
	effort, as coming to consensus on such an update is likely to be much		effort, as coming to consensus on such an update is likely to be much
	more difficult, and is likely to take much longer.		more difficult, and is likely to take much longer.
	2. Clarifying Capitalization of Key Words		2. Clarifying Capitalization of Key Words
	skipping to change at page 3, line 10 ¶		skipping to change at page 3, line 10 ¶
	the requirements in the specification. These words are often		the requirements in the specification. These words are often
	capitalized. This document defines these words as they should be		capitalized. This document defines these words as they should be
	interpreted in IETF documents. Authors who follow these guidelines		interpreted in IETF documents. Authors who follow these guidelines
	should incorporate this phrase near the beginning of their document:		should incorporate this phrase near the beginning of their document:
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119.		document are to be interpreted as described in RFC 2119.
	=== NEW ===		=== NEW ===
	In many standards track documents several words are used to signify		In many IETF documents several words are used to signify the
	the requirements in the specification. These words are often		requirements in the specification, when they are in all capitals as
	capitalized, as shown below, but they do not have to be. This		shown below. This document defines how these words are interpreted
	document defines how these words are interpreted in IETF documents		in IETF documents when the words are in all capitals.
	when the words are capitalized.
	o These words can be used as defined here, but it is not required		o These words can be used as defined here, but using them is not
	that they be. Specifically, normative text does not require the		required. Specifically, normative text does not require the use
	use of these key words. They are used for clarity and consistency		of these key words. They are used for clarity and consistency
	when that is what's wanted, but a lot of normative text does not		when that is what's wanted, but a lot of normative text does not
	use them, and does not need to use them.		use them, and is still normative.
	o The words have the meanings specified herein only when they are		o The words have the meanings specified herein only when they are in
	capitalized.		all capitals.
	o When these words are not capitalized, they have their normal		o When these words are not capitalized, they have their normal
	English meanings; this document has nothing to do with them.		English meanings; this document has nothing to do with them.
	Authors who follow these guidelines should incorporate this phrase		Authors who follow these guidelines should incorporate this phrase
	near the beginning of their document:		near the beginning of their document:
	The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	"MAY" in this document are to be interpreted as described in		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
	BCP 14 [RFC2119],[RFCxxxx] when, and only when, they appear		"MAY", and "OPTIONAL" in this document are to be interpreted as
	capitalized, as shown.		described in BCP 14 [RFC2119],[RFCxxxx] when, and only when, they
			appear in all capitals, as shown here.
	=== END ===		=== END ===
	[[RFC Editor: Please replace "RFCxxxx", above, with a reference to		[[RFC Editor: Please replace "RFCxxxx", above, with a reference to
	this RFC number, and remove this note.]]		this RFC number, and remove this note.]]
	3. Deprecating some synonymous key words		3. IANA Considerations
	To reduce the number of reserved key words, the following key words
	are deprecated, and no longer have special meanings defined by BCP
	14:
	REQUIRED, SHALL, SHALL NOT, RECOMMENDED, NOT RECOMMENDED, OPTIONAL
	4. IANA Considerations
	There are no IANA considerations for this document.		There are no IANA considerations for this document.
	5. Security Considerations		4. Security Considerations
	This document is purely procedural, and there are no related security		This document is purely procedural, and there are no related security
	considerations.		considerations.
	6. Normative References		5. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	Author's Address		Author's Address
	Barry Leiba		Barry Leiba
	Huawei Technologies		Huawei Technologies
	Phone: +1 646 827 0648		Phone: +1 646 827 0648
	Email: barryleiba@computer.org		Email: barryleiba@computer.org
	URI: http://internetmessagingtechnology.org/		URI: http://internetmessagingtechnology.org/
End of changes. 17 change blocks.
	39 lines changed or deleted		28 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/