From 17e3beae74beb054f88e4579cd571cd3225eca99 Mon Sep 17 00:00:00 2001 From: xinbenlv Date: Fri, 7 Oct 2022 18:26:27 -0700 Subject: [PATCH] Update EIP-1: Suggest that EIPs use RFC 8174 (updates RFC 2119) (#5466) * EIP-1: propose to adopt RFC 8174 (updates 2119) RFC 2119 is updated by 8174. Have we discussed whether or not to adopt 8174? * Update eip-template.md * Update eip-template.md * Update eip-1.md * Update eip-template.md * Update EIPS/eip-1.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> * Update eip-template.md Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> * Update eip-1.md * Update eip-template.md * Update eip-1.md * Apply suggestions from code review Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Co-authored-by: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Co-authored-by: Sam Wilson <57262657+SamWilsn@users.noreply.github.com> --- EIPS/eip-1.md | 6 +++--- eip-template.md | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md index 58c33b6b7bf197..3c7b466d950abc 100644 --- a/EIPS/eip-1.md +++ b/EIPS/eip-1.md @@ -265,11 +265,11 @@ The `description` field in the preamble: When referring to an EIP by number, it should be written in the hyphenated form `EIP-X` where `X` is the EIP's assigned number. -### RFC 2119 +### RFC 2119 and RFC 8174 -EIPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) for terminology and to insert the following at the beginning of the Specification section: +EIPs are encouraged to follow [RFC 2119](https://www.ietf.org/rfc/rfc2119.html) and [RFC 8174](https://www.ietf.org/rfc/rfc8174.html) for terminology and to insert the following at the beginning of the Specification section: -> The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. +> 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 RFC 2119 and RFC 8174. ## History diff --git a/eip-template.md b/eip-template.md index a561aeb07e84c0..28d75a047fdcef 100644 --- a/eip-template.md +++ b/eip-template.md @@ -24,7 +24,7 @@ Abstract is a multi-sentence (short paragraph) technical summary. This should be The motivation section should describe the "why" of this EIP. What problem does it solve? Why should someone want to implement this standard? What benefit does it provide to the Ethereum ecosystem? What use cases does this EIP address? ## Specification -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119. +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 RFC 2119 and RFC 8174. The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (go-ethereum, parity, cpp-ethereum, ethereumj, ethereumjs, and [others](https://github.com/ethereum/wiki/wiki/Clients)).