IDN.2.4.Same Entity Allocation
Describe how compliance will be achieved for second-level variant labels that arise from a registration based on a second-level IDN table where all allocatable variant labels in the set must only be allocated to the same entity or withheld for possible allocation only to that entity (e.g., all allocatable second-level labels {s1, s1v1, …} under the TLD.
Response
Registry Services, LLC d/b/a/ GoDaddy Registry loads all languages/scripts into the system from their native LGR form and assigned to the relevant TLDs based on their Registry Agreement.
All second-level domain name registrations have three forms recorded and stored in the database:
- The requested domain name as they have provided in both U-label and A-label form.
- Canonical form that is generated by the system which considers all the character variant mappings between languages and scripts supported in a TLD to ensure uniqueness.
For example, the Cyrillic IDN registration вов.example where .example supports Cyrillic and ASCII registrations. This IDN is composed of (excluding the TLD) the following:
- в;U+0432#CYRILLIC SMALL LETTER VE
- о;U+043E#CYRILLIC SMALL LETTER O
- в;U+0432#CYRILLIC SMALL LETTER VE
The LGR for Cyrillic has the following variant mappings:
в;<char cp="0432"><var cp="0062" type="blocked" /></char>
о;<char cp="043E"><var cp="006F" type="blocked" /><var cp="00F3" type="blocked" /><var cp="03BF" type="blocked" /><var cp="03CC" type="blocked" /></char>
This maps в (0432) with ASCII b (0062) and о (043E) with ASCII o (006F).
The process involves the following steps:
- Registrar over EPP performs a domain create extended with the idn-1.0 extension and provides:
* The IDN using A-Labels.
* The language/script tag.
* Optionally the IDN using U-Labels.
- The system validates the characters in the IDN are included in the LGR identified by its language/script tag.
- The system checks that the IDN is canonically unique by checking the canonical form of all registered domain names in the TLD.
- If the above conditions pass, the IDN is created, and the following is stored:
* U-Label: вов.example.
* A-Label: xn--b1aa9a.example.
* Computed canonical form.
If an attempt to create bob.example is requested, it will fail because bob.example is not canonically unique as вов.example/xn--b1aa9a.example is registered.
See diagram Fig 2 in attachment, this diagram shows the process in how the Registry stores IDNs in the database.
The Registry ensures that an IDN and any variants it potentially has all compute to the same canonical form (in a TLD).
The Registry requires that every IDN registration has a unique canonical form. This ensures that all variants of a registration are withheld from separate registration.
See diagram Fig 5 in attachment, this diagram shows how variants are blocked from new registrations.
Variants may be allocated to a domain (if applicable and the TLD configuration allows) however are not considered separate objects.
To activate a variant, only the sponsor of the IDN may request the activation and must supply the exact label they wish to activate. If the label is canonically identical to the IDN and the LGR rules permit, then the activation is permitted.
A label cannot be added as a variant to an unrelated IDN as they would not share the same canonical form.
See diagram Fig 6 in attachment, this diagram shows how variants are allocated.
Via EPP, Registrars can manage variants by using the variant extension which isn’t a published IETF extension, it is extension that is written for use with the system. https://godaddyregistry.github.io/doc/variant-1.1/variant-1.1.html
Because variants are attributes of their parent domain name, they do not have a separate lifecycle.
Upon activation of the variant, all DNS records of the parent IDN are published into DNS for the variant IDN, and the variant itself cannot be separately managed meaning:
- A lookup of the variant will return the parent IDN and is shown as a variant.
- The variant is an attribute of the parent IDN.
See diagram Fig 3 in attachment, this diagram shows how the Registry publishes DNS records for an activated IDN variant based on their parent domain’s DNS records.
Registry Operators may consider including a provision in their Registry-Registrar Agreement to require same entity allocation of variants.
Attachments