Setting ERC-1271 to Last Call #2857
Conversation
|
Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):
|
|
A little help @axic to move to last call? 🙏 |
There was a problem hiding this comment.
- Simple Summary: One-liner "what is this".
- Abstract: What this EIP does (human readable).
- Motivation: Why this EIP exists.
- Specification: Technical (almost computer readable).
- Rationale: Why specific decisions were made.
Simple Summary is currently too long. This should be one or two sentences that gives a 10,000 foot description of the EIP. It shouldn't include reasoning why the EIP exists, or technical details about the EIP. Just a simple statement or two indicating what it is. Currently, the simple summary contains almost exclusively content that should be in the Motivation section.
The Abstract should be a human readable summary of the specification. Try to leave the "why" of the specification out of this section and focus on the what. Also, I generally recommend wording the abstract such that it stands alone. When possible, try not to assume that the reader of the specification will be familiar with historic state of art, and just tell them about the specification in isolation (as much as possible).
The motivation section is where you should put all of the "why do we need this, why is it a good idea, who benefits, etc.". Where possible, I recommend against linking out to external websites as we want EIPs to be able to stand on their own 10 years from now when other products may or may not exist. Instead, try to give a very brief description of the class of product you are referring to like "exchanges where the orderbook is off chain" instead of "0x and EtherDelta".
In general, in the motivation section the thing I am most interested to see (especially for ERCs) is "why does this need to be a standard rather than just a 'best practice' or 'good idea'?" I believe that is included in the motivation currently, but it may be worthwhile to pull that up to the top with an opening like:
There are and will be many contracts that want to utilize signed messages for validation of rights-to-move assets. In order for these contracts to be able to support non signing owners (i.e., contract owners), we need a standard mechanism by which the asset issuer can validate that a non-signing owner contract has authorized a particular transaction.
The rationale section should describe why specific decisions were made in this specification, it doesn't need to just reiterate the motivation for why this specification should exist at all. An example would be describing why you chose a particular name over others, or why you chose a particular parameter set instead of others, or why an event fires in a particular situation that may not be obvious (these are just examples, you don't need to include them if the reasoning is likely obvious to all readers or if it is arbitrary).
The EIP MUST include a ## Security Considerations section, and for this ERC in particular it does feel like one is probably necessary since it is dealing with signatures (though I'm not sure off the top of my head what sort of security considerations need to be made here).
Where possible, consider inlining as much as you can rather than linking externally, or utilizing the assets folder of this repository to include larger content. While sometimes linking externally makes sense, it also makes the EIP more likely to end up with dead links. If there is an opportunity for a simple example implementation of this contract, consider including it inline in the ## Implementation section.
All links to other EIPs should be of the form [eip-1234](./eip-1234.md) to ensure they work in all environments (GitHub, Jekyll, future website, etc.).
|
There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review. |
|
This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment. |
Setting the ERC-1271 status as Last Call