Update EIP-721: Update link

[fulldecent]

When opening a pull request to submit a new EIP, please use the suggested template: https://github.com/ethereum/EIPs/blob/master/eip-template.md

We have a GitHub bot that automatically merges some PRs. It will merge yours immediately if certain criteria are met:

• The PR edits only existing draft PRs.
• The build passes.
• Your GitHub username or email address is listed in the 'author' header of all affected PRs, inside .
• If matching on email address, the email address is the one publicly listed on your GitHub profile.

[eth-bot]

All tests passed; auto-merging...

(pass) eip-721.md

classification
updateEIP

• passed!

[fulldecent]

Sound good @xinbenlv I'm a fan of permalinks. Just updated it at 8508642 to use the version available at time of publication.

[Pandapip1]

+0 to updating the link, +1 if it's removed altogether.

[xinbenlv]

+0 to updating the link, +1 if it's removed altogether.

Respectfully, @Pandapip1 , I am afraid I can't agree with your suggestion of removing it

IMHO, such links were part of the technical argument demonstrating the adoption landscape back then and made the proposal argument more convincing. I think they play an important role in making ERC721 an model EIP.

[Pandapip1]

EIP-721 is not a model EIP, as:

• Policies have changed since then
• The template has changed significantly

I agree that the content of EIP-721 is excellent. As such, it would indeed make sense to update EIP-20, EIP-721, and EIP-1155 to reflect current EIP practices. However, current EIP practices include "not including external links to unapproved domains." Respectfully, arbitrary GitHub links and OpenZeppelin links are not approved domains, nor should they be.

[fulldecent]

Comments here are discussing two things:

1. Whether EIPs, especially new ones, should link to GitHub and other domains
2. Updating ERC-721

I have updated many EIPs with and without the consent of the original authors. There are limits to the changes that we have pushed through in these situations. Because we are not planning to rewrite all existing published EIPs that means that there is a at least some difference on what is publishable for existing versus new EIPs.

---

I do not have any comments right now about whether linking to GitHub should be acceptable or not.

But I recognize one complaint is that most links to GitHub are rugpullable—a page at some URL can be changed and replaced with some entirely different content. There may be other complaints as well.

This PR changes an existing GitHub link on a named branch to link on a specific hash which cannot be modified. This corrects an error I originally made while publishing (sorry!), always use permalinks.

Whereas this PR addresses one material concern about an existing link to GitHub and it does not introduce any new link to GitHub, I request that this be merged as-is. Also the debate about whether linking to GitHub is good or bad should be closed without prejudice. Such broad discussion can be much better held elsewhere and this PR does not have any net impact on linking to GitHub.

[Pandapip1]

I agree with @fulldescent that PRs that fix broken links are good. That's why I've approved this PR, and have added it to the manual merge queue.

I also think that PRs that remove links are also good. But that's, as you have rightly said, a separate discussion.

[SamWilsn]

We've discussed this pull request on EIPIP today. Since this link is not part of the actual specification (aka non-normative), and it breaking doesn't affect the understanding of this EIP, we are going to close this pull request for the time being.

That said, @gcolvin would like to define a more formal process for correcting errata, and we should revisit this change at that time.