]> Identity Digital

Bellevue US jgalvin@identity.digital

Knipp Medien und Kommunikation GmbH

Dortmund Germany michael.bauland@knipp.de

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 Label Generation Rules (LGR): A standard way of defining IDN tables. Among others, they define the variant relationships as well as their disposition values (blocked or allocatable). Variant group: An implicit set of domains defined by the Label Generation Rule (LGR) of the registry. The variant relationship is symmetric and transitive. Hence, an arbitrary element of a variant set defines the whole set. This set is not expressed explicitly in EPP, because it can be impractically large. At the time of writing, a domain is registered whose variant set would contain 10¹⁵ variants. Primary domain: The chronologically first domain in a variant group. While the variant relationship is symmetric, its disposition value is not. It can either be blocked or allocatable. The primary domain name therefore partitions the variant group into allocatable variants and blocked variants. In case of variant TLDs, there can be a primary domain per TLD. Variant domain: A domain in a variant group which is not a primary domain. Allocated variant: A domain that has been created in the registry, and which is tied to an existing primary domain. Allocatable variant: A domain that has not been allocated but is allocatable (according to the LGR), and which is conceptually tied to an existing primary domain. Activated variant: An allocated domain that is in the DNS. TODO: Do we need to differentiate between allocated and activated? Does it make any difference, whether a variant has DNS name servers or not? Exempted domain: A preexisting domain that exists as a stand-alone domain, but would be part of a variant group if it were allocated now. The same entity principle does not apply to exempted domains. The exemption stops as soon as at most 1 allocated domain remains within a variant group. Blocked domain: A domain that cannot be allocated due to its disposition value in relation to the primary domain name.

EPP Commands

EPP <check> command TODO: probably better not to have a command extension. For Registrars, it would be difficult to determine the suitable primary domain. Therefore, it is better to not ask them to send it, but rather return the appropriate primary domain name in the response. `This extension defines a new command called the Variant Check Command that defines an additional primary domain name element for the EPP <check> command. The command MAY contain an <extension> element, which MUST contain a <var:check> element. The <var:check> element MUST contain one <var:primary> element containing the intended primary domain. C: C: C: C: C: examplev1.com C: examplev1.net C: examplev1.xyz C: C: C: C: C: example.com C: C: C: ABC-12345 C: C: ` ]]> For the response, there is a distinction between variant-aware clients (having supplied this extension durin the EPP <login>) and clients that are agnostic of variants. When the server receives a <check> command from a variant-agnostic client and any domain within the checked domain's variant group is allocated (or at least one exempted domain within the variant group exists) the server MUST NOT include an <extension> element. Instead, its response MUST be available = "false". The optional reason MAY be "Unavailable (except as variant)" to tell the registrar it might be available as a variant. When the server receives a <check> command from a variant-aware client and the checked domain is part of a variant group with at least one allocated variant (or exempted domain), its response MUST contain an <extension> element, which MUST contain a child <var:chkData> element. The <fee:chkData> element MUST contain a <var:cd> element for each object referenced in the client <check> command. Each <var:cd> (check data) element MUST contain the following child elements:

• A <var:objID> element, which MUST match an element referenced in the client <check> command.
• An OPTIONAL <var:primary> element.
• A <var:status> element, which explains in more detail the availability status of the queried domain.

Example <check> response: S: S: S: S: Command completed successfully S: S: S: S: S: examplev1.com S: S: S: examplev1.net S: S: S: examplev1.tel S: S: S: examplev1.swiss S: S: S: S: S: S: S: example.com S: example.com S: AllocatableVariant S: S: S: example.net S: NotSameEntity S: S: S: example.tel S: Blocked S: S: S: example.swiss S: PendingTransfer S: S: S: S: S: ABC-12345 S: 54322-XYZ S: S: S: ]]> The EPP <check> command may return five new results:

• The domain cannot be provisioned because it is a variant of a primary domain, and the primary domain belongs to a different client
  => NotSameEntity
• The domain cannot be provisioned because its disposition value is blocked.
  => Blocked
• The domain cannot be provisioned because it is a variant of at least one exempted domain.
  => Exempted
• The domain cannot be provisioned because it is a variant in a group that is currently being transferred to a different registrar.
  => PendingTransfer
• Additional custom value that may be used for server peculiarities.
  => Custom

EPP <info> command Just like with the <check> there needs to be a distinction between variant-aware and variant-agnostic clients. For variant-agnostic clients there is no change to the standard behaviour. The response contains the actual data of the domain, independent of the fact whether it is a variant or not. For variant-aware clients, the EPP <info> command is not extended, but its response is extended if the <info> command concerns a variant domain, i.e., at least two domains within a variant gruop have been activated. The response then always MUST include all primary domain names across any variant TLDs. Optionally the response may include the list of all activated variants (across all variant TLDs). In case a primary domain name is queried in the <info> command, the list of activated variants within the same TLD MUST be returned. In other words: * If you ask about a primary domain name * you must return all existing primaries * you must return all activated variants in that TLD * you may return all activated variants in all variant TLDs

• if you ask about a variant
  • you must return the primary label for that variant
  • you must return all primary labels in all variant TLDs
  • you may return all activated variants in that TLDs
  • you may return all activated variants in all variant TLDs

The main part of the response MUST contain the actual data of the queried domain name (contacts, hosts, status values, etc.)` TODO: check whether EPP spec says anything about the alignment of check and info. For registrars not supporting variants: inquiring about a non-allocated variant should have the similar result as inquiring about a reserved name. If you don't have a policy, suggest a policy. TODO XML example of response

EPP <transfer> command In order to have a safeguard for variant-agnostic clients to not accidentally transfer a bundle of domains when initiating a transfer-in, the EPP <transfer> command is extended to include a flag "include-all-variants". If the flag is set to true, the server knows that the client is aware of variants and willing to include them within the requested transfer. In case the flag is set to false (or the extension is missing), the client is expecting to just transfer the single domain. The <transfer> is extended to include the full list of activated variants accross all TLDs that are transferred together with the main domain. This allows the gaining client to prepare those variant domains in its local database. It is up to the server policy to define whether a variant group can only be transferred in case the (a?) primary domain is used in the request.

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 an exempted 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 exempted This error code is used when a domain specifies a primary domain, and the change is impossible because the specified domain is exempted 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.

Acknowledgements The design of this extension is almost completely based on work done by and decisions made by the committee, chaired by James Galvin. This text (in RFC format) was initially written by Arnt Gulbrandsen based on a conference presentation by James Galvin. Edmon Chung, [YOUR NAME HERE] have reviewed it, provided helpful comments or contributed in other ways.

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

References 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. Informative References This document describes a method of representing rules for validating identifier labels and alternate representations of those labels using Extensible Markup Language (XML). These policies, known as "Label Generation Rulesets" (LGRs), are used for the implementation of Internationalized Domain Names (IDNs), for example. The rulesets are used to implement and share that aspect of policy defining which labels and Unicode code points are permitted for registrations, which alternative code points are considered variants, and what actions may be performed on labels containing those variants.

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 exempted? 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 exempted 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.