Add EIP-5757: Propose process for allowing external links

EIPS/eip-5757.md

@@ -0,0 +1,95 @@
+---
+eip: 5757
+title: Process for Approving External Resources
+description: Requirements and process for allowing new origins of external resources
+author: Sam Wilson (@SamWilsn)
+discussions-to: https://ethereum-magicians.org/t/eip-5757-process-for-approving-external-resources/11215
+status: Draft
+type: Meta
+created: 2022-09-30
+requires: 1
+---
+
+## Abstract
+
+Ethereum improvement proposals (EIPs) occasionally link to resources external to this repository. This document sets out the requirements for origins that may be linked to, and the process for approving a new origin.
+
+## 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.
+
+### Definitions
+
+ - **Link**: Any method of referring to a resource, including: markdown links, anchor tags (`<a>`), images, citations of books/journals, and any other method of referencing content not in the current resource.
+ - **Resource**: A web page, document, article, file, book, or other media that contains content.
+ - **Origin**: A publisher/chronicler of resources, like a standards body (eg. w3c) or a system of referring to documents (eg. Digital Object Identifier System).
+
+### Requirements for Origins
+
+Permissible origins **SHOULD NOT** obviously allow redistributing their resources as part of the EIP repository. If an origin does obviously allow redistribution of resources, include those resources in an appropriate directory within this repository and link to those copies instead. The common exception to this rule are git repositories under the Ethereum organization.
+
+Permissible origins **MUST** provide a method of uniquely identifying a particular revision of a resource. Examples of such methods may include git commit hashes, version numbers, or publication dates.
+
+Permissible origins **MUST** have a proven history of availability. A origin existing for at least ten years and reliably serving resources would be sufficient—but not necessary—to satisfy this requirement.
+
+Permissible origins **MUST NOT** charge a fee for accessing resources.
+
+### Origin Removal
+
+Any approved origin that ceases to satisfy the above requirements **MUST** be removed from [EIP-1](./eip-1.md). If a removed origin later satisfies the requirements again, it MAY be re-approved by creating a new EIP as described in [Origin Approval](#origin-approval).
+
+Finalized EIPs (eg. those in the `Final` or `Withdrawn` statuses) **SHOULD NOT** be updated to remove links to these origins.
+
+Non-Finalized EIPs **MUST** remove links to these origins before changing statuses.
+
+### Origin Approval
+
+#### Proposal
+
+Each potential permitted origin **SHALL** be described in its own EIP.
+
+These EIPs **MUST** describe how the origin meets the requirements described above.
+
+These EIPs **MUST** include the markup for creating a link that satisfies all the above requirements and an example of such a link.
+
+When opened, these EIPs:
+
+ - **MUST** have a `status` of `Draft`.
+
+Throughout their lifetime, these EIPs:
+
+ - **MUST** have a `type` of `Meta`;
+ - **MUST** have a `title` beginning with `External Origin - ` followed by a unique name describing the origin; and
+ - **MAY** include links to any resources relevant to the approval process (regardless of origin).
+
+[A template for these proposals is available](../assets/eip-5757/template.md).
+
+#### Review
+
+Should the editors determine that an origin meets the requirements above, its proposal **SHALL** be granted a `status` of `Final`, and EIP-1 **MUST** be updated to show the new origin.
+
+## Rationale
+
+### Redistribution
+
+It is much easier to meet the process' goals for immutability if the resource is subject to this repository's tooling. Likewise, it is much easier to ensure availability if the resources are distributed alongside their EIPs. Therefore, if an origin allows it, prefer redistribution in this repository.
+
+### Unique Identifiers
+
+If it is impossible to uniquely identify a version of a resource, it becomes impractical to track changes, which makes it difficult to ensure immutability.
+
+### Availability
+
+If it is possible to implement a standard without a linked resource, then the linked resource is unnecessary. If it is impossible to implement a standard without a linked resource, then that resource must be available for implementers.
+
+### Free Access
+
+The Ethereum ecosystem is built on openness and free access, and the EIP process should follow those principles.
+
+### One Origin per Proposal
+
+Adding any origin is likely to be contentious and involve long debate. If each origin is proposed in its own EIP, they each will get a `discussions-to` link to focus and preserve discussion.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).

assets/eip-5757/template.md

@@ -0,0 +1,60 @@
+---
+eip: <to be assigned>
+title: External Origin - <origin name>
+description: <Description is one full (short) sentence>
+author: <a comma separated list of the authors, see EIP-1>
+discussions-to: <URL>
+status: Draft
+type: Meta
+created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
+requires: 5757
+---
+
+<!--
+  Please remove all comments before submitting a pull request!
+-->
+
+## Abstract
+This proposal presents <origin name> as a permissible external origin for EIPs. Permissible origins must satisfy requirements for identification, availability, and access. This origin meets all of the requirements.
+
+## Motivation
+<!-- In this section, describe why this origin is useful to EIPs and how it meets the requirements set out in EIP-5757. -->
+
+<origin name> should be an allowed origin of external resources because <couple sentences describing why this origin should be allowed and why it's necessary>.
+
+### Redistribution
+<!-- In this subsection, describe why you can't put resources from this origin in `assets`. Include links to incompatible licenses if applicable. -->
+
+It is impractical to redistribute resources from <origin name> because <couple sentences describing why>.
+
+### Identification
+<!-- In this subsection, describe how this origin meets the identification requirement. If the content described by an identifier is mutable, describe how/when those changes can be made. -->
+
+Each version of a resource <choose one: made available / cataloged> by <origin name> are uniquely identified by <description of how versions are identified>.
+
+### Availability
+<!-- In this subsection, convince the reader that the content provided by the origin will be around as long as Ethereum will be. -->
+
+<!-- For availability based on history: -->
+Since <year>, <origin name> has made its resources available with minimal interruption, and should continue to do so indefinitely.
+
+<!-- It's also possible for a origin to guarantee availability with some technical solution (maybe posting to a blockchain). If that's the case for your origin, explain that instead of using the above. -->
+
+## 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.
+
+### Link Format
+<!-- In this subsection, describe how to write links to resources published/cataloged by this origin. Links should always point to the most stable version. -->
+
+```markdown
+<...>
+```
+
+### Link Example
+<!-- In this subsection, show a rendered example of a link as described above. -->
+
+## Rationale
+<!-- Explain any decisions made within this proposal in this section. Particularly, if there are multiple options for URL/identifiers, explain why you picked the one you did. -->
+
+## Copyright
+Copyright and related rights waived via [CC0](../LICENSE.md).