Update language to reflect the reason of why we should not link to external resources, and propose exceptions #4880
Conversation
Update language to reflect the reason of why we should not link to external resources, and propose exceptions
xinbenlv
changed the title
|
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
|
|
Requesting reviews from SamWilsn@ MicahZoltu@, gcolvin@ who authored / reviewed #4872 |
| @@ -185,9 +185,9 @@ The `created` header records the date that the EIP was assigned a number. Both h | |||
|
|
|||
| EIPs may have a `requires` header, indicating the EIP numbers that this EIP depends on. | |||
|
|
|||
| ## Linking to External Resources | |||
| ## Direct Linking to External Resources | |||
There was a problem hiding this comment.
For consistency with the other header, I dislike this change.
| ## Direct Linking to External Resources | |
| ## Linking to External Resources |
|
|
||
| Links to external resources **SHOULD NOT** be included. External resources may disappear, move, or change unexpectedly. | ||
| Excersise extreme caution when adding external resources. Direct link e.g. [URI](https://datatracker.ietf.org/doc/html/rfc3986) **SHOULD NOT** be included. External resources, if hosted centralized, may disappear, move, or change unexpectedly or manipulated by adversary, creating security and abuse harm. Exceptions to this rule are: other well recognized standards such as IETF RFCs or content hosted in decentralized persistant storage. |
There was a problem hiding this comment.
Your suggestion is actually pretty close to my original philosophy for this change. After some discussion with Micah, I came to agree that reviewing what services fulfill the requirements (durable, compatible licenses, etc) is probably too much work for the editors we have.
That said, it might be worth opening a discussion thread on eth magicians to hammer out a couple exceptions (like IETF RFCs.)
There was a problem hiding this comment.
I'm very weakly in favor of allowing RFC and IETF specifications, but I am a bit worried that just the act of creating such a list is a slippery slope to having to maintain such a list. People will definitely want to add to that list once it exists. Also, I currently do allow links to consensus specs, so that should be on the list too...
There was a problem hiding this comment.
Here is what the IETF has to say about the Reference Section. It's brief:
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. The URI will be verified as valid during the RFC editorial process.
If a dated URI (one that includes a timestamp for the page) is available for a referenced web page, its use is required.
Note that URIs may not be the sole information provided for a reference entry.
The entire style guide is worth a gander.
RFC 7322
RFC Style Guide
https://www.rfc-editor.org/rfc/rfc7322.html
https://www.rfc-editor.org/rfc/rfc7322.html#page-14
|
We discussed this in the EIPIP meeting and the rough consensus (small number of editors present sadly) was that I think we generally prefer the current (short/terse) text over the proposed text. I think that generally editors would like to retain some flexibility, but our general policy is "no external links" and the current text reflects that while retaining flexibility. |
Update language to reflect the reason of why we should not link to external resources, and propose exceptions