数据托管要求注意本规范的中期草案正由ICANN与多家注册.PDFVIP

附件 2 数据托管要求 注意：本规范的中期草案正由 ICANN 与多家注册机构的技术团队制定。 注册运营商将根据与注册协议相关的数据托管服务的规定，指定某一独立实体作为数据托 管代理（以下简称“托管代理 ” ）。注册运营商与托管代理之间达成的任何数据托管协议， 均应包含以下第一部分中规定的技术规范 ，以及第二部分中规定的法律要求 ，并且必须将 ICANN 认定为第三方受益人。除以下要求外，数据托管协议还可以包含其他规定，但这些规定不 能破坏下面提供的必要条款，或与这些条款相抵触。 第一部分 — 技术规范 1. 寄存。 1.1 寄存必须采用两种类型之一：完全寄存和增量寄存。 1.1.1 “完全寄存”是指符合以下条件的注册数据：反映当前的整个注册数据 库，并将包括反映截止到每个星期日 0000 UTC 为止的注册状态的数据。在此时刻的未决交易（即尚未提交到注册数 据库中的交易）不会反映在完全寄存中。 1.1.2 “增量寄存”是指符合以下条件的数据：反映所有涉及数据库，但根据 具体情况未在上次完全寄存或增量寄存中反映，并自上次完全寄存后 累积起来的交易。每个增量文件将包含自上次完全寄存完成后的所有 数据库交易。 2. 寄存程序。每个具有特定格式的完全寄存和增量寄存均须进行适当处理，并以加 密形式通过电子手段发送给托管代理。这些特定格式的寄存文件在经过加密和签名 后，必须在指定的时限内通过匿名文件传输发送到托管代理的服务器。 3. 寄存时间表。注册运营商有义务根据以下要求每日提交一组托管文件： 3.1 每周必须提交一次注册机构中整组对象的完全寄存。这些文件均须使用 [full] 类型标注。 1 草案 — 仅供讨论使用 3.2 在每周的其他六天中，均须提交指示已创建或已更新对象的增量寄存。这些 文件均须使用 [inc] 类型标注。 3.3 每次增量提交必须至少 涵盖自生成上次提交以来的时间段。 3.4 可以与上次托管提交有部分重叠。 2 草案 — 仅供讨论使用 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]