Skip to main content
Resources

Trademark Clearinghouse Rights Protection Mechanism Requirements Frequently Asked Questions

Published on 25 October 2019

The following are frequently asked questions regarding the Trademark Clearinghouse Rights Protection Mechanism Requirements ("TMCH Requirements"). These FAQs should be used as guidance by Registry Operators and registrars in complying with the TMCH Requirements, but they should not be construed as describing every requirement of the TMCH Requirements and the actual TMCH Requirements should be reviewed carefully. ICANN org may update these FAQs from time to time. Capitalized terms used in these FAQs have the meaning given to them in the TMCH Requirements.

Integration Testing

Q1: Who is the TMCH Sunrise and Claims Operator?

A1: The TMCH Sunrise and Claims Operator is IBM.

Q2: How do I conduct Integration Testing?

A2: Integration Testing is conducted in a test database made available by IBM. For more information regarding Integration Testing, please visit http://newgtlds.icann.org/en/about/trademark-clearinghouse/scsvcs.

Q3: What is the validity of the token? What is the process to renew credentials?

A3: Tokens are generally active within four hours of receipt and do not expire so by using the token provided, registry operators and registrars may register at the TMDB website to generate user credentials at their convenience. The credentials are provided by IBM. Thus, in case there are issues with credentials, registry operators and registrars should reach out to IBM directly to acquire new credentials either via emailing ICANNSD@nl.ibm.com or calling +32 2 711 8604 or +48 7 1760 8509.

Q4: For what period of time will Registry Operators and registrars be permitted to conduct their Integration Testing?

A4: Following execution of the Registry Agreement/Registrar Accreditation Agreement, Registry Operators/registrars may complete Integration Testing (and request testing certification) at any time convenient for them.

Q5: How will waivers of Integration Testing be granted?

A5: In some cases, e.g., where a Registry Operator, its service provider or a registrar maintains multiple gTLD services from a single platform, Integration Testing may be waived. For more information on the waiver process and criteria, please visit https://newgtlds.icann.org/en/about/trademark-clearinghouse/scsvcs/certification-exemption-procedure-10feb14-en.pdf.

TLD Startup Information

Q6: What is "TLD Startup Information" and do Registry Operators have to provide it for each TLD?

A6: TLD Startup Information is the required information that each Registry Operator must provide to ICANN org for each TLD after delegation and prior to starting its Sunrise Period. TLD Startup Information includes the dates for the relevant startup periods (e.g., Sunrise, Claims, and, if applicable, any Qualified Launch Program and Limited Registration Periods), as well as the complete Sunrise registration policies for the TLD, including all applicable policies related to restrictions to register a domain name in the TLD during the Sunrise Period, and the TLD's Sunrise Dispute Resolution Policy. TLDs with an approved Specification 13 are not required to run a Sunrise Period, thus their launch plans are not required to include dates for Sunrise or any Sunrise Period related policies.

Q7: When can a Registry Operator submit its TLD Startup Information to ICANN org?

A7: Registry Operators may submit their TLD Startup Information to ICANN org any time after their TLD is delegated. TLD Startup Information submitted prior to delegation will not be accepted.

Q8: How does a Registry Operator submit its TLD Startup Information to ICANN org?

A8: Registry Operators should submit their TLD Startup Information via ICANN org's Naming Services portal by selecting the applicable service case - "Submit TLD Startup Information (Spec-13)" or "Submit TLD Startup Information (non-Spec13)".

Q9: How long will ICANN org's review of a Registry Operator's TLD Startup Information take?

A9: ICANN org will review TLD Startup Information as promptly as practicable. The actual review time will vary depending on the volume of submissions at a given time and the quality of each submission. The review will ordinarily not exceed four business days. If there are issues found within the submitted TLD Startup information, ICANN org's review might take longer and require follow up with the Registry Operator.

Q10: Do Registry Operators need to account for ICANN org's review of TLD Startup Information in the timing of their Sunrise startup plans?

