Skip to main content
Resources

转让政策

  1. 注册服务机构域名转让

    1. 域名持有者授权的域名转让

      1. 注册服务机构要求

        只要接手注册服务机构的转让流程符合本政策的最低标准,且 ICANN 和注册管理机构政策不禁止此类转让,注册域名的持有者则必然可以在注册服务机构之间转让其域名注册。为了避免造成混乱,注册服务机构域名转让流程必须简洁明了。此外,注册服务机构应尽力向注册域名持有者通报该注册服务机构所采用的具体转让流程的发布文档,并提供相应的访问权限。

        1.1 转让权限

        只有在转出注册服务机构或适用的注册管理机构(如果有)的公众可访问的 WHOIS 服务中列出的管理联系人和注册域名持有者,才有权批准或否决接手注册服务机构提出的转让请求。如果存在争议,注册域名持有者的权限将取代管理联系人的权限。

        注册服务机构可利用来自登记在册注册服务机构或相关注册管理机构,或者通过由共识性政策确定的其他数据来源的 WHOIS 数据,来验证转让请求的真实性。

      2. 接手注册服务机构要求

        每当注册域名持有者请求将域名注册转让给其他注册服务机构时,接手注册服务机构应该:

        2.1 获得来自注册域名持有者或管理联系人(以下统称"转让联系人")的明确授权。因此,只有在接手注册服务机构收到来自转让联系人的转让确认后,转让过程才能继续进行。

        2.1.1 必须通过(域名转让)标准授权形式 (FOA) 进行授权。ICANN 网站提供了两种不同类型的 FOA。接手注册服务机构必须使用标记为"注册服务机构转让初步授权"的 FOA,请求获得来自转让联系人的注册服务机构转让授权。登记在册注册服务机构必须使用标记为"注册服务机构转让请求确认"的 FOA,请求获得来自转让联系人的转让确认。

        交流 FOA 时应采用英文,并且所有因转让请求而引发的争议均须使用英文进行裁决。注册服务机构可选择使用其他语言与转让联系人进行沟通。然而,选择使用这种沟通方式的注册服务机构有责任准确而完整地将 FOA 翻译为相应的非英文版本。

        2.1.2 如果接手注册服务机构凭借实体流程来获取授权,则需要得到转让联系人签署的 FOA 书面文档即可;另外,还可以加上登记在册注册服务机构相关域名 WHOIS 输出的复印件。

        2.1.2.1 如果接手注册服务机构依靠实体授权流程,那么这个接手的注册服务机构需负责以下事项:获得有关转让联系人身份的可靠证据,并且就这份获得的证据,维护相应的记录。除此之外,接手注册服务机构还应确保提出请求的实体确实真正获得了授权。可接受的实体身份形式包括:

        1. 公证书
        2. 有效的驾驶执照
        3. 护照
        4. 公司章程
        5. 军官证
        6. 国家/政府颁发的身份证件
        7. 出生证

        2.1.3.1 如果接手注册服务机构凭借电子流程来获取授权,则可接受的身份认证形式包括:

        1. 符合接手注册服务机构所在国家立法规定的电子签名(如有立法)。
        2. 来自个人或实体的同意书(电子邮件地址需要与转让联系人的电子邮件地址相同)。

        2.1.3.2 登记在册注册服务机构不能只是因为接手注册服务机构尚未收到上述确认,就否决转让申请。

        2.1.3.3 接手注册服务机构只有在收到确认后,才能执行转让流程。所有转让案例的前提是接手注册服务机构收到并验证了转让联系人提出的转让请求。

        2.2 通过传输注册服务机构工具包中指定的"转让"命令,提出更改注册管理运行机构数据库的请求,以此来显示新的注册服务机构。

        2.2.1 传输"转让"命令即代表接手注册服务机构已从授权 WHOIS 数据库列出的转让联系人处获得了所需授权。

        2.2.2 接手注册服务机构负责验证注册域名持有者在注册服务机构之间转让域名的请求。不过,登记在册注册服务机构仍然必须独立确认注册域名持有者向接手注册服务机构转让域名的意图是否遵循了本政策第 I.A.3 节("登记在册注册服务机构的义务")。

        2.2.3 在下面的情况中,标记为"注册服务机构转让初步授权"的 FOA 将会失效:

        2.2.3.1 接手注册服务机构发布 FOA 已有六十 (60) 天,除非接手注册服务机构允许自动续用 FOA,且注册域名持有者已明确选择自动续用;

        2.2.3.2 在完成注册服务机构域名转让之前域名过期;

        2.2.3.3 根据第 II.C 节完成注册人变更;

        2.2.3.4 注册服务机构域名转让已结束。

        2.2.4 在向注册管理机构提交"转让"请求之前,如果因 I.A.2.2.3.1 – I.A.2.2.3.4 中描述的某种情况而导致 FOA 过期,那么为了继续转让,接手注册服务机构必须通过新的 FOA 重新授权转让请求。

      3. 登记在册注册服务机构的义务

        3.1 当收到来自注册管理机构的未决转让通知时,登记在册注册服务机构应通过向注册域名持有者发出域名转让通知来确认其意图。确认意图时,登记在册注册服务机构必须遵守本政策中规定的各项标准。

        3.2 为了确保登记在册注册服务机构所采用的请求形式从本质上讲既便于管理、详实明了,又能够清楚地提供给转让联系人以验证其意图,登记在册注册服务机构必须使用 FOA。

        3.3 交流 FOA 时应采用英文,并且所有因转让请求而引发的争议均须使用英文进行裁决。注册服务机构可选择使用其他语言与转让联系人进行沟通。然而,选择使用这种沟通方式的注册服务机构有责任准确而完整地将 FOA 翻译为相应的非英文版本。而且,这种非英文的沟通方式必须符合本政策中规定的流程和步骤。其中包括但不限于,注册服务机构不得在 FOA 中添加任何用于转让请求时获得转让联系人同意的其他信息。

        如果注册域名持有者预先批准转让,登记在册注册服务机构则可以选择发送 FOA 的修改版本,以便通知注册域名持有者,预先批准的转让已经启动。

        这项要求不会妨碍登记在册注册服务机构通过不同的沟通渠道,对其现有客户进行市场营销。

        3.4 登记在册注册服务机构应在可行的情况下尽快将 FOA 发送给注册域名持有者,而且必须在收到注册管理运行机构转让请求后的二十四 (24) 小时内发送。

        3.5 如果登记在册注册服务机构未在五 (5) 个日历日内回应注册管理机构发出的转让请求通知,则默认视为"同意"这项转让。

        3.6 如果 WHOIS 中列出的转让联系人未向登记在册注册服务机构确认其转让请求,且登记在册注册服务机构未明确否决该转让请求,则默认视为登记在册注册服务机构允许进行转让。

        3.7 如果登记在册注册服务机构基于以下任何理由否决了转让请求,则必须向注册域名持有者和潜在接手注册服务机构提供否决的原因。登记在册注册服务机构只能在以下特定情况下否决转让请求:

        3.7.1 转让请求明显属于欺诈行为。

        3.7.2 对注册域名持有者或管理联系人身份提出合理争议。

        3.7.3 域名已过期,先前注册期未付费(包括信用卡拒付);或者域名未过期,先前或当前注册期未付费。在所有此类情况下,登记在册注册服务机构必须在否决转让之前将域名设为"注册服务机构持有"状态。

        3.7.4 授权转让联系人明确拒绝转让。授权转让联系人可采用特定的拒绝方式(通过书面或电子形式的请求)来否决某个转让请求,或者可以临时或无期限地一概拒绝注册服务机构收到的所有转让请求。对于所有情况,拒绝转让时都必须提供授权转让联系人的明确知情同意书,且该同意书应基于可选择参加的形式。当授权转让联系人提出请求时,注册服务机构必须在五 (5) 个日历日内解除锁定,或向授权转让联系人提供可行的使用方法来解除锁定。

        3.7.5 在域名创建(根据该域名在注册管理机构中显示的 WHOIS 记录)后的 60 天内请求转让。

        3.7.6 域名距离上次转让不满 60 天(或其他有待确定的更短天数)(经过注册服务机构双方的一致同意和/或按照争议解决流程的决议而转回原注册服务机构的情况除外)。"已转让"仅表示按照本政策的程序进行的注册服务机构域名转让。

        3.8 对于以下情况,登记在册注册服务机构必须否决转让请求:

        3.8.1 注册服务机构收到未决 UDRP 诉讼程序的通知。

        3.8.2 具有司法管辖权的法庭作出的法庭指令。

        3.8.3 根据转让争议解决政策,与上次转让相关的未决争议。

        3.8.4 根据本政策中规定的程序,注册服务机构在注册人变更后强制实行 60 天的注册服务机构域名转让锁定期。

        3.8.5 注册服务机构在注册人变更后强制实施了 60 天的注册服务机构域名转让锁定,并且注册域名持有人未在注册人变更请求前选择退出 60 天的注册服务机构域名转让锁定。

        3.9 不能否决变更注册服务机构请求的情况包括但不限于:

        3.9.1 没有支付未决或未来注册期的款项。

        3.9.2 未收到来自注册域名持有者或管理联系人的回应。

        3.9.3 域名处于"注册服务机构锁定状态",除非注册域名持有者在提出转让请求之前,已获得解除域名锁定的合理机会及易用方法。

        3.9.4 域名注册期的时间限制,除了根据第 II.C.2 节的规定,在初次注册后的头 60天、注册服务机构转让后的头 60 天,或者在变更注册人后的 60 天锁定期之外。

        3.9.5 在所涉及域名的注册域名持有者已为该域名注册支付费用的情况下,注册服务机构与业务合作伙伴/附属机构之间出现一般费用违约。

        3.10 登记在册注册服务机构拥有独立于转让流程之外的其他机制,可以向注册域名持有者收费。因此,如果出现付费争议,登记在册注册服务机构不得将转让流程作为确保向注册域名持有者收取服务费用的机制。这项要求的例外情况如下所示:

        3.10.1 在域名过期后提出转让请求,且未支付先前注册期费用;或者

        3.10.2 在域名过期前提出转让请求,且未支付当前注册期费用。

      4. 注册服务机构协作

        4.1 每个注册服务机构都有责任保存文档副本,其中包括 FOA 及转让联系人对 FOA 的回应文件,在依照争议解决政策提出和解决争议时,会用到这些文档。接手注册服务机构必须按照合约规定的标准文档保留政策,维护从转让联系人处收到的 FOA 副本。身份可靠证据的副本必须和 FOA 一起保存。

        4.2 相关注册服务机构域名交易期间和之后,接手注册服务机构和登记在册注册服务机构都必须提供有关域名转让的可靠证据。这些信息只能在属于转让交易方的其他注册服务机构提出请求时提供。此外,ICANN、注册管理运行机构、拥有管辖权的法院或管理机构,或第三方争议解决小组也可要求获得该信息,该信息需在收到请求后的五 (5) 天内提供。

        4.3 接手注册服务机构必须按照转出注册服务机构的请求保留和出具书面或电子版的 FOA 副本。登记在册注册服务机构请求获得 FOA 副本时,接手注册服务机构必须在五 (5) 个日历日内满足登记在册注册服务机构的这一请求(包括提供随附的支持文档)。如果无法在指定时间内提供该文档,那么当按照本政策的要求提出转让投诉时,注册管理运行机构或争议解决小组可据此废除该转让。

        4.4 如果登记在册注册服务机构或接手注册服务机构认为转让请求的处理违反了本政策的规定,那么注册服务机构可按照本政策第 I.C 节,启动争议解决程序。

        4.5 为了便于处理转让请求,注册服务机构应提供并维护一个专门用来与其他注册服务机构和注册管理机构联络的专用电子邮件地址:

        4.5.1 该电子邮件地址仅用于处理与转让请求以及本政策规定的程序相关的事务。

        4.5.2 应确保由能够对转让事务作出回应的人员负责该电子邮件地址的邮件接收工作。

        4.5.3 该邮件地址接收到邮件后,应该在合理的商业期限内,即,七 (7) 个日历日内对邮件内容作出回应。

        4.6 紧急转让行动联系

        4.6.1 注册服务机构将设立紧急转让行动联系("TEAC"),以便处理与转让有关的紧急通信。设立 TEAC 是为了让注册服务机构之间在遇到紧急情况时,(以双方都理解的语言)快速进行实时对话。从而可以采取进一步措施以达成决议,其中包括启动当前(或未来)转让争议或撤销程序。

        4.6.2 涉及 TEAC 的通信将予以保留,供 ICANN 认证的注册服务机构、gTLD 注册管理运行机构和 ICANN 员工使用。TEAC 的联系点可指定为一个电话号码或其他一些实时通信渠道,并且将记录在 ICANN 注册服务机构门户网站中,由该门户网站进行保护。在未经授权转出域名之后,必须在一个合理的时间期限内及时向 TEAC 发起通信。

        4.6.3 通过 TEAC 通信渠道发送的邮件必须由接手注册服务机构的代表人做出非自动回应。做出回应的人员或团队必须能够且获得授权调查和处理紧急转让事务。必须在收到初始请求后 4 小时内做出回应,即使需要更长时间才能找到事件的最终解决方案。

        4.6.4 对于未能回应 TEAC 通信的情况,转出注册服务机构必须向 ICANN 合规团队和注册管理运行机构报告。根据本政策的第 I.A.6.4 节规定,未能回应 TEAC 通信将会导致转让撤销,并可能导致 ICANN 采取进一步措施,最严重的情况包括不再续约或终止认证。

        4.6.5 转让双方将保持以书面或电子形式进行任何 TEAC 通信和回应,并根据请求,与 ICANN 和注册管理运行机构分享该文档副本。依照注册服务机构认证协议 (RAA) 第 3.4 节规定,应保留该文档。TEAC 通信渠道的用户必须向 ICANN 报告未予以回应的注册服务机构。另外,ICANN 将在其认为合适的情况下以适当的方式对注册服务机构 TEAC 通信渠道进行定期测试,以确保注册服务机构确实对 TEAC 消息做出回应。

      5. 对"ClientTransferProhibited"状态和"AuthInfo"代码的要求

        5.1 根据 ICANN 规范或政策以及任何适用的法律或法规,注册服务机构必须遵守以下要求。

        依照注册域名或注册域名持有者的后续请求,注册服务机构只能将域名设置为"ClientTransferProhibited"状态,然而,注册服务机构应当在其注册协议(获得注册域名持有者的明确同意)中包括有关禁止转让域名的条款和条件。此外,如果注册服务机构未向注册域名持有者提供用于解除"ClientTransferProhibited"状态的工具,注册服务机构则必须在收到注册域名持有者首次请求的五 (5) 个日历日内解除"ClientTransferProhibited"状态。

        5.2 如果注册服务机构未向注册域名持有者提供用于生成和管理其"AuthInfo"独有代码的工具并解除"ClientTransferProhibited"状态,注册服务机构必须在收到注册域名持有者首次请求的五 (5) 个日历日内向注册域名持有者提供"AuthInfo"独有代码并解除"ClientTransferProhibited"状态。

        5.3 注册域名持有者请求解除"ClientTransferProhibited"状态或获得适用的"AuthInfo 代码"时,注册服务机构为满足这一请求而采取的机制不得比用于更改注册域名持有者联系人或名称服务器信息的机制更为严格。

        5.4 登记在册注册服务机构不能只是因为注册域名持有者与注册服务机构之间存在付款争议,而拒绝解除"ClientTransferProhibited"状态或向注册域名持有者提供"AuthInfo 代码"。

        5.5 注册服务机构生成的"AuthInfo"代码必须针对唯一的域名。

        5.6 "AuthInfo"代码只能用于确认注册域名持有者的身份,但是按照本政策第 I.A.2 节和第 I.A.4 节的要求,仍需使用 FOA 进行转让请求的授权或确认。

      6. 注册管理机构要求

        6.1 在收到来自接手注册服务机构的"转让"命令后,注册管理运行机构会向注册服务机构双方发送电子通知。如果注册管理机构使用电子邮件进行通知,则可以将回应通知发送到每个注册服务机构的转让专用电子邮件地址。

        6.2 注册管理运行机构需要完成所请求的转让,除非在五 (5) 个日历日之内,注册管理运行机构收到来自登记在册注册服务机构的 NACK 协议命令。

        6.3 更新注册管理机构的数据库以反映接手注册服务机构的变更时,注册管理运行机构将向注册服务机构双方发送电子通知。可将通知发送到每个注册服务机构的转让专用电子邮件地址或者各方同意的其他电子邮件地址。

        6.4 完成转让后,如果注册管理运行机构收到以下某项通知,则会撤销转让。对于这种情况,将会撤销转让,同时"登记在册注册服务机构"字段将重置为原始状态。注册管理运行机构必须在收到通知的五 (5) 个日历日内撤销转让,除非存在注册管理机构争议决议,此时注册管理运行机构必须在 14 个日历日内撤销转让(法庭诉讼除外)。撤销转让的前提是需要收到以下通知之一:

        6.4.1 通过电子邮件、信件或传真发送的登记在册注册服务机构和接手注册服务机构的协议,声明转让有误或不符合本政策规定的程序;

        6.4.2 拥有转让管辖权的争议解决机构所作出的最终决定;或者

        6.4.3 拥有转让管辖权的法院发出的指令;

        6.4.4 登记在册注册服务机构先于转让之前提供文档,即,接手注册服务机构没有在第 I.A.4.6 节指定的时间期限内通过 TEAC 回复消息。

      7. 注册记录

        每个注册服务机构要求其客户(注册域名持有者)维护自己的记录,以便对首次域名注册日期进行存档和证明。

      8. 注册条款生效

        只要注册域名的总有效期没超过十 (10) 年,当注册管理运行机构按照本政策第 I.A 节完成持有者授权转让时,就可以将现有注册域名的使用期限延长一年。

    2. ICANN 批准的转让

      1. 如果某个注册服务机构由于下列原因而对其发起的所有注册域名进行发起权转让,(i) 该注册服务机构或其资产被其他注册服务机构收购,或 (ii) 未获得注册服务机构认证或未取得注册管理运行机构授权,则需要按照以下程序进行转让:

        1.1 接手注册服务机构必须获得 ICANN 注册管理机构 TLD 的认证,且必须与注册管理机构 TLD 的注册管理运行机构签署注册管理机构/注册服务机构协议。

        1.2 ICANN 必须向注册管理运行机构书面保证转让有利于社群利益,例如,可避免因注册服务机构已经或即将倒闭而威胁到稳定性方面的利益。

      2. 如果注册管理运行机构满意上述两个条件,那么对于涉及不超过 50,000 个注册域名的转让情况,注册管理运行机构将有必要免费一次性修改注册管理机构数据库。如果涉及超过 50,000 个注册域名的转让,注册管理运行机构则会对接手注册服务机构一次性收取固定费用 50,000 美元。

    3. 转让争议解决政策

      转让争议解决政策对如何处理注册服务机构域名转让争议的程序进行了规定。相关注册管理运行机构和 ICANN 认证的注册服务机构必须遵守该政策所规定的程序。

  2. 注册人之间的转让(注册人变更)

    1. 定义

      1. 本政策使用以下术语:

        1.1 "注册人变更"是指对以下任何内容进行实质性更改:

        1.1.1 前注册人姓名

        1.1.2 前注册人组织

        1.1.3 前注册人电子邮件地址

        1.1.4 管理联系人电子邮件地址(如果没有前注册人电子邮件地址)。

        1.2 "指定的代理"是指前注册人或新注册人明确授权代表自己批准注册人变更的个人或实体。

        1.3 "实质性变更"是指非印刷更正性质的变更。以下变更将被视为实质性变更:

        1.3.1 注册域名持有者的姓名或组织变更,这不仅仅只是印刷更正性质的变更;

        1.3.2 注册域名持有者的姓名或组织变更,同时附带地址或电话号码的变更;

        1.3.3 注册域名持有者的电子邮件地址变更。

        1.4 "前注册人"是指发起注册人变更时的注册域名持有者。

        1.5 "新注册人"是指接受前注册人注册域名转让的实体或个人。

    2. 注册人变更的适用情况

      1. 一般而言,必须允许注册人更新其注册域名/WHOIS 数据,以及向其他注册人自由转让其注册域名。

      2. 在下列情况中,注册服务机构必须否决注册人变更请求:

        2.1 根据"过期注册恢复政策"中第 2.2.5 节的规定,如果域名注册协议已过期,注册域名持有者则不再有权续用域名或将域名转让给其他注册服务机构;

        2.2 根据下文第 II.C 节,未经前注册人和新注册人适当授权的注册人变更;

        2.3 当域名存在争议时,不允许注册人变更,其中包括但不限于:

        2.3.1 注册服务机构收到未决 UDRP 诉讼程序的通知;

        2.3.2 注册服务机构收到未决 URS 诉讼程序的通知;

        2.3.3 未决 TDRP 诉讼程序;

        2.3.4 注册服务机构收到具有司法管辖权的法庭作出的法庭指令,禁止注册人变更。

      3. 在下列情况中,注册服务机构或注册管理运行机构可以更改注册域名持有者的详细信息,但不适用于下文第 II.C 节所述的注册人变更流程:

        3.1 注册协议到期;1

        3.2 注册协议已由注册服务机构终止;

        3.3 注册服务机构或注册管理运行机构按照法庭指令,更新前注册人的信息;

        3.4 注册服务机构在实施 UDRP 决策的过程中,更新前注册人的信息;

        3.5 注册服务机构按照"过期域名删除政策",更新前注册人的信息;

        3.6 注册服务机构为回应滥用投诉而更新前注册人的信息。

    3. 注册人变更流程

      1. 若要进行注册人变更,将前注册人改为新注册人,注册服务机构必须执行以下所有操作:

        1.1 依照第 II.B 节,确认域名符合"注册人变更"的规定;

        1.2 获得新注册人或新注册人指定代理的注册人变更请求确认。注册服务机构必须使用安全机制2 来确认新注册人和/或其相应的指定代理已明确同意注册人变更。为了获得确认,注册服务机构必须通知新注册人要与该注册服务机构达成注册协议(可提供转到注册协议的链接)。注册服务机构还必须提供有关如何批准或取消注册人变更的说明,并通知新注册人或其指定代理(如果有),一旦注册服务机构未在一定天数(不超过六十 (60) 天)内确认请求,则不处理该变更请求;

        1.3 通知前注册人或其指定代理,如果最终目标是将域名转让给其他注册服务机构,则建议前注册人先提出注册服务机构域名转让请求,然后再进行注册人变更,以避免引发第 II.C.2 节中所述的 60 天锁定期(除非注册服务机构允许前注册人选择不进入 60 天锁定期,且前注册人选择不进入 60 天锁定期);

        1.4 按照第 II.C.1.3 节的规定通知前注册人期间或之后,获得前注册人或前注册人指定代理的注册人变更请求确认。注册服务机构必须使用安全机制来确认前注册人和/或其相应的指定代理已明确同意注册人变更。为获得确认,注册服务机构必须通知前注册人或其指定代理(如果有),一旦注册服务机构未在一定天数(不超过六十 (60) 天)内确认请求,则不处理该变更请求。3

        1.5 在获得上述确认后一 (1) 天内处理注册人变更;

        1.6 在完成注册人变更的前一天或当天内,通知前注册人和新注册人。通知应满足以下要求:

        1.6.1 始终在执行注册人变更的前一天或当天内,将通知发送给新注册人和前注册人;

        1.6.2 表明已收到请求并列出相关域名;

        1.6.3. 包含联系人信息,以便解决问题。

        1.6.4. 建议前注册人和新注册人选择进入第 II.C.2 节所述的 60 天注册服务机构域名转让锁定期,或建议前注册人提前选择不进入第 II.C.2 节所述的 60 天注册服务机构域名转让锁定期。

      2. 注册服务机构必须在注册人变更后强制实施 60 天注册服务机构域名转让锁定期。然而,注册服务机构可以允许注册域名持有者选择在任何注册人变更请求之前不进入 60 天注册服务机构域名转让锁定期4

