注意：本规范的中期草案正由 ICANN 与多家注册机构的技术团队制定。
规范 2
数据托管要求
注意：本规范的中期草案正由 ICANN 与多家注册机构的技术团队制定。
注册运营商将根据与注册协议相关的数据托管服务的规定，指定某一独立实体作为数据托管代理（以下简称 “托管代理”）。注册运营商与托管代理之间达成的任何数据托管协议，均应包含以下第一部分中规定的技术 规范，以及第二部分中规定的法律要求，并且必须将 ICANN 认定为第三方受益人。除以下要求外，数据托管协议还可以包含其他规定，但这些规定不能破坏下面提供的必要条款，或与这些条款相抵触。
第一部分 — 技术规范
1. 寄存。
1.1 寄存必须采用两种类型之一：完全寄存和增量寄存。
1.1.1 “完全寄存”是指符合以下条件的注册数据：反映当前的整个注册数据库，并将包括反映截止到每个星期日 0000 UTC 为止的注册状态的数据。在此时刻的未决交易
（即尚未提交到注册数据库中的交易）不会反映在完全寄存中。
1.1.2 “增量寄存”是指符合以下条件的数据：反映所有涉及数据库，但根据具体情况未在上次完全寄存或增量寄存中反映，并自上次完全寄存后累积起来的交易。每个增量文件将包含自上次完全寄存完成后的所有数据库交易。
2. 寄存程序。每个具有特定格式的完全寄存和增量寄存均须进行适当处理，并以加密形式通过电子手段发送给托管代理。这些特定格式的寄存文件在经过加密和签名后，必须在指定的时限内通过匿名文件传输发送到托管代理的服务器。
3. 寄存时间表。注册运营商有义务根据以下要求每日提交一组托管文件：
3.1 每周必须提交一次注册机构中整组对象的完全寄存。这些文件均须使用 [full] 类型标注。
3.2 在每周的其他六天中，均须提交指示已创建或已更新对象的增量寄存。这些文件均须使用
[inc] 类型标注。
3.3 每次增量提交必须至少 涵盖自生成上次提交以来的时间段。
3.4 可以与上次托管提交有部分重叠。
4. 托管格式规范。
4.1 文件命名规则。文件应该根据以下规则命名：
[gTLD]_[FILE]_[YYYY-MM-DD]_[type]_[#].[suffix]，其中：
4.1.1 [gTLD] 将替换为 gTLD 名称；
4.1.2 [FILE] 将替换为以下文件类型（如 [[|#详细文件格式]] 部分所述）；
4.1.3 [YYYY-MM-DD] 将替换为文件创建日期；
4.1.4 [type] 将替换为：
(1) full，如果数据代表完全寄存；
(2) inc，如果数据代表增量寄存；
(3) hash，如果数据代表寄存文件的哈希字符串；
(4) [#] 将替换为该文件在文件系列中的位置。
(5) [suffix] 表示与所使用的压缩和加密方法相对应的文件扩展名或后缀
(6) 用于涵盖可能的网络错误条件的其他命名规则（一旦传输成功完成即应重命名文件）：
i) [YYYY-MM-DD] 可能会增为 [YYYY-MM-DD-HH]，以指示传输的时间，用于区别一天内的多次尝试
ii) [type] 可能允许附加类型“resend”，指示尝试重新发送寄存。
4.2 对象句柄。对于每种对象类型（域、联系人、名称服务器、DNSSEC 授权签名者记录和注册商），ID 或“句柄”将用于允许以紧凑方式引用来自其他文件的对象。
4.2.1 这些句柄可以使用字母数字值表示，以提供最大的灵活性。
4.2.2 注册运营商可以使用域名作为域句柄。
4.3 日期。指示“日期”的多个字段，如域的创建日期或到期日期。这些字段应该包含以某种格式指示日期和时间的时间戳，以及在托管寄存中的所有此类字段之间保持一致的时区。 ICANN 可能要求遵循以下标准之一：
4.3.1 RFC 3339 — 互联网上的日期和时间；
4.3.2 统一多种关于日期和时间表示法的旧版 ISO 标准的 ISO 8601；以及
4.3.3 时间戳应该相对于 UTC 来表示，与 RFC 4930 EPP 中的日期/时间处理方式一致。
4.4 CSV 格式。如 RFC 4180 中所述，托管数据应编译为 CSV 文本文件。根据 RFC 4180，这些文件的字符编码应为 US-ASCII，但也可以是 UTF-8。
4.5 对象状态。RFC 4930 (EPP) 和相关的 RFC（4931、4932、4933）指示允许用于各种注册对象的状态代码。如这些 RFC 中所述，托管寄存应该使用 RFC 指定的以下代码，如：
状态 |
clientHold |
clientDeleteProhibited |
clientTransferProhibited |
clientUpdateProhibited |
clientRenewProhibited |
serverHold |
serverDeleteProhibited |
serverRenewProhibited |
serverTransferProhibited |
serverUpdateProhibited |
Ok |
pendingCreate |
pendingDelete |
pendingTransfer |
pendingRenew |
pendingUpdate |
Linked |
可能需要其他值，如“Reserved”（用于指示已保留的名称）。
4.6 详细文件格式。
4.6.1 域。指示文件类型“DOMAIN”
以下字段应存储在 DOMAIN 文件中：
i) 域句柄；
ii) 域名；
iii) 当前赞助注册商的注册商句柄；
iv) 创建日期；
v) 初始赞助注册商的注册商句柄；
vi) 到期日期；
vii) 域的 Authinfo；以及
viii) 联系人句柄。
4.6.2 国际化域名 (IDN)。对于国际化域名，应在域名字段（例如“xn-11b5bs1di.tld”）中引用 IDN 字符串的 ASCII 兼容形式 (A-Label)，而不是 Unicode 标签 (U- Label)。如果必须同时捕获 A-Label 和 U-Label，应通过创建扩展文件进行处 理。
以下字段应存储在 DOMIDN 文件中：
i) 域句柄；
ii) Unicode 标签/U-Label；
iii) 语言标记（基于 ISO 639-1）；以及
iv) 脚本标记（基于 ISO 15924）。
4.6.3 变量的处理。如果注册运营商提供 IDN，变量表和注册政策必须寄存在 IANA IDN 做法库 (xxxx://xxx.xxxx.xxx/xxxxxxx/xxx-xxxxxx/) 中。在某些情况 下，一个特定名称可能有多个“变量”，此时保留域名意味着要以相应的语言表示法保留一个或多个等效的其他名称。根据实施情况，托管有多种可能的含义：
(1) 可以在注册机构中表示多个名称变量，并存在于 DNS 区域中；每个此类名称都应存储在 DOMAIN 文件中，如上所述。
(2) 在某些情况下，可以使用上述“DOMIDN”文件的形式存储变量，其中变量名称以 Unicode 形式表示，并与“父/正则”域名相关联。
(3) 有时会使用某种算法生成变量名称，若变量的数目过于巨大，将无法进行存储直接提交进行托管。在这种情况下，带外文档必须提供有关变量生成算法的详细信息。还可能需要添加扩展文件，以指示（对于包含变量名称的域）用于计算变量的算法和任何其他参数。
4.6.4 保留名称的处理。注册机构通常会为自己或 IANA 保留一组名称。以下是可以选择的合理方法：
(1) 保留名称可以包含在 DOMAIN 文件中，并在 DOMSTATUS 文件中包含与该保留名称相关联的特殊状态“Reserved”，以指示该名称已保留；以及
(2) 可以创建附加文件 RESERVED，并使之包含以下字段：
i) 保留名称；以及
ii) 注册商句柄，用于为其保留名称的组织。
注意：
4.6.5 联系人。指示文件类型“CONTACT”。 以下字段应存储在 CONTACT 文件中：
i) 联系人句柄；
ii) 赞助注册商的注册商句柄；
iii) 创建日期；
iv) 联系人的 Authinfo；
v) 联系人姓名；
vi) 联系人的组织；
vii) 语音电话号码；
viii) 语音电话分机（如果有）；
ix) 传真电话号码；
x) 传真电话分机（如果有）；
xi) 邮政地址 1；
xii) 邮政地址 2；
xiii) 邮政地址 3；
xiv) 邮政地址 4；
xv) 城市；
xvi) 州/省/区域；
xvii) 邮政编码；
xviii) 国家/地区；以及
xix) 电子邮件地址。
标准文档可以使用以下字段中来指示验证要求。具体来说，EPP 联系人映射 (RFC 3733) 要求引用其他标准文档，如下所示：
国家/地区
国家/地区标识符使用 ISO 3166 中指定的两个字符标识符表示。电话号码
电话号码（语音和传真）的格式基于 ITU 标准 E164a 中定义的结构。电子邮件地址
电子邮件语法在 RFC 2822 中定义。
4.6.6 名称服务器。指示文件类型“NAMESERVER”。以下字段应存储在 NAMESERVER 文件中：
i) 名称服务器句柄；
ii) 名称服务器名；
iii) 创建日期；以及
iv) 赞助注册商的注册商句柄。
4.6.7 名称服务器 IP 地址。指示文件类型“NSIP”以下字段应存储在 NSIP 文件中：
i) 名称服务器句柄；以及
ii) IP 地址。
注意：对于 IPv4 地址，IP 地址必须符合 RFC 791；对于 IPv6 地址，IP 地址必须符合 RFC 4291。
4.6.8 注册商。指示文件类型“REGISTRAR”
以下字段应存储在 REGISTRAR 文件中：
i) 注册商句柄；
ii) 根据 IANA 注册商 ID 表示的注册商 IANA ID；以及
iii) 注册商名称；
4.6.9 域/状态关联。指示文件类型“DOMSTATUS”以下字段应存储在 DOMSTATUS 文件中：
i) 域句柄；
ii) 状态值（详见前面的“对象状态”一节）；以及
iii) 原因代码。
4.6.10 联系人/状态关联。指示文件类型“CONSTATUS”以下字段应存储在 CONSTATUS 文件中：
i) 联系人句柄；
ii) 状态值（详见前面的“对象状态”一节）；以及
iii) 原因代码。
4.6.11 名称服务器/状态关联。指示文件类型“NSSTATUS”以下字段应存储在 NSSTATUS 文件中：
i) 名称服务器句柄；
ii) 状态值（详见前面的“对象状态”一节）；以及
iii) 原因代码。
4.6.12 域/联系人关联。指示文件类型“DOMCONTACT”以下字段应存储在 DOMCONTACT 文件中：
i) 域句柄；
ii) 联系人句柄；以及
iii) 联系人类型。
类型 | 可能的缩写 |
注册人联系人 | R、REG |
管理联系人 | A、ADMIN |
付费联系人 | B、BILL |
技术联系人 | T、TECH |
4.6.13 域/名称服务器关联。指示文件类型“DOMNS”以下字段应存储在 DOMNS 文件中：
i) 域句柄；以及
ii) 名称服务器句柄。
4.6.14 删除域。指示文件类型“DOMDEL”。仅增量托管寄存（例如文件类型“inc”）需要此文件；此文件表示已删除的上次寄存中的域的列表。
(1) 域名；以及
(2) 删除日期。
4.6.15 删除联系人。指示文件类型“CONTDEL”。仅增量托管寄存（例如文件类型 “inc”）需要此文件；此文件表示已删除的上次寄存中的联系人的列表。
(1) 联系人句柄；以及
(2) 删除日期。
4.6.16 删除名称服务器。指示文件类型“NSDEL”。仅增量托管寄存（例如文件类型 “inc”）需要此文件；此文件表示已被删除的上次寄存中的名称服务器的列表。
(1) 名称服务器名；以及
(2) 删除日期。
4.6.17 DNSSEC 授权签名者记录。指示文件类型“DS”以下字段应存储在 DS 文件中：
i) DNSSEC 授权签名者记录；
ii) 创建日期；以及
iii) 赞助注册商的注册商句柄。
4.6.18 XXXXXX 授权签名者记录/状态关联。指示文件类型“DSSTATUS”以下字段应存储在 DSSTATUS 文件中：
i) DNSSEC 授权签名者记录；
ii) 状态值（详见前面的“对象状态”一节）；以及
iii) 原因代码。
4.6.19 域/DNSSEC 授权签名者记录关联。指示文件类型“DOMDS”以下字段应存储在 DOMDS 文件中：
i) 域句柄；以及
ii) DNSSEC 授权签名者记录。
4.6.20 删除 DNSSEC 授权签名者记录。指示文件类型“DSDEL”。仅增量托管寄存（例如文件类型“inc”）需要此文件；此文件表示已删除的上次寄存中的 DNSSEC 授权签名者记录的列表。
(1) DNSSEC 授权签名者记录；以及
(2) 删除日期。
4.6.21 扩展。如果某一特定注册运营商的合同要求提交上文未包含的附加数据，则可以定义附加的“扩展”文件以表示该数据，该数据可以使用域、联系人、名称服务器和注册商句柄，以便使该数据与这些对象关联起来。此外该数据还可以引入新的对象，再通过这些新对象自身的句柄，让扩展文件指示对这些新对象的引用。
4.7 压缩和加密。应通过数据加密保护注册机构托管数据的隐私性。
4.7.1 “最佳做法”还包括使用数据压缩，因为数据压缩可以缩短传输时间，增强加密的安全性。PGP 通常可在加密纯文本前对其进行压缩；OpenPGP 消息格式 (RFC 2440) 表示实施者应支持 ZIP (RFC 1951) 压缩，并且可以实施 ZLIB (RFC
1950)。实施也可以自由支持附加算法；有些实施支持 BZIP2。
4.7.2 注册运营商应在以下情况下使用压缩和加密：
(1) 文件应进行压缩。对于此操作是否应与加密过程一起执行，本规范不作要求。
(2) 压缩数据应使用托管代理的公钥进行加密，生成数字签名并使用注册机构的私钥进行签名。
(3) 加密文件和数字签名随后应该传输给托管代理。本规范不要求使用任何特定的传输机制；可接受的选择包括（但不限于）：通过 FTP、SFTP 等协议进行电子传输，或通过 CD-ROM、DVD-ROM 或 USB 存储设备等物理介质进行传输。
(4) 托管代理随后可以通过解密文件并验证数字签名，来验证加密数据是否已正确传输。
4.8 公钥的分发。每个注册运营商和托管代理均应按照指定的电子邮件地址将公钥分发给另一方（注册运营商或托管代理，根据具体情况而定）。各方应该通过回复电子邮件确认收到另一方的公钥，分发方随后将重新确认已传输密钥的真实性。通过这种方式，公钥传输经过身份验证，用户可以通过分发方运营的邮件服务器发送和接收邮件。托管代理、注册机构和 ICANN 之间均应按照上述程序交换密钥。
5. 寄存通知。注册运营商每提交一个寄存，都必须同时向托管代理和 ICANN 提交一份书面声明（可以通过经验证的电子邮件提交），其中要包含在创建寄存时生成的报告副本，并声明该寄存业经注册运营商检查，是完整而准确的。托管代理将在收到每个寄存后两个工作日内将寄存情况通知 ICANN。
6. 验证程序。
6.1 在收到每个寄存后两个工作日内，托管代理必须验证每个寄存的格式和完整性，并向
ICANN 提交一份为每个寄存生成的验证报告（可以通过经验证的电子邮件提交）。
6.2 如果托管代理发现有任何寄存不能通过验证程序，托管代理必须在发现后四十八小时内，以包括电子邮件、传真和电话在内的形式，向注册运营商和 ICANN 通报此类不合规定的情况。注册运营商在获悉此类验证失败的情况时，必须开始开发寄存的修改、更新、修正和其他修补程序，以使寄存能够通过验证程序，并将此类修补程序尽快提交给托管代理。
托管代理必须验证所有此类经修正的寄存的准确性或完整性，并在验证成功后二十四小时内通知 ICANN。
第二部分 — 法律要求
1. 托管代理的身份。注册运营商在签订托管协议前，必须联系 ICANN 并通报托管代理的身份，同时向 ICANN 提供联系信息和相关托管协议的副本。
2. 费用。注册运营商必须直接或让其代表代为向托管代理付费。如果注册运营商未能在截止日期前付清任何费用，托管代理将向 ICANN 发出有关未付费情况的书面通知，而 ICANN 可在收到托管代理的书面通知后十个工作日内支付过期未付费用。在 ICANN 支付过期未付费用后，ICANN 应向注册运营商索要该笔费用，而注册运营商必须将该笔费用连同按注册协议需交纳的下一笔费用提交给 ICANN。
3. 所有权。在托管协议期限内，寄存的所有权将始终归注册运营商所有。如果托管让渡寄存，则注册运营商在寄存中享有的此类权利（如果有的话）将自动在非排他、不可撤回、免版税和费用已付的基础上许可给 ICANN 或 ICANN 书面指定的一方。
4. 完整性和保密性。托管代理必须 (i) 将寄存保管于有保卫措施、经锁定和对环境安全的设施内，该设置只能由托管代理的授权代表访问；(ii) 使用一切在商业上合理的措施保护寄存的完整性和保密性。ICANN 和注册运营商将有权检查托管代理的相应记录，此类检查应有事先的合理通知，并且须在正常工作时间进行。
5. 副本。托管代理为了遵守托管协议的条款和规定，可以自费复制任何寄存。
6. 寄存的让渡。如果寄存代理收到注册运营商的有关请求，或收到 ICANN 声明下列情况之一的书面通知，则托管代理应在由注册运营商承担费用的情况下将其掌握的所有寄存交付给 ICANN 或 ICANN 指定的一方：
6.1 注册协议已到期且未续约，或者注册协议已终止；或
6.2 在有关 (a) 任何完全寄存或 (b) 任一日历月内的五个增量寄存的预定交付日期过后， ICANN 未在五个历日内收到托管代理的接收通知；并且 (x) ICANN 已向托管代理和注册运营商通知该情况；而 (y) ICANN 未在发出此类通知后七个历日内收到托管代理声明收到寄存的通知；或
6.3 ICANN 已收到托管代理关于某一完全寄存验证失败或任一日历月内的五个增量寄存验证失败的通知，并且 (a) ICANN 已将该情况通知注册运营商；而 (b) ICANN 未在发出此类通知后七个历日内收到托管代理有关寄存修正版本验证情况的通知；或
6.4 注册运营商已：(i) 停止执行其正常业务；或 (ii) 申请破产、无力偿债或按世界上任何地区的任何法律管辖范围的法律而处于与上述情况类似的状态；或
6.5 具备有效管辖权的法院、仲裁机构、立法机构或政府部门命令将寄存让渡给 ICANN。
6.6 托管代理在注册协议终止时必须将所有寄存交付给注册运营商，除非托管代理先前已将注册运营商的寄存让渡给 ICANN 或 ICANN 指定的一方。