A10: Since it is possible that TLD Startup Information may be determined to not be compliant, Registry Operators are encouraged to account for ICANN org's review of TLD Startup Information when submitting their TLD Startup Information, including the expected start dates. In order to facilitate a smooth transition from submission of TLD Startup Information to the start of the TLD's Sunrise Period, Registry Operators are encouraged to request a Sunrise Period start date that is at least seven calendar days after the date of submission of their TLD Startup Information if they are conducting an End-Date Sunrise Period or at least seven calendar days plus the 30-day notice period from the planned start date of a Start-Date Sunrise Period.

Q11: Does a Registry Operator need to provide ICANN org its policies related to general registration in addition to policies related to Sunrise Registrations?

A11: Registry Operators are not required to provide ICANN org with registration policies that only relate to General Registration as part of their TLD Startup Information. However, to make registration policies available to potential registrants, Registry Operators are encouraged to provide ICANN org with copies of all General Registration policies as part of their TLD Startup Information. Additionally, ICANN will publish compliant TLD Startup Information on its website.

Q12: Does a Registry Operator have to provide language of its relevant registration policies in its TLD Startup Information or will links to websites with the published policies suffice?

A12: Registry Operators must include the language of their relevant registration policies in its TLD Startup Information submitted to ICANN org.

Q13: What happens if a Registry Operator's TLD Startup Information is determined to not be compliant with the TMCH Requirements?

A13: ICANN org will review submitted TLD Startup Information for compliance with the TMCH Requirements (e.g., Was all necessary information provided? Are the time periods compliant?). If ICANN org determines that the provided TLD Startup Information is non- compliant, it will notify the Registry Operator and explain the non-compliant aspects of the TLD Startup Information. Thereafter, the Registry Operator must provide revised TLD Startup Information, which ICANN org will then review for compliance. The Registry Operator may not begin its Sunrise Period until ICANN org has determined that that Registry Operator's TLD Startup Information is compliant with the TMCH Requirements and has provided the Registry Operator with the accepted Sunrise Period start and end dates.

Q14: Will ICANN org review TLD Startup Information for matters not related to the TMCH Requirements?

A14: ICANN org's review of TLD Startup Information is to confirm compliance with the TMCH Requirements. To the extent commercial terms are unrelated to the TMCH Requirements, they will not be reviewed.

Q15: What if a Registry Operator wants to make changes to its TLD Startup Information, such as to change the start date or end date of its Sunrise Period?

A15: If a Registry Operator wants to change information contained in TLD Startup Information that has been accepted by ICANN org, it must provide updated compliant TLD Startup Information by opening a General Inquiry case through the Naming Services portal. Any changes to the start date or end date of a Sunrise Period must be provided at least ten calendar days before the rescheduled start date and will be subject to a compliance review by ICANN org. Sunrise registration policies and whether a Sunrise Period will be a Start-Date Sunrise or an End-Date Sunrise cannot be changed once a Sunrise Period has started. Additionally, if a Registry Operator wants to make changes to its registration policies which were already approved, it is required to provide updated policies to ICANN org. Once the mandatory Sunrise Period and Claims Period are complete, any additional registration periods that a Registry Operator may run, or changes to registration policies, do not require ICANN org's review and approval.

Sunrise Period

Q16: Is a Sunrise Period required for every TLD?

A16: A Sunrise Period is required for every new gTLD except for those with Registry Agreements that include Specification 13 (.Brand TLD Provisions). If a Registry Operator either voluntarily requests removal of Specification 13 from their Registry Agreement or if ICANN org disqualifies a TLD as .Brand TLD, that Registry Operator must comply with all other provisions of the Trademark Clearinghouse including providing TLD Startup information and compliance with the Sunrise requirements effective as of the removal/disqualification date and commence a Sunrise Period within 60 calendar days of the removal/disqualification date.

Q17: Does every Registry Operator have to use the Trademark Clearinghouse for its Sunrise Period?

A17: Yes. A Registry Operator may not process registrations of domain names during a Sunrise Period unless the registration is accompanied by a valid Signed Mark Data (SMD) file issued by the Trademark Clearinghouse.

Q18: Must a Registry Operator provide ICANN org with advance notice before launching its Sunrise Period?

