Skip to main content
Resources

快速通道 RSEP 流程和标准授权文件

注:所有语种版本中,英文版为官方版本,其他语种版本仅供参考.

快速通道 RSEP 流程

随着注册管理运行机构通过 RSEP 流程经常请求一些注册管理机构服务,标准化的授权文件(一般指的是《注册管理机构协议》(RA) 修订案)应运而生。另外,对于其中的一些服务,ICANN 组织还创建了适合快速通道 RSEP 流程的 RSEP 请求简略申请表。此网页列出了适用于快速通道 RSEP 流程的服务。

此网页将会不定期更新,以此来增加符合上述说明的相关服务。请注意,IDN 服务利用标准化的授权文件,更多信息请访问 IDN 服务请求页面。

快速通道 RSEP 流程

"快速通道 RSEP 流程"是 RSEP 流程的简化版,该流程要求注册管理运行机构按原样一字不改地使用指定的授权文件(通常作为 RA 的修订案)。与标准的 RSEP 请求相比,快速通道 RSEP 请求旨在缩短从提交到授权这个过程的持续时间。

如果注册管理运行机构希望修改快速通道 RSEP 请求的授权文件,则在提交请求时必须将其作为标准的 RSEP 请求。通过在域名服务门户案例中提交意见,注册管理运行机构可随时撤消其 RSEP 请求。

快速通道 RSEP 流程包含四 (4) 个阶段:

  1. 提交快速通道 RSEP 请求 – 在域名服务门户的标题"RSEP 快速通道 –[服务名称]"下方列出。请遵循以下步骤:(a) 确认拟定服务,(b) 确认标准化的授权文件,(c) 回复标准竞争问题,(d) 提供签字人信息(联系权威机构以执行 RA 修订案的联系人)。
  2. ICANN 组织完整性检查(预计持续时间:5 个日历日)– 如果注册管理运行机构充分回复了表单中所有的必填项目,则表明已完成请求。在此阶段期间,不发布 RSEP 请求。
  3. ICANN 审核(预计持续时间:12 个日历日)- 一旦请求进入"ICANN 审核"阶段,它就会发布在 RSEP 流程网页上。ICANN 组织将审核拟定服务,以确定该服务是否会引发重大安全性、稳定性或竞争方面的问题。当"ICANN 审核"阶段结束时,ICANN 组织将把针对拟定服务的初步裁定结果通知注册管理运行机构。
    1. 如果拟定服务另外还要求变更关键职能(如 RA 第 6 节规范 10 中所述)的提供商,ICANN 组织将提醒注册管理运行机构,必须在 RSEP 请求获得批准后,提交实质性转包安排 (MSA) 变更请求(例如,根据适用法律且使用代理进行注册验证)。
  4. 裁定和最终处理(启动此阶段的预计持续时间:5 个日历日)– 如果该请求在经过"ICANN 审核"阶段后获得批准,ICANN 组织将在 5 个日历日内启动授权流程(以执行 RA 修订案,或发送一封"自由部署"函件)。裁定和授权结果会发布在 RSEP 流程网页上。

快速通道 RSEP 流程适用于以下服务:

服务名称 说明 预先批准的 RA 修订案文件

完成域名资产组合的部分收购后进行批量转移 (BTAPPA)

允许注册管理运行机构根据 RA 修订案的相关规范,针对以下情形向注册服务机构赋予批量转移的能力:(a) 某注册服务机构收购了另一注册服务机构在顶级域 (TLD) 下拥有的域名资产组合中的部分域名(不是全部域名),或者 (b) 新认证的注册服务机构请求从(域名)转出注册服务机构转移所有域名,因为(域名)转入注册服务机构已作为这些域名的分销商。

完成域名资产组合的部分收购后进行批量转移 (BTAPPA)

根据适用法律且使用/不使用代理进行注册验证

允许注册管理运行机构执行注册验证,以遵守具体司法管辖区内适用法律的要求。注册管理运行机构可以在提供这项服务时,使用或不使用在预先批准的 RA 修订案文件方案中指明的补充注册代理服务。

注册管理机构锁定

通过采取以下方法,协助防范意外转移、修改或删除域名注册数据的行为:允许来自支持注册服务机构的授权代表请求激活或取消激活特定可扩展供应协议 (EPP) 的状态。

注册管理机构锁定

存档

此网页作为 RSEP 流程的一项运营改进措施,于 2019 年 6 月进行了更新(请参阅 ICANN 组织的博客文章)。可在此处获得此网页的存档版本。

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."