术语表
以下术语表提供了《申请人指导手册》中常用术语的含义和缩写词(如适用)。为便于参考,术语按字母顺序排列。本列表并非详尽列表。
表 G1:术语表
| 术语 | 缩写 | 含义 |
|---|---|---|
| 2012 Round(2026 轮次) | 2012 年启动的新 gTLD 项目申请轮次。 | |
| 2026 Round(2026 轮次) | 本《申请人指导手册》所述的新 gTLD 项目于 2026 年 4 月启动。 | |
| A-Label(A-标签) | “A-标签”是一个国际化域名 (IDN) 字符串的 ASCII 兼容编码 (ASCII-Compatible Encoding, ACE) 形式。“A-标签”以“xn--”前缀开头,后接符合国际化域名编码 (Punycode) 算法 [RFC3492] 输出的有效字符串,长度上限为 59 个 ASCII 字符。 | |
| Accountability Mechanisms(问责机制) | 《ICANN 章程》中建立的机制,用于审查和复议 ICANN 的行动(请参阅第 2.7 节:问责机制)。所含机制包括:赋权社群、重审、独立审核流程和监察官。 | |
| Administrative Check and Preparation for Reveal Day(行政核查和“揭晓日”筹备) | 一项手动流程,用于执行行政尽职调查(请参阅第 3.2 节:行政核查与“揭晓日”筹备),核实评估费是否已收讫,并为 ICANN 筹备“揭晓日”预留时间(请参阅第 3.4 节:揭晓日)。 | |
| Advice(建议) | 咨询委员会向 ICANN 董事会提出的意见。 | |
| Advisory Committee(咨询委员会) | AC | 根据《ICANN 章程》1正式确立的机构,负责就属于 ICANN 使命和职责范围内的各种政策向 ICANN 董事会提供建议。《ICANN 章程》确立了四个 AC:一般会员咨询委员会、政府咨询委员会、根服务器系统咨询委员会和安全与稳定咨询委员会。 |
| Affirmations(确认) | 《SubPro 最终报告》2中的“确认”表明该工作组认为,2012 年新 gTLD 项目中的某个要素不仅之前适用,而且现在仍然适用(或者至少是可以接受的),因此可继续用于后续流程。 | |
| Affirmations with Modifications(经修订的确认) | 如 SubPro 最终报告中所述,与“确认”类似,但不同的是,“经修订的确认”表明该工作组就 2012 年新 gTLD 项目的政策或实施提出相对细微的修改建议。 | |
| American Standard Code for Information Interchange(美国信息交换标准码) | ASCII | 一种字符编码标准,用于表示特定的 95 个(以英文为主)可打印字符和 33 个控制字符——共计 128 个码点。 |
| Appeals Process(申诉流程) | Appeal(申诉) | 允许相关方对异议专家组的异议裁决提出申诉的一种机制。请参阅第 4.5.9.1 节:提交申诉。 |
| Applicant(申请人) | 在申请提交期内提交申请以向 ICANN 申请新 gTLD 的实体。 | |
| Applicant Evaluation(申请人评估) | 申请人评估适用于两种情形:(a) 申请通过了字符串评估,且不属于字符争用集,或 (b) 申请通过了字符串评估,且在字符争用集中胜出。该程序与申请评估(请参阅模块 7:字符串与申请评估程序)并行开展,依据申请的优先级编号进行,除非其他流程阻碍申请推进。申请人评估包括两项强制性评估:背景筛查以及财务和运营评估。请参阅第 6.1 节:背景筛查、第 6.2 节:财务和运营评估。 | |
| Applicant Guidebook(《申请人指导手册》) | AGB | 现行有效的 gTLD《申请人指导手册》,其中规定了申请流程及评估流程的要求。 |
| Applicant Support Program(申请人支持计划) | ASP | 一项独立于 gTLD 申请流程的计划,为证实存在财务需求的合格申请人减免 ICANN 新 gTLD 项目的相关费用。请参阅附录 11:申请人支持计划。 |
| Application(申请) | 根据《申请人指导手册》的条款和条件提交的新 gTLD 申请。申请包括完整填写的申请问题、任何支持文件以及 ICANN 要求申请人提交的任何其他信息。请参阅附录 1:申请问题。 | |
| Application Change Request(申请变更请求) | ACR | 通过申请变更请求,申请人可以要求对其申请进行变更,包括但不限于增加或修改注册管理机构自愿承诺或社群注册政策,以回应在异议中提出的问题。请参阅第 3.8 节:申请变更请求。 |
| Application Evaluation(申请评估) | 申请评估包括以下评估:注册管理机构服务提供商审核、地理名称审核、保留名称审核、域名冲突高风险缓和计划评估、行为准则豁免评估、注册管理机构承诺评估(包括社群注册政策评估)、“.Brand”TLD 资格评估以及变体字符串评估。其中,只有“注册管理机构服务提供商审核”为强制项目。请参阅模块 7:字符串和申请评估程序。 | |
| Application Priority(申请优先级) | 每份申请将通过优先排序抽签获得优先编号(请参阅第 3.7 节:申请处理顺序和优先级抽签)。优先序号决定同一轮次中所有申请的处理顺序。 | |
| Application Questions(申请问题) | 申请人需要回答的一组问题。在 2012 轮次中,这些问题作为《申请人指导手册》模块 2 的附件发布。请参阅附录 1:申请问题。 | |
| Application Round(申请轮次) | 在 gTLD 的一个申请提交期内,对所收到申请进行处理的整个过程,全流程包含一系列依次进行的不同阶段。《申请人指导手册》的条款和条件适用于单轮申请周期(请参阅附录 10:条款和条件)。任何后续申请轮次均须遵循更新后的《指导手册》信息(请参阅第 2.8 节:后续申请轮次)。 | |
| Application submission period(申请提交期) | 可创建并提交申请的时间范围。请参阅第 3.1.1 节:申请提交期。 | |
| Application system(申请系统) | 通过此系统,申请人可安全提交申请新 gTLD 项目一个或多个组成部分所需的必要信息。该系统适用的申请人可包括:“申请人支持计划”申请人、“注册管理机构服务提供商预评估”申请人和 gTLD 申请人。请参阅 TLD 管理系统 (TLD Management System, TAMS)。 | |
| Applied-for gTLD string(所申请的 gTLD 字符串) | 作为 gTLD 申请主体的字符串。 | |
| Background Screening(背景筛查) | 背景筛查通过确保只有信誉良好的成熟企业、组织或机构才能运营新 gTLD,从而保护关键互联网资源分配中的公共利益。请参阅第 6.1 节:背景筛查。 | |
| Base Registry Agreement(基准《注册管理机构协议》) | 基准 RA | 成功申请 gTLD 的申请人在获得新 gTLD 的授权前,需与 ICANN 签订的《注册管理机构协议》的形式。该协议规定了管理 gTLD 的注册管理运行机构在法律、运营、技术及其他方面的义务,同时明确了 ICANN 的相应权利与责任。根据评估结果及各 gTLD 的具体情况,可在基准《注册管理机构协议》中增补一项或多项规范条款。 基准《注册管理机构协议》是通过广泛社群协商而获得的成果。ICANN 仅在特殊情况下才会考虑修改本协议,例如存在特殊的法律、管辖权或监管问题,从而导致实体因法律要求而无法签署基准《注册管理机构协议》。 |
| Blocked Names(禁用名称) | 根据现行政策,某些字符串(包括其可分配的变体字符串)在任何未来 gTLD 轮次中都没有申请或授权资格。禁用名称不适用例外流程,任何实体均不得申请。请参阅第 7.2.1 节:禁用名称。 | |
| Blocked Names Identification(禁用域名识别) | 当申请人填写申请字符串时,系统会自动检查申请人选择的字符串及其任何适用的变体字符串是否属于禁用名称。 | |
| .Brand TLD(“.Brand”顶级域) | 实体按照其与 ICANN 签署的《注册管理机构协议》中列出的商标名称而运营或获得的授权 TLD。请参阅第 7.7 节:“.Brand”资格评估和附录 4:基准《注册管理机构协议》。要获得“.Brand”TLD 资格,注册管理运行机构必须申请获得“.Brand”TLD 授权,且必须在商标信息交换中心登记相应的品牌商标。 | |
| .Brand TLD Eligibility Evaluation(“.Brand”顶级域资格评估) | “.Brand”TLD 资格评估用于核验申请人是否符合“.Brand”TLD 的认定标准。如果申请人成功完成全部评估阶段,一旦认定成功,申请人的基准《注册管理机构协议》将增补规范 13 相关条款。请参阅第 7.3 节:“.Brand”顶级域资格评估。 | |
| CCT Final Report(CCT 最终报告) | 竞争、消费者信任和消费者选择审核最终报告3(2018 年 9 月 8 日)。 | |
| Clarifying Question(澄清问题) | CQ | 评估专家组可以提出澄清问题,以便从申请人处获得更多信息。请参阅第 1.2.12 节:澄清问题。 |
| Closed generic(封闭型通用域名) | 根据 SubPro 政策制定流程工作组提交的最终报告,封闭型通用域名是“一个顶级域 (TLD),它所代表的字符串是一个通用域名或名称,该域下的域名均已经注册,只能供注册管理运行机构或其附属机构使用”。请参阅第 3.1.7 节:封闭型通用字符串/独占式通用字符串。 | |
| Code of Conduct Exemption Evaluation(行为准则豁免评估) | 如果申请人拟注册某 gTLD 中的所有域名,专供该注册管理运行机构自身或其附属机构使用,并愿意放弃对其自身及附属机构的保护,ICANN 可对行为准则(基准《注册管理机构协议》的规范 9)予以豁免,前提是该 gTLD 不是通用字符串,且该注册管理运行机构符合豁免标准。请参阅第 7.4 节:行为准则豁免评估。 | |
| Collision String List(冲突字符串列表) | 由 ICANN 维护、且已被 ICANN 确定为存在域名冲突风险较高的字符串列表(请参阅第 7.7 节:域名冲突)。 | |
| Community(社群) | ICANN 采用多利益相关方模型,其中,个人、非商业利益相关方团体、行业和政府统称为“ICANN 社群”,他们在以社群为基础、以共识为导向的决策方法中发挥着重要作用。 | |
| Community application(社群申请) | 一种 gTLD 字符串申请,其预期用途是以明确界定的社群利益而运营。请参阅第 5.4 节:社群优先评估。此类指定完全由申请人自行决定。如果申请人将其申请指定为社群申请,则必须准备好证明自己代表了申请中指明的社群。 | |
| Community Objection(社群异议) | 基于以下理由提出的异议:gTLD 字符串可能明确或暗示针对某个社群,且该社群相当一部分成员强烈反对该 gTLD 申请。请参阅第 4.5.10.4 节:原则:社群。 | |
| Community Priority Evaluation(社群优先评估) | CPE | 用于解决字符串争用的流程,可由一名社群申请人做出选择。请参阅第 5.4 节:社群优先评估。 |
| Community Registration Policies(社群注册政策) | 《注册管理机构协议》社群注册政策(简称“社群注册政策”)是社群申请人必须纳入适用的《注册管理机构协议》的政策。请参阅第 7.8.4 节:社群注册政策。这些政策至少应规定:谁可以在申请的 gTLD 中注册,以及在什么条件下注册管理机构可以接受二级域名。社群 gTLD 注册管理运行机构可在《注册管理机构协议》之外制定额外注册政策,只要这些政策不违反适用的 ICANN 协议和政策的要求。 | |
| Community Registration Policies Evaluation(社群注册政策评估) | 拟议的社群注册政策还需经过 ICANN 评估和批准,才能纳入基准《注册管理机构协议》规范 12 中。请参阅第 7.8.4 节:社群注册政策。 | |
| Community gTLD(社群 gTLD) | 社群 gTLD 是以明确界定的社群利益为目的而运营的 gTLD。 | |
| Consensus policy(共识性政策) | 通过 GNSO 政策制定流程而制定的政策,如《ICANN 章程》附件 A 所述4。共识性政策的当前列表可在签约方网站上查阅。5 | |
| Contention(争用) | 相同或相似的一个字符串出现多个申请的情况。请参阅第 5.2 节:字符串争用和争用解决程序。 | |
| Contention set(字符争用集) | 根据字符串相似性评估或字符串混淆异议程序,被判定在视觉、听觉或语义上与其他申请的 gTLD 字符串相同或相似的一组申请。 | |
| Controlled interruption(控制性中断) | 新授权的 gTLD 必须维持的一种状态,至少持续 90 天;在此期间,针对该顶级域的所有查询均返回特定响应,以提示用户发生了域名冲突。请参阅第 7.7 节:域名冲突。 | |
| Country Code Top-Level Domain(国家和地区顶级域) | ccTLD | 专门为国家、地区和地理区域留存的一类顶级域,这些域名源于 ISO 3166-1 国家和地区代码清单。请参阅根区数据库6。 |
| Delegation(授权) | 通过此流程,根区将被编辑以包含新的 TLD,并将该 TLD 下的域名注册管理权移交给注册管理运行机构。 | |
| Dispute Resolution Service Provider(争议解决服务提供商) | DRSP | ICANN 批准的一种实体,负责在对异议进行回应之前通过争议解决程序进行裁决。请参阅第 4.5.3 节:争议解决服务提供商。 |
| DNS Stability Review(DNS 稳定性审核) | DNS 稳定性审核使用自动化系统,旨在审核申请的所有主字符串和变体字符串。请参阅第 3.1.8.3 节:DNS 稳定性审核。该评估可确保所有字符串均符合强制性字符串要求,特别是 DNS 和主机名要求、IDNA 2008 对 IDN 的要求以及 RZ-LGR。如果字符串不符合这些要求,申请人会收到警告,并可以申请对自动评估结果进行审核。 | |
| Domain name(域名) | 在注册管理机构数据库中维护的、由两级或更多级组成的唯一字符串(如 john.smith.name)。 | |
| Domain Name System(域名系统) | DNS | 域名的全球层级系统。 |
| Domain Name System Security Extensions(域名系统安全扩展) | DNSSEC | DNSSEC 通过将数字签名链纳入 DNS 层级结构来保障互联网域名查询的安全性。 |
| Evaluation Challenge(评估质疑) | 一种允许申请人基于系统错误、事实错误或程序错误对特定评估结果提出质疑的机制。 | |
| Evaluation Panel(评估专家组) | 在被审核领域(例如字符串相似性评估专家组)具备专业知识的专家组。评估专家组使用社群制定的标准来评估申请人是否符合标准。 | |
| Existing TLD(现有 TLD) | 包含在根区数据库7列表中的字符串。 | |
| Extended Evaluation(扩展评估) | EE | 扩展评估为申请人提供额外的时间来通过在初始评估阶段开始的评估。此第二阶段评估适用于未通过初始评估但有资格进一步审核的申请。请参阅第 1.2.14.1 节:延长评估。 |
| Extensible Provisioning Protocol(可扩展供应协议) | EPP | 注册服务机构和注册管理机构之间用于域名供应的电子通信协议。 |
| Final contention set(最终字符争用集) | 最终字符争用集是字符串相似性评估的结果。请参阅第 7.10 节:字符串相似性评估。 | |
| Final Report on the New gTLD Program Subsequent Procedures Policy Development Process(新 gTLD 后续流程政策制定流程最终报告) | SubPro Final Report(SubPro 最终报告) | 新 gTLD 后续流程政策制定流程的最终报告8(2021 年 1 月 20 日)。 |
| Finalized contention set(最终确定的字符争用集) | 符合以下拍卖资格标准的字符争用集:
|
|
| Financial and Operational Evaluation(财务和运营评估) | 财务和运营评估将考察申请人是否具备长期运营注册管理机构的财务和运营能力,以及是否实施了合理保障措施来确保业务稳健运营和应对滥用问题。请参阅第 6.2 节:财务和运营评估。 | |
| Future Rounds(后续轮次) | 新 gTLD 项目按轮次评估申请。未来轮次(或“后续申请轮次”)是指 2026 轮次之后将开展的所有轮次。请参阅第 2.8 节:后续申请轮次。 | |
| GAC Consensus Advice on New gTLDs(GAC 对新 gTLD 的共识性建议) | GAC 就一项或多项 gTLD 申请向 ICANN 董事会提供的建议。请参阅第 4.3 节:GAC 共识性建议。 | |
| GAC Member Early Warning(GAC 成员早期预警) | GAC 就 gTLD 申请发出的通知,指出一个或多个政府认为该申请可能具有敏感性或存在问题。请参阅第 4.2 节:GAC 成员早期预警。 | |
| Generic Names Supporting Organization(通用名称支持组织) | GNSO | ICANN 负责制定通用 TLD 相关政策的机构9,同时负责就新 gTLD 的引入制定政策建议。 |
| Generic top-level domain(通用顶级域) | gTLD | 用于通用目的的顶级域,例如:.com、.net、.edu 和 .org。这一类型还包括与新 gTLD 项目相关的域名,例如:.futbol、.istanbul 和 .pizza,以及以其他字母和文字构成的域名。ICANN 负责协调制定用于管理 gTLD 域名注册的规则和政策。 |
| Geographic Name(地理名称) | 如果 gTLD 及其可分配变体标签符合以下任一标准,即视为地理名称:它是 ISO3166-1 标准所列国家/地区的首都/首府名称(任何语言);它是城市或地区的名称(申请人声明计划将该 gTLD 用于与该名称相关的目的);它与 ISO3166-2 标准所列次级行政区划名称(如县、省、州)完全匹配;它是 UNESCO 地区名称10 或出现在联合国地理区域 M49 部分11 的名称。各类别资格要求各不相同。请参阅第 7.5 节:地理名称。 | |
| Geographic Names Identification(地理名称识别) | 在地理名称识别的过程中,专家组将审核所有申请的字符串以识别可能被视为地理名称的字符串,此举根据第 7.5 节:地理名称来判定。请注意,此流程有别于“申请评估”过程中执行的一种更具实质性的验证流程,即地理名称审核(第 7.5.3.2 节)。 | |
| Geographic Names Panel(地理名称专家组) | GNP | 一个由 ICANN 负责管理的专家组,负责审核所申请的 TLD 字符串,以识别地理名称并确认其所需的证明文件。 |
| Geographic Names Review(地理名称审核) | 对于确定为地理名称的字符串,对其申请回复进行验证和实质性审核的过程。本次审核作为申请评估环节的一部分进行。请参阅第 7.5.3.2 节:地理名称审核。 | |
| Governmental Advisory Committee(政府咨询委员会) | GAC | GAC 是各国政府和国际政府间组织 (Intergovernmental Organizations, IGO) 在 ICANN 多利益相关方架构中的声音。GAC 根据《ICANN 章程》设立,是 ICANN 董事会的一个咨询委员会。GAC 的主要作用是针对公共政策问题,特别是在 ICANN 的活动或政策与国家法律或国际协定之间可能存在互动的情况下,向 ICANN 提供建议。 |
| gTLD Application Fee(gTLD 申请费) | 每个申请人为获得申请评估而应付的费用。每份已提交申请的这一费用由预付保证金和全款尾款的支付构成。 | |
| High-Risk Mitigation Plan(高风险缓和计划) | 第 7.7.5 节:域名冲突高风险缓和计划评估阐述了申请人将采取的具体预防及纠正措施,以缓和域名冲突风险,包括与受影响终端用户的沟通活动。每项缓和措施都必须有具体的实施时限,且总时限不得超过两年。 | |
| ICANN Auction(ICANN 拍卖) | ICANN 根据字符串争用程序进行的拍卖。 | |
| ICANN Board(ICANN 董事会) | 负责审核 ICANN 社群制定的政策建议,并将经过批准的政策提交给 ICANN 组织进行实施的实体。董事会12还对 ICANN 组织进行战略监督,确保该组织在其使命范畴内行事,实现道德、高效的运营。 | |
| ICANN Community(ICANN 社群) | “The Community”(“社群”) | ICANN 采用多利益相关方模型,其中,个人、非商业利益相关方团体、行业和政府统称为“ICANN 社群”,他们在以社群为基础、以共识为导向的决策方法中发挥着重要作用。 |
| ICANN organization(ICANN 组织) | org/ICANN org(组织/ICANN 组织) | 根据 ICANN 董事会的指示实施 ICANN 社群建议的实体13。 |
| ICANN-accredited registrar(ICANN 认证注册服务机构) | 已与 ICANN 签订《注册服务机构认证协议 (Registrar Accreditation Agreement)》14的实体。注册服务机构有权通过添加、删除或更新域名记录,对注册表进行更改。 | |
| Implementation Guidance(实施指南) | IG | SubPro 最终报告的成果之一。在此情况下,该工作组强烈建议执行所述行动方案,并且坚信所述行动方案一定会得到落实,但工作组同时也认识到,在特定情况下,可能会因为一些正当理由而导致建议的行动方案无法得到完全落实。不过,建议的行动方案所针对的相关方必须竭力实现该方案所欲达到的目标(如与“实施指南”相关的建议及其理据中所述,如果适用),即使是通过其他行动方案实现这一目标,也是可以接受的。但是,在选择其他行动方案之前,始终须先充分了解该方案可能带来的所有后果并认真进行权衡取舍。“实施指南”通常涉及如何实施建议。“实施指南”通常使用“应当”一词,以表示工作组期望相关方在了解上述注意事项的前提下实施建议的行动方案。 |
| Implementation Review Team(实施审核小组) | IRT | 实施审核小组是一个由 ICANN 社群成员自愿组成的团队,负责审核由 ICANN 组织起草的拟实施规划,并检查其与 ICANN 董事会批准的 GNSO 建议是否一致。该小组还会视需要回答相关问题并从 ICANN 组织处收集澄清说明。他们会就相关建议所涉及的技术和运营细节提供建议。 |
| Independent Objector(独立异议人) | IO | 由 ICANN 选任、仅代表最符合公共利益行事的一方。独立异议人(请参阅第 4.5.4 节:独立异议人)可基于有限公共利益(请参阅第 4.5.1.3 节:异议理由:有限公共利益)和社群(请参阅第 4.5.1.4 节:异议理由:社群)对申请提出异议。 |
| Intergovernmental Organization(国际政府间组织) | IGO | IGO 是主要由主权国家或其他政府间组织组成的机构。IGO 通过条约或其他协议作为组织章程而成立。例如联合国、世界银行和欧盟。 |
| Internationalized Domain Name(国际化域名) | IDN | 一种域名,其中有一个或多个字符串包含了除美国信息交换标准码 (ASCII) 字母、数字或连字符之外的其他字符。IDN 支持使用统一码 (Unicode) 字符,因此可能会包含各种当地语言和文字的字符。例如,[실례.테스트] 是一个完全由朝鲜文构成的域名。 |
| Internet Assigned Numbers Authority(互联网号码分配机构) | IANA | 负责一系列互联网协调职能的机构,以确保全球唯一标识符协议参数的分配,包括管理 DNS 根区和互联网协议地址空间。 IANA 的具体职能由 ICANN 附属机构“公共技术标识符”负责履行。 |
| Legal Rights Objection(合法权利异议) | 以所申请 gTLD 字符串侵犯了异议人现有合法权利为由提出的异议。请参阅第 4.5.1.2 节:异议理由:合法权利。 | |
| Limited Public Interest Objection(有限公共利益异议) | 以所申请 gTLD 字符串违背了人们普遍接受并受到国际法律原则认可的与道德和公共秩序相关的法律规范为由提出的异议。请参阅第 4.5.1.3 节:异议理由:有限公共利益。 | |
| Main Registry Service Provider(主注册管理机构服务提供商) | Main RSP(主 RSP) | 主注册管理机构服务提供商至少需提供可扩展供应协议和注册目录服务,并生成数据托管存储内容,将其发送给获得批准的 gTLD 数据托管代理。 |
| Mandatory Public Interest Commitments(强制性公共利益承诺) | Mandatory PICs(强制性 PIC) | 强制性公共利益承诺(请参阅第 7.8.1 节:强制性公共利益承诺)是 ICANN 为保护公共利益和消费者权利,而要求 gTLD 注册管理运行机构必须遵守的规则或指南。此类承诺通常为响应 GAC 提出的关切而实施。 |
| Name Collision Analysis Project(域名冲突分析项目) | NCAP | 2017 年,董事会指示 SSAC 启动 NCAP,旨在开展与“域名冲突”相关的研究,即在一个域名空间中定义和使用的域名也可能出现在另一个域名空间中的情况。在一个域名空间中使用一个域名的用户和申请可能实际在另一个域名空间中也使用该域名,但考虑到这个域名的预定使用情形在两个域名空间中并不相同,因而这种情况可能带来出乎人们意料的结果。导致域名冲突的情况可能是偶然的,也可能是恶意的。 |
| Name Collision High-Risk Mitigation Plan Evaluation(域名冲突高风险缓和计划评估) | 对于被 ICANN 认定存在域名冲突高风险且已解决争用问题的字符串,其申请人可提交一份高风险字符串缓和计划以供审核。该计划将由技术专家进行审核。请参阅第 7.7.5 节:域名冲突高风险缓和计划评估。 | |
| Name Collision Initial Assessment(域名冲突初步评估) | 域名冲突初步评估旨在识别域名冲突风险较高的字符串,如“域名冲突”中所述。请参阅第 7.7.2 节:域名冲突初步评估。如果某个字符串被认定为高风险,申请人可提交一份缓和计划以供评估;如获批准,相关申请即可继续进行。 | |
| Naming Services portal(域名服务门户) | NSp | 通过 ICANN 网站提供的一种在线服务,为签约方(如签约注册管理运行机构和认证服务机构)提供了一个中心位置,以便 ICANN 组织开展业务。该门户有助于简化运营流程,并且可以使用社群请求的功能进行定制,如案例跟踪、多用户公司访问和结构化工作流程。用户可以通过门户来提问、提交信息和申请批准。 |
| Naming System(名称系统) | 请参阅 RFC 9499 第 2 节:https://www.rfc-editor.org/rfc/rfc9499.html#name-names。 | |
| Objection(异议) | 根据争议解决服务提供商的程序向其提交的异议。 请参阅第 4.5 节:异议和申诉。 | |
| Objector(异议人) | 针对新 gTLD 申请向相应 DRSP 提出异议的个人或实体。 | |
| Organizational Account Record(组织账户记录) | 申请预提交阶段收集的组织信息。这些信息包括但不限于申请人信息、主要和次要联系人信息以及合法设立证明。 与组织账户记录相关的问题,请参阅附录 1:申请问题中的第 4 组问题:申请实体背景与组织信息。 |
|
| Outputs(成果) | 源自最终报告的确认、政策建议和实施指导。 | |
| Personally Identifiable Information(个人验证信息) | PII | 任何可据以推断信息主体个人身份的信息表述。 |
| Pre-Submission String Validations(提交前字符串验证) | 对主字符串和变体字符串(包括替代字符串)进行的验证,通过 TAMS 系统自动集成并实施。请参阅第 3.1.8 节:提交前字符串验证。 | |
| Preliminary contention(初步争用) | 在“揭晓日”(请参阅第 3.4 节:揭晓日)所有相同的字符串申请将被视为进入初步争用状态。 | |
| Program Implementation Review Report(项目实施审核报告) | PIRR | ICANN 组织于 2016 年编写的一份报告,其中汇总了 2012 轮次新 gTLD 项目运营实施过程获得的员工经验。15 |
| Public Interest Commitment Dispute Resolution Procedures(公共利益承诺争议解决流程) | PICDRP | PICDRP 是特定情况下采用评估小组形式的一种争议解决机制。若《注册管理机构协议》在管理 gTLD 时纳入了公共利益承诺争议解决流程 (PICDRP),则当注册管理运行机构未遵守其公共利益承诺 (PIC) 时,任何受害方均可采用这一流程。PIC 和 PICDRP 是 2012 年新 gTLD 项目启动时,由社群确立的保障措施之一。 |
| Public Interest Commitments(公共利益承诺) | PIC | 公共利益承诺是 gTLD 注册管理运行机构根据其与 ICANN 组织签订的合同对互联网社群做出的具有约束力的承诺,这些项目须接受 ICANN 组织的合规监督与执行。(另参阅 PICDRP 和 RVC。) |
| Registrar(注册服务机构) | Rr | 为个人和实体(注册人)注册域名的服务组织。在注册过程中,注册服务机构要验证申请的域名是否符合注册管理机构要求,并将域名提交给相应的注册管理运行机构。注册服务机构还要负责向注册人收集必要的信息并通过 RDDS 提供这些信息。 |
| Registration Restrictions Dispute Resolution Procedure(注册限制争议解决程序) | RRDRP | 一种正式程序,旨在为现有机构提供解决与 gTLD 的《注册管理机构协议》中的注册限制相关的争议。 |
| Registry(注册管理机构) | Ry | 权威主数据库,其中包含在每个顶级域内注册的所有域名。注册管理运行机构负责维护该主数据库并生成“区文件”,让计算机可以与世界各地的顶级域名进行互联网通信。 |
| Registry Agreement(《注册管理机构协议》) | RA | ICANN 与指定 gTLD 注册管理运行机构之间的合同,该合同规定了注册管理运行机构运营该 gTLD 的权利、义务及条款。请参阅附录 4:基准《注册管理机构协议》。 |
| Registry Commitments Evaluation(注册管理机构承诺评估) | RCE | ICANN 将对提交的每项 RVC 或拟纳入适用《注册管理机构协议》的社群注册政策进行评估,以确定其是否符合本 AGB 规定的全部标准。请参阅第 7.8.3.2 节:注册管理机构承诺评估。 |
| Registry Operator(注册管理运行机构) | RO | 负责维护在特定 TLD 中注册的所有域名的主数据库(注册表)的组织。注册管理运行机构 (RO) 负责接收注册服务机构提出的添加、删除或修改域名的申请,然后在注册表中执行请求的更改。RO 还负责运营 TLD 的权威域名服务器和生成区域文件。这些信息可以在互联网上让递归域名服务器将域名转换成互联网协议地址,从而实现互联网上的设备互联。 |
| Registry Service Provider(注册管理机构服务提供商) | RSP | 注册管理机构服务提供商是指为注册管理运行机构提供某些技术运营工作的实体。 |
| Registry Service Provider (RSP) Evaluation Program(注册管理机构服务提供商 (RSP) 评估项目) | 该项目允许注册管理机构服务提供商就其拟向申请人提供的服务接受一次性评估。成功通过评估的申请人将在 2026 轮次申请中获得预先批准。如果申请人在申请中采用预先批准的 RSP,则只要该 RSP 仍处于预先批准状态,申请人就无需接受技术评估。 | |
| Registry Services Evaluation Policy(注册管理机构服务评估政策) | RSEP | 该政策规定了注册管理运行机构或申请人对拟定的注册管理机构服务进行评估的流程。 |
| Registry Services Technical Evaluation Panel(注册管理机构服务技术评估小组) | RSTEP | 由精通互联网基础设施与 DNS 所用复杂系统及标准协议的设计、管理和实施的专家所组成的专家组。RSTEP 成员由其主席遴选。所有 RSTEP 成员及主席均签署一项协议,这项协议要求他们以中立立场,根据既定的安全性与稳定性定义来审议提交至专家组的问题。 |
| Registry Voluntary Commitments(注册管理机构自愿承诺) | RVC | RVC 通常是申请人可以选择做出的承诺,其目的是为了消除第三方对其申请的 gTLD 字符串的顾虑,或者是为了促进公共利益和社群信任或增强 gTLD 运营的安全保障。这些承诺经注册管理机构承诺评估 (RCE) 程序获得 ICANN 批准后,应作为合同义务纳入基准《注册管理机构协议》规范 11 中。 |
| Reserved Names(保留名称) | 通常因预留给特定实体而不可注册的字符串及其可分配变体字符串。保留名称包括与某些国际组织和国际政府间组织(有限国际 IGO-INGO)相关的名称。这些名称只能由相关实体通过例外流程进行申请,申请时需按适用程序的规定提交相应证明文件。 | |
| Reserved Names Identification(保留名称识别) | 当申请人填写申请字符串名称时,系统将自动检查申请人选择的字符串及其所有适用变体字符串是否出现在保留名称列表中。请参阅第 7.2.2.2 节:保留名称识别。 | |
| Reserved Names Review(保留名称审核) | 保留名称评估流程将确认相应组织申请的是否为保留字符串,并对支持文件进行验证,如保留名称中所述。请参阅第 7.2.2.3 节:保留名称审核。 | |
| Rights Protection Mechanism(权利保护机制) | RPM | 旨在保护域名系统中的知识产权的一种机制。RPM 包括统一域名争议解决政策、统一快速中止程序和商标授权后争议解决程序。 |
| Root zone(根区) | 根区数据库记录了顶级域(包括 gTLD 和 ccTLD)的授权详情。作为 DNS 根区的管理机构,IANA 负责根据其政策和程序来协调此类授权。 | |
| Safeguard Assessment(保障措施评估) | 保障措施评估将判断所申请的字符串是否需要与消费者保护、敏感字符串和受监管市场有关的特定保障措施。请参阅第 7.8.2 节:保障性公共利益承诺。 | |
| Safeguard PIC(保障性 PIC) | 制定和实施保障性 PIC 是为了回应《ICANN46 北京公报》中提出的 GAC 共识性建议以及 2012 轮次新 gTLD 项目期间发布的后续 ICANN 董事会决议。ICANN 将需要保障性 PIC 的 gTLDs(请参阅第 7.8.2.2 节:按字符串类别划分的适用保障性 PIC)分成了四大基于风险的组别:监管行业/开放式准入要求:唤起消费者信任但风险较高的字符串;高度监管行业/封闭式准入要求:与需要许可或认证的行业相关的字符串;潜在网络霸凌/骚扰:可能助长骚扰行为的字符串;政府固有职能:与政府域名相关的字符串。 | |
| Script(文字) | 用于在一种或多种书写系统中表示文本信息的字母及其他书面符号集合。例如,俄语使用西里尔文字母的一个子集书写;乌克兰语则使用另一个子集书写。日语的书写系统使用多种文字。 | |
| Singular/Plural Notification Evaluation(单数/复数通知评估) | ICANN 将审核单数/复数通知流程中提交的材料,确认特定字符串是否代表同一语言中同一单词的单数和复数形式。请参阅第 4.4 节:单数/复数通知。 | |
| String(字符串) | 构成申请 gTLD 或其变体字符串的一串字符。 | |
| String Confusion Objection(字符串混淆异议) | 以所申请的 gTLD 字符串与现有 TLD 或同一轮申请中的其他所申请 gTLD 字符串过于相似并容易引起混淆为由提出的异议。请参阅第 4.5.1.1 节:异议理由:字符串混淆。 | |
| String Contention(字符串争用) | “字符串争用”指的是这样一种情景:多位符合条件的申请人申请了同一 gTLD 或具有混淆性的高度相似的 gTLD,以至于在将其中一个字符串授权到根区后,可能会给用户造成混淆。请参阅第 5.2 节:字符串争用和争用解决程序。 | |
| String Evaluation(字符串评估) | 字符串评估(请参阅第 1.2.4 节:字符串评估)仅针对申请字符串及其可分配变体字符串进行评估。字符串评估包括五项将同时进行评估的要素:字符串相似性评估(请参阅第 7.10 节:字符串相似性评估)、域名冲突初步评估(请参阅第 7.7.2 节:域名冲突初步评估)、保障措施评估(请参阅第 7.8.2 节:保障性公共利益承诺)、 地理名称识别(请参阅第 7.5 节:地理名称)、单复数形式通知评估(请参阅第 4.4 节:单数/复数通知)。 | |
| String Similarity Evaluation(字符串相似性评估) | 字符串相似性评估(请参阅第 7.10 节:字符串相似性评估)将判定 gTLD 申请与其他 gTLD 申请、现有 TLD、已提交但仍在处理中的 gTLD 申请及 ccTLD 申请之间的视觉相似性,禁用名称(请参阅第 7.2 节:禁用和保留名称概述),以及任何双字符 ASCII 字符串(即潜在未来的 ccTLD)。 | |
| Subsequent Procedures(后续流程) | SubPro | 用于在 2012 轮次之后引入新 gTLD。与新 gTLD 后续流程政策制定流程和最终报告16有关(最终报告包括与 2026 轮次新 gTLD 项目相关的全部成果)。 |
| Temporary Delegation(临时授权) | 在初始评估(请参阅第 7.7.2 节:域名冲突初始评估)过程中未被认定为高风险的字符串(包括变体字符串),将进入临时授权队列(请参阅第 7.7.3 节:临时授权和最终评估)。一旦初始评估结束,即使字符串评估环节的其他评估仍在进行中,临时授权也会立即启动。临时授权的优先级将由申请所分配到的优先序号来确定。 | |
| TLD Application Management System(TLD 申请管理系统) | TAMS | 通过此系统,申请人可安全提交申请新 gTLD 项目一个或多个组成部分所需的必要信息。该系统适用的申请人可包括:“申请人支持计划”申请人、“注册管理机构服务提供商预评估”申请人和 gTLD 申请人。 |
| Top-Level Domain(顶级域) | TLD | “顶级域”(简称“TLD”)是 DNS 命名级别中最高层次的域名。在域名中,它们是最后一个圆点分隔符后的字符串,例如 www.example.net 中的“NET”。TLD 的管理者负责控制该 TLD 下哪些二级域名能被识别。根域或根区的管理者负责掌管哪些 TLD 能被 DNS 识别。 |
| Trademark Clearinghouse(商标信息交换中心) | TMCH | 一种旨在帮助保护商标持有人权利的机制。商标信息交换中心负责验证和记录来自世界各地的权利信息。在域名注册过程中,特别是当新 gTLD 启动时,需要使用这种经过验证的信息。 |
| Trademark Database(商标数据库) | TMDB | 商标数据库是商标信息交换中心的一部分。它为注册管理机构和注册服务机构提供专用接口,协助他们满足某些权利保护机制的要求。 |
| Uniform Domain Name Dispute Resolution Policy(统一域名争议解决政策) | UDRP | 该政策旨在解决因涉嫌域名滥用注册(例如域名抢注)而引发的争议,商标权持有人可通过向已获批准的争议解决服务提供商提出投诉来启动快速行政程序。 |
| Uniform Rapid Suspension(统一快速中止程序) | URS | 权利持有人可针对特定类型的域名争议启动的一种快速管理程序。URS 程序是快速解决非常明确的商标侵权行为的一种工具。 |
| United Nations official languages(联合国官方语言) | UN6 语言 | 联合国使用的六种语言:阿拉伯文、中文、英文、法文、西班牙文和俄文。 |
| Variant String Evaluation(变体字符串评估) | 如果申请人要为所申请的主字符串或现有 gTLD 申请一个或多个可分配变体字符串,则必须对每个所申请变体字符串进行必要性论证。该理由将由一个专家组根据相关 IDN EPDP 第 1 阶段政策建议中规定的标准进行评估(请参阅第 7.6 节:变体字符串评估)。已经成功通过评估的变体 gTLD 将纳入基准《注册管理机构协议》规范 14 中。请参阅附录 4:基准《注册管理机构协议》。 | |
| Variant String(变体字符串) | 被相关文字社群视为与另一字符串“相同”的字符串,因此根据特定的标签生成规则 (Label Generation Rules, LGR) 作为主字符串的变体字符串而生成。对于顶级域,另一字符串的变体字符串由根区标签生成规则 (RZ-LGR) 定义。 | |
| Variant-string-set(变体字符串集) | 主字符串、可分配变体字符串和禁用变体字符串称为“变体字符串集”。对于现有 gTLD,它被视为计算和提交其变体字符串集的主字符串。对于顶级域,变体字符串集是通过将根区标签生成规则 (RZ-LGR) 应用于主字符串来创建的。 | |
Visual Similarity -or-Visually Similar(视觉相似性 -或- 视觉相似) |
“视觉相似”指两个或更多个字符串存在视觉相似,若允许其同时存在,则可能导致用户混淆。请参阅第 5.2 节:字符争用和争用解决程序。 | |
| Working Group(工作组) | WG | 由支持组织或咨询委员会组建的临时小组,负责解决特定问题或执行特定任务。 |
| Zone File(区文件) | 权威域名服务器上的文件,用于定义域名系统相应区的内容。区文件中的资源记录 (RR) 可识别域名服务器相应区中的主机(例如,网络服务器、邮件服务器)和域名服务器的 IP 地址。区文件还可包含区所有人确定的其他类型的 RR(如包含数字签名的 RR)。利用区文件中的 RR,权威名称服务器能够对有关区内容的 DNS 查询做出明确响应。 |
请参阅《ICANN 章程》:https://www.icann.org/en/governance/bylaws。↩︎
敬请查看《SubPro 最终报告》:https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf。↩︎
请参阅《竞争、消费者信任与消费者选择审核最终报告》:https://www.icann.org/en/system/files/files/cct-rt-final-08sep18-en.pdf。↩︎
请参阅《ICANN 章程》附件 A:http://www.icann.org/en/general/bylaws.htm#AnnexA。↩︎
请参阅签约方网站:http://www.icann.org/en/general/consensus-policies.htm。↩︎
请参阅根区数据库:http://iana.org/domains/root/db/。↩︎
请参阅根区数据库列表:http://iana.org/domains/root/db。↩︎
请参阅新 gTLD 后续流程政策制定流程最终报告:https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-20jan21-en.pdf。↩︎
请参阅 GNSO 网页:https://gnso.icann.org/en。↩︎
请参阅联合国教科文组织世界遗产名录:https://whc.unesco.org/en/list/&order=region。↩︎
请参阅地理区域部分 M49:https://unstats.un.org/unsd/methodology/m49/。↩︎
请参阅董事会信息:https://www.icann.org/en/board/about。↩︎
请参阅 ICANN 官网:https://www.icann.org/。↩︎
请参阅认证注册服务机构列表:https://www.icann.org/en/accredited-registrars。↩︎
请参阅 2016 年 1 月 29 日项目实施审核:https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf。↩︎
请参阅新 gTLD 后续流程政策制定流程最终报告:https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf。↩︎