A18: Registry Operators must conduct either a "Start-Date Sunrise" or an "End-Date Sunrise". To offer a Start-Date Sunrise, a Registry Operator must provide at least 30 days notice to ICANN org and Trademark Clearinghouse before the start date of the Sunrise Period. An End-Date Sunrise may commence any time after a Registry Operator's TLD Startup Information has been accepted by ICANN org. In either case, a Sunrise Period must not begin until ICANN org has accepted the Registry Operator's TLD Startup Information and the Registry Operator has been assigned a Sunrise Period start date. Please see also Q10.

Q19: How long must a Sunrise Period last?

A19: A Start-Date Sunrise Period must stay open for at least 30 days and cannot commence prior to expiration of the required 30-day advance notice period. An End-Date Sunrise Period must stay open for at least 60 days.

Q20: Must a Registry Operator have Sunrise Period registration policies?

A20: Other than the requirement that Sunrise Registrations be accompanied by a valid SMD file, a Registry Operator may follow its general registration policies during the Sunrise Period. If a Registry Operator will apply only its General Registration policies during the Sunrise Period and no Sunrise Period specific registration policies, the Registry Operator must provide those General Registration policies as its Sunrise Period registration policies with its TLD Startup Information.

Q21: What registration restrictions can a Registry Operator impose during the Sunrise Period?

A21: All registrations during a Sunrise Period must include a valid SMD file. Additionally, a Registry Operator may (i) apply restrictions relating to the underlying rights of a trademark related to the purpose of the TLD, (ii) specify requirements that are not related to the scope of mark rights, (iii) require the SMD file information to match the applicable registration data, and (iv) impose reasonable date restrictions relating to the date that the trademark was registered, validated or protected, to prevent gaming of the Sunrise Period. Any registration restrictions during Sunrise Period must be imposed consistently throughout any other period, such as Limited Registration Period and General Registration.

Q22: Can a Registry Operator impose trademark related registration requirements in a Sunrise Period and curtail or eliminate these requirements in subsequent registration periods?

A22: No. During a Sunrise Period, a Registry Operator may apply restrictions relating to the underlying rights of a Trademark Record so long as those restrictions are related to the purpose of the TLD. For example, if the purpose of a TLD was to serve a particular region, the Registry Operator could require that the Trademark Record be registered in that jurisdiction to be eligible for the Sunrise Period. However, if a subsequent registration period has a registration restriction where a domain name registrant only needs to have a Trademark Record from any jurisdiction, such a registration restriction may be seen as evidence that the jurisdiction restriction in the Sunrise Period was not actually related to the purpose of the TLD.

Q23: Do Registry Operators have to offer any sort of dispute resolution policies for registrations in their Sunrise Periods?

A23: Yes. New gTLD Registry Operators with a Sunrise Period must have a Sunrise Dispute Resolution Policy (SDRP), which will allow challenges to Sunrise Registrations related to the Registry Operator's Allocation and registration policies, including on the grounds that the domain name that was registered does not match the Trademark Record on which the Sunrise-Eligible Rights Holder based its Sunrise Registration. Because each TLD's Sunrise Period registration policies can be different, the Registry Operator has discretion when designing its SDRP. A complete SDRP must be included in the TLD Startup Information.

Q24: Can a Registry Operator register or Allocate domain names prior to the completion of the Sunrise Period to non-Sunrise Eligible Rights Holders?

A24: The general rule is that domain names may only be registered during a Sunrise Period to Sunrise-Eligible Rights Holders who have a valid SMD file issued by the Trademark Clearinghouse. Unless the Registry Operator has received ICANN org's approval for an Approved Launch Program or conducts a Qualified Launch Program as described in the TMCH Requirements, the Registry Operator may not register or Allocate domain names prior to the completion of the Sunrise Period to non-Sunrise-Eligible Rights Holders. An Allocation of a domain name includes any allocation, designation, assignment, or other form of earmarking of a domain name to a potential domain name registrant. A domain name may be considered to have been Allocated even if the domain name is not ultimately registered to the third party to whom the domain name was Allocated. Whether there are events or conditions that must happen or not happen after an earmarking of the domain name for the domain name to be registered to that registrant does not affect whether the domain name was Allocated at a certain point in time.

