]> Identity Digital

Bellevue Washington jgalvin@identity.digital

ICANN

6 Rond Point Schumann, Bd. 1 Brussels 1040 Belgium arnt@gulbrandsen.priv.no https://icann.org/ua

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 .) 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 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 This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

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.