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
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]）は、もともとインターネットレジストラと、ドメイン名レジストリとの間で使用するための標準的なインターネットドメイン名登録プロトコルを提供するように設計しました。しかし、特定の設計上の決定は、プロトコルはまた、他のプロビジョニング環境で使用することができることを確実にするために行われました。具体的に：
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は、[6]プロトコル文法を識別するために使用されるXML名前空間で（[3] XML）拡張マークアップ言語で表現され、そしてXMLスキーマで指定されている（[4]及び[5]）。
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コアプロトコル仕様は、プロトコルによって管理される一般的なプロトコル機能ではなく、オブジェクトを記述する。このようなインターネットドメイン名[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を考慮プロトコル設計者のために特別に書かれたものの、IETFプロトコルを表現するためにXMLを使用してに興味がある人は、これらのガイドラインが役立つかもしれません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
そしてXML名前空間（[4]のセクション3.10.2に記載されているように）EPP拡張モデルは、[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].
EPPの拡張は、XMLで指定する必要があります。これは、EPP構造を処理可能なパーサはまたEPP拡張を処理することができるであろうことを保証します。 IETFプロトコルにおけるXML（拡張デザイナーのための良好な情報）を使用するためのガイドラインは、RFC 3470 [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 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.
拡張の設計者は、その拡張子の対象読者と消費者を考慮する必要があります。設計者が連携、相互運用性、および広い分布のための要件に直面している場合は、意図成熟度レベル（情報提供、提案された標準、など）は、主にどのように拡張されており、量にもよるが拡張機能は、インターネットドラフトやRFC文書として文書化されるかもしれません延長での一般的な関心の。限られた興味の標準トラック仕様の拡張は、情報公開のためのより適しかもしれないのに対し、広範な関心と標準トラック仕様の拡張はよく、標準トラック出版のための候補であるかもしれません。
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.
拡張機能は、それらが閉鎖された環境で動作するように意図されているか、そうでない場合は限られた聴衆のために意図されている場合は、インターネット・ドラフトや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拡張は、一意（RFC 2396で定義され、URI [7]）ユニフォームリソース識別子によって識別されます。拡張機能を識別するために使用されるURIはまた、拡張に関連付けられたXML名前空間を識別するために使用されなければなりません。 URIの形式（ユニフォーム・リソース・ロケータ（URL）等の相対的な、対階層対ユニフォームリソース名（URN））の選択は、組織などの要因に依存するべきであるけれども、任意の有効なURIは、EPPの拡張を識別するために使用され得ます変更管理と持続性のためのリソースと要件を見つけるの間のバランスのポリシー。拡張名前空間は、名前空間を定義するために使用されるスキーマ内で、そのような新しいプロトコルの特徴、目的、または要素の定義のような複数の拡張メカニズムを記述することができます。
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サーバは、クライアントがサーバーとの対話セッションを確立する前に、クライアントに送信され、<あいさつ>要素の一部としてクライアントの使用のために利用可能な機能拡張を発表しなければなりません。 <挨拶>要素が存在する場合、URIが利用可能で拡張を識別する含む、ゼロ以上の<svcExtension>要素が含まれます。
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" エンコード= "UTF-8" スタンドアロン= "なし"？> S：<EPPののxmlns = "壷：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 <挨拶> S <SVID>実施例EPPサーバepp.example.com </ SVID> S <svDate> 2000-06-08T22：00：00.0Z </ svDate> S <svcMenu> S <バージョン> 1.0 < /バージョン> S：<言語> EN </言語> S：<言語> FR </言語> 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：<アクセス> <すべて/> </アクセス> S：<声明> S：<目的> <管理/> <プロブ/> </目的> S：<受信者> <私たち/> <パブリック/> </受取人> S：<保持> <述べ/> </保持> S：</声明> S：</ DCP> S：</挨拶> S：</ EPP>
In the example above, the server is announcing the availability of two extensions:
上記の例では、サーバーは、2つの拡張の可用性を発表しています。
urn:ietf:params:xml:ns:foo-ext1, and
URN：IETF：のparams：XML：NS：FOO-EXT1、および
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 <ログイン>コマンドを使用してEPPサーバとのセッションを確立する必要があります。コマンドが存在する場合、URIは、クライアントがセッションの途中で使用したいという利用できる拡張機能を識別含まれ、ゼロ以上の<svcExtension>要素が含まれ、<ログイン>：
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" エンコード= "UTF-8" スタンドアロン= "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 <コマンド> C：<ログイン> C：<CLID> ClientX </ CLID> C：<PW> FOO-BAR2 </ PW> C：<newPW>バーfoo2は</ newPW> C：<オプション> C：<バージョン> 1.0 </バージョン> C：<言語> EN </言語> C </オプション> C <SVCの> 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 </ SVCの> C </ログイン> C <clTRID> ABC-12345 </ clTRID> C </コマンド> 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.
<ログイン>コマンドが正常に完了した時点で確立されたセッション中にURI //custom/obj1ext-1.0：上記の例では、クライアントがHTTPで識別される拡張機能を使用することを望んでいることを示しています。
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サーバは、クライアントのIDとサーバオペレータによって付与された権限に基づいて、拡張子を選択するためのクライアントの能力を制限することができます。
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.7.1に記載されている[2]。
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.7.2に記載されている[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.7.3に記載されている[2]。
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:
このようなインターネットドメイン名のマッピング[10]、などのいくつかのEPPオブジェクトマッピングは、オブジェクトと（パスワードなど）の認証情報を関連付ける要素を含みます。認証情報をサポートする任意のオブジェクトマッピングのためのスキーマは、認証情報の複数のフォームを指定するのに十分に柔軟であるべきです。 XMLスキーマ（[4]及び[5]）で、これは<任意>要素情報項目を含む要素の選択を提供することによって達成することができます。
<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の強力な機能ですが、それはまた、貧弱な設計上の意思決定を行うために、複数の機会を提供しています。そこ単一のタスクを達成するには、いくつかの異なる方法が一般的であり、すべてが「働く」ことながら、他の人が与えられたタスクを完了するよりも、（「仕事」のいくつかの定義について）1つの拡張形式は、通常、より適切であろう。以下の一連のステップは、拡張の問題を解決するために、適切な拡張形式を選択するために従うことができます。
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オブジェクトレベルの拡張子：あなたの要件を満たすように拡張することができます既存のオブジェクトのマッピングが存在しない場合は、新しいオブジェクトのマッピングを開発することを検討してください。拡張フォームを検討する際に依頼する2番目の質問は、このようです：
Can the task be accomplished using the existing EPP command and
response structures applied to a new object?
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 developing new protocol commands, responses, or other structures. The third and final question to ask when considering an extension form is thus:
Oプロトコルレベルの拡張は：そこにあなたの要件を満たすように拡張することができます既存のオブジェクトのマッピングはありませんし、既存のEPPコマンドとレスポンスの構造が不足している場合は、新しいプロトコルコマンド、応答、または他の構造の開発を検討してください。拡張フォームを検討する際に依頼する3番目と最後の質問はこれです：
Can the task be accomplished by adding new EPP commands,
responses, or other structures applied to new or existing
objects?
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.
IETF○：オブジェクトのマッピングおよびその他の拡張は、RFCとインターネットドラフトに記載されています。
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.
XML.org [17] O：XML.orgは、複数の産業で使用するためのスキーマ定義を含むXMLアーカイブを維持します。
o Other archives are likely in the future. Consult your favorite Internet search engine for additional resources.
Oその他のアーカイブは、将来的に可能性があります。追加のリソースのためのお気に入りのインターネット検索エンジンを参照してください。
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 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は、[14] UTF-8 [13]及びUTF-16の両方を認識するように準拠パーサを必要とする、[3]はXMLで表現されています。他の文字エンコーディングのサポートも可能です。 EPP拡張はRFC 2277に記載された文字セットおよび言語の使用にEPPコアプロトコル仕様[2]及びIETFポリシーに記載の国際化の考慮事項の両方を遵守しなければならない[9]。
This memo has no direct impact on the IANA. Guidelines for extensions that require IANA action are described in Section 2.2.1.
このメモはIANAに直接的な影響を及ぼしません。 IANAのアクションを必要とする機能拡張のためのガイドラインは、2.2.1項で説明されています。
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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[2]ホレンベック、S.、 "拡張プロビジョニングプロトコル（EPP）"、RFC 3730、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]ブレイ、T.、パオリ、J.、Sperberg-マックィーン、C.およびE. MALER、 "拡張マークアップ言語（XML）1.0（第2版）"、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]トンプソン、H.、ブナ、D.、マロニー、M.およびN.メンデルゾーン、 "XMLスキーマパート1：構造"、W3C REC-XMLSCHEMA-1、2001年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]ビロン、P.およびA.マルホトラ、 "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]ブレイ、T.、オランダ、D.およびA.素人、 "XMLで名前空間"、W3C REC-XML-名、1999年1月、<http://www.w3.org/TR/REC-xml-名前>。
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7]バーナーズ=リー、T.、フィールディング、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.、BCP 18、RFC 2277 "文字セットと言語のIETF方針"、1998年1月。
[10] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", RFC 3731, March 2004.
[10]ホレンベック、S.、 "拡張プロビジョニングプロトコル（EPP）ドメイン名のマッピング"、RFC 3731、2004年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]ホレンベック、S.、ローズ、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]ホレンベック、S.、 "拡張可能なプロビジョニングプロトコルE.164番号のマッピング"、進歩、2003年2月での作業。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[13] Yergeau、F.、 "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]ホフマン、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.
、BCP 72、RFC 3552、2003年7月[15]レスコラ、E.とB.コーバー、 "セキュリティの考慮事項の書き方RFCテキストのためのガイドライン"。
[16] <http://oasis-open.org/>
「１６」 ＜ｈっｔｐ：／／おあしｓーおぺん。おｒｇ／＞
[17] <http://xml.org/>
「１７」 ＜ｈっｔｐ：／／ｘｍｌ。おｒｇ／＞
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
スコットホレンベックベリサイン社21345 Ridgetopサークルダレス、バージニア州20166から6503 USA
EMail: shollenbeck@verisign.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。