RFC3735 日本語訳
3735 Guidelines for Extending the Extensible Provisioning Protocol(EPP). S. Hollenbeck. March 2004. (Format: TXT=27326 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hollenbeck Request for Comments: 3735 VeriSign, Inc. Category: Informational March 2004
Hollenbeckがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3735年のベリサインInc.カテゴリ: 情報の2004年3月
Guidelines for Extending the Extensible Provisioning Protocol (EPP)
広げることができる食糧を供給することを広げるためのガイドラインは議定書を作ります。(エップ)
Status of this Memo
この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)インターネット協会(2004)。 All rights reserved。
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.
Extensible Provisioningプロトコル(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. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 本書では使用されるコンベンション。 . . . . . . . . . . 2 2. プロトコル拡大. . . . . . . . . . . . . . 3 2.1のプリンシプルズ。 拡大. . . . . . . . . . . . . . . . 3 2.2を記録します。 拡大. . . . . . . . . . . . . . . . 4 2.2.1を特定します。 規格は拡大. . . . . . . . . . 4 2.2.2を追跡します。 他の拡大. . . . . . . . . . . . . . . 5 2.3。 拡大発表と選択. . . . . . . . . 5 2.4。 プロトコルレベル拡大. . . . . . . . . . . . . . . 7 2.5。 オブジェクトレベル拡大. . . . . . . . . . . . . . . . 7 2.6。 コマンド応答拡大. . . . . . . . . . . . . . 7 2.7。 認証情報拡張子. . . . . . . . . 7 3。 拡張機能. . . . . . . . . . . . . . 8 3.1を選択します。 マッピングと拡大アーカイブ. . . . . . . . . . . 9 4。 国際化問題. . . . . . . . . . . . 9 5。 IANA問題. . . . . . . . . . . . . . . . . . . . 10 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . 10 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1。 引用規格. . . . . . . . . . . . . . . . . 10
Hollenbeck Informational [Page 1] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[1ページ]のRFC3735ガイドライン
7.2. Informative References . . . . . . . . . . . . . . . . 11
8. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
7.2. 有益な参照. . . . . . . . . . . . . . . . 11 8。 URI. . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 12 10。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
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:
Extensible Provisioningプロトコル、(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 Schema([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インスタンスと例を解釈しなければなりません。
1.1. Conventions Used In This Document
1.1. 本書では使用されるコンベンション
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
Hollenbeck Informational [Page 2] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[2ページ]のRFC3735ガイドライン
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:」 系列はプロトコルサーバで戻りました。表す、刻み目と白いスペースは、例に提供しますが、要素関係を例証して、この仕様のREQUIREDの特徴ではありません。
2. Principles of Protocol Extension
2. プロトコル拡大のプリンシプルズ
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拡大モデルがどんな>要素にも<を使用することでワイルドカード図式の部品のXML表現に基づいている、情報項目、([4])と.2のセクション3.10XML名前空間[6]で説明されるように。 このセクションは、詳細にプロトコル拡大の開発のためのガイドラインを提供して、拡大モデルについて説明します。
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では、変化が既存の図式の拡大ではなく、既存の図式の新しいバージョンをもたらしているかもしれない間、それは、拡大が既存のプロトコル図式を変更してはいけないことを意味します。 例えば、デザイナーは、新しい要素を既存の図式に追加して、結果をプロトコルの「拡大」と呼んではいけません。 結果が新しくaである、非後方に、コンパチブル、既存の図式のバージョン。 拡大は有効なプロトコル拡大であると考えられるためにこのセクションで説明された原則を固く守らなければなりません。
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拡張子ができるのを確実にします。 RFC3470[11]でIETFプロトコル(その結果、拡大デザイナーにとって、良い情報)におけるXMLの使用のためのガイドラインを見つけることができます。
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.
デザイナーは、また、拡大自体が広げることができるかもしれないのを覚えていなければなりません。 拡大の良いチェーンはプロトコルschemasが一般的な機能性から、より特定(恐らくさらに限られさえしたさえ)の機能性に発展するものです。
2.1. Documenting Extensions
2.1. 拡大を記録します。
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]には、ドキュメントプロトコル拡張子に提案されたアウトラインを含む付録があります。 彼らが話題のすべてがテンプレートに記載した最小のアドレスで発作、しかし、拡大ドキュメントSHOULDを見るとき、デザイナーは自由にこのテンプレートかいかなる他の形式も使用できます。
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ドキュメントとして記録されるかもしれません、意図している成熟レベル(情報の、そして、提案された規格など)は広げられていることに主によりますが
Hollenbeck Informational [Page 3] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[3ページ]のRFC3735ガイドライン
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.
彼らが閉じている環境における操作のために意図するか、または限られた聴衆のために別の方法で意図するなら、インターネット草稿かRFCが記録するように拡大は発行される必要はありません。 そのような場合拡大は対象とする訪問者にとって、適切なファイルと構造的な形式で記録されるかもしれません。
2.2. Identifying Extensions
2.2. 拡大を特定します。
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.
Uniform Resource Identifierによって特定されて、EPP拡張子は唯一そうです。(RFC2396[7])で定義されたURI。 また、拡大に関連しているXML名前空間を特定するのに拡大を特定するのに使用されるURIを使用しなければなりません。 どんな有効なURIもEPP拡張子を特定するのに使用されるかもしれません、URI形式(Uniform Resource Locator(URL)対親類などに対して階層的なUniform Resource Name(URN))の選択ですが SHOULDは変化コントロールの組織的な方針などの要素と固執のためのリソースと要件の場所を見つけることの間のバランスに依存します。 拡大名前空間は複数の拡張機能について説明するかもしれません、新しいプロトコル機能、オブジェクト、または要素の定義などのように、名前空間を定義するのに使用される図式の中で。
The following are sample extension-identifying URIs:
↓これはサンプル拡大特定URIです:
urn:ietf:params:xml:ns:foo-ext1
つぼ:ietf:params:xml:ナノ秒: 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自体は、拡大を改訂するか、またはアップデートするとき変化する必要があるでしょう。
2.2.1. Standards Track Extensions
2.2.1. 標準化過程拡大
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構文仕様と登録手順に従わなければなりません。
Hollenbeck Informational [Page 4] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[4ページ]のRFC3735ガイドライン
2.2.2. Other Extensions
2.2.2. 他の拡大
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はRFC2396で説明されたURI構文仕様に従わなければなりません。
2.3. Extension Announcement and Selection
2.3. 拡大発表と選択
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バージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>S: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1インチS:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Sと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: epp-1.0秒間:、」 epp-1.0.xsd、「>S:」 <挨拶>S: <svID>Example EPPサーバepp.example.com</svID>S: <svDate>2000-06-08T22:00:00.0Z</svDate>S: <svcMenu>S: <バージョン>1.0</バージョン>S: <lang>アン</lang>S: <lang>fr</lang>S: <objURI>つぼ:ietf:params: xml:ナノ秒:obj1</objURI>S: <objURI>つぼ:ietf:params: xml:ナノ秒:obj2</objURI>S: <objURI>つぼ:ietf:params: xml:ナノ秒:obj3</objURI>S: <svcExtension>S: <extURI>つぼ:ietf:params: xml:ナノ秒:foo-ext1</extURI>S: <extURI>http://習慣/obj1ext-1.0</extURI>S: </svcExtension>S: </svcMenu>S: <dcp>S: すべての/></がアクセスする<アクセス><、>S: <声明>S: <目的><アドミン/><prov/></目的>S: <受取人><、私たちのもの、/><公衆/></受取人>S: <保有><は/></保有>Sを述べました: </声明>S: </dcp>S: </挨拶>S: </epp>。
In the example above, the server is announcing the availability of two extensions:
例では、上では、サーバが2つの拡大の有用性を発表しています:
Hollenbeck Informational [Page 5] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[5ページ]のRFC3735ガイドライン
urn:ietf:params:xml:ns:foo-ext1, and
そしてつぼ:ietf:params: xml:ナノ秒: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バージョン=「=「UTF-8インチのスタンドアロン=」ノー、をコード化する1インチ」?>C: <epp xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: epp1インチC:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "Cと等しいです: xsi: schemaLocationが等しい、「つぼ:ietf:params: xml:ナノ秒:epp-1.0C:、」 epp-1.0.xsd、「>C:」 <コマンド>C: <ログイン>C: <clID>ClientX</clID>C: <pw>foo-BAR2</pw>C: FOO2</newPWを禁じている<newPW>>C: <オプション>C: <バージョン>1.0</バージョン>C: <lang>アン</lang>C: </オプション>C: <svcs>C: <objURI>つぼ:ietf:params: xml:ナノ秒:obj1</objURI>C: <objURI>つぼ:ietf:params: xml:ナノ秒:obj2</objURI>C: <objURI>つぼ:ietf:params: xml:ナノ秒:obj3</objURI>C: <svcExtension>C: <extURI>http://習慣/obj1ext-1.0</extURI>C: </svcExtension>C: </svcs>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.
例では、上では、クライアントが、<ログイン>命令の無事終了のときに確立されたセッションの間に 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サーバはクライアントのアイデンティティに基づく拡大とサーバオペレータによって与えられた承認を選択するクライアントの能力を制限するかもしれません。
Hollenbeck Informational [Page 6] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[6ページ]のRFC3735ガイドライン
2.4. Protocol-level Extension
2.4. プロトコルレベル拡大
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はクライアント/サーバコマンド応答相互作用のために1セットの構造を定義しますが、追加構造はプロトコルに追加されるかもしれません。 新しい構造定義は構造への必要な機能性を定義する図式を定義して、唯一オブジェクト名前空間と図式を特定するためにURIを割り当てる問題です。 特定のプロトコルレベル拡張機能は.1のセクション2.7EPPコアプロトコル仕様[2]で説明されます。
2.5. Object-level Extension
2.5. オブジェクトレベル拡大
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を割り当てる問題です。 特定のオブジェクトレベル拡張機能は.2のセクション2.7EPPコアプロトコル仕様[2]で説明されます。
2.6. Command-Response Extension
2.6. コマンド応答拡大
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]を表すドメイン名の食糧を供給するのに必要な状態でインターネットドメイン名の食糧を供給する一般的な機能性について説明するオブジェクトマッピングは含まれている追加コマンドと応答要素まで広げることができます。 特定のコマンド応答拡張機能は.3のセクション2.7EPPコアプロトコル仕様[2]で説明されます。
2.7. Authentication Information Extension
2.7. 認証情報拡張子
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オブジェクトマッピングが、認証情報(パスワードなどの)をオブジェクトに関連づけるために要素を含んでいます。 どんなオブジェクトのための認証情報がSHOULDであるとサポートする図式も写像されて、複数のフォームに関する認証情報を指定するほどフレキシブルであってください。 XML Schema([4]と[5])で、どんな>要素情報の品目も<を含んでいる要素選択に提供することによって、これを達成できます:
<any namespace="##other"/>
「<、どんな名前空間も」 ##もう一方」 />と等しいです。
Hollenbeck Informational [Page 7] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[7ページ]のRFC3735ガイドライン
3. Selecting an Extension Mechanism
3. 拡張機能を選択します。
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
o プロトコルレベル拡大: あなたの要件を満たすために広げることができるどんな既存のオブジェクトマッピングもなくて、既存のEPPコマンドと応答構造が不十分であるなら、考えてください。
Hollenbeck Informational [Page 8] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[8ページ]のRFC3735ガイドライン
developing new protocol commands, responses, or other structures.
The third and final question to ask when considering an extension
form is thus:
新しいプロトコルコマンド、応答、または非重要構造を発生します。 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.
ここに記載された拡大書式と決定ポイントは複雑さの順に提示されます。 利用可能な拡大オプションの熟慮なしで拡大フォームを選択すると、機能性の少しも利得なしで複雑さを加えることができます。
3.1. Mapping and Extension Archives
3.1. マッピングと拡大アーカイブ
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: オブジェクトマッピングと他の拡大はRFCsとインターネット草稿で記録されました。
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 XML登録」[8]にIETFによって使用されたIANA XML登録に、説明されます。
o OASIS [16]: OASIS maintains an XML archive containing schema
definitions for use in the business applications of XML.
o オアシス[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 他のアーカイブは将来、ありそうです。 追加リソースのためにお気に入りのインターネット検索エンジンに相談してください。
4. Internationalization Considerations
4. 国際化問題
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]に表されます。(XMLはUTF-8[13]とUTF-16[14]の両方を認識するためにパーサを従わせるのを必要とします)。 また、他の文字符号化のサポートも可能です。 EPP拡張子は見なければなりません。
Hollenbeck Informational [Page 9] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[9ページ]のRFC3735ガイドライン
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]とIETF方針で説明された両方のInternationalization ConsiderationsはRFCで2277[9]について説明しました。
5. IANA Considerations
5. IANA問題
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で説明されます。
6. Security Considerations
6. セキュリティ問題
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拡張子を開発するプロトコルデザイナーは、適切なセキュリティー・サービスを提供できるように彼らの意図している操作環境で面するべき軍事的脅威を意識している必要があります。 RFC3552[15]で適切なSecurity Considerations部に書くためのデザイナーが考えるガイドラインと提案を見つけることができます。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", RFC
3730, March 2004.
2004年のS.、「広げることができる食糧を供給するプロトコル(EPP)」、RFC3730行進の[2]Hollenbeck。
[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、<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.Malhotra、「XML図式第2部:」 「データ型式」(W3C REC-xmlschema-2)は2001、<http://www.w3.org/TR/xmlschema-2/>がそうするかもしれません。
Hollenbeck Informational [Page 10] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[10ページ]のRFC3735ガイドライン
[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>.
「XMLの名前空間」という[6]ロバの鳴き声、T.、オランダ人、D.、およびA.Laymanは1999年1月に<http://www.w3.org/TR/REC-xml名を>にW3C 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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[8] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
[9] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[9]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
7.2. Informative References
7.2. 有益な参照
[10] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain
Name Mapping", RFC 3731, March 2004.
[10]Hollenbeck、S.、「広げることができる食糧を供給するプロトコル(EPP)ドメイン名マッピング」、RFC3731、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.とローズ、M.とL.Masinter、「IETFプロトコルの中の拡張マークアップ言語(XML)の使用のためのガイドライン」BCP70、RFC3470(2003年1月)。
[12] Hollenbeck, S., "Extensible Provisioning Protocol E.164 Number
Mapping", Work in Progress, February 2003.
[12] S.、「広げることができる食糧を供給しているプロトコルE.164数のマッピング」というHollenbeckは進歩、2003年2月に働いています。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[13]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変化形式」RFC2279。
[14] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646",
RFC 2781, February 2000.
[14] ホフマン、P.とF.Yergeau、「UTF-16、ISO10646のコード化」RFC2781、2000年2月。
[15] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
Security Considerations", BCP 72, RFC 3552, July 2003.
[15] レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
8. URIs
8. URI
[16] <http://oasis-open.org/>
[16] <http://オアシス-open.org/>。
[17] <http://xml.org/>
[17] <http://xml.org/>。
Hollenbeck Informational [Page 11] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[11ページ]のRFC3735ガイドライン
9. Author's Address
9. 作者のアドレス
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
スコットHollenbeckベリサインInc.21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: shollenbeck@verisign.com
メール: shollenbeck@verisign.com
Hollenbeck Informational [Page 12] RFC 3735 Guidelines for Extending the EPP March 2004
2004年のEPP行進のときに広がるためのHollenbeckの情報[12ページ]のRFC3735ガイドライン
10. Full Copyright Statement
10. 完全な著作権宣言文
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)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hollenbeck Informational [Page 13]
Hollenbeck情報です。[13ページ]
一覧
スポンサーリンク
