Back

16 Describe the applicant's efforts to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string

gTLDFull Legal NameE-mail suffixDetail
.streamdot Stream Limitedfamousfourmedia.comView
Q16
The Applicant has taken steps to ensure that there are no known operational or rendering problems concerning the applied-for gTLD string (the “String”). The following has been undertaken:

a)The TLD label is valid as specified in relevant technical standards, including: Domain Names: Implementation and Specification (RFC 1035), and Clarifications to the DNS Specification (RFC 2181) and any updates thereto;

b)The TLD label, which is 6 characters long, is well short of the 63 character maximum length;

c) The TLD label is a valid host name, as specified IN: DOD Internet Host Table Specification (RFC 952), Requirements for Internet Hosts — Application and Support (RFC1123), and Application Techniques for Checking and Transformation of Names (RFC 3696), Internationalized Domain Names in Applications (IDNA)(RFCs 5890-5894), and any updates thereto;

d)The TLD label consists entirely of letters (a-z)

The Applicant has evaluated the risks of the TLD experiencing TLD Acceptance issues similar to problems reported in the “Evaluation of the New gTLDs: Policy and Legal Issues” (31⁄08⁄2004) which discussed acceptance issues associated with the year 2000 round of new gTLDs with more than three characters (i.e.,.aero,.coop,.info, .museum, .name). At that time, only one gTLD, .arpa, which is not widely used outside of limited circles – had four letters. As a result, the new gTLDs had compatibility problems with the software used by Internet infrastructure operators and application providers. Some users have recently been reporting issues with the use of .xxx names in applications such as Twitter and Skype where domain names entered from that TLD are not instantly recognized with a hyperlink as more established gTLDs are.

The Applicant’s registry backend services provider, Neustar Inc tested the String for potential rendering or operational problems; none were found.

As the String is not an IDN it does not contain characters that require mixed right-to-left or left-to-right functions. The applicant has familiarized itself with the requirements and components of the IDNA protocol by reviewing the RFCs and background information found on the ICANN IDN Wiki.

The Applicant tested the String using the ICANN SWORD String Similarity Assessment Tool algorithm. The result of this test is 53. The Applicant considers this to be below the level where issues might occur. Should Registrants experience any acceptance issues the Applicant will have a dedicated Operational and Rendering Team (“ORT”) on an on-going basis to assist with operational, rendering issues or any other problems that might arise. The ORT will be in place to assist Registrants with any additional problems that may arise out of new TLD that other applicants may be awarded during this process which could lead to unforeseen string confusion now and in the future.
-end-
gTLDFull Legal NameE-mail suffixDetail
.tiresDog Edge, LLCdonuts.coView
Donuts has conducted technical analysis on the applied-for string, and concluded that there are no known potential operational or rendering issues associated with the string.

The following sections discuss the potential operational or rendering problems that can arise, and how Donuts mitigates them.

## Compliance and Interoperability

The applied-for string conforms to all relevant RFCs, as well as the string requirements set forth in Section 2.2.1.3.2 of the Applicant Guidebook.


## Mixing Scripts

If a domain name label contains characters from different scripts, it has a higher likelihood of encountering rendering issues. If the mixing of scripts occurs within the top-level label, any rendering issue would affect all domain names registered under it. If occurring within second level labels, its ill-effects are confined to the domain names with such labels.

All characters in the applied-for gTLD string are taken from a single script. In addition, Donutsʹs IDN policies are deliberately conservative and compliant with the ICANN Guidelines for the Implementation of IDN Version 3.0. Specifically, Donuts does not allow mixed-script labels to be registered at the second level, except for languages with established orthographies and conventions that require the commingled use of multiple scripts, e.g. Japanese.


## Interaction Between Labels

Even with the above issue appropriately restricted, it is possible that a domain name composed of labels with different properties such as script and directionality may introduce unintended rendering behaviour.

Donuts adopts a conservative strategy when offering IDN registrations. In particular, it ensures that any IDN language tables used for offering IDN second level registrations involve only scripts and characters that would not pose a risk when combined with the top level label.


## Immature Scripts

Scripts or characters added in Unicode versions newer than 3.2 (on which IDNA2003 was based) may encounter interoperability issues due to the lack of software support.

Donuts does not currently plan to offer registration of labels containing such scripts or characters.


## Other Issues

To further contain the risks of operation or rendering problems, Donuts currently does not offer registration of labels containing combining characters or characters that require IDNA contextual rules handling. It may reconsider this decision in cases where a language has a clear need for such characters.

Donuts understands that the following may be construed as operational or rendering issues, but considers them out of the scope of this question. Nevertheless, it will take reasonable steps to protect registrants and Internet users by working with vendors and relevant language communities to mitigate such issues.

- missing fonts causing string to fail to render correctly; and
- universal acceptance of the TLD;