注释

背景介绍: IRTP C 部分中的政策制定流程 (PDP) 是针对现有转让政策中的改进领域而制定的五个系列 PDP 中的第三个 PDP。

在 2012 年 9 月 22 日召开的会议中,GNSO 理事会启动了一个 PDP,以此来解决下面的三个问题:

  1. "控制权变更"功能,包括调查现在的 IRTP 所达到的功能,检查在国家/地区代码名称空间中是否存在任何适用于 gTLD 空间的最佳模型以及任何与此相关的安全问题。其中还应包括对锁定程序的审查,如第 8 条和第 9 条拒绝理由所述,旨在平衡合法的转让活动及其安全性。
  2. 是否应实施(域名转让)标准授权形式 (FOA) 的时间限制规定,以避免出现欺诈式转让。例如,如果接手注册服务机构向转让联系人发送 FOA 并收到后者的 FOA,但其域名锁定,那么该注册服务机构可以暂停对该域名状态的 FOA 调整(注册人或其他注册信息可能会在此期间发生更改)。
  3. 是否可以通过要求注册管理机构使用 IANA 注册服务机构 ID 而非专有 ID 来简化该流程。

IRTP 工作组 C 于 2012 年 6 月 4 日发布初始报告 [PDF, 1.23 MB],并开放了一个公共评议论坛(更多详细信息,请参阅第 6 节);随后,在 2012 年 10 月 9 日发布了最终报告 [PDF, 624 KB]。ICANN 董事会于 2012 年 12 月 20 日采纳了 IRTP 工作组 C 提出的建议。实施审核小组与 ICANN 员工合作,制定了转让政策草案。该政策草案是在公共评议期讨论的主题。

在 2016 年 11 月 1 日之前,所有 ICANN 认证的注册服务机构都必须遵守该政策。

实质性变更:根据第 II.A.1.3 节的定义,"实质性变更"是指非印刷更正性质的变更。注册服务机构可灵活确定印刷更正性质变更的含义。印刷更正性质的变更示例包括:

  1. 将"注册人姓名"字段从 oJhn Smith 改为 John Smith。
  2. 将"注册人姓名"字段从 Jane Kgan 改为 Jane Kang。
  3. 将"注册人组织"从"某某司公"改为"某某公司"。
  4. 将"注册人组织"从"某某公司"改为"某某 公司"。

为避免产生疑问,注册服务机构有权将"注册人姓名"或"注册人组织"字段的任何变更都视为"实质性变更"。

安全机制:GNSO 提出的政策建议认为,注册服务机构在处理注册人变更的方式上需具备一定的灵活性。作为非限制性示例,注册服务机构可能需要基于无法从注册服务机构帐户或公开可用资源(如 WHOIS)中了解的信息来考虑"带外"身份验证。包括但不仅限于以下示例:

  1. 通过一种基于工具的身份验证方法(例如,提供必须以注册服务机构指定的方式返回的唯一代码),发送请求确认回复的电子邮件;或者
  2. 拨打注册域名持有者的电话号码或发送短信,提供必须以注册服务机构指定的方式返回的唯一代码;或者
  3. 拨打注册域名持有者的电话号码,并要求注册域名持有者提供曾经通过网络、电子邮件和信件邮寄方式发送给注册域名持有者的唯一代码。

注册人变更后注册服务机构域名转让锁定:注册服务机构不需要为第 II.C.2 节中所述的 60 天的注册服务机构域名转让锁定应用特定的 EPP 状态代码;然而,如果注册服务机构选择应用"clientTransferProhibited"EPP 状态代码,必须按照第 I.A.5.1 节中所述的禁止注册域名持有人删除锁定的方式锁定该域名。


1 根据注册协议条款,如果在域名到期后更改注册域名和 WHOIS 详细信息,那么过期注册恢复政策中的保护措施仍然适用。

2 有关安全机制的示例,请参阅本政策正文后的实施注释。

3 注册服务机构获得前注册人确认后,可使用其他联系人信息,但不限于公众可访问的 WHOIS。

4 注册服务机构可以对解除第 II.C.2 节所述的锁定加以限制,但不作为强制要求。例如,如果注册服务机构只能在五个工作日后解除锁定,则必须通过前注册人确认回复电子邮件等方式,来授权解除锁定。

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