Domain variant support for EPP
Internet-Draft draft-galvin-regext-epp-variants-00
James Galvin
Identity Digital
Bellevue
Washington
jgalvin@identity.digital
Arnt Gulbrandsen
ICANN
6 Rond Point Schumann, Bd. 1
Brussels
1040
Belgium
arnt@gulbrandsen.priv.no
https://icann.org/ua
18 September 2024
Applications
EXTRA
EPP
This document defines an EPP extension allowing clients to learn about and manipulate variant groups of domains, ie. groups of domains whose names are equivalent in a registry-defined way and are tied to a single registrant.
Introduction
Spelling is not necessarily uniform. For example, an è and an e may be regarded as equivalent in some languages, and as different in others.
Some registries plan to support this explicitly, with groups of variant domains that can only be registered by the same registrant.
This document defines an EPP extension allowing clients to learn about and manipulate variant groups. (EPP is defined in [RFC5730].)
Registering a domain creates a variant group and the first domain in the group becomes the group's primary domain. Subsequent domains in the same group can only be registered by the same registrar, which asserts that it is acting on behalf of the same registrant. Domains in a variant group are transferred or deleted together with the primary domain. The remainder of this document describes the specific details.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Terms
Variant group: An implicit set of domains. This set is not expressed explicitly in EPP, because it can be impractically large. At the time of writing, a domain is registered whose a variant group would contain 10¹⁵ variants.
Primary domain: The chronologically first domain in a variant group.
Variant domain: A domain in a variant group.
Allocatable variant: A domain that has not been registered, and which is conceptually tied to an existing primary domain.
Allocated variant: A domain that has been registered, and which is tied to an existing primary domain.
Grandfathered domain: A preexisting domain that would form a variant group if it were registered now.
Blocked domain: A domain that has not been registered, and which is conceptually tied to one or more existing grandfathered domains.
Normal domain: Any domain that has no variants, ie. its variant group would consist of only the domain itself. "42.example" might be such a domain, assuming that there are no equivalent variants of "42".
EPP Commands
EPP <check> command
The EPP <check> command may return three new results:
- The domain cannot be provisioned because it is a variant of a primary domain, and the primary domain was not mentioned in the <check> command.
- The domain cannot be provisioned because it is a variant of at least one grandfathered domain.
- The domain cannot be provisioned because it is a variant in a group that is currently being transferred to a different registrar.
TODO XML examples of at least one
EPP <info> command
The EPP <info> command is not extended, but its response is extended with the name of the primary domain if the <info> command concerns a variant domain.
TODO XML example of response
EPP <transfer> command
The EPP <transfer> command is modified as follows:
- A transfer of a primary domain also transfers all of the variants of that domain.
- A transfer of a variant domain returns en error.
EPP <create> command
The EPP <create> command may have three new errors, as described in the <check> section above.
The EPP <create> command's task is to provision a new normal domain. The task of converting an allocatable domain into an allocated domain is instead performed using the update command.
EPP <update> command
The EPP <update> command is extended to cover two new major tasks:
When an EPP client wishes to provision a new domain in a variant group, it uses the <update> command rather than the <create> command. This informs the EPP server that the client understands that the task is to provision a variant domain rather than a new normal domain, and asserts that the two domains belong to the same registrant.
Note that depending on registry policy, the variant domain may e.g. share name servers with the primary domain. This implies that the set of elements required/permitted for a variant domain may differ from that of a primary domain or a normal domain.
TODO update XML that shows the primary domain specified
When an EPP client wishes to turn a grandfathered domain into a primary domain, it issues an <update> command including the list of variant domains, which the EPP client thereby asserts belong to the same registrant.
TODO update XML that shows the list of variant domains specified
EPP <delete> command
The EPP <delete> command is extended with one new task: Deleting the primary domain deletes all allocated variant groups along with the primary domain.
Deleting a variant group other than the primary deletes just that domain.
EPP renew command
The EPP renew command is not extended.
The server MAY reject renewals while a variant group is being transferred.
EPP <transfer> query command
The EPP <transfer> query command is not extended.
Note that because variant groups are transferred as a group, the result of the a <transfer> query command is necessarily the same for all domains in a group. Therefore, the result of <transfer> query command for any domain in a variant group applies to all domains in the group.
Result codes
The following additional result codes are defined:
23x1: Change impossible because of a transfer in progress.
23x2: Change impossible because something is not a variant.
This error code is used when a change presupposes that two domains belong to the same variant group, but the EPP server's implementation disagrees.
23x3: Change impossible due to invalid primary domain
This error code is used when the primary domain specified in the command is not registered, or is not registered via this registrar.
23x4: Change impossible due to unspecified primary domain
This error code is used when a command needs to specify a primary domain, and does not.
23x5: Specified domain is grandfathered
This error code is used when a domain specifies a primary domain, and the change is impossible because the specified domain is grandfathered instead.
23x6: Specified domain is allocatable, but not by you.
This result code is used when a domain is a member of a variant set, and the command did not refer to the primary domain.
Security Considerations
If two domains are different according to the DNS rules and identical in the eyes of the intended audience, then the audience may be confused. Confusion can always have security-related effects.
This extension expresses the relationships between variants clearly, making it a little more difficult for a would-be impersonator to register a variant of another registrant's existing domain.
IANA Considerations
Normative References
[RFC5730]

Extensible Provisioning Protocol (EPP)
S. Hollenbeck
August 2009
STD 69
RFC 5730
DOI 10.17487/RFC5730
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Open issues
Open issue: Assign numbers to the error codes, properly.
Open issue: Not clear that there are any security considerations here — the relationships between the domains may have some, but those exist outside EPP, EPP merely describes them. In Italian, caffe and caffè are variants of the same thing, it's not clear that linking them in a protocol affects security in any way.
Open issue: Check how to insert a DS record in a variant domain.
Open issue: Can a unicode upgrade cause domains to become grandfathered? Yes, I think, and the terminology covers it, but as of now, it's difficult for the EPP client to understand the situation. Extending the <info> command would help here, perhaps.
Open issue: Creating a primary domain now consists of a two-step process, <create> and then <update>. The first step turns all variants into blocked domains, the second makes them allocatable. It's not clear to me why the two-step process is desirable, compared to a one-step process where a <create> command creates a primary domain if the variant group contains other domains than that one. That needs a couple of sentences of explanation, or else a change.
Open issue: <Delete> now cascades and deletes many domains. Should it instead turn any variant domains into grandfathered domains?
Open issue: Should the <info> of the primary domain also return the list of allocated variants? Probably not — at the moment, this extension has the client send a set that the server checks, and the server may need to generate a set for checking, but the server does not need to generate a list for returning.