dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0137
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0137 [2019/06/01 22:40] nick ↷ Page moved from dido:public:stds:defact:ethereum:erc_0137 to dido:public:stds:defact:ethereum:eip:erc_0137 |
dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip:erc_0137 [2021/08/18 11:20] (current) murphy |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ======== EIP 137: Ethereum Domain Name Service - Specification ========= | + | ==== EIP 137: Ethereum Domain Name Service - Specification ==== |
| - | [[dido:public:stds:defact:ethereum | Return to Ethereum ERCs ]] | + | [[dido:public:ra:xapend:xapend.b_stds:defact:ethereum:eip| Return to Ethereum ERCs ]] |
| - | + | ||
| - | : **Note**: The following is an excerpt from the official Ethereum site. It is provided here as a connivence and is not authoritative. Refer to the original document as the authoritative reference. | + | |
| + | : **Note**: The following is an excerpt from the official Ethereum site. It is provided here as a convenience and is not authoritative. Refer to the original document as the authoritative reference. | ||
| <table> | <table> | ||
| - | <caption>Data sheet for TTTTT</caption> | + | <caption>Data sheet for Ethereum Domain Name Service - Specification </caption> |
| | Title | Ethereum Domain Name Service - Specification | | | Title | Ethereum Domain Name Service - Specification | | ||
| | Author | Nick Johnson | | | Author | Nick Johnson | | ||
| Line 16: | Line 15: | ||
| </table> | </table> | ||
| - | + | === Abstract === | |
| - | ====== Abstract ====== | + | |
| : //This draft EIP describes the details of the Ethereum Name Service, a proposed protocol and ABI definition that provides flexible resolution of short, human-readable names to service and resource identifiers. This permits users and developers to refer to human-readable and easy to remember names, and permits those names to be updated as necessary when the underlying resource (contract, content-addressed data, etc) changes.// | : //This draft EIP describes the details of the Ethereum Name Service, a proposed protocol and ABI definition that provides flexible resolution of short, human-readable names to service and resource identifiers. This permits users and developers to refer to human-readable and easy to remember names, and permits those names to be updated as necessary when the underlying resource (contract, content-addressed data, etc) changes.// | ||
| - | : //The goal of domain names is to provide stable, human-readable identifiers that can be used to specify network resources. In this way, users can enter a memorable string, such as ‘vitalik.wallet’ or ‘www.mysite.swarm’, and be directed to the appropriate resource. The mapping between names and resources may change over time, so a user may change wallets, a website may change hosts, or a swarm document may be updated to a new version, without the domain name changing. Further, a domain need not specify a single resource; different record types allow the same domain to reference different resources. For instance, a browser may resolve ‘mysite.swarm’ to the IP address of its server by fetching its A (address) record, while a mail client may resolve the same address to a mail server by fetching its MX (mail exchanger) record.// | + | : //The [[dido:public:ra:xapend:xapend.a_glossary:g:goal|goal]] of domain names is to provide stable, human-readable identifiers that can be used to specify network resources. In this way, users can enter a memorable string, such as ‘vitalik.wallet’ or ‘www.mysite.swarm’, and be directed to the appropriate resource. The mapping between names and resources may change over time, so a user may change [[dido:public:ra:xapend:xapend.a_glossary:w:wallet|wallets]], a website may change hosts, or a swarm document may be updated to a new version, without the domain name changing. Further, a domain need not specify a single resource; different record types allow the same domain to reference different resources. For instance, a browser may resolve ‘mysite.swarm’ to the IP address of its [[dido:public:ra:xapend:xapend.a_glossary:s:server|server]] by fetching its A (address) record, while a mail [[dido:public:ra:xapend:xapend.a_glossary:c:client|client]] may resolve the same address to a mail server by fetching its MX (mail exchanger) record.// |
dido/public/ra/xapend/xapend.b_stds/defact/ethereum/eip/erc_0137.1559443252.txt.gz · Last modified: 2019/06/01 22:40 by nick
