Add RFC Information

[Pandapip1]

• Adds links RFC 822 and RFC 2119
• Adds rules to deal with RFCs

Change to EIP-1: See files tab

[eth-bot]

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

---

(fail) eip-1.md

classification
updateEIP

• Changes to EIP 1 require at least 5 unique approvals from editors; there's currently 1 approvals; the remaining editors are @lightclient, @axic, @SamWilsn, @MicahZoltu, @gcolvin

(fail) eip-template.md

classification
ambiguous

• 'eip-template.md' must be in eip-###.md format; this error will be overwritten upon relevant editor approval

[Pandapip1]

Huh, who knew? RFCs have spelling mistakes.

[gcolvin]

There is also a good argument for not copying RFCs. The RFC Editor maintains a canonical list at https://www.rfc-editor.org. For each RFC there is an Info page with TXT, PDF, and HTML renderings of the RTF and a host of information about the RFC. The RFC style guide at https://www.rfc-editor.org/info/rfc7322 requires that links to RFCs be to their Info page, not to a particular rendering. The required form is https://www.rfc-editor.org/info/rfc#. Why not just do as they ask?

[MicahZoltu]

@gcolvin Where in the style guide does it say that third parties referring to RFCs should not include the raw text?

[gcolvin]

@gcolvin Where in the style guide does it say that third parties referring to RFCs should not include the raw text?

@MicahZoltu It doesn't. It requires that links to RFCs be to their Info page, presumably because it is more informative.

https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.6.2

We are free to choose a particular rendering and copy it anywhere we like, but I am doubting that we should.

[lightclient]

I am generally against enforcing the "no external links" decree on RFCs.

[Pandapip1]

So here's my thought: we create a page that redirects to the specified RFC info page, while keeping text backups of the RFCs. If for some reason the info page dies, we can have it redirect to the text backups instead. How does that sound?

[lightclient]

I think that solution is too hacky. It would require users either type the entire eips.ethereum.org/rfc-X url for links (which is in contrast of our current relative link policy) or we use relative links that are resolved only once the site has been deployed, meaning the links can't be accessed when viewing on github.

[SamWilsn]

I guess an option would be to allow direct links to the RFC, but have the linter fail if a backup isn't made?

[gcolvin]

Why are we afraid of RFC links failing? The whole Internet is built to IETF Standards, and IETF Standards themselves use those links. They aren't going away.

What I would suggest is that we provide a Normative Reference section with full citations for both EIPs and RFCs, as is required by IETF for RFCs.

[Pandapip1]

Why are we afraid of RFC links failing? The whole Internet is built to IETF Standards, and IETF Standards themselves use those links. They aren't going away.

This argument could be made for many links. By not allowing any external links, we avoid a lot of unneeded discussions. And after all, the internet could die...

What's the problem with linking to text-based RFCs? Yes, it might not be perfect according to their style guide. But I feel like keeping all information in the EIPs repository is worth the small tradeoff.

[MicahZoltu]

I'm pretty sure the style guide linked by @gcolvin above is specifically for people drafting RFCs, not for people referring to RFCs from elsewhere.

In the past we have discussed managing a whitelist of "acceptable" external links (like RFCs), but the challenge is in maintaining that list and dealing with people requesting that their thing be added to it. While RFCs certainly seem like an obviously right choice, it opens the doors to everyone claiming their standardization thing is also a right choice.

I think the primary difference here (including the RFC text in this repository) is that anyone can do this for any source of standard being referenced (assuming it is license compatible) and we don't have to get into the weeds about what each different standards committee's policy is on immutability and whatnot.

[gcolvin]

@MicahZoltu I'm pretty sure the style guide linked by @gcolvin above is specifically for people drafting RFCs, not for people referring to RFCs from elsewhere.

RFC 7322 includes guidance for how to refer to RFCs from within another RFC. They also have guidance for other types of references. I strongly advise that we follow their guidance. In essence

... The use of URIs in references is acceptable, as long as the URI is the most stable (i.e., unlikely to change and expected to be continuously available) and direct reference possible.
... Note that URIs may not be the sole information provided for a reference entry.

So like the IETF I just don't have a problem with the judicious use of external references, normative and informative. RFC 7322 itself has a lot of informative references. I don't find "we are afraid they might cause too much work in the future" a convincing argument for imposing unnecessary restrictions on EIP authors. Authors, reviewers, and editors can simply exercise good judgment, and if we can't get the resources we need to create high-quality documents we are in trouble regardless.

I also don't have a problem with putting an extra copy in our repo when we are allowed to. The citation in the Reference section can include both links. But of course that means being sure that we have the legal right to publish a copy, which creates its own problems. For RFCs we are sure we have that right.

[Pandapip1]

as long as the URI is the most stable (i.e., unlikely to change and expected to be continuously available) and direct reference possible

For the purposes of the EIPs repository, the EIPs repository itself is the most stable and direct reference possible.

[gcolvin]

It's stable and direct, and also misses the full context of the Info page. I've suggested we put both the canonical link to the IETF and a link to our copy in the Reference section. And please let's use the HTML rendering of the RFC, which includes links to the other renderings and to the Info page.

[Pandapip1]

And please let's use the HTML rendering of the RFC, which includes links to the other renderings and to the Info page.

I'd be okay with that.

It's stable and direct, and also misses the full context of the Info page.

If the HTML rendering includes links to the other renderings, then we're good, right?

[Pandapip1]

@SamWilsn EIPW bug?

[gcolvin]

If the HTML rendering includes links to the other renderings, then we're good, right?

Good enough, thanks.

[Pandapip1]

Moving to draft until the PR with the external link changes is made.

[Pandapip1]

Closing in favor of a new PR once the external link changes are done.