| Internet-Draft | EPP Variants | September 2024 |
| Galvin & Gulbrandsen | Expires 22 March 2025 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 March 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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.¶
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.¶
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".¶
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¶
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¶
The EPP <transfer> command is modified as follows:¶
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.¶
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¶
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.¶
The EPP renew command is not extended.¶
The server MAY reject renewals while a variant group is being transferred.¶
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.¶
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.¶
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.¶
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.¶