This is a standard for generic name resolution with arbitrarily complex access control and resolution. It permits a contract that implements this EIP (referred to as a "domain" hereafter) to be addressable with a more human-friendly name, with a similar purpose to ERC-137 (also known as "ENS").
The advantage of this EIP over existing standards is that it provides a minimal interface that supports name resolution, adds standardized access control, and has a simple architecture. ENS, although useful, has a comparatively complex architecture and does not have standard access control.
In addition, all domains (including subdomains, TLDs, and even the root itself) are actually implemented as domains, meaning that name resolution is a simple iterative algorithm, not unlike DNS itself.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
To resolve a name (like "a.b.c"), split it by the delimiter (resulting in something like ["a", "b", "c"]). Set domain initially to the root domain, and path to be an empty list.
Pop off the last element of the array ("c") and add it to the path, then call domain.hasDomain(path). If it's false, then the domain resolution fails. Otherwise, set the domain to domain.getDomain(path). Repeat until the list of split segments is empty.
There is no limit to the amount of nesting that is possible. For example, 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z would be valid if the root contains z, and z contains y, and so on.
Here is a solidity function that resolves a name:
This EIP's goal, as mentioned in the abstract, is to have a simple interface for resolving names. Here are a few design decisions and why they were made:
This EIP is general enough to support ENS, but ENS is not general enough to support this EIP.
canMoveSubdomainMoving a subdomain using setDomain is a potentially dangerous operation.
Depending on the parent domain's implementation, if a malicious new subdomain unexpectedly returns false on canMoveSubdomain, that subdomain can effectively lock the ownership of the domain.
Alternatively, it might return true when it isn't expected (i.e. a backdoor), allowing the contract owner to take over the domain.
canMoveSubdomainClients should help by warning if canMoveSubdomain or canDeleteSubdomain for the new subdomain changes to false. It is important to note, however, that since these are functions, it is possible for the value to change depending on whether or not it has already been linked. It is also still possible for it to unexpectedly return true. It is therefore recommended to always audit the new subdomain's source code before calling setDomain.
Parent domains have full control of name resolution for their subdomains. If a particular domain is linked to a.b.c, then b.c can, depending on its code, set a.b.c to any domain, and c can set b.c itself to any domain.
Before acquiring a domain that has been pre-linked, it is recommended to always have the contract and all the parents up to the root audited.
Copyright and related rights waived via CC0.