[要約] RFC 3735は、Extensible Provisioning Protocol（EPP）を拡張するためのガイドラインです。このRFCの目的は、EPPの機能を拡張するための手法とベストプラクティスを提供することです。
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.
Copyright（c）The Internet Society（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は、拡張可能なマークアップ言語（XML、[3]）で表され、プロトコル文法の識別に使用されるXML名空間[6]を使用して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をプロビジョニングの問題の解決策と見なしているプロトコル設計者向けに特に書かれていますが、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
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].
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 [7]で定義されているURI）によって一意に識別されます。拡張機能を識別するために使用されるURIは、拡張機能に関連付けられているXML名空間を識別するためにも使用する必要があります。有効なURIはEPP拡張機能を識別するために使用される場合がありますが、URIフォームの選択（ユニフォームリソースロケーター（URL）対ユニフォームリソース名（URN）、階層対相対など）の選択は、組織などの要因に依存する必要があります。変更制御に関するポリシーと、リソースの位置と持続性の要件とのバランス。拡張ネームスペースは、名前空間を定義するために使用されるスキーマ内の新しいプロトコル機能、オブジェクト、または要素の定義など、複数の拡張メカニズムを記述できます。
The following are sample extension-identifying URIs:
以下は、サンプル拡張識別ウリです。
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標準の使用を目的とした拡張機能のURISは、[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標準の使用を目的としていない拡張機能のURISは、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>
In the example above, the server is announcing the availability of two extensions:
上記の例では、サーバーは2つの拡張機能の可用性を発表しています。
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>コマンドには、存在する場合、クライアントがセッション中に使用したい拡張機能を識別する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>
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.
上記の例では、クライアントは、<login>コマンドの正常に完了したときに確立されたセッション中に、http：//custom/obj1ext-1.0 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サーバーは、サーバーオペレーターによって付与されたクライアントの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>要素情報項目を含む要素の選択を提供することで実現できます。
<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?
新しいオブジェクトに適用された既存の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 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?
新しい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およびインターネットドラフトで文書化されています。
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 他のアーカイブは将来的にある可能性があります。追加のリソースについては、お気に入りのインターネット検索エンジンを参照してください。
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はXML [3]で表されています。これは、UTF-8 [13]とUTF-16 [14]の両方を認識するために適合パーサーを必要とします。他のキャラクターエンコーディングのサポートも可能です。EPP拡張機能は、RFC 2277 [9]で説明されている文字セットと言語の使用に関するEPPコアプロトコル仕様[2]に記載されている国際化の考慮事項の両方を観察する必要があります。
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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC 3730, March 2004.
[2] Hollenbeck、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] Bray、T.、Paoli、J.、Sperberg-Mcqueen、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] Thompson、H.、Beech、D.、Maloney、M. and N. Mendelsohn、「XML Schema Part 1：Structures」、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] Biron、P。and A. Malhotra、「XML Schema Part 2：DataTypes」、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。and A. layman、「XMLの名前空間」、W3C Rec-Xml-Names、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。and L. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、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 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] Hollenbeck、S.、Rose、M。and 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] 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] Hoffman、P。and 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。and B. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[16] <http://oasis-open.org/>
[17] <http://xml.org/>
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
Scott Hollenbeck Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 USA
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.
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。