Q25: How is Allocation or registration of domain names different between a Start-Date Sunrise and an End-Date Sunrise?

A25: In a Start-Date Sunrise, a Registry Operator may Allocate or register domain names on a first-come, first-served basis or any other time-based Allocation or registration process, in addition to any other manner of Allocation or registration they desire. In an End-Date Sunrise, a Registry Operator must not Allocate or register domain names prior to the end of the Sunrise Period and must not employ a first-come, first-served or any other time- based Allocation or registration process.

Q26: If a Registry Operator plans to hold auctions at the end of its Sunrise Period, how does that comply with Section 3.2.4 of the TMCH Requirements?

A26: Registry Operators may accept applications for the same domain name from different Sunrise-Eligible Rights Holders. If an auction is used to define the ultimate registrant of that domain name as one of the Sunrise-Eligible Rights Holders, and the domain name is withheld for such Sunrise-Eligible Rights Holder, thus not allocating nor registering the domain name to registrants in a Limited Registration Period or General Registration, then the auction methodology complies with Section 3.2.4.

Q27: How does the 120-day no-activation period under Name Collision Occurrence Management Framework factor into Sunrise Periods?

A27: Under the Name Collision Occurrence Management Framework, no domain names may be activated in a TLD until 120 days after the Registry Agreement for the TLD is signed. It is possible that a Sunrise Period may commence prior to the expiration of this 120-day period. In this situation, Sunrise Registrations may be registered or Allocated to Sunrise Eligible Rights Holders during the Sunrise Period but cannot be activated until the 120-day period has expired. The same prohibition on activation also applies to any Qualified Launch Program or Approved Launch Program.

Q28: What must a registrar do when processing Sunrise Registrations?

A28: The specific technical obligations that Registrars may choose to perform when processing Sunrise Registrations are available at https://tools.ietf.org/html/draft-ietf-regext-tmch-func-spec sections 5.2.4 and 5.2.5. In general, Registrars may choose to perform the checks for verifying domain name registrations as performed by the Registry Operators before sending the command to register a domain name. These checks include verifying that a SMD file has been sent by the Registrant to the Registrar (which the Registrar sends to the Registry Operator), that the signature of the SMD file is valid, and that the SMD file has not been revoked by the TMCH.

Launch Programs and Other Registration Periods

Q29: What are the different types of new gTLD launch programs?

A29: Qualified Launch Program and Approved Launch Program are the launch programs defined in TMCH Requirements.

Q30: What is the Qualified Launch Program described in Section 4.5.1 of TMCH Requirements?

A30: The Qualified Launch Program provides a mechanism for Registry Operators to register up to 100 names to third parties to promote their TLDs prior to the Sunrise Period, while maintaining safeguards against intellectual property infringement. A Registry Operator wishing to take advantage of the Qualified Launch Program may do so after delegation of the TLD and before the end of the Sunrise period. Registry Operators intending to use the Qualified Launch Program must inform ICANN org as part of their TLD Startup Information. See https://newgtlds.icann.org/en/announcements-and-media/announcement-10apr14-en for details on the Qualified Launch Program.

Q31: Besides Qualified Launch Programs, is there any way for a Registry Operator to Allocate or register domain names prior to its Sunrise Period?

A31: Yes. Approved Launch Program allows a Registry Operator to Allocate or register domain names prior to its Sunrise Period. A Registry Operator may, after signing its Registry Agreement and until the start date of its Sunrise Period, apply to ICANN org for approval to conduct an Approved Launch Program as described in Section 4.5.2 of the TMCH Requirements.

Q32: What is the Approved Launch Program described in Section 4.5.2 of TMCH Requirements?

A32: An Approved Launch Program provides a mechanism for a Registry Operator to apply to ICANN org for approval to conduct a registration program prior to the start date of its Sunrise Period. Except pursuant to a Launch Program (such as Approved Launch Program) or Registry Operator's self-allocation or registration to itself of domain names pursuant to Section 3.2 of Specification 5 of the Registry Agreement, Registry Operator MUST NOT allow a domain name to be Allocated or registered in the TLD to a registrant that is not a Sunrise-Eligible Rights Holder with a valid SMD file prior to the Allocation or registration of all Sunrise Registrations.

Q33: How does a Registry Operator apply for an Approved Launch Program?

A33: A Registry Operator wishing to apply for an Approved Launch Program must submit such request via the Naming Services portal by opening a General Inquiry case. An Approved Launch Program must be received and approved by ICANN org before the Registry Operator starts its Sunrise Period. Any Registry Operator's application to offer an Approved Launch Program may be published for public comment at ICANN org's discretion.

Q34: I am a Registry Operator who described a launch plan in my application for my TLD. How does that affect me if I apply for an Approved Launch Program?

A34: If a Registry Operator applies to ICANN org to conduct an Approved Launch Program that would implement programs set forth in its application for the TLD, there will be a presumption that the Launch Program will be allowed so long as it was set forth in reasonable detail in the application for the TLD so as to allow for meaningful review and public comment of the plan at the time the application was posted. A Registry Operator who seeks the benefit of this presumption must state with specificity the relevant portions of its TLD application that describe the launch program as well as detail how the applied for program in its Approved Launch Program application compares to the launch program described in its TLD application. ICANN org will review the Approved Launch Program application, as well as any public comments submitted in response to the program described in the TLD application, and may reject the Approved Launch Application if ICANN org reasonably determines that such requested registration program could contribute to consumer confusion or the infringement of intellectual property rights.

Q35: If ICANN org has already approved an Approved Launch Program similar to the registration program that a Registry Operator applies for, does that mean the application will automatically be approved?

A35: If a Registry Operator seeks ICANN org's approval of a registration program that is substantially similar to an Approved Launch Program previously approved by ICANN org under similar circumstances for the new gTLD program, the requested registration program application will carry a presumption of being approved. A Registry Operator who seeks the benefit of this presumption must state with specificity why the Approved Launch Program application is similar to the allegedly similar Approved Launch Program and detail the facts and circumstances evidencing such similarity. ICANN org will review the Approved Launch Program application and may reject the Approved Launch Program application if ICANN org reasonably determines that the requested registration program could contribute to consumer confusion or the infringement of intellectual property rights.

Q36: I am a Registry Operator that indicated in my application that my TLD would be a geographic TLD. What are my options with respect to Approved Launch Programs?

A36: A Registry Operator that indicated that its TLD would be a geographic TLD can apply to conduct an Approved Launch Program just like any other Registry Operator.

In addition, if registry operators that indicated in their applications for their TLDs that their TLD would be a geographic TLD and representatives of the Intellectual Property Constituency (IPC) recommend to ICANN org the creation of a registration program that sets forth a defined list of labels or categories of labels that geographic TLDs may Allocate or register to third parties prior to or during a Sunrise Period, and ICANN org accepts and implements such recommendation, there will be a presumption of approval for geographic TLDs that thereafter apply for that program. However, ICANN org will still review the application and may reject the application if ICANN org reasonably determines that such requested registration program could contribute to consumer confusion or the infringement of intellectual property rights. Neither the IPC nor any Registry Operator is required to have these discussions, but Registry Operators will always be allowed to individually apply to conduct an Approved Launch Program as discussed above.

Q37: What is a Limited Registration Period?

A37: A Limited Registration Period is any registration period typically between the end of the Sunrise Period and the start of General Registration. Thus, a Limited Registration Period must have some registration restriction that limits domain names from being generally available to all registrants that are qualified to register domain names within the TLD. Any registration during a Limited Registration Period must be subject to the Claims Services in the same manner as registrations registered or Allocated during the Claims Period.

Q38: Can a Limited Registration Period overlap with the Sunrise Period?

A38: Yes. The Sunrise Period and a Limited Registration Period may overlap, provided that Registry Operator MUST NOT Allocate or register any domain names in a Limited Registration Period until all Sunrise Registrations have been Allocated and registered.

Q39: Can a Limited Registration Period overlap with the Claims Period?

A39: No. The Claims Period is the first 90 days of General Registration. A Limited Registration Period, by definition, is a registration period in which the Registry Operator has imposed additional registration restrictions beyond the registration policies for the TLD's General Registration. Thus, a Limited Registration Period cannot occur at the same time as the Claims Period/General Registration.

Claims Period

Q40: What is the Claims Period?

A40: For a period of at least the first 90 days of General Registration, each TLD must provide Claims Services. Claims Services provide notice to potential domain name registrants that the name they are seeking to register matches a label in the Trademark Clearinghouse. If the registrant decides to register the domain name, the Trademark Clearinghouse will notify the applicable trademark holder of the domain name registration.

Q41: What must a registrar do when processing Claims Registrations?

A41: The specific technical obligations that registrars must satisfy when processing Claims Registrations are available at http://tools.ietf.org/html/draft-lozano-tmch-func-spec sections 5.3.4 and 5.3.5. In general, Registrars must verify domain name availability with the Registry Operator and obtain a CNIS (Claim Notice Information Service) lookup key if the label is covered by a trademark record. Registrars must also query the CNIS service to obtain Claims Notice Information, (see section 6.5 of http://tools.ietf.org/html/draft-lozano-tmch-func-spec), use the Claims Notice Information to populate the Trademark Notice (see Exhibit A of http://newgtlds.icann.org/en/about/trademark-clearinghouse/rpm-requirements-14may14-en.pdf ), clearly and conspicuously display the Trademark Notice to the potential domain name registrant and inquire as to whether the potential domain name registrant wishes to continue with the registration. The Trademark Notice must be provided by the registrar at the time of potential registration in real time, without cost to the prospective domain name registrant, and must be in the form specified in the Trademark Notice Form (an example of which is attached to Exhibit B of the TMCH Requirements). The Trademark Notice must require an affirmative confirmation by the potential domain name registrant to continue with the registration.

Q42: What language does the Trademark Notice provided to potential domain name registrants need to use?

A42: The Trademark Notice must be provided by the registrar to the potential domain name registrant in English. Additionally, to best serve its potential domain name registrants, registrars should provide the Trademark Notice to potential domain name registrants in the language of the registrant's registration agreement.

Q43: Under what conditions are registrars allowed to query the CNIS?

A43: Registrars can only query the CNIS for domain names that have been applied for by a potential domain name registrant. Registrars are prohibited from querying the CNIS for any other purpose.

Q44: Can Registry Operators query the CNIS?

A44: No. Only registrars may query the CNIS.

Q45: Can a Registry Operator offer a "landrush period" at the start of its General Registration?

A45: General Registration begins on the first day that domain names are generally made available to all registrants that are qualified to register domain names in the TLD. A "landrush period" that meets the above description would be considered General Registration. If, however, the "landrush period" has eligibility requirements that limit the availability of domain names to registrants satisfying certain conditions, then the "landrush period" would be considered a Limited Registration Period and not the beginning of General Registration. Because a Limited Registration Period cannot overlap with the Claims Period, it also cannot overlap with General Registration. Registry Operators are encouraged to be clear in defining each of their registration periods so as to aid the community's understanding and participation in each registration period and to avoid questions from ICANN org about each registration period's compliance with the TMCH Requirements.

Q46: Can a Registry Operator later release for Allocation or registration a domain name that it had reserved in accordance with the Registry Agreement?

A46: Yes. If a Registry Operator reserves a domain name from registration in accordance with the Registry Agreement and thereafter releases for Allocation or registration the reserved domain name at any time prior to the start date of the Claims Period, the domain name must be treated like any other domain name for any applicable Sunrise Period, Limited Registration Period, Launch Program or Claims Period. However, if the domain name is released for Allocation or registration at any time following the start date of the Claims Period, the domain name must be subject to the Claims Services for a period of 90 calendar days following the date it was released (even if the domain name is released following completion of the scheduled Claims Period).

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."