EIP-831: Standard URL Format #831
Conversation
ligi
force-pushed
the
url_format
branch
2 times, most recently
from
efa7473
to
7f9ab5f
Compare
EIPS/eip-831.md
Outdated
| Type: Standard Track | ||
| Category: ERC | ||
| Status: Draft | ||
| Replaces: 67 |
There was a problem hiding this comment.
@nicksavers is this how to refer to the original GitHub issue? Or should the issue be mentioned in Motivation?
There was a problem hiding this comment.
There was a problem hiding this comment.
Does this refer to issue #67?
It doesn't really replace a previously adopted EIP, so I don't see the need for adding it to the EIP. Besides, that issue is still open. If this PR is supposed to supersede it, shouldn't it be closed? Yes, some EIPs contain previous discussions in the references, which is where you could add the link to GitHub for historic purposes.
There was a problem hiding this comment.
was inspired by how it was done in 681 - will remove it then
|
|
||
| request = "ethereum" ":" [ prefix "-" ] payload | ||
| prefix = STRING | ||
| payload = STRING |
There was a problem hiding this comment.
Nitpicking:
How to distinguish
payload = "with-hyphen"
request = "ethereum:with-hyphen"
against
prefix = "with"
payload = "hyphen"
request = "ethereum:with-hyphen"
?
Perhaps, if prefix is omitted, payload can contain no "-"s?
There was a problem hiding this comment.
Good point. We can use the property of 681 that if the prefix is omitted the payload must start with 0x (be an address) - will add this constraint - thanks
There was a problem hiding this comment.
Dam - doing this I noticed that it is not working as the address can now also be a ens-domain. And AFAIK the ens-domain can contain a "-" - so this is really a problem - think then we really need to prefix ens - think this is a good idea anyway for future updates - @nagydani - what do you think - or do you have a better idea?
EIPS/eip-831.md
Outdated
|
|
||
| ### 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 |
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
|
@pirapira your change requests should be fulfilled now - thanks for them & let me know if there is anything else I can do to get this one merged |
EIPS/eip-831.md
Outdated
| @@ -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. | |||
There was a problem hiding this comment.
Is the first sentence intended as:
When the prefix is omitted, ...
(notice , instead of -).
EIPS/eip-831.md
Outdated
|
|
||
| `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. |
There was a problem hiding this comment.
In this paragraph, the first - might be a semicolon ; and the second - might be a comma ,.
|
Final editor-like nitpicks. |
|
@pirapira thanks - addressed the editor-like nitpicks - text not that dashy anymore now ;-) |
|
Now I found a solution to how to add a link to ERC-67. There is one good way to add links for EIPs that only exist as issues, like this: |
|
@pirapira good idea - added 76 and 681 as references |
Added explicit reference to ethereum#831
as discussed with @nagydani - extracting the container format from #681 for a cleaner future
cc @rmeissner