Fix a problem with separating prefixes from payload

This commit is contained in:
ligi 2018-01-23 17:03:08 +01:00
parent d90db8361e
commit 359f34523d
No known key found for this signature in database
GPG Key ID: 8E81894010ABF23D
1 changed files with 2 additions and 2 deletions

View File

@ -28,14 +28,14 @@ Ethereum URLs contain "ethereum" in their schema (protocol) part and are constru
### Semantics
`prefix` is optional and defines the use-case for this URL. If no prefix is given "pay-" is assumed to be concise and ensure backward compatibility to ERC-67.
`prefix` is optional and defines the use-case for this URL. If no prefix is given: "pay-" is assumed to be concise and ensure backward compatibility to ERC-67. When the prefix is omitted - the payload must start with `0x`. Also prefixes must not start with `0x`. So starting with `0x` can be used as a clear signal that there is no 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.
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 attempt on 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