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
.taxiTaxi Pay GmbHtaxi.euView
TaxiPay GmbH has carefully examined the applied-for string (incl. S.W.O.R.D test) and found that deployment of it would not cause adverse operational, rendering, or general user-confusion due to visual similarity with existing TLDs, ISO3166 lists, ICANN list of reserved names, or list of ineligible strings. It is safe to assume similar to existing ASCII-only TLD strings like .com, .net or .de, no operational or rendering problems should be expected. In particular, the string “taxi” consists entirely of ASCII letters that are already used for existing top level domains. All the characters in the name are even used in the leftmost position of existing TLD labels. It constitutes a valid host name having at least three and less than 63 characters. The ASCII label is therefore in compliance with the string requirements set forth in the Applicant Guidebook (Applicant Guidebook, p. 64, 2.2.1.3.2 “String Requirements”) and with all technical standards such as, but not limited to, RFC 1035, RFC 2181, RFC 952, RFC 1123, and RFC 3696. Since the registry does not support right-to-left scripts on the second level, bi-directional issues (as described at http:⁄⁄stupid.domain.name⁄node⁄683) will not occur. Moreover, the gTLD string exclusively uses characters from a single alphabet, and contains characters that are not subject to homograph issues. This means that there is no potential for confusion with regard to the rendering of other TLD strings. However, TaxiPay GmbH is aware of its responsibility to mitigate and resolve possible issues, as discussed during the TLD Universal Acceptance session at the Costa Rica ICANN Meeting (http:⁄⁄costarica43.icann.org⁄meetings⁄sanjose2012⁄presentation-tld-universal-acceptance-14mar12-en.pdf). Such issues are: 1. Validity checks of TLDs based on either a hard-coded list (which may not be updated with all new gTLDs) or a length check (i.e. maximum of characters). 2. Name conversion in various applications and browsers. Based on wrong definitions or outdated lists of TLDs, some applications may not convert new gTLD to links. 3. User acceptance. Some websites or applications may regard email addresses or URLs entered by users as invalid, if they contain a new gTLD, with the effect of e.g. refusing registration. 4. Email clients validating addresses on the length of TLDs by applying an outdated list of TLDs may also cause problems, as valid email addresses may not be accepted. 5. Websites and search engines such as, but not limited to, Google, Yahoo, and Bing may refuse to offer services such as advertising, if they validate email addresses and valid domain names based on outdated definitions of TLDs, or simply refuse to add new gTLDs to their listsTaxiPay GmbH will work towards enabling general global acceptance of new gTLDs by consulting with registry operators, service providers, and software developers to ensure and encourage a quick adoption of new gTLDs on the internet namespace.
gTLDFull Legal NameE-mail suffixDetail
.allfinanzAllfinanz Deutsche Vermögensberatung Aktiengesellschaftthomsentrampedach.comView
We have carefully examined (including S.W.O.R.D test) the applied-for string “ALLFINANZ” and found that deployment of it would not cause adverse operational, rendering, or general user-confusion due to visual similarity with existing TLDs⁄ISO3166 lists⁄ICANN reserved list of names & list of ineligible strings. The string consists entirely of ASCII letters and is a valid hostname having at least three and less than 63 characters, the ASCII Label is therefore in compliance with the string requirements set forth in the Applicant Guidebook (Applicant Guidebook, page 64, section: 2.2.1.3.2 “String Requirements”) and with all technical standards such as but not limited to RFC 1035, RFC 2181, RFC 952, RFC 1123, and RFC 3696.

Although the applied for string is pure ASCII characters the applicant is aware of its responsibility to seek to mitigate and solve inter alia such issues, as discussed on the “TLD Universal Acceptance” session at the Costa Rica ICANN Meeting on Wed, 14 March 2012 (http:⁄⁄costarica43.icann.org⁄meetings⁄sanjose2012⁄presentation-tld-universal-acceptance-14mar12-en.pdf):

1. Validity checks of TLDs based on either a hard coded list (may not be updated with all new gTLDs) or on a length check (i.e. maximum three characters)
2. Name conversion in various applications and browsers. Based on wrong definitions or outdated lists of TLDs, some applications may not convert this new gTLD to links
3. User acceptance. Some websites⁄applications may refuse user acceptance of users entering a new gTLD not accepted by the website⁄application
4. Email clients validating on length on TLDs on by applying an outdated list of TLDs may also cause problems for this new gTLD, as valid email addresses may not be accepted
5. Websites and Search Engines such as, but not limited to, Google, Yahoo! may refuse to offer services such as advertising, if they validate email addresses and valid domain names based on outdated definitions of TLDs, or simply refuse to add new gTLDs to their lists
6. Mobile browsers may also not be updating their lists of valid TLDs, as live DNS look ups, may be considered costly or in adequate by the providers

Actions to mitigate or solve these issues:

As the TLD is longer than 3 characters, it is understood that some issues concerning usage of the TLD in online forms will exists. We take the full responsibility for any such issues and will work towards enabling general global acceptance for TLDs, not just with this TLD but all others as well. We will ensure that all known websites expecting to use the TLD will be communicated with concerning this issue and we will make all our own online forms available to accept all ICANN TLDs per the IANA list. We will work with ICANN in our on-going effort on this subject both for IDN TLDs and ASCII TLDs.

Second Level IDN specific issues are addressed in our response to Question 44.