Applications / .海尔 / QHZM2659T-T20311 · published by ICANN 7 October 2026 · snapshot 2026-10-08
.海尔
Brand TLD · Spec 13IDNActiveA-label xn--3et971b Q116
Qingdao Haishang Zhicai Management Consulting Co., Ltd., CN Q1·Q25
Ultimately controlled by Qingdao Haironghui Holdings Co., Ltd. Q108 · ICANN record ↗
§ 1 — Meaning of the string Q118·Q120
No English Translation
/xaɪ˧˥ ɚ˨˩˦/
§ 2 — Mission and purpose Q133
1. Mission and Objectives
As the applicant for the ".海尔" (xn--3et971b) and its variant ".海爾" (xn--90ww5h) registry, we aim to build a secure, trusted, and unified global digital identity infrastructure for Haier Group, promoting standardized development and global collaboration through centralized management. We will position these domains as the exclusive digital identifiers for the Group and its subsidiaries, restricting registrations accordingly. This enables unified global brand control, compliant usage, and a highly secure internal network, ultimately enhancing brand asset value and digital efficiency.
2. Intended Registrants
Intended registrants are limited to Haier Group and its various affiliates, including: Haier Group headquarters, Haier Smart Home, Thunderobot, Haier Biomedical, INKON Life, Shanghai RAAS, STEP, Autohome, and ZHONGMIAO HOLDINGS – eight listed companies and their subsidiaries – as well as the operating entities of global premium brands such as Haier, Casarte, Leader, GE Appliances, Fisher & Paykel, AQUA, and CANDY.
3. Intended Users
Intended users primarily include Haier Group employees, global consumers, enterprise customers, and ecosystem partners. Through these exclusive domains, they will access Haier Group's official services across six major industrial ecosystems – Smart Home Ecosystem, Comprehensive Healthcare Industry Ecosystem, Digital Economy Industry Ecosystem, Robotics Industry Ecosystem, New Energy Industry Ecosystem, and Automotive Industry Ecosystem – and obtain secure, tamper-proof official information and product experiences.
4. Relevant Activities
(1)Use ".海尔" (xn--3et971b) and its variant ".海爾" (xn--90ww5h) as the unified internal brand TLD for Haier Group, integrating the digital identity framework to centralize brand asset management.
(2)Leverage ".海尔" (xn--3et971b) and its variant ".海爾" (xn--90ww5h) to support digital collaboration across the ecosystem, enabling seamless user-device-service connectivity through various second-level domains.
(3)Integrate with the COSMOPlat industrial internet platform to build a digital foundation for global enterprise collaboration and secure data exchange.
(4)Provide intuitive, memorable domain access points to simplify multilingual and multi‑region access paths, improving user efficiency in accessing Haier's ecosystem services.
5.Long-Term Sustainability Statement
(1)Since 1984, Haier Group has built a global brand, ranking first in major home appliance retail sales globally for 17 consecutive years (Euromonitor). With 10 R&D centers, 71 research institutes, 35 industrial parks, 173 manufacturing centers and a sales network of 230,000 touchpoints worldwide, this solid global presence ensures ongoing demand and a strong foundation for the long‑term use of the ".海尔" and ".海爾".
(2)As the Group's internal dedicated registry, we have a professional team and sufficient funding, with comprehensive systems for registration, resolution, management, and security. Continuous investment ensures system evolution with business growth, forming a service loop and financial sustainability.
(3)Upholding "Forever Sincere", we reinforce brand value through CSR initiatives like "Project Hope". This heritage and social responsibility provide a spiritual core and reputational guarantee for the domain system's sustainability.
(4)We will comply with ICANN rules, implement security monitoring and emergency response, ensure compliance and technical security, mitigate risks, and uphold credibility—providing a secure, reliable digital platform for Haier's global digitalization.
§ 3 — Commitments and safeguards Q164–Q188
| More trustworthy, consumer risk, regulated sector, government reporting, harm, government function Q164–Q169 | Yes to: more trustworthy (Q164), consumer risk if abused (Q165) |
|---|---|
| Voluntary Safeguard PICs Q170·Q171 | |
| Registry Voluntary Commitments Q172·Q173 | None · 5 do |
| Brand TLD criteria confirmed, trademark certificate attached Q180·Q181 | Yes · certificate not published |
| Confirms the string is not a “generic string” Q183 | Yes |
| Spec 11 §3(d) statement Q184 | |
§ 4 — All other published answers
Every other answer ICANN published for this application, in the order of the form. Contact details (Q17–Q24) are left to the ICANN record.
Q212Q4.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC4.2-1.1 - The applying entity and/or a QPE will fund the startup and long-term operation of all applied-for gTLD strings and (if applicable) currently operated gTLDs of a QPE. SC4.2-1.2 - The applying entity or QPE has at a minimum of US$50,000 plus 25% of the application base fee for each applied-for gTLD string in Cash and Cash Equivalents on the balance sheet of the provided financial statements, up to a maximum of US$300,000, designated to support the startup and operation of all of the applying entity’s applied-for gTLD strings. SC4.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.
Q4.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. If financial statements are provided by a Qualified Parent Entity (QPE), the CEO, President, CFO, and/or equivalent officer of the QPE must co-sign the certification document. The self-certification document must represent and warrant: SC4.2-1.1 - The applying entity and/or a QPE will fund the startup and long-term operation of all applied-for gTLD strings and (if applicable) currently operated gTLDs of a QPE. SC4.2-1.2 - The applying entity or QPE has at a minimum of US$50,000 plus 25% of the application base fee for each applied-for gTLD string in Cash and Cash Equivalents on the balance sheet of the provided financial statements, up to a maximum of US$300,000, designated to support the startup and operation of all of the applying entity’s applied-for gTLD strings. SC4.2-1.3 - The applying entity and/or its officers are bound by law in its jurisdiction to represent financial statements accurately and the applying entity is in good standing in that jurisdiction.
Answered with a document. Attachments are not published by ICANN.
Q220Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.
Q5.1-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.1-1.1 - The applying entity will appropriately protect confidentiality of data and prevent unauthorized access to data and services. SC5.1-1.2 - The applying entity will maintain a mature, appropriately funded and staffed security program, following a recognized, modern security framework based on risk management (such as the ISO27000 series, COBIT, HITRUST CSF, legally required security frameworks, or equivalent). The security program must be in place prior to delegation, and exist through at least the period of the registry agreement. SC5.1-1.3 - The applying entity is aware of and has designed its systems and business to comply with the relevant privacy and security regulations for all countries in which it operates.
Answered with a document. Attachments are not published by ICANN.
Q221Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.
Q5.2-1 - Provide the applying entity’s self-certification document, signed by the CEO, President, CFO and/or equivalent officer of the applying entity. The self-certification document must represent and warrant: SC5.2-1.1 - The applying entity will, no later than delegation of the Top Level Domain (TLD), establish a dedicated abuse point of contact responsible for addressing matters requiring expedited attention and providing a timely response to abuse complaints concerning any name registered in the TLD. SC5.2-1.2 - The applying entity will, no later than delegation of the TLD, establish, publish, and provide to ICANN the location of a mechanism for members of the public to submit reports of abuse in accordance with the current obligations of the Base RA and any Consensus Policies. SC5.2-1.3 - The applying entity has developed proposed measures for removal of orphan glue records for names removed from the zone when provided with evidence in written form that the glue is present in connection with malicious conduct (see Specification 6). SC5.2-1.4 - The applying entity has or will have at time of delegation, established policies for handling complaints regarding abuse. Such policies are to be maintained and posted publicly so that anyone can review the policies via the Internet and any other means deemed appropriate by the applying entity. The applying entity’s policies at a minimum should contain appropriate confirmation of the receipt of the abuse report, the process of review of the report, and actions that will be taken if the applying entity confirms the report is legitimate. SC5.2-1.5 - The applying entity understands that DNS Abuse is Phishing, Malware, Botnets, Pharming and Spam (when used to deliver other forms of DNS Abuse). The applying entity understands and is prepared to contribute to the mitigation or disruption of DNS Abuse in domains in the TLD zone. SC5.2-1.6 - The applying entity’s abuse response capabilities are resourced appropriately to ensure a timely and adequate investigation and response to reports of DNS Abuse. This includes capabilities to receive and evaluate evidence of DNS Abuse in reports, and to take action to stop or disrupt the DNS Abuse. SC5.2-1.7 - The applying entity is prepared to conduct periodic scans of its zone to identify if domains are being used to perpetrate DNS Abuse, and to maintain statistical reports of the scans, the findings, and actions taken.
Answered with a document. Attachments are not published by ICANN.
Q119Script of String
Script of String
Chinese (Han)
Q121As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.
As per Section 3(d) of Specification 11 of the Base Registry Agreement, a registry operator of a “generic string” may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others. Confirm that the applied-for string is not a “generic string” in which the applying entity intends to limit registrations exclusively to a single person or entity.
true
Q117.1Applied-for Primary String (U-Label)
Applied-for Primary String (U-Label)
海尔
Q117.2Applied-for Primary String (Code Points)
Applied-for Primary String (Code Points)
U+6D77 U+5C14
Q124Script of Variant String
Script of Variant String
Chinese (Han)
Q125Is this variant string for an existing gTLD that is already operated by the applying entity or for a newly applied-for string in the 2026 Round?
Is this variant string for an existing gTLD that is already operated by the applying entity or for a newly applied-for string in the 2026 Round?
New TLD
Q126What is the meaning/definition of the variant string?
What is the meaning/definition of the variant string?
no English Translation/Meaning
Q127Explain how the primary applied-for and variant strings are considered the same, including the meaning, by the relevant user communities.
Explain how the primary applied-for and variant strings are considered the same, including the meaning, by the relevant user communities.
The primary applied‑for string "海尔" (xn--3et971b) in Simplified Chinese and its variant string "海爾" (xn--90ww5h) in Traditional Chinese are regarded as identical within the Chinese‑speaking user community. This equivalence is grounded in three core aspects:
1.Semantic and orthographic identity – The characters “尔” and “爾” are historically and lexically the same character, differing only in their written forms (simplified vs. traditional). In all Chinese dictionaries and everyday usage, they carry exactly the same meaning and pronunciation, and are mutually interchangeable without any change in semantics.
2.User community perception – For native Chinese speakers worldwide (including Mainland China, Taiwan, Hong Kong, Macau, and overseas Chinese communities), both forms are instantly recognised as representing the same entity. When users see “海尔” or “海爾” in branding, advertising, or digital environments, they universally understand it as the same well‑known household appliance brand. No confusion or ambiguity arises, as the two scripts are part of the same writing system and are used interchangeably in cross‑strait and cross‑regional contexts.
3.Regulatory and technical recognition – The Root Zone Label Generation Rules (RZ‑LGR) for the Chinese script explicitly group Simplified and Traditional character variants into the same variant set. Under ICANN’s variant management framework, these strings are treated as equivalent for domain registration and resolution purposes, ensuring that they point to the same logical namespace. This technical equivalence aligns perfectly with real‑world user expectations.
Furthermore, Haier Group itself consistently uses both “海尔” and “海爾” across its official materials, product packaging, and global marketing campaigns, reinforcing the brand identity across different Chinese‑script regions. In practice, users accessing either domain would anticipate reaching the same online presence, making it both linguistically and technologically justified to treat them as identical.
To further substantiate this claim, we have compiled a set of real‑world examples covering official websites, e‑commerce platforms, offline advertisements, trademarks, and social media usage, which are provided in the attached document for detailed reference.
Answered with a document. Attachments are not published by ICANN.
Q128Explain the benefits and the user communities who will benefit from the introduction of the applied-for variant string(s).
Explain the benefits and the user communities who will benefit from the introduction of the applied-for variant string(s).
This document outlines the necessity, technical approach, and value of applying for the Traditional Chinese variant ".海爾" (xn--90ww5h) for the internal brand TLD ".海尔" (xn--3et971b). As the TLD is internal and not open to public registration, offering both Simplified and Traditional forms ensures global digital asset consistency and accessibility.
1.Simplified and Traditional Chinese are distinct writing systems used in different regions. To represent Haier's brand identity, both "海尔" (xn--3et971b) and "海爾" (xn--90ww5h) are required. Relying on a single string falls short of the Group's operational and cultural needs for two reasons:
(1)With global branches and employees worldwide, a single‑script domain would hinder employees using Traditional Chinese systems in accessing internal resources, due to input habit mismatches, reducing efficiency. Beyond practicality, requiring employees to use a non‑customary script risks being perceived as culturally insensitive. Providing domains in local scripts fosters a sense of belonging and strengthens internal brand cohesion.
(2)As a core digital asset, if any major script variant is omitted, it could, through internal oversight or lack of local awareness, be registered or misused outside the Group's control—fragmenting the brand image and creating asset management vulnerabilities.
Therefore, applying for both "海尔" and "海爾" is essential to safeguard the integrity of Haier Group's global digital identity, support efficient international operations, and demonstrate responsible brand management.
2. User communities served by the primary TLD and all its variant TLDs
(1)The primary TLD ".海尔" (xn--3et971b) serves the community of the Group's institutions and employees whose primary written language is Simplified Chinese. This includes headquarters and branches in mainland China, Simplified Chinese‑using teams in Singapore, Malaysia, and other locations, as well as employees and partners worldwide who are accustomed to Simplified Chinese systems.
(2)The variant TLD ".海爾" (xn--90ww5h) serves the community of the Group's institutions and employees whose primary written language is Traditional Chinese. This mainly comprises branch offices and representative offices in the Taiwan, Hong Kong, and Macao regions of China, as well as Chinese employees and business partners in other global regions who are accustomed to Traditional Chinese systems.
3. How the similarities and differences in IDN table design reflect user community needs
To balance internal user habits with technical consistency, the IDN tables for both ".海尔" (xn--3et971b) and ".海爾" (xn--90ww5h) follow these principles:
(1)Both IDN tables are based on exactly the same character range, ensuring a consistent technical foundation, full compliance with international standards, and identical supported character sets.
(2)Both are system‑designated registrable suffixes with identical registration policies. The only difference lies in default priority: Simplified Chinese users are preferentially recommended "example.海尔", while Traditional Chinese users are preferentially recommended "example.海爾". This respects regional writing conventions without creating any disparity in eligibility or policy.
(3)When registering "example.海尔", the system can be configured to automatically register or preferentially reserve "example.海爾" for the same registrant; the same applies in reverse. This ensures that both variants are uniformly managed by the same entity, accommodating various business needs while preventing brand confusion and misuse.
Q129Describe the steps that the applying entity will take to minimize the operational and management complexities of variant gTLDs and variant domain names that impact registrars, resellers and/or registrants.
Describe the steps that the applying entity will take to minimize the operational and management complexities of variant gTLDs and variant domain names that impact registrars, resellers and/or registrants.
This application for the brand TLDs ".海尔" (xn--3et971b) and ".海爾" (xn--90ww5h) adopts a "Registry – brand Registrar – Internal Registrant" model. This model consolidates and simplifies registration channels and processes through a brand registrar, reducing operational and management complexity for the broader DNS ecosystem. The Applicant commits to implementing measures to ensure efficient and stable operation and to fulfill all obligations to ICANN.
1.Registration Channel Simplification.
Unlike traditional gTLDs that need to interface with hundreds of registrars worldwide, we will streamline registration service channels to a brand registrar:
(1)All policy dissemination, technical interfacing, financial settlement, and compliance collaboration will only be conducted with a single partner, avoiding the huge management overhead and potential inconsistency risks.
(2) We can carry out deep system-level integration with the brand registrar, developing customized registration management interfaces and automated processes.
(3) Ensure that all domain registrations through this channel follow unified service standards, pricing strategies, and customer support processes.
2.End-to-End Automation and Synchronization.
We will offer the brand registrar a comprehensive set of technical and management solutions:
(1)The Applicant will deliver to the brand registrar a management toolkit that encapsulates all variant synchronization logic. When the registrar system initiates registration, renewal, or DNS modification instructions for example.海尔, this toolkit will automatically complete the synchronous operations for example.海爾 and return an aggregated result to the registrar. The registrar does not need to develop additional logic for variants in its front-end system.
(2) All complex variant management policies will be automatically enforced by the registry backend system. The brand registrar and their end users do not need to make extra choices or judgments during operations; the system guarantees consistency and compliance of results, eliminating the possibility of complex problems caused by human operational errors.
(3) The brand registrar can obtain clear, aggregated domain asset reports through a dedicated management panel, simplifying reconciliation, management, and customer service work.
3.Internal Registration Policies and Processes.
Since users are limited to internal group entities, we can implement simplified strategies:
(1) The front-end system of the brand registrar will interface with the group's internal identity authentication or approval system. Only internal employees or departments can initiate applications. The application process can automatically trigger internal approval workflows; upon approval, the system automatically completes registration.
(2) Domain fees will adopt a unified annual internal settlement model.
(3) Since all registrants are affiliated entities, any disputes or change requests regarding domain usage will first be resolved through the group's internal administrative processes; only in extreme cases will external legal procedures need to be invoked.
4.Clear Responsibility Boundaries.
We will ensure that complexity is contained within controllable limits through contract and process design:
(1) For any operational issues arising from variant TLD design and the registry system itself, the applying entity will proactively assume responsibility and provide clear Service Level Agreement (SLA) guarantees to the brand registrar.
(2) The brand registrar does not need to understand, explain, or handle the complex rules behind variant synchronization, but only needs to ensure that its interface accurately triggers the automated tools we provide.
(3) This model ensures that public registrars, distributors, and public registrants will have no contact with this brand TLD, and therefore will not incur any additional technical, policy, or economic burden or complexity from it.
Q130This applied-for TLD is not a “generic string” using the definition of "generic string" in Section 3(d) of Specification 11 of the Base RA (as described in Question 121).
This applied-for TLD is not a “generic string” using the definition of "generic string" in Section 3(d) of Specification 11 of the Base RA (as described in Question 121).
true
Q122Applied-for Variant(s)
Applied-for Variant(s)
xn--90ww5h
Q123.1Variant String (U-Label)
Variant String (U-Label)
海爾
Q123.2Variant String (Code Points)
Variant String (Code Points)
U+6D77 U+723E
Q223By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.
By submitting this Application, the applying entity confirms that it is submitting this Application with a good faith (“bona fide”) intent to operate the gTLD for which it has applied, and that the applying entity has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.
true
Q224By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.
By submitting this Application, the applying entity confirms that it has read and understands the provisions of Section 5.2.3.1 Prohibited Communications and Activities of the Applicant Guidebook regarding the New gTLD Program rules prohibiting certain communications and activities to prevent parties from privately resolving string contention among themselves.
true