Network Working Group S. Hollenbeck
Request for Comments: 4932 VeriSign, Inc.
Obsoletes: 3732 May 2007
Category: Standards Track
Network Working Group S. Hollenbeck
Request for Comments: 4932 VeriSign, Inc.
Obsoletes: 3732 May 2007
Category: Standards Track
Extensible Provisioning Protocol (EPP) Host Mapping
可扩展资源调配协议（EPP）主机映射
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names. This document obsoletes RFC 3732.
本文档描述了可扩展资源调配协议（EPP）映射，用于调配和管理存储在共享中央存储库中的Internet主机名。在XML中指定，映射定义应用于主机名的EPP命令语法和语义。本文件淘汰了RFC 3732。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship of Host Objects and Domain Objects . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Host Names . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Client Identifiers . . . . . . . . . . . . . . . . . . . . 4
2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 6
2.5. IP Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 7
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 7
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 9
3.1.3. EPP <transfer> Query Command . . . . . . . . . . . . . 11
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 11
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 12
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 13
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 15
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 15
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 15
3.3. Offline Review of Requested Actions . . . . . . . . . . . 17
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Internationalization Considerations . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Changes from RFC 3732 . . . . . . . . . . . . . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship of Host Objects and Domain Objects . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Host Names . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Client Identifiers . . . . . . . . . . . . . . . . . . . . 4
2.3. Status Values . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Dates and Times . . . . . . . . . . . . . . . . . . . . . 6
2.5. IP Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 7
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 7
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . . 9
3.1.3. EPP <transfer> Query Command . . . . . . . . . . . . . 11
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 11
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . . 12
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . . 13
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 15
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . . 15
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . . 15
3.3. Offline Review of Requested Actions . . . . . . . . . . . 17
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Internationalization Considerations . . . . . . . . . . . . . 24
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Changes from RFC 3732 . . . . . . . . . . . . . . . . 28
This document describes an Internet host name mapping for version 1.0 of the Extensible Provisioning Protocol (EPP). This mapping is specified using the Extensible Markup Language (XML) 1.0 as described in [W3C.REC-xml-20040204] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028]. This document obsoletes RFC 3732 [RFC3732].
本文档介绍可扩展资源调配协议（EPP）1.0版的Internet主机名映射。此映射是使用[W3C.REC-XML-20040204]中所述的可扩展标记语言（XML）1.0和[W3C.REC-xmlschema-1-20041028]和[W3C.REC-xmlschema-2-20041028]中所述的XML模式表示法指定的。本文件废除了RFC 3732[RFC3732]。
[RFC4930] provides a complete description of EPP command and response structures. A thorough understanding of the base protocol specification is necessary to understand the mapping described in this document.
[RFC4930]提供了EPP命令和响应结构的完整描述。要理解本文档中描述的映射，必须彻底理解基本协议规范。
XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation.
XML区分大小写。除非另有说明，否则本文档中提供的XML规范和示例必须按照提供的字符大小写进行解释，以开发一致的实现。
This document assumes that host name objects have a subordinate relationship to a superordinate domain name object. For example, host name "ns1.example.com" has a subordinate relationship to domain name "example.com". EPP actions (such as object transfers) that do not preserve this relationship MUST be explicitly disallowed.
本文档假定主机名对象与上级域名对象具有从属关系。例如，主机名“ns1.example.com”与域名“example.com”具有从属关系。必须明确禁止不保留此关系的EPP操作（例如对象传输）。
A host name object can be created in a repository for which no superordinate domain name object exists. For example, host name "ns1.example.com" can be created in the ".example" repository so that DNS domains in ".example" can be delegated to the host. Such hosts are described as "external" hosts in this specification since the name of the host does not belong to the name space of the repository in which the host is being used for delegation purposes.
可以在不存在上级域名对象的存储库中创建主机名对象。例如，可以在“.example”存储库中创建主机名“ns1.example.com”，以便将“.example”中的DNS域委派给主机。在本规范中，此类主机被描述为“外部”主机，因为主机的名称不属于用于委派目的的存储库的名称空间。
Whether a host is external or internal relates to the repository in which the host is being used for delegation purposes. Whether or not an internal host is subordinate relates to a domain within the repository. For example, host ns1.example1.com is a subordinate host of domain example1.com, but it is not a subordinate host of domain example2.com. ns1.example1.com can be used as a name server for example2.com. In this case, ns1.example1.com MUST be treated as an internal host, subject to the rules governing operations on subordinate hosts within the same repository.
主机是外部的还是内部的与用于委派目的的主机所在的存储库有关。内部主机是否从属关系到存储库中的域。例如，主机ns1.example1.com是域example1.com的从属主机，但它不是域example2.com的从属主机。ns1.example1.com可以用作example2.com的名称服务器。在这种情况下，必须将ns1.example1.com视为内部主机，并遵守管理同一存储库中从属主机上操作的规则。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol.
在示例中，“C:”表示协议客户端发送的行，“S:”表示协议服务器返回的行。示例中的缩进和空白仅用于说明元素关系，不是本协议的必需功能。
An EPP host object has attributes and associated values that can be viewed and modified by the sponsoring client or the server. This section describes each attribute type in detail. The formal syntax for the attribute values described here can be found in the "Formal Syntax" section of this document and in the appropriate normative references.
EPP主机对象具有发起客户端或服务器可以查看和修改的属性和关联值。本节详细描述了每种属性类型。此处描述的属性值的正式语法可在本文件的“正式语法”部分和相应的规范性参考文件中找到。
The syntax for host names described in this document MUST conform to [RFC0952] as updated by [RFC1123]. At the time of this writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change in the future as a result of progressing work in developing standards for internationalized host names.
本文档中描述的主机名语法必须符合[RFC1123]更新的[RFC0952]。在撰写本文时，RFC 3490[RFC3490]描述了使用某些ASCII名称标签来表示非ASCII名称标签的标准。随着国际化主机名标准开发工作的进展，这些一致性要求将来可能会发生变化。
All EPP clients are identified by a server-unique identifier. Client identifiers conform to the "clIDType" syntax described in [RFC4930].
所有EPP客户端都由服务器唯一标识符标识。客户机标识符符合[RFC4930]中描述的“clIDType”语法。
A host object MUST always have at least one associated status value. Status values MAY be set only by the client that sponsors a host object and by the server on which the object resides. A client can change the status of a host object using the EPP <update> command. Each status value MAY be accompanied by a string of human-readable text that describes the rationale for the status applied to the object.
主机对象必须始终至少有一个关联的状态值。状态值只能由发起主机对象的客户端和对象所在的服务器设置。客户端可以使用EPP<update>命令更改主机对象的状态。每个状态值可能伴随着一个人类可读文本字符串，该字符串描述了应用于对象的状态的基本原理。
A client MUST NOT alter status values set by the server. A server MAY alter or override status values set by a client subject to local server policies. The status of an object MAY change as a result of either a client-initiated transform command or an action performed by a server operator.
客户端不得更改服务器设置的状态值。服务器可以根据本地服务器策略更改或覆盖客户端设置的状态值。对象的状态可能会因客户端启动的转换命令或服务器操作员执行的操作而改变。
Status values that can be added or removed by a client are prefixed with "client". Corresponding status values that can be added or removed by a server are prefixed with "server". Status values that do not begin with either "client" or "server" are server-managed.
客户端可以添加或删除的状态值以“客户端”作为前缀。可由服务器添加或删除的相应状态值以“服务器”作为前缀。不以“客户端”或“服务器”开头的状态值由服务器管理。
Status Value Descriptions:
状态值说明：
- clientDeleteProhibited, serverDeleteProhibited
- 客户端删除禁止，服务器删除禁止
Requests to delete the object MUST be rejected.
必须拒绝删除对象的请求。
- clientUpdateProhibited, serverUpdateProhibited
- clientUpdateProhibited，serverUpdateProhibited
Requests to update the object (other than to remove this status) MUST be rejected.
必须拒绝更新对象（而不是删除此状态）的请求。
- linked
- 联系
The host object has at least one active association with another object, such as a domain object. Servers SHOULD provide services to determine existing object associations.
主机对象与另一个对象（如域对象）至少有一个活动关联。服务器应提供确定现有对象关联的服务。
- ok
- 好啊
This is the normal status value for an object that has no pending operations or prohibitions. This value is set and removed by the server as other status values are added or removed.
这是没有挂起操作或禁止的对象的正常状态值。当添加或删除其他状态值时，服务器将设置和删除此值。
- pendingCreate, pendingDelete, pendingTransfer, pendingUpdate
- pendingCreate、pendingDelete、pendingTransfer、pendingUpdate
A transform command has been processed for the object (or in the case of a <transfer> command, for the host object's superordinate domain object), but the action has not been completed by the server. Server operators can delay action completion for a variety of reasons, such as to allow for human review or third-party action. A transform command that is processed, but whose requested action is pending, is noted with response code 1001.
已为对象处理了变换命令（或者在<transfer>命令的情况下，为宿主对象的上级域对象处理了变换命令），但服务器尚未完成该操作。服务器操作员可以出于各种原因延迟操作完成，例如允许人工审核或第三方操作。已处理但其请求的操作处于挂起状态的转换命令用响应代码1001表示。
When the requested action has been completed, the pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status value MUST be removed. All clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed.
完成请求的操作后，必须删除pendingCreate、pendingDelete、pendingTransfer或pendingUpdate状态值。必须使用服务消息通知事务中涉及的所有客户端操作已完成，并且对象的状态已更改。
"ok" status MAY only be combined with "linked" status.
“确定”状态只能与“链接”状态组合。
"linked" status MAY be combined with any status.
“链接”状态可以与任何状态组合。
"pendingDelete" status MUST NOT be combined with either "clientDeleteProhibited" or "serverDeleteProhibited" status.
“pendingDelete”状态不能与“ClientDelete禁止”或“ServerDelete禁止”状态组合。
"pendingUpdate" status MUST NOT be combined with either "clientUpdateProhibited" or "serverUpdateProhibited" status.
“pendingUpdate”状态不能与“clientUpdateProhibited”或“serverUpdateProhibited”状态组合。
The pendingCreate, pendingDelete, pendingTransfer, and pendingUpdate status values MUST NOT be combined with each other.
pendingCreate、pendingDelete、pendingTransfer和pendingUpdate状态值不得相互组合。
Other status combinations not expressly prohibited MAY be used.
可以使用未明确禁止的其他状态组合。
Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters.
日期和时间属性值必须使用公历以世界协调时间（UTC）表示。必须使用[W3C.REC-xmlschema-2-20041028]中定义的大写“T”和“Z”字符的扩展日期时间表单来表示日期时间值，因为XML模式不支持截断日期时间表单或小写“T”和“Z”字符。
The syntax for IPv4 addresses described in this document MUST conform to [RFC0791]. The syntax for IPv6 addresses described in this document MUST conform to [RFC4291]. Practical considerations for publishing IPv6 address information in zone files are documented in [RFC1886], [RFC2874], and [RFC3152]. A server MAY reject IP addresses that have not been allocated for public use by IANA. When a host object is provisioned for use as a DNS name server, IP addresses SHOULD be required only as needed to generate DNS glue records.
本文档中描述的IPv4地址语法必须符合[RFC0791]。本文档中描述的IPv6地址语法必须符合[RFC4291]。[RFC1886]、[RFC2874]和[RFC3152]中记录了在区域文件中发布IPv6地址信息的实际注意事项。服务器可能会拒绝IANA尚未分配供公共使用的IP地址。当主机对象被设置为用作DNS名称服务器时，IP地址应该仅在生成DNS粘合记录时才需要。
A detailed description of the EPP syntax and semantics can be found in [RFC4930]. The command mappings described here are specifically for use in provisioning and managing Internet host names via EPP.
有关EPP语法和语义的详细说明，请参见[RFC4930]。这里描述的命令映射专门用于通过EPP配置和管理Internet主机名。
EPP provides two commands to retrieve host information: <check> to determine if a host object can be provisioned within a repository, and <info> to retrieve detailed information associated with a host object.
EPP提供了两个用于检索主机信息的命令：<check>用于确定是否可以在存储库中配置主机对象，以及<info>用于检索与主机对象关联的详细信息。
The EPP <check> command is used to determine if an object can be provisioned within a repository. It provides a hint that allows a client to anticipate the success or failure of provisioning an object using the <create> command as object provisioning requirements are ultimately a matter of server policy.
EPP<check>命令用于确定是否可以在存储库中配置对象。它提供了一个提示，允许客户端预测使用<create>命令设置对象的成功或失败，因为对象设置要求最终取决于服务器策略。
In addition to the standard EPP command elements, the <check> command MUST contain a <host:check> element that identifies the host namespace. The <host:check> element contains the following child elements:
除了标准的EPP命令元素外，<check>命令还必须包含标识主机名称空间的<host:check>元素。<host:check>元素包含以下子元素：
- One or more <host:name> elements that contain the fully qualified names of the host objects to be queried.
- 一个或多个<host:name>元素，其中包含要查询的主机对象的完全限定名。
Example <check> command:
示例<check>命令：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <check>
C: <host:check
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: <host:name>ns2.example.com</host:name>
C: <host:name>ns3.example.com</host:name>
C: </host:check>
C: </check>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <check>
C: <host:check
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: <host:name>ns2.example.com</host:name>
C: <host:name>ns3.example.com</host:name>
C: </host:check>
C: </check>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <check> command has been processed successfully, the EPP <resData> element MUST contain a child <host:chkData> element that identifies the host namespace. The <host:chkData> element contains one or more <host:cd> elements that contain the following child elements:
成功处理<check>命令后，EPP<resData>元素必须包含标识主机命名空间的子<host:chkData>元素。<host:chkData>元素包含一个或多个<host:cd>元素，这些元素包含以下子元素：
- A <host:name> element that contains the fully qualified name of the queried host object. This element MUST contain an "avail" attribute whose value indicates object availability (can it be provisioned or not) at the moment the <check> command was completed. A value of "1" or "true" means that the object can be provisioned. A value of "0" or "false" means that the object cannot be provisioned.
- 包含查询的主机对象的完全限定名的<host:name>元素。此元素必须包含一个“avail”属性，该属性的值表示在<check>命令完成时对象的可用性（是否可以设置）。值“1”或“true”表示可以设置对象。值“0”或“false”表示无法设置对象。
- An OPTIONAL <host:reason> element that MAY be provided when an object cannot be provisioned. If present, this element contains server-specific text to help explain why the object cannot be provisioned. This text MUST be represented in the response language previously negotiated with the client; an OPTIONAL "lang" attribute MAY be present to identify the language if the negotiated value is something other than the default value of "en" (English).
- 一个可选的<host:reason>元素，当无法设置对象时可以提供该元素。如果存在，此元素包含特定于服务器的文本，以帮助解释无法设置对象的原因。该文本必须以之前与客户协商的回复语言表示；如果协商值不是默认值“en”（英语），则可能存在可选的“lang”属性来标识语言。
Example <check> response:
示例<check>响应：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <host:chkData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:cd>
S: <host:name avail="1">ns1.example.com</host:name>
S: </host:cd>
S: <host:cd>
S: <host:name avail="0">ns2.example2.com</host:name>
S: <host:reason>In use</host:reason>
S: </host:cd>
S: <host:cd>
S: <host:name avail="1">ns3.example3.com</host:name>
S: </host:cd>
S: </host:chkData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <host:chkData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:cd>
S: <host:name avail="1">ns1.example.com</host:name>
S: </host:cd>
S: <host:cd>
S: <host:name avail="0">ns2.example2.com</host:name>
S: <host:reason>In use</host:reason>
S: </host:cd>
S: <host:cd>
S: <host:name avail="1">ns3.example3.com</host:name>
S: </host:cd>
S: </host:chkData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <check> command cannot be processed for any reason.
如果由于任何原因无法处理<check>命令，则必须返回EPP错误响应。
The EPP <info> command is used to retrieve information associated with a host object. In addition to the standard EPP command elements, the <info> command MUST contain a <host:info> element that identifies the host namespace. The <host:info> element contains the following child elements:
EPP<info>命令用于检索与主机对象关联的信息。除了标准的EPP命令元素外，<info>命令还必须包含标识主机名称空间的<host:info>元素。<host:info>元素包含以下子元素：
- A <host:name> element that contains the fully qualified name of the host object for which information is requested.
- 一个<host:name>元素，包含请求其信息的主机对象的完全限定名。
Example <info> command:
示例<info>命令：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <host:info
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: </host:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <host:info
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: </host:info>
C: </info>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <host:infData> element that identifies the host namespace. The <host:infData> element contains the following child elements:
成功处理<info>命令后，EPP<resData>元素必须包含标识主机命名空间的子<host:infData>元素。<host:infData>元素包含以下子元素：
- A <host:name> element that contains the fully qualified name of the host object.
- 包含宿主对象的完全限定名的<host:name>元素。
- A <host:roid> element that contains the Repository Object IDentifier assigned to the host object when the object was created.
- 一个<host:roid>元素，包含创建对象时分配给主机对象的存储库对象标识符。
- One or more <host:status> elements that describe the status of the host object.
- 描述宿主对象状态的一个或多个<host:status>元素。
- Zero or more <host:addr> elements that contain the IP addresses associated with the host object.
- 零个或多个<host:addr>元素，其中包含与主机对象关联的IP地址。
- A <host:clID> element that contains the identifier of the sponsoring client.
- 包含发起客户端标识符的<host:clID>元素。
- A <host:crID> element that contains the identifier of the client that created the host object.
- 一个<host:crID>元素，包含创建主机对象的客户端的标识符。
- A <host:crDate> element that contains the date and time of host object creation.
- 包含主机对象创建日期和时间的<host:crDate>元素。
- A <host:upID> element that contains the identifier of the client that last updated the host object. This element MUST NOT be present if the host object has never been modified.
- 包含上次更新主机对象的客户端标识符的<host:upID>元素。如果从未修改过宿主对象，则此元素不得存在。
- A <host:upDate> element that contains the date and time of the most recent host object modification. This element MUST NOT be present if the host object has never been modified.
- 包含最近一次主机对象修改的日期和时间的<host:upDate>元素。如果从未修改过宿主对象，则此元素不得存在。
- A <host:trDate> element that contains the date and time of the most recent successful host object transfer. This element MUST NOT be provided if the host object has never been transferred. Note that host objects MUST NOT be transferred directly; host objects MUST be transferred implicitly when the host object's superordinate domain object is transferred. Host objects that are subject to transfer when transferring a domain object are listed in the response to an EPP <info> command performed on the domain object.
- 一个<host:trDate>元素，包含最近一次成功的主机对象传输的日期和时间。如果从未传输过宿主对象，则不得提供此元素。请注意，不能直接传输主体对象；在传输宿主对象的上级域对象时，必须隐式传输宿主对象。传输域对象时要传输的主机对象列在对域对象执行的EPP<info>命令的响应中。
Example <info> response:
示例<info>响应：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <host:infData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name>ns1.example.com</host:name>
S: <host:roid>NS1_EXAMPLE1-REP</host:roid>
S: <host:status s="linked"/>
S: <host:status s="clientUpdateProhibited"/>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <host:infData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name>ns1.example.com</host:name>
S: <host:roid>NS1_EXAMPLE1-REP</host:roid>
S: <host:status s="linked"/>
S: <host:status s="clientUpdateProhibited"/>
S: <host:addr ip="v4">192.0.2.2</host:addr>
S: <host:addr ip="v4">192.0.2.29</host:addr>
S: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
S: <host:clID>ClientY</host:clID>
S: <host:crID>ClientX</host:crID>
S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S: <host:upID>ClientX</host:upID>
S: <host:upDate>1999-12-03T09:00:00.0Z</host:upDate>
S: <host:trDate>2000-04-08T09:00:00.0Z</host:trDate>
S: </host:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S: <host:addr ip="v4">192.0.2.2</host:addr>
S: <host:addr ip="v4">192.0.2.29</host:addr>
S: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
S: <host:clID>ClientY</host:clID>
S: <host:crID>ClientX</host:crID>
S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S: <host:upID>ClientX</host:upID>
S: <host:upDate>1999-12-03T09:00:00.0Z</host:upDate>
S: <host:trDate>2000-04-08T09:00:00.0Z</host:trDate>
S: </host:infData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an <info> command cannot be processed for any reason.
如果由于任何原因无法处理<info>命令，则必须返回EPP错误响应。
Transfer semantics do not directly apply to host objects, so there is no mapping defined for the EPP <transfer> query command.
传输语义不直接应用于主机对象，因此没有为EPP<Transfer>query命令定义映射。
EPP provides three commands to transform host objects: <create> to create an instance of a host object, <delete> to delete an instance of a host object, and <update> to change information associated with a host object. This document does not define host object mappings for the EPP <renew> and <transfer> commands.
EPP提供三个命令来转换主机对象：<create>创建主机对象的实例，<delete>删除主机对象的实例，以及<update>更改与主机对象关联的信息。本文档未定义EPP<renew>和<transfer>命令的主机对象映射。
Transform commands are typically processed and completed in real time. Server operators MAY receive and process transform commands, but defer completing the requested action if human or third-party review is required before the requested action can be completed. In such situations, the server MUST return a 1001 response code to the client to note that the command has been received and processed, but the requested action is pending. The server MUST also manage the status of the object that is the subject of the command to reflect the initiation and completion of the requested action. Once the action has been completed, all clients involved in the transaction MUST be notified using a service message that the action has been completed and that the status of the object has changed.
转换命令通常是实时处理和完成的。服务器操作员可以接收和处理转换命令，但如果在完成请求的操作之前需要人工或第三方审核，则推迟完成请求的操作。在这种情况下，服务器必须向客户端返回1001响应代码，以说明命令已被接收和处理，但请求的操作处于挂起状态。服务器还必须管理作为命令主题的对象的状态，以反映请求操作的启动和完成。操作完成后，必须使用服务消息通知事务中涉及的所有客户端操作已完成，并且对象的状态已更改。
The EPP <create> command provides a transform operation that allows a client to create a host object. In addition to the standard EPP command elements, the <create> command MUST contain a <host:create> element that identifies the host namespace. The <host:create> element contains the following child elements:
EPP<create>命令提供一个转换操作，允许客户端创建主机对象。除了标准的EPP命令元素外，<create>命令还必须包含标识主机名称空间的<host:create>元素。<host:create>元素包含以下子元素：
- A <host:name> element that contains the fully qualified name of the host object to be created.
- 一个<host:name>元素，包含要创建的宿主对象的完全限定名。
- Zero or more <host:addr> elements that contain the IP addresses to be associated with the host. Each element MAY contain an "ip" attribute to identify the IP address format. Attribute value "v4" is used to note IPv4 address format. Attribute value "v6" is used to note IPv6 address format. If the "ip" attribute is not specified, "v4" is the default attribute value.
- 零个或多个<host:addr>元素，其中包含要与主机关联的IP地址。每个元素可能包含一个“ip”属性，用于标识ip地址格式。属性值“v4”用于说明IPv4地址格式。属性值“v6”用于说明IPv6地址格式。如果未指定“ip”属性，“v4”是默认属性值。
Hosts can be provisioned for use as name servers in the Domain Name System (DNS), described in [RFC1034] and [RFC1035]. Hosts
可以将主机配置为用作域名系统（DNS）中的名称服务器，如[RFC1034]和[RFC1035]中所述。主人
provisioned as name servers might be subject to server operator policies that require or prohibit specification of IP addresses depending on the name of the host and the name space in which the server will be used as a name server. When provisioned for use as a name server, IP addresses are REQUIRED only as needed to produce DNS glue records. For example, if the server is authoritative for the "com" name space and the name of the server is "ns1.example.net", the server is not required to produce DNS glue records for the name server and IP addresses for the server are not required by the DNS.
配置为名称服务器可能受服务器运营商策略的约束，这些策略要求或禁止指定IP地址，具体取决于主机名称和服务器将用作名称服务器的名称空间。当设置为用作名称服务器时，仅当需要生成DNS粘合记录时才需要IP地址。例如，如果服务器是“com”名称空间的权威服务器，并且服务器的名称是“ns1.example.net”，则不需要服务器为名称服务器生成DNS粘合记录，DNS也不需要服务器的IP地址。
If the host name exists in a name space for which the server is authoritative, then the superordinate domain of the host MUST be known to the server before the host object can be created.
如果主机名存在于服务器授权的名称空间中，则服务器必须知道主机的上级域，然后才能创建主机对象。
Example <create> command:
示例<create>命令：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <create>
C: <host:create
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: <host:addr ip="v4">192.0.2.2</host:addr>
C: <host:addr ip="v4">192.0.2.29</host:addr>
C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
C: </host:create>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <create>
C: <host:create
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: <host:addr ip="v4">192.0.2.2</host:addr>
C: <host:addr ip="v4">192.0.2.29</host:addr>
C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
C: </host:create>
C: </create>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C: </create>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <create> command has been processed successfully, the EPP <resData> element MUST contain a child <host:creData> element that identifies the host namespace. The <host:creData> element contains the following child elements:
成功处理<create>命令后，EPP<resData>元素必须包含标识主机命名空间的子<host:creData>元素。<host:creData>元素包含以下子元素：
- A <host:name> element that contains the fully qualified name of the host object.
- 包含宿主对象的完全限定名的<host:name>元素。
- A <host:crDate> element that contains the date and time of host object creation.
- 包含主机对象创建日期和时间的<host:crDate>元素。
Example <create> response:
示例<create>响应：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <host:creData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name>ns1.example.com</host:name>
S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S: </host:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <host:creData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name>ns1.example.com</host:name>
S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S: </host:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <create> command cannot be processed for any reason.
如果由于任何原因无法处理<create>命令，则必须返回EPP错误响应。
The EPP <delete> command provides a transform operation that allows a client to delete a host object. In addition to the standard EPP command elements, the <delete> command MUST contain a <host:delete> element that identifies the host namespace. The <host:delete> element contains the following child elements:
EPP<delete>命令提供一个转换操作，允许客户端删除主机对象。除了标准的EPP命令元素外，<delete>命令还必须包含标识主机名称空间的<host:delete>元素。<host:delete>元素包含以下子元素：
- A <host:name> element that contains the fully qualified name of the host object to be deleted.
- 一个<host:name>元素，包含要删除的主机对象的完全限定名。
A host name object SHOULD NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object SHOULD NOT be deleted until the existing association has been broken. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted host object.
如果主机名对象与任何其他对象关联，则不应删除该主机名对象。例如，如果主机对象与域对象关联，则在现有关联被破坏之前，不应删除主机对象。在不首先中断现有关联的情况下删除主机对象可能会导致引用已删除主机对象的域对象的DNS解析失败。
Example <delete> command:
示例<delete>命令：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <delete>
C: <host:delete
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: </host:delete>
C: </delete>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <delete>
C: <host:delete
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: </host:delete>
C: </delete>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <delete> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.
成功处理<delete>命令后，服务器必须使用不带<resData>元素的EPP响应进行响应。
Example <delete> response:
示例<delete>响应：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if a <delete> command cannot be processed for any reason.
如果由于任何原因无法处理<delete>命令，则必须返回EPP错误响应。
Renewal semantics do not apply to host objects, so there is no mapping defined for the EPP <renew> command.
更新语义不适用于主机对象，因此没有为EPP<renew>命令定义映射。
Transfer semantics do not directly apply to host objects, so there is no mapping defined for the EPP <transfer> command. Host objects are subordinate to an existing superordinate domain object, and as such they are subject to transfer when a domain object is transferred.
传输语义不直接应用于主机对象，因此没有为EPP<Transfer>命令定义映射。宿主对象从属于现有的上级域对象，因此，当域对象被转移时，它们将被转移。
The EPP <update> command provides a transform operation that allows a client to modify the attributes of a host object. In addition to the standard EPP command elements, the <update> command MUST contain a <host:update> element that identifies the host namespace. The <host: update> element contains the following child elements:
EPP<update>命令提供转换操作，允许客户端修改主机对象的属性。除了标准的EPP命令元素外，<update>命令还必须包含标识主机名称空间的<host:update>元素。<host:update>元素包含以下子元素：
- A <host:name> element that contains the fully qualified name of the host object to be updated.
- 一个<host:name>元素，包含要更新的主机对象的完全限定名。
- An OPTIONAL <host:add> element that contains attribute values to be added to the object.
- 可选的<host:add>元素，包含要添加到对象的属性值。
- An OPTIONAL <host:rem> element that contains attribute values to be removed from the object.
- 可选的<host:rem>元素，包含要从对象中删除的属性值。
- An OPTIONAL <host:chg> element that contains object attribute values to be changed.
- 可选的<host:chg>元素，包含要更改的对象属性值。
At least one <host:add>, <host:rem>, or <host:chg> element MUST be provided if the command is not being extended. All of these elements MAY be omitted if an <update> extension is present. The <host:add> and <host:rem> elements contain the following child elements:
如果命令未扩展，则必须至少提供一个<host:add>、<host:rem>或<host:chg>元素。如果存在<update>扩展，则可以省略所有这些元素。<host:add>和<host:rem>元素包含以下子元素：
- One or more <host:addr> elements that contain IP addresses to be associated with or removed from the host object. IP address restrictions described in the <create> command mapping apply here as well.
- 一个或多个<host:addr>元素，其中包含要与主机对象关联或从主机对象中删除的IP地址。<create>命令映射中描述的IP地址限制也适用于此处。
- One or more <host:status> elements that contain status values to be associated with or removed from the object. When specifying a value to be removed, only the attribute value is significant; element text is not required to match a value for removal.
- 一个或多个<host:status>元素，其中包含要与对象关联或从对象中删除的状态值。指定要删除的值时，只有属性值有效；元素文本不需要与要删除的值匹配。
A <host:chg> element contains the following child elements:
<host:chg>元素包含以下子元素：
- A <host:name> element that contains a new fully qualified host name by which the host object will be known.
- 一个<host:name>元素，它包含一个新的完全限定的主机名，通过该主机名可以知道主机对象。
Host name changes MAY require the addition or removal of IP addresses to be accepted by the server. IP address association MAY be subject to server policies for provisioning hosts as name servers.
主机名更改可能需要添加或删除IP地址才能被服务器接受。IP地址关联可能受服务器策略的约束，以便将主机配置为名称服务器。
Host name changes can have an impact on associated objects that refer to the host object. A host name change SHOULD NOT require additional updates of associated objects to preserve existing associations, with one exception: changing an external host object that has associations with objects that are sponsored by a different client. Attempts to update such hosts directly MUST fail with EPP error code 2305. The change can be provisioned by creating a new external host with a new name and needed new attributes and subsequently updating the other objects sponsored by the client.
主机名更改可能会对引用主机对象的关联对象产生影响。主机名更改不应要求对关联对象进行额外更新以保留现有关联，但有一个例外：更改与其他客户端发起的对象具有关联的外部主机对象。直接更新此类主机的尝试必须失败，EPP错误代码为2305。可以通过使用新名称和所需的新属性创建一个新的外部主机，然后更新客户机发起的其他对象来提供更改。
Example <update> command:
示例<update>命令：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <host:update
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: <host:add>
C: <host:addr ip="v4">192.0.2.22</host:addr>
C: <host:status s="clientUpdateProhibited"/>
C: </host:add>
C: <host:rem>
C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
C: </host:rem>
C: <host:chg>
C: <host:name>ns2.example.com</host:name>
C: </host:chg>
C: </host:update>
C: </update>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <host:update
C: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
C: <host:name>ns1.example.com</host:name>
C: <host:add>
C: <host:addr ip="v4">192.0.2.22</host:addr>
C: <host:status s="clientUpdateProhibited"/>
C: </host:add>
C: <host:rem>
C: <host:addr ip="v6">1080:0:0:0:8:800:200C:417A</host:addr>
C: </host:rem>
C: <host:chg>
C: <host:name>ns2.example.com</host:name>
C: </host:chg>
C: </host:update>
C: </update>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an <update> command has been processed successfully, a server MUST respond with an EPP response with no <resData> element.
成功处理<update>命令后，服务器必须使用不带<resData>元素的EPP响应进行响应。
Example <update> response:
示例<update>响应：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an <update> command could not be processed for any reason.
An EPP error response MUST be returned if an <update> command could not be processed for any reason.translate error, please retry
Commands are processed by a server in the order they are received from a client. Though an immediate response confirming receipt and processing of the command is produced by the server, a server operator MAY perform an offline review of requested transform commands before completing the requested action. In such situations, the response from the server MUST clearly note that the transform command has been received and processed, but the requested action is pending. The status of the corresponding object MUST clearly reflect processing of the pending action. The server MUST notify the client when offline processing of the action has been completed.
服务器按照从客户端接收命令的顺序处理命令。虽然服务器会生成确认接收和处理命令的即时响应，但服务器操作员可以在完成请求的操作之前对请求的转换命令执行脱机检查。在这种情况下，来自服务器的响应必须清楚地注意到已接收并处理转换命令，但请求的操作处于挂起状态。相应对象的状态必须清楚地反映挂起操作的处理。当操作的脱机处理完成时，服务器必须通知客户端。
Examples describing a <create> command that requires offline review are included here. Note the result code and message returned in response to the <create> command.
此处包括描述需要脱机检查的<create>命令的示例。注意响应<create>命令返回的结果代码和消息。
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1001">
S: <msg>Command completed successfully; action pending</msg>
S: </result>
S: <resData>
S: <host:creData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name>ns1.example.com</host:name>
S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S: </host:creData>
S: </resData>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1001">
S: <msg>Command completed successfully; action pending</msg>
S: </result>
S: <resData>
S: <host:creData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name>ns1.example.com</host:name>
S: <host:crDate>1999-04-03T22:00:00.0Z</host:crDate>
S: </host:creData>
S: </resData>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
The status of the host object after returning this response MUST include "pendingCreate". The server operator reviews the request offline, and informs the client of the outcome of the review either by queuing a service message for retrieval via the <poll> command or by using an out-of-band mechanism to inform the client of the request.
返回此响应后主机对象的状态必须包括“pendingCreate”。服务器操作员脱机审查请求，并通过通过<poll>命令将服务消息排队以供检索，或通过使用带外机制将审查结果通知客户端。
The service message MUST contain text in the <response>, <msgQ>, <msg> element that describes the notification. In addition, the EPP <resData> element MUST contain a child <host:panData> element that identifies the host namespace. The <host:panData> element contains the following child elements:
服务消息必须包含描述通知的<response>，<msgQ>，<msg>元素中的文本。此外，EPP<resData>元素必须包含标识主机命名空间的子<host:panData>元素。<host:panData>元素包含以下子元素：
- A <host:name> element that contains the fully qualified name of the host object. The <host:name> element contains a REQUIRED "paResult" attribute. A positive boolean value indicates that the request has been approved and completed. A negative boolean value indicates that the request has been denied and the requested action has not been taken.
- 包含宿主对象的完全限定名的<host:name>元素。<host:name>元素包含必需的“paResult”属性。正布尔值表示请求已被批准并完成。负布尔值表示请求已被拒绝，且未采取请求的操作。
- A <host:paTRID> element that contains the client transaction identifier and server transaction identifier returned with the original response to process the command. The client transaction identifier is OPTIONAL and will only be returned if the client provided an identifier with the original <create> command.
- 一个<host:patid>元素，包含处理命令的原始响应返回的客户端事务标识符和服务器事务标识符。客户端事务标识符是可选的，仅当客户端使用原始的<create>命令提供了标识符时才会返回。
- A <host:paDate> element that contains the date and time describing when review of the requested action was completed.
- 包含日期和时间的<host:paDate>元素，描述请求操作的审核何时完成。
Example "review completed" service message:
“审阅完成”服务消息示例：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg>
S: </result>
S: <msgQ count="5" id="12345">
S: <qDate>1999-04-04T22:01:00.0Z</qDate>
S: <msg>Pending action completed successfully.</msg>
S: </msgQ>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1301">
S: <msg>Command completed successfully; ack to dequeue</msg>
S: </result>
S: <msgQ count="5" id="12345">
S: <qDate>1999-04-04T22:01:00.0Z</qDate>
S: <msg>Pending action completed successfully.</msg>
S: </msgQ>
S: <resData>
S: <host:panData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name paResult="1">ns1.example.com</host:name>
S: <host:paTRID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </host:paTRID>
S: <host:paDate>1999-04-04T22:00:00.0Z</host:paDate>
S: </host:panData>
S: </resData>
S: <trID>
S: <clTRID>BCD-23456</clTRID>
S: <svTRID>65432-WXY</svTRID>
S: </trID>
S: </response>
S:</epp>
S: <resData>
S: <host:panData
S: xmlns:host="urn:ietf:params:xml:ns:host-1.0">
S: <host:name paResult="1">ns1.example.com</host:name>
S: <host:paTRID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54322-XYZ</svTRID>
S: </host:paTRID>
S: <host:paDate>1999-04-04T22:00:00.0Z</host:paDate>
S: </host:panData>
S: </resData>
S: <trID>
S: <clTRID>BCD-23456</clTRID>
S: <svTRID>65432-WXY</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP object mapping is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.
EPP对象映射是用XML模式表示法指定的。这里给出的形式语法是对象映射的完整模式表示，适合于自动验证EPP XML实例。开始和结束标记不是模式的一部分；它们用于记录模式的开始和结束，以便进行URI注册。
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema targetNamespace="urn:ietf:params:xml:ns:host-1.0"
xmlns:host="urn:ietf:params:xml:ns:host-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<schema targetNamespace="urn:ietf:params:xml:ns:host-1.0"
xmlns:host="urn:ietf:params:xml:ns:host-1.0"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<!--
Import common element types.
-->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
<import namespace="urn:ietf:params:xml:ns:epp-1.0"/>
<!--
Import common element types.
-->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0"/>
<import namespace="urn:ietf:params:xml:ns:epp-1.0"/>
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
host provisioning schema.
</documentation>
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
host provisioning schema.
</documentation>
</annotation>
</annotation>
<!--
Child elements found in EPP commands.
-->
<element name="check" type="host:mNameType"/>
<element name="create" type="host:createType"/>
<element name="delete" type="host:sNameType"/>
<element name="info" type="host:sNameType"/>
<element name="update" type="host:updateType"/>
<!--
Child elements found in EPP commands.
-->
<element name="check" type="host:mNameType"/>
<element name="create" type="host:createType"/>
<element name="delete" type="host:sNameType"/>
<element name="info" type="host:sNameType"/>
<element name="update" type="host:updateType"/>
<!--
Child elements of the <create> command.
-->
<complexType name="createType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="addr" type="host:addrType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
Child elements of the <create> command.
-->
<complexType name="createType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="addr" type="host:addrType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="addrType">
<simpleContent>
<extension base="host:addrStringType">
<attribute name="ip" type="host:ipType"
default="v4"/>
</extension>
</simpleContent>
</complexType>
<complexType name="addrType">
<simpleContent>
<extension base="host:addrStringType">
<attribute name="ip" type="host:ipType"
default="v4"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="addrStringType">
<restriction base="token">
<minLength value="3"/>
<maxLength value="45"/>
</restriction>
</simpleType>
<simpleType name="addrStringType">
<restriction base="token">
<minLength value="3"/>
<maxLength value="45"/>
</restriction>
</simpleType>
<simpleType name="ipType">
<restriction base="token">
<enumeration value="v4"/>
<enumeration value="v6"/>
</restriction>
</simpleType>
<simpleType name="ipType">
<restriction base="token">
<enumeration value="v4"/>
<enumeration value="v6"/>
</restriction>
</simpleType>
<!--
Child elements of the <delete> and <info> commands.
-->
<!--
Child elements of the <delete> and <info> commands.
-->
<complexType name="sNameType">
<sequence>
<element name="name" type="eppcom:labelType"/>
</sequence>
</complexType>
<complexType name="sNameType">
<sequence>
<element name="name" type="eppcom:labelType"/>
</sequence>
</complexType>
<!--
Child element of commands that accept multiple names.
-->
<complexType name="mNameType">
<sequence>
<element name="name" type="eppcom:labelType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
Child elements of the <update> command.
-->
<complexType name="updateType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="add" type="host:addRemType"
minOccurs="0"/>
<element name="rem" type="host:addRemType"
minOccurs="0"/>
<element name="chg" type="host:chgType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Child element of commands that accept multiple names.
-->
<complexType name="mNameType">
<sequence>
<element name="name" type="eppcom:labelType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
Child elements of the <update> command.
-->
<complexType name="updateType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="add" type="host:addRemType"
minOccurs="0"/>
<element name="rem" type="host:addRemType"
minOccurs="0"/>
<element name="chg" type="host:chgType"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Data elements that can be added or removed.
-->
<complexType name="addRemType">
<sequence>
<element name="addr" type="host:addrType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="status" type="host:statusType"
minOccurs="0" maxOccurs="7"/>
</sequence>
</complexType>
<!--
Data elements that can be added or removed.
-->
<complexType name="addRemType">
<sequence>
<element name="addr" type="host:addrType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="status" type="host:statusType"
minOccurs="0" maxOccurs="7"/>
</sequence>
</complexType>
<!--
Data elements that can be changed.
-->
<complexType name="chgType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<!--
Data elements that can be changed.
-->
<complexType name="chgType">
<sequence>
<element name="name" type="eppcom:labelType"/>
</sequence>
</complexType>
</sequence>
</complexType>
<!--
Child response elements.
-->
<element name="chkData" type="host:chkDataType"/>
<element name="creData" type="host:creDataType"/>
<element name="infData" type="host:infDataType"/>
<element name="panData" type="host:panDataType"/>
<!--
Child response elements.
-->
<element name="chkData" type="host:chkDataType"/>
<element name="creData" type="host:creDataType"/>
<element name="infData" type="host:infDataType"/>
<element name="panData" type="host:panDataType"/>
<!--
<check> response elements.
-->
<complexType name="chkDataType">
<sequence>
<element name="cd" type="host:checkType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
<check> response elements.
-->
<complexType name="chkDataType">
<sequence>
<element name="cd" type="host:checkType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<complexType name="checkType">
<sequence>
<element name="name" type="host:checkNameType"/>
<element name="reason" type="eppcom:reasonType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="checkType">
<sequence>
<element name="name" type="host:checkNameType"/>
<element name="reason" type="eppcom:reasonType"
minOccurs="0"/>
</sequence>
</complexType>
<complexType name="checkNameType">
<simpleContent>
<extension base="eppcom:labelType">
<attribute name="avail" type="boolean"
use="required"/>
</extension>
</simpleContent>
</complexType>
<complexType name="checkNameType">
<simpleContent>
<extension base="eppcom:labelType">
<attribute name="avail" type="boolean"
use="required"/>
</extension>
</simpleContent>
</complexType>
<!--
<create> response elements.
-->
<complexType name="creDataType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="crDate" type="dateTime"/>
</sequence>
</complexType>
<!--
<create> response elements.
-->
<complexType name="creDataType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="crDate" type="dateTime"/>
</sequence>
</complexType>
<!--
<info> response elements.
-->
<complexType name="infDataType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="roid" type="eppcom:roidType"/>
<element name="status" type="host:statusType"
maxOccurs="7"/>
<element name="addr" type="host:addrType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="clID" type="eppcom:clIDType"/>
<element name="crID" type="eppcom:clIDType"/>
<element name="crDate" type="dateTime"/>
<element name="upID" type="eppcom:clIDType"
minOccurs="0"/>
<element name="upDate" type="dateTime"
minOccurs="0"/>
<element name="trDate" type="dateTime"
minOccurs="0"/>
</sequence>
</complexType>
<!--
<info> response elements.
-->
<complexType name="infDataType">
<sequence>
<element name="name" type="eppcom:labelType"/>
<element name="roid" type="eppcom:roidType"/>
<element name="status" type="host:statusType"
maxOccurs="7"/>
<element name="addr" type="host:addrType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="clID" type="eppcom:clIDType"/>
<element name="crID" type="eppcom:clIDType"/>
<element name="crDate" type="dateTime"/>
<element name="upID" type="eppcom:clIDType"
minOccurs="0"/>
<element name="upDate" type="dateTime"
minOccurs="0"/>
<element name="trDate" type="dateTime"
minOccurs="0"/>
</sequence>
</complexType>
<!--
Status is a combination of attributes and an optional human-readable
message that may be expressed in languages other than English.
-->
<complexType name="statusType">
<simpleContent>
<extension base="normalizedString">
<attribute name="s" type="host:statusValueType"
use="required"/>
<attribute name="lang" type="language"
default="en"/>
</extension>
</simpleContent>
</complexType>
<!--
Status is a combination of attributes and an optional human-readable
message that may be expressed in languages other than English.
-->
<complexType name="statusType">
<simpleContent>
<extension base="normalizedString">
<attribute name="s" type="host:statusValueType"
use="required"/>
<attribute name="lang" type="language"
default="en"/>
</extension>
</simpleContent>
</complexType>
<simpleType name="statusValueType">
<restriction base="token">
<enumeration value="clientDeleteProhibited"/>
<enumeration value="clientUpdateProhibited"/>
<enumeration value="linked"/>
<enumeration value="ok"/>
<enumeration value="pendingCreate"/>
<enumeration value="pendingDelete"/>
<enumeration value="pendingTransfer"/>
<enumeration value="pendingUpdate"/>
<simpleType name="statusValueType">
<restriction base="token">
<enumeration value="clientDeleteProhibited"/>
<enumeration value="clientUpdateProhibited"/>
<enumeration value="linked"/>
<enumeration value="ok"/>
<enumeration value="pendingCreate"/>
<enumeration value="pendingDelete"/>
<enumeration value="pendingTransfer"/>
<enumeration value="pendingUpdate"/>
<enumeration value="serverDeleteProhibited"/>
<enumeration value="serverUpdateProhibited"/>
</restriction>
</simpleType>
<enumeration value="serverDeleteProhibited"/>
<enumeration value="serverUpdateProhibited"/>
</restriction>
</simpleType>
<!--
Pending action notification response elements.
-->
<complexType name="panDataType">
<sequence>
<element name="name" type="host:paNameType"/>
<element name="paTRID" type="epp:trIDType"/>
<element name="paDate" type="dateTime"/>
</sequence>
</complexType>
<complexType name="paNameType">
<simpleContent>
<extension base="eppcom:labelType">
<attribute name="paResult" type="boolean"
use="required"/>
</extension>
</simpleContent>
</complexType>
<!--
Pending action notification response elements.
-->
<complexType name="panDataType">
<sequence>
<element name="name" type="host:paNameType"/>
<element name="paTRID" type="epp:trIDType"/>
<element name="paDate" type="dateTime"/>
</sequence>
</complexType>
<complexType name="paNameType">
<simpleContent>
<extension base="eppcom:labelType">
<attribute name="paResult" type="boolean"
use="required"/>
</extension>
</simpleContent>
</complexType>
<!-- End of schema. --> </schema> END
<!-- 架构结束。--></架构>结束
EPP is represented in XML, which provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED in environments where parser encoding support incompatibility exists.
EPP用XML表示，它为使用Unicode字符集及其更紧凑的表示（包括UTF-8）编码信息提供了本机支持。一致性XML处理器同时识别UTF-8和UTF-16[RFC2781]。尽管XML包含通过在<？XML？>声明中使用“encoding”属性来识别和使用其他字符编码的规定，但在解析器编码支持不兼容的环境中，建议使用UTF-8。
All date-time values presented via EPP MUST be expressed in Universal Coordinated Time using the Gregorian calendar. XML Schema allows use of time zone identifiers to indicate offsets from the zero meridian, but this option MUST NOT be used with EPP. The extended date-time form using upper case "T" and "Z" characters defined in
通过EPP提供的所有日期时间值必须使用公历以全球协调时间表示。XML模式允许使用时区标识符来指示从零子午线的偏移，但此选项不得与EPP一起使用。使用中定义的大写“T”和“Z”字符的扩展日期时间窗体
[W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time values as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters.
[W3C.REC-xmlschema-2-20041028]必须用于表示日期时间值，因为XML模式不支持截断的日期时间形式或小写的“T”和“Z”字符。
This document requires host name syntax as specified in [RFC0952] as updated by [RFC1123]. At the time of this writing, RFC 3490 [RFC3490] describes a standard to use certain ASCII name labels to represent non-ASCII name labels. These conformance requirements might change as a result of progressing work in developing standards for internationalized host names.
本文档需要[RFC0952]中指定的主机名语法，并由[RFC1123]更新。在撰写本文时，RFC 3490[RFC3490]描述了使用某些ASCII名称标签来表示非ASCII名称标签的标准。随着为国际化主机名开发标准的工作进展，这些一致性要求可能会发生变化。
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been registered by the IANA.
本文档使用URN来描述符合[RFC3688]中描述的注册表机制的XML名称空间和XML模式。IANA已经注册了两个URI分配。
Registration request for the host namespace:
主机命名空间的注册请求：
URI: urn:ietf:params:xml:ns:host-1.0
URI: urn:ietf:params:xml:ns:host-1.0
Registrant Contact: See the "Author's Address" section of this document.
注册人联系人：请参阅本文件的“作者地址”部分。
XML: None. Namespace URIs do not represent an XML specification.
XML：没有。命名空间URI不表示XML规范。
Registration request for the host XML schema:
主机XML架构的注册请求：
URI: urn:ietf:params:xml:schema:host-1.0
URI: urn:ietf:params:xml:schema:host-1.0
Registrant Contact: See the "Author's Address" section of this document.
注册人联系人：请参阅本文件的“作者地址”部分。
XML: See the "Formal Syntax" section of this document.
XML：请参阅本文档的“正式语法”部分。
The object mapping described in this document does not provide any security services or introduce any additional considerations beyond those described by [RFC4930] and protocol layers used by EPP.
本文档中描述的对象映射不提供任何安全服务，也不引入任何超出[RFC4930]和EPP使用的协议层描述的其他注意事项。
This document was originally written as an individual submission Internet-Draft. The PROVREG working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.
本文件最初是作为个人提交的互联网草案编写的。PROVREG工作组后来将其作为工作组文件通过，并提出了许多宝贵的意见和改进建议。作者希望感谢工作组主席Edward Lewis和Jaap Akkerhuis的工作过程和编辑贡献。
Specific suggestions that have been incorporated into this document were provided by Chris Bason, Jordyn Buchanan, Dave Crocker, Anthony Eden, Sheer El-Showk, Klaus Malorny, Dan Manley, Michael Mealling, Patrick Mevzek, and Rick Wesson.
Chris Bason、Jordyn Buchanan、Dave Crocker、Anthony Eden、Sheer El Showk、Klaus Malorny、Dan Manley、Michael Mealling、Patrick Mevzek和Rick Wesson提供了纳入本文件的具体建议。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985.
[RFC0952]Harrenstien，K.，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC 952，1985年10月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4930] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 4930, May 2007.
[RFC4930]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，RFC 4930，2007年5月。
[W3C.REC-xml-20040204] Yergeau, F., Maler, E., Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.
[W3C.REC-xml-20040204]Yergeau，F.，Maler，E.，Sperberg McQueen，C.，Bray，T.，和J.Paoli，“可扩展标记语言（xml）1.0（第三版）”，万维网联盟第一版REC-xml-20040204，2004年2月<http://www.w3.org/TR/2004/REC-xml-20040204>.
[W3C.REC-xmlschema-1-20041028] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-1-20041028]Thompson，H.，Maloney，M.，Mendelsohn，N.，和D.Beech，“XML模式第1部分：结构第二版”，万维网联盟建议REC-xmlschema-1-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-xmlschema-2-20041028]Biron，P.和A.Malhotra，“XML模式第2部分：数据类型第二版”，万维网联盟建议REC-xmlschema-2-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP version 6", RFC 1886, December 1995.
[RFC1886]Thomson，S.和C.Huitema，“支持IP版本6的DNS扩展”，RFC 18861995年12月。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[RFC2781]Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]Crawford，M.和C.Huitema，“支持IPv6地址聚合和重新编号的DNS扩展”，RFC 28742000年7月。
[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[RFC3152]Bush，R.，“IP6.ARPA的授权”，BCP 49，RFC 3152，2001年8月。
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[RFC3490]Faltstrom，P.，Hoffman，P.，和A.Costello，“应用程序中的域名国际化（IDNA）”，RFC 34902003年3月。
[RFC3732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", RFC 3732, March 2004.
[RFC3732]Hollenbeck，S.，“可扩展资源调配协议（EPP）主机映射”，RFC 3732，2004年3月。
1. Minor reformatting as a result of converting I-D source format from nroff to XML.
1. 由于将I-D源格式从nroff转换为XML，因此需要进行较小的重新格式化。
2. Removed this text from Section 2.3:
2. 从第2.3节中删除此文本：
"Transform commands MUST be rejected when a pendingCreate, pendingDelete, pendingTransfer, or pendingUpdate status is set."
设置pendingCreate、pendingDelete、pendingTransfer或pendingUpdate状态时，必须拒绝转换命令
3. Changed text in Section 3.2.2 from this:
3. 更改了第3.2.2节中的以下内容：
"A host name object MUST NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object MUST NOT be deleted until the existing association has been broken."
如果主机名对象与任何其他对象关联，则不得删除该主机名对象。例如，如果主机对象与域对象关联，则在现有关联被破坏之前，不得删除该主机名对象
to this:
为此：
"A host name object SHOULD NOT be deleted if the host object is associated with any other object. For example, if the host object is associated with a domain object, the host object SHOULD NOT be deleted until the existing association has been broken. Deleting a host object without first breaking existing associations can cause DNS resolution failure for domain objects that refer to the deleted host object."
如果主机名对象与任何其他对象相关联，则不应删除该主机名对象。例如，如果主机对象与域对象相关联，则在现有关联被破坏之前不应删除该主机对象。在不首先破坏现有关联的情况下删除主机对象可能会导致DNS解析失败用于引用已删除主机对象的域对象。“
4. Changed text in Section 3.2.5 from "At least one <host:add>, <host:rem>, or <host:chg> element MUST be provided." to "At least one <host:add>, <host:rem>, or <host:chg> element MUST be provided if the command is not being extended. All of these elements MAY be omitted if an <update> extension is present."
4. 将第3.2.5节中的文本从“必须提供至少一个<host:add>、<host:rem>或<host:chg>元素”更改为“如果命令未扩展，则必须提供至少一个<host:add>、<host:rem>或<host:chg>元素。如果存在<update>扩展，则可以省略所有这些元素。”
5. Changed text in Section 3.3 (old Section 3.2.6) from this:
5. 将第3.3节（旧的第3.2.6节）中的文本更改为：
"The server operator reviews the request offline, and informs the client of the outcome of the review by queuing a service message for retrieval via the <poll> command."
服务器操作员脱机审查请求，并通过<poll>命令将服务消息排队以供检索，从而将审查结果通知客户端
to this:
为此：
"The server operator reviews the request offline, and informs the client of the outcome of the review either by queuing a service message for retrieval via the <poll> command or by using an out-of-band mechanism to inform the client of the request."
服务器操作员脱机审查请求，并通过将服务消息排队等待通过<poll>命令检索或使用带外机制通知客户端该请求，将审查结果通知客户端
6. Removed text describing use of the XML Schema schemaLocation attribute. This is an optional attribute that doesn't need to be mandated for use in EPP.
6. 已删除描述使用XML架构schemaLocation属性的文本。这是一个可选属性，不需要强制在EPP中使用。
7. Removed references to RFC 3339 and replaced them with references to the W3C XML Schema specification.
7. 删除了对RFC 3339的引用，并将其替换为对W3C XML模式规范的引用。
8. Replaced references to RFC 3513 with references to RFC 4291.
8. 将参考RFC 3513替换为参考RFC 4291。
9. Updated EPP and XML references.
9. 更新了EPP和XML引用。
Author's Address
作者地址
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。