Network Working Group S. Hollenbeck
Request for Comments: 3735 VeriSign, Inc.
Category: Informational March 2004
Network Working Group S. Hollenbeck
Request for Comments: 3735 VeriSign, Inc.
Category: Informational March 2004
Guidelines for Extending the Extensible Provisioning Protocol (EPP)
扩展可扩展资源调配协议（EPP）的指南
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
The Extensible Provisioning Protocol (EPP) is an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document presents guidelines for use of EPP's extension mechanisms to define new features and object management capabilities.
可扩展资源调配协议（EPP）是一种应用层客户机-服务器协议，用于调配和管理存储在共享中央存储库中的对象。协议以XML形式指定，定义了通用对象管理操作和一个可扩展框架，该框架将协议操作映射到对象。本文档提供了使用EPP扩展机制定义新特性和对象管理功能的指南。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used In This Document. . . . . . . . . . . 2
2. Principles of Protocol Extension . . . . . . . . . . . . . . 3
2.1. Documenting Extensions . . . . . . . . . . . . . . . . 3
2.2. Identifying Extensions . . . . . . . . . . . . . . . . 4
2.2.1. Standards Track Extensions . . . . . . . . . . 4
2.2.2. Other Extensions . . . . . . . . . . . . . . . 5
2.3. Extension Announcement and Selection . . . . . . . . . 5
2.4. Protocol-level Extension . . . . . . . . . . . . . . . 7
2.5. Object-level Extension . . . . . . . . . . . . . . . . 7
2.6. Command-Response Extension . . . . . . . . . . . . . . 7
2.7. Authentication Information Extension . . . . . . . . . 7
3. Selecting an Extension Mechanism . . . . . . . . . . . . . . 8
3.1. Mapping and Extension Archives . . . . . . . . . . . 9
4. Internationalization Considerations . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used In This Document. . . . . . . . . . . 2
2. Principles of Protocol Extension . . . . . . . . . . . . . . 3
2.1. Documenting Extensions . . . . . . . . . . . . . . . . 3
2.2. Identifying Extensions . . . . . . . . . . . . . . . . 4
2.2.1. Standards Track Extensions . . . . . . . . . . 4
2.2.2. Other Extensions . . . . . . . . . . . . . . . 5
2.3. Extension Announcement and Selection . . . . . . . . . 5
2.4. Protocol-level Extension . . . . . . . . . . . . . . . 7
2.5. Object-level Extension . . . . . . . . . . . . . . . . 7
2.6. Command-Response Extension . . . . . . . . . . . . . . 7
2.7. Authentication Information Extension . . . . . . . . . 7
3. Selecting an Extension Mechanism . . . . . . . . . . . . . . 8
3.1. Mapping and Extension Archives . . . . . . . . . . . 9
4. Internationalization Considerations . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . 11
8. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . 11
8. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
The Extensible Provisioning Protocol (EPP, [2]) was originally designed to provide a standard Internet domain name registration protocol for use between Internet domain name registrars and domain name registries. However, specific design decisions were made to ensure that the protocol could also be used in other provisioning environments. Specifically:
可扩展配置协议（EPP，[2]）最初设计用于提供标准的Internet域名注册协议，供Internet域名注册商和域名注册商之间使用。但是，做出了具体的设计决策，以确保该协议也可用于其他资源调配环境。明确地：
o Extensibility has been a design goal from the very beginning. EPP is represented in the Extensible Markup Language (XML, [3]), and is specified in XML Schema ([4] and [5]) with XML namespaces [6] used to identify protocol grammars.
o 可扩展性从一开始就是设计目标。EPP用可扩展标记语言（XML，[3]）表示，并在XML模式（[4]和[5]）中指定，使用XML名称空间[6]来标识协议语法。
o The EPP core protocol specification describes general protocol functions, not objects to be managed by the protocol. Managed object definitions, such as the mapping for Internet domain names [10] (itself a protocol extension), are loosely coupled to the core specification.
o EPP核心协议规范描述一般协议功能，而不是协议管理的对象。托管对象定义，如Internet域名映射[10]（本身是协议扩展），与核心规范松散耦合。
o A concentrated effort was made to separate required minimum protocol functionality from object management operating logic.
o 集中精力将所需的最低协议功能与对象管理操作逻辑分离。
o Several extension mechanisms were included to allow designers to add new features or to customize existing features for different operating environments.
o 包括了一些扩展机制，允许设计者为不同的操作环境添加新功能或自定义现有功能。
This document describes EPP's extensibility features in detail and provides guidelines for their use. Though written specifically for protocol designers considering EPP as the solution to a provisioning problem, anyone interested in using XML to represent IETF protocols might find these guidelines useful.
本文档详细描述了EPP的可扩展性特性，并提供了使用指南。尽管是专门为将EPP视为供应问题解决方案的协议设计人员编写的，但任何对使用XML表示IETF协议感兴趣的人都可能会发现这些指南很有用。
XML is case sensitive. Unless stated otherwise, XML instances and examples provided in this document MUST be interpreted in the character case presented to develop a conforming implementation.
XML区分大小写。除非另有说明，否则本文档中提供的XML实例和示例必须按照提供的字符大小写进行解释，以开发一致性实现。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
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 is provided only to illustrate element relationships and is not a REQUIRED feature of this specification.
在示例中，“C:”表示协议客户端发送的行，“S:”表示协议服务器返回的行。示例中的缩进和空白仅用于说明元素关系，而不是本规范的必需功能。
The EPP extension model is based on the XML representation for a wildcard schema component using an <any> element information item (as described in section 3.10.2 of [4]) and XML namespaces [6]. This section provides guidelines for the development of protocol extensions and describes the extension model in detail.
EPP扩展模型基于使用<any>元素信息项（如[4]第3.10.2节所述）和XML名称空间[6]的通配符模式组件的XML表示。本节提供协议扩展的开发指南，并详细描述扩展模型。
Extending a protocol implies the addition of features without changing the protocol itself. In EPP that means that an extension MUST NOT alter an existing protocol schema as changes may result in new versions of an existing schema, not extensions of an existing schema. For example, a designer MUST NOT add new elements to an existing schema and call the result an "extension" of the protocol. The result is a new, non-backwards-compatible version of an existing schema. Extensions MUST adhere to the principles described in this section to be considered valid protocol extensions.
扩展协议意味着在不更改协议本身的情况下添加特性。在EPP中，这意味着扩展不能改变现有的协议模式，因为更改可能导致现有模式的新版本，而不是现有模式的扩展。例如，设计器不能向现有模式添加新元素，而将结果称为协议的“扩展”。结果是现有模式的一个新的、不向后兼容的版本。扩展必须遵守本节所述的原则，才能被视为有效的协议扩展。
EPP extensions MUST be specified in XML. This ensures that parsers capable of processing EPP structures will also be capable of processing EPP extensions. Guidelines for the use of XML in IETF protocols (thus good information for extension designers) can be found in RFC 3470 [11].
必须在XML中指定EPP扩展。这确保了能够处理EPP结构的解析器也能够处理EPP扩展。在IETF协议中使用XML的指南（因此对于扩展设计者来说是很好的信息）可以在RFC3470[11]中找到。
A designer MUST remember that extensions themselves MAY also be extensible. A good chain of extensions is one in which the protocol schemas evolve from general functionality to more specific (perhaps even more limited) functionality.
设计者必须记住，扩展本身也可能是可扩展的。一个好的扩展链是协议模式从一般功能发展到更具体（甚至可能更有限）的功能。
The EPP core specification [2] has an appendix that contains a suggested outline to document protocol extensions. Designers are free to use this template or any other format as they see fit, but the extension document SHOULD at a minimum address all of the topics listed in the template.
EPP核心规范[2]有一个附录，其中包含了记录协议扩展的建议大纲。设计师可以自由使用此模板或他们认为合适的任何其他格式，但扩展文档应至少解决模板中列出的所有主题。
Extension designers need to consider the intended audience and consumers of their extensions. Extensions MAY be documented as Internet-Draft and RFC documents if the designer is facing requirements for coordination, interoperability, and broad distribution, though the intended maturity level (informational, proposed standard, etc.) largely depends on what is being extended
扩展设计器需要考虑其扩展的预期受众和消费者。如果设计人员面临协调、互操作性和广泛分发的要求，则可将扩展记录为互联网草稿和RFC文档，尽管预期的成熟度水平（信息、拟定标准等）在很大程度上取决于扩展的内容
and the amount of general interest in the extension. An extension to a standards-track specification with broad interest might well be a candidate for standards track publication, whereas an extension to a standards track specification with limited interest might be better suited for informational publication.
以及延期的一般利息金额。兴趣广泛的标准跟踪规范的扩展可能是标准跟踪发布的候选，而兴趣有限的标准跟踪规范的扩展可能更适合于信息发布。
Extensions need not be published as Internet-Draft or RFC documents if they are intended for operation in a closed environment or are otherwise intended for a limited audience. In such cases extensions MAY be documented in a file and structural format that is appropriate for the intended audience.
如果扩展的目的是在封闭环境中运行，或者是针对有限的受众，则不需要将其发布为Internet草稿或RFC文档。在这种情况下，扩展名可能以适合预期受众的文件和结构格式记录。
An EPP extension is uniquely identified by a Uniform Resource Identifier (URI, defined in RFC 2396 [7]). The URI used to identify the extension MUST also be used to identify the XML namespace associated with the extension. Any valid URI MAY be used to identify an EPP extension, though the selection of a URI form (Uniform Resource Locator (URL) vs. Uniform Resource Name (URN), hierarchical vs. relative, etc.) SHOULD depend on factors such as organizational policies on change control and a balance between locating resources and requirements for persistence. An extension namespace MAY describe multiple extension mechanisms, such as definition of new protocol features, objects, or elements, within the schema used to define the namespace.
EPP扩展由统一资源标识符（URI，在RFC 2396[7]中定义）唯一标识。用于标识扩展的URI还必须用于标识与扩展关联的XML命名空间。任何有效的URI都可用于标识EPP扩展，尽管URI表单（统一资源定位器（URL）与统一资源名称（URN）、层次结构与相对关系等）的选择应取决于各种因素，如关于变更控制的组织策略以及资源定位与持久性需求之间的平衡。扩展名称空间可以描述用于定义名称空间的模式中的多个扩展机制，例如新协议特性、对象或元素的定义。
The following are sample extension-identifying URIs:
以下是识别URI的扩展示例：
urn:ietf:params:xml:ns:foo-ext1
urn:ietf:params:xml:ns:foo-ext1
http://custom/obj1ext-1.0
http://custom/obj1ext-1.0
Extension designers MAY include version information in the URI used to identify an extension. If version information is included in the URI, the URI itself will need to change as the extension is revised or updated.
扩展设计器可以在用于标识扩展的URI中包含版本信息。如果URI中包含版本信息，则URI本身需要随着扩展的修订或更新而更改。
URIs for extensions intended for IETF standards track use MUST conform to the URN syntax specifications and registration procedures described in [8].
用于IETF标准轨道使用的扩展的URI必须符合[8]中描述的URN语法规范和注册程序。
URIs for extensions that are not intended for IETF standards track use MUST conform to the URI syntax specifications described in RFC 2396.
非IETF标准轨道使用的扩展的URI必须符合RFC 2396中描述的URI语法规范。
An EPP server MUST announce extensions that are available for client use as part of a <greeting> element that is sent to a client before the client establishes an interactive session with the server. The <greeting> element contains zero or more <svcExtension> elements that, if present, contain a URI identifying an available extension:
在客户端与服务器建立交互会话之前，EPP服务器必须宣布可供客户端使用的扩展，作为发送到客户端的<greeting>元素的一部分。<greeting>元素包含零个或多个<svctension>元素，这些元素如果存在，则包含标识可用扩展名的URI：
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <greeting>
S: <svID>Example EPP server epp.example.com</svID>
S: <svDate>2000-06-08T22:00:00.0Z</svDate>
S: <svcMenu>
S: <version>1.0</version>
S: <lang>en</lang>
S: <lang>fr</lang>
S: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
S: <svcExtension>
S: <extURI>urn:ietf:params:xml:ns:foo-ext1</extURI>
S: <extURI>http://custom/obj1ext-1.0</extURI>
S: </svcExtension>
S: </svcMenu>
S: <dcp>
S: <access><all/></access>
S: <statement>
S: <purpose><admin/><prov/></purpose>
S: <recipient><ours/><public/></recipient>
S: <retention><stated/></retention>
S: </statement>
S: </dcp>
S: </greeting>
S:</epp>
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
S: epp-1.0.xsd">
S: <greeting>
S: <svID>Example EPP server epp.example.com</svID>
S: <svDate>2000-06-08T22:00:00.0Z</svDate>
S: <svcMenu>
S: <version>1.0</version>
S: <lang>en</lang>
S: <lang>fr</lang>
S: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
S: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
S: <svcExtension>
S: <extURI>urn:ietf:params:xml:ns:foo-ext1</extURI>
S: <extURI>http://custom/obj1ext-1.0</extURI>
S: </svcExtension>
S: </svcMenu>
S: <dcp>
S: <access><all/></access>
S: <statement>
S: <purpose><admin/><prov/></purpose>
S: <recipient><ours/><public/></recipient>
S: <retention><stated/></retention>
S: </statement>
S: </dcp>
S: </greeting>
S:</epp>
In the example above, the server is announcing the availability of two extensions:
在上面的示例中，服务器宣布两个扩展可用：
urn:ietf:params:xml:ns:foo-ext1, and
urn:ietf:params:xml:ns:foo-ext1, and
http://custom/obj1ext-1.0
http://custom/obj1ext-1.0
An EPP client MUST establish a session with an EPP server using the EPP <login> command before attempting to use any standard commands or extensions. The <login> command contains zero or more <svcExtension> elements that, if present, contain a URI identifying an available extension that the client wishes to use during the course of the session:
在尝试使用任何标准命令或扩展之前，EPP客户端必须使用EPP<login>命令与EPP服务器建立会话。<login>命令包含零个或多个<svctextension>元素，这些元素（如果存在）包含一个URI，用于标识客户端希望在会话过程中使用的可用扩展：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <login>
C: <clID>ClientX</clID>
C: <pw>foo-BAR2</pw>
C: <newPW>bar-FOO2</newPW>
C: <options>
C: <version>1.0</version>
C: <lang>en</lang>
C: </options>
C: <svcs>
C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
C: <svcExtension>
C: <extURI>http://custom/obj1ext-1.0</extURI>
C: </svcExtension>
C: </svcs>
C: </login>
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: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
C: epp-1.0.xsd">
C: <command>
C: <login>
C: <clID>ClientX</clID>
C: <pw>foo-BAR2</pw>
C: <newPW>bar-FOO2</newPW>
C: <options>
C: <version>1.0</version>
C: <lang>en</lang>
C: </options>
C: <svcs>
C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
C: <svcExtension>
C: <extURI>http://custom/obj1ext-1.0</extURI>
C: </svcExtension>
C: </svcs>
C: </login>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
In the example above, the client indicates that it wishes to use an extension identified by the http://custom/obj1ext-1.0 URI during the session established upon successful completion of the <login> command.
在上面的示例中，客户机表示希望使用由http://custom/obj1ext-1.0 成功完成<login>命令后建立的会话期间的URI。
An EPP server MUST announce all extensions that are publicly available for client use. An EPP client MUST NOT request an extension that has not been announced by the server. An EPP server MAY restrict a client's ability to select an extension based on a client's identity and authorizations granted by the server operator.
EPP服务器必须宣布所有可公开供客户端使用的扩展。EPP客户端不得请求服务器尚未宣布的扩展。EPP服务器可能会限制客户机根据客户机的身份和服务器操作员授予的授权选择扩展的能力。
EPP defines a set of structures for client-server command-response interaction, but additional structures MAY be added to the protocol. New structure definition is a matter of defining a schema for the structures that defines needed functionality and assigning a URI to uniquely identify the object namespace and schema. Specific protocol-level extension mechanisms are described in section 2.7.1 of the EPP core protocol specification [2].
EPP为客户机-服务器命令-响应交互定义了一组结构，但是可以向协议中添加其他结构。新结构定义是为定义所需功能的结构定义模式，并分配URI以唯一标识对象命名空间和模式。EPP核心协议规范[2]第2.7.1节描述了特定的协议级扩展机制。
EPP commands and responses do not contain attributes that are specific to any managed object. Every command and response MUST contain elements bound to an object namespace. Object definition is a matter of defining a schema for the object that defines functionality for each needed command and associated response, and assigning a URI to uniquely identify the object namespace and schema. Specific object-level extension mechanisms are described in section 2.7.2 of the EPP core protocol specification [2].
EPP命令和响应不包含特定于任何托管对象的属性。每个命令和响应都必须包含绑定到对象命名空间的元素。对象定义是为对象定义一个模式，该模式为每个需要的命令和关联的响应定义功能，并分配一个URI来唯一标识对象名称空间和模式。EPP核心协议规范[2]第2.7.2节描述了特定的对象级扩展机制。
EPP command and response structures defined in existing object mappings MAY also be extended. For example, an object mapping that describes general functionality for the provisioning of Internet domain names can be extended to included additional command and response elements needed for the provisioning of domain names that represent E.164 telephone numbers [12]. Specific command-response extension mechanisms are described in section 2.7.3 of the EPP core protocol specification [2].
现有对象映射中定义的EPP命令和响应结构也可以扩展。例如，描述互联网域名供应一般功能的对象映射可以扩展为包括供应代表E.164电话号码的域名所需的额外命令和响应元素[12]。EPP核心协议规范[2]第2.7.3节描述了具体的命令响应扩展机制。
Some EPP object mappings, such as the Internet domain name mapping [10], include elements to associate authentication information (such as a password) with an object. The schema for any object mapping that supports authentication information SHOULD be flexible enough to specify multiple forms of authentication information. With XML Schema ([4] and [5]), this can be accomplished by offering an element choice that includes an <any> element information item:
某些EPP对象映射（如Internet域名映射[10]）包含将身份验证信息（如密码）与对象关联的元素。支持身份验证信息的任何对象映射的模式都应该足够灵活，可以指定多种形式的身份验证信息。对于XML模式（[4]和[5]），这可以通过提供包含<any>元素信息项的元素选择来实现：
<any namespace="##other"/>
<any namespace="##other"/>
Extensibility is a powerful feature of XML, but it also provides multiple opportunities to make poor design decisions. There are typically several different ways to accomplish a single task, and while all may "work" (for some definition of "work") one extension form will usually be more appropriate than others to complete a given task. The following sequence of steps can be followed to select an appropriate extension form to solve an extension problem:
可扩展性是XML的一个强大特性，但它也提供了许多机会来做出糟糕的设计决策。通常有几种不同的方式来完成一项任务，虽然所有方式都可能“工作”（对于“工作”的某些定义），但一种扩展形式通常比其他形式更适合完成给定的任务。可以按照以下步骤顺序选择适当的扩展表单以解决扩展问题：
o Command-Response Extension: Adding elements to an existing object mapping is the simplest form of extension available, and is thus the form that should be explored before any other form is considered. The first question to ask when considering an extension form is thus:
o 命令响应扩展：向现有对象映射添加元素是可用的最简单的扩展形式，因此，在考虑任何其他形式之前，应该先对其进行研究。因此，在考虑延期申请时，首先要问的问题是：
Can the task be accomplished by adding to an existing object mapping or changing an existing object mapping slightly?
可以通过添加到现有对象映射或稍微更改现有对象映射来完成任务吗？
If the answer to this question is "yes", you should consider extending an existing object mapping to complete your task. Knowing where to find object mappings is critical to being able to answer this question; see section Section 3.1 for information describing mapping archives. If the answer to this question is "no", consider an object-level extension next.
如果这个问题的答案是“是”，你应该考虑扩展现有的对象映射来完成你的任务。知道在哪里找到对象映射对于回答这个问题至关重要；有关描述映射档案的信息，请参见第3.1节。如果这个问题的答案是“否”，那么考虑下一个对象级扩展。
o Object-level Extension: If there is no existing object mapping that can be extended to meet your requirements, consider developing a new object mapping. The second question to ask when considering an extension form is thus:
o 对象级扩展：如果没有可扩展的现有对象映射来满足您的要求，请考虑开发新的对象映射。因此，在考虑延期申请时要问的第二个问题是：
Can the task be accomplished using the existing EPP command and response structures applied to a new object?
可以使用应用于新对象的现有EPP命令和响应结构来完成任务吗？
If the answer to this question is "yes", you should consider developing a new object mapping to complete your task. A new object mapping should differ significantly from existing object mappings; if you find that a new mapping is replicating a significant number of structures found in an existing mapping you probably answered the command-response question incorrectly. If the answer to this question is "no", consider a protocol-level extension next.
如果这个问题的答案是“是”，你应该考虑开发一个新的对象映射来完成你的任务。新的对象映射应与现有对象映射显著不同；如果发现新映射正在复制现有映射中发现的大量结构，则可能没有正确回答命令响应问题。如果这个问题的答案是“否”，那么考虑下一个协议级扩展。
o Protocol-level Extension: If there is no existing object mapping that can be extended to meet your requirements and the existing EPP command and response structures are insufficient, consider
o 协议级扩展：如果没有现有的对象映射，可以扩展以满足您的需求，并且现有EPP命令和响应结构不充分，请考虑
developing new protocol commands, responses, or other structures. The third and final question to ask when considering an extension form is thus:
开发新的协议命令、响应或其他结构。因此，在考虑延期申请表时要问的第三个也是最后一个问题是：
Can the task be accomplished by adding new EPP commands, responses, or other structures applied to new or existing objects?
可以通过添加新的EPP命令、响应或应用于新对象或现有对象的其他结构来完成任务吗？
If the answer to this question is "no", EPP can not be used directly to complete your task. If the answer to this question is "yes", extend the protocol by defining new operational structures.
如果这个问题的答案是“否”，EPP不能直接用于完成您的任务。如果这个问题的答案是“是”，则通过定义新的操作结构来扩展协议。
The extension forms and decision points listed here are presented in order of complexity. Selecting an extension form without careful consideration of the available extension options can add complexity without any gain in functionality.
这里列出的扩展形式和决策点是按照复杂性的顺序给出的。在没有仔细考虑可用扩展选项的情况下选择扩展表单可能会增加复杂性，而不会增加任何功能。
Existing object mappings are a critical resource when trying to select an appropriate extension form. Existing mappings or extensions can provide a solid basis for further extension, but designers have to know where to find them to consider them for use.
在尝试选择适当的扩展表单时，现有对象映射是一个关键资源。现有的映射或扩展可以为进一步扩展提供坚实的基础，但设计者必须知道在哪里找到它们以供它们使用。
Several organizations maintain archives of XML structures that can be useful extension platforms. These include:
一些组织维护XML结构的档案，这些档案可以成为有用的扩展平台。这些措施包括：
o The IETF: Object mappings and other extensions have been documented in RFCs and Internet-Drafts.
o IETF：对象映射和其他扩展已记录在RFC和Internet草案中。
o IANA: Guidelines and registration procedures for an IANA XML registry used by the IETF are described in "The IETF XML Registry" [8].
o IANA：IETF使用的IANA XML注册表的指南和注册程序在“IETF XML注册表”[8]中描述。
o OASIS [16]: OASIS maintains an XML archive containing schema definitions for use in the business applications of XML.
o OASIS[16]：OASIS维护一个XML存档，其中包含用于XML业务应用程序的模式定义。
o XML.org [17]: XML.org maintains an XML archive containing schema definitions for use in multiple industries.
o XML.org[17]：XML.org维护一个包含模式定义的XML存档，用于多个行业。
o Other archives are likely in the future. Consult your favorite Internet search engine for additional resources.
o 将来可能会有其他档案。有关其他资源，请咨询您最喜爱的Internet搜索引擎。
EPP is represented in XML [3], which requires conforming parsers to recognize both UTF-8 [13] and UTF-16 [14]; support for other character encodings is also possible. EPP extensions MUST observe
EPP是用XML[3]表示的，这需要一致的解析器识别UTF-8[13]和UTF-16[14]；还可以支持其他字符编码。EPP扩展必须遵守
both the Internationalization Considerations described in the EPP core protocol specification [2] and IETF policy on the use of character sets and languages described in RFC 2277 [9].
EPP核心协议规范[2]中描述的国际化注意事项以及RFC 2277[9]中描述的关于字符集和语言使用的IETF政策。
This memo has no direct impact on the IANA. Guidelines for extensions that require IANA action are described in Section 2.2.1.
本备忘录对IANA没有直接影响。第2.2.1节描述了需要IANA行动的扩展指南。
EPP extensions inherit the security services of the protocol structure that's being extended. For example, an extension of an object mapping inherits all of the security services of the object mapping. Extensions MAY specify additional security services, such as services for peer entity authentication, confidentiality, data integrity, authorization, access control, or non-repudiation. Extensions MUST NOT mandate removal of security services available in the protocol structure being extended.
EPP扩展继承正在扩展的协议结构的安全服务。例如，对象映射的扩展继承了对象映射的所有安全服务。扩展可以指定额外的安全服务，例如对等实体身份验证、机密性、数据完整性、授权、访问控制或不可否认性服务。扩展不得强制删除正在扩展的协议结构中可用的安全服务。
Protocol designers developing EPP extensions need to be aware of the security threats to be faced in their intended operating environment so that appropriate security services can be provided. Guidelines for designers to consider and suggestions for writing an appropriate Security Considerations section can be found in RFC 3552 [15].
开发EPP扩展的协议设计人员需要了解其预期操作环境中面临的安全威胁，以便提供适当的安全服务。在RFC 3552（15）中可以找到设计者考虑和建议编写适当的安全考虑部分的指南。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[2] Hollenbeck，S.，“可扩展资源调配协议（EPP）”，RFC3730，2004年3月。
[3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[3] Bray，T.，Paoli，J.，Sperberg McQueen，C.和E.Maler，“可扩展标记语言（XML）1.0（第二版）”，W3C REC XML，2000年10月<http://www.w3.org/TR/REC-xml>.
[4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[4] Thompson，H.，Beech，D.，Maloney，M.和N.Mendelsohn，“XML模式第1部分：结构”，W3C REC-xmlschema-12001年5月<http://www.w3.org/TR/xmlschema-1/>.
[5] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
[5] Biron，P.和A.Malhotra，“XML模式第2部分：数据类型”，W3C REC-xmlschema-2，2001年5月<http://www.w3.org/TR/xmlschema-2/>.
[6] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[6] Bray，T.，Hollander，D.和A.Layman，“XML中的名称空间”，W3C REC XML名称，1999年1月<http://www.w3.org/TR/REC-xml-names>.
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[8] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[9] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[9] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[10] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.
[10] Hollenbeck，S.，“可扩展供应协议（EPP）域名映射”，RFC 37312004年3月。
[11] Hollenbeck, S., Rose, M. and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", BCP 70, RFC 3470, January 2003.
[11] Hollenbeck，S.，Rose，M.和L.Masinter，“IETF协议中可扩展标记语言（XML）的使用指南”，BCP 70，RFC 3470，2003年1月。
[12] Hollenbeck, S., "Extensible Provisioning Protocol E.164 Number Mapping", Work in Progress, February 2003.
[12] Hollenbeck，S.，“可扩展供应协议E.164数字映射”，正在进行的工作，2003年2月。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[13] “UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[14] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, February 2000.
[14] Hoffman，P.和F.Yergeau，“UTF-16，ISO 10646编码”，RFC 2781，2000年2月。
[15] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[15] Rescorla，E.和B.Korver，“关于安全考虑的RFC文本编写指南”，BCP 72，RFC 3552，2003年7月。
[16] <http://oasis-open.org/>
[16] <http://oasis-open.org/>
[17] <http://xml.org/>
[17] <http://xml.org/>
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Scott Hollenbeck VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。