status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-01-14 17:04:11 +00:00
Code Issues Projects Releases Wiki Activity

Remove "Replaces: 67" and move to Rationale that replaces Motivation

Browse Source 
ERC-67 was used but never merged - so there can be no replacemenmt
Using Rationale as it is a better fit and leaving out optional Motivation
This commit is contained in:
ligi 2018-01-22 11:34:12 +01:00
parent f156733da0
commit d90db8361e
No known key found for this signature in database
GPG Key ID: 8E81894010ABF23D
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
EIPS/eip-831.md
View File

@ -6,7 +6,6 @@
Type: Standard Track Type: Standard Track
Category: ERC Category: ERC
Status: Draft Status: Draft
Replaces: 67
Created: 2018-01-15 Created: 2018-01-15
## Simple Summary ## Simple Summary
@ -17,10 +16,6 @@ A standard way of creating Ethereum URLs for various use-cases.
URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format allows for instant invocation of the user's preferred wallet application. URLs embedded in QR-codes, hyperlinks in web-pages, emails or chat messages provide for robust cross-application signaling between very loosely coupled applications. A standardized URL format allows for instant invocation of the user's preferred wallet application.
## Motivation
The need for this ERC emerged when refining ERC-681. We need a container ERC that does not carry the weight of the use-cases and just serves the container for them.
## Specification ## Specification
### Syntax ### Syntax
@ -37,6 +32,12 @@ Ethereum URLs contain "ethereum" in their schema (protocol) part and are constru
`payload` is mandatory and the content depends on the prefix. Structuring of the content is defined in the ERC for the specific use-case and not in the scope of this document. One example is ERC-681 for the pay- prefix. `payload` is mandatory and the content depends on the prefix. Structuring of the content is defined in the ERC for the specific use-case and not in the scope of this document. One example is ERC-681 for the pay- prefix.
## Rationale
The need for this ERC emerged when refining ERC-681. We need a container that does not carry the weight of the use-cases. ERC-67 was the first standard defining Ethereum-URLs - this ERC tries to keep backward compatibibility and not break existing flows. This means ERC-67 URLs should still be valid and readable. But if the prefix feature is used - ERC-67 parsers might break.
## Copyright ## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).