[要約] RFC 8495は、EPP（Extensible Provisioning Protocol）のためのAllocation Token拡張機能に関するものであり、ドメイン名やIPアドレスなどのリソースの割り当てに使用されるトークンの機能を拡張することを目的としています。
Internet Engineering Task Force (IETF) J. Gould
Request for Comments: 8495 VeriSign, Inc.
Category: Standards Track K. Feher
ISSN: 2070-1721 Neustar
November 2018
Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
Extensible Provisioning Protocol（EPP）の割り当てトークン拡張
Abstract
概要
This document describes an Extensible Provisioning Protocol (EPP) extension for including an Allocation Token in "query" and "transform" commands. The Allocation Token is used as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer".
このドキュメントでは、「query」コマンドと「transform」コマンドに割り当てトークンを含めるためのExtensible Provisioning Protocol（EPP）拡張について説明します。割り当てトークンは、「作成」や「転送」などのEPP変換コマンドの1つを使用して、サーバーに特定のオブジェクトの割り当てをリクエストすることをクライアントに許可する資格情報として使用されます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8495.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8495で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Allocation Token . . . . . . . . . . . . . . . . . . . . 4
3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4
3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4
3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 4
3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 8
3.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 10
3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 11
3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 11
3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 12
3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 12
3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 12
3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 13
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Allocation Token Extension Schema . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15
5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, which is an extension to EPP object mappings similar to the EPP domain name mapping [RFC5731], supports passing an Allocation Token as a credential that authorizes a client to request the allocation of a specific object from the server using one of the EPP transform commands, including "create" and "transfer".
このドキュメントでは、Extensible Provisioning Protocol（EPP）[RFC5730]のバージョン1.0の拡張マッピングについて説明します。このマッピングは、EPPドメイン名マッピング[RFC5731]と同様のEPPオブジェクトマッピングの拡張であり、クライアントがEPPの1つを使用してサーバーから特定のオブジェクトの割り当てをリクエストすることを許可する資格情報として割り当てトークンを渡すことをサポートします「作成」および「転送」を含む変換コマンド。
Allocation is when a server assigns the sponsoring client of an object based on the use of an Allocation Token credential. Examples include allocating a registration based on a pre-eligibility Allocation Token, allocating a premium domain name registration based on an auction Allocation Token, allocating a registration based on a founders Allocation Token, and allocating an existing domain name held by the server or by a different sponsoring client based on an Allocation Token that is passed with a transfer command.
割り当てとは、サーバーが割り当てトークンの資格情報の使用に基づいてオブジェクトのスポンサークライアントを割り当てる場合です。例には、事前適格割り当てトークンに基づく登録の割り当て、オークション割り当てトークンに基づくプレミアムドメイン名登録の割り当て、ファウンダー割り当てトークンに基づく登録の割り当て、サーバーまたはサーバーが保持する既存のドメイン名の割り当てが含まれます。転送コマンドで渡される割り当てトークンに基づく別のスポンサークライアント。
Clients pass an Allocation Token to the server for validation, and the server determines if the supplied Allocation Token is one supported by the server. It is up to server policy which EPP transform commands and which objects require the Allocation Token. The Allocation Token MAY be returned to an authorized client for passing out-of-band to a client that uses it with an EPP transform command.
クライアントは検証のために割り当てトークンをサーバーに渡し、サーバーは提供された割り当てトークンがサーバーによってサポートされているものであるかどうかを判断します。どのEPP変換コマンドとどのオブジェクトが割り当てトークンを必要とするかは、サーバーポリシー次第です。割り当てトークンは、EPP変換コマンドでそれを使用するクライアントに帯域外を渡すために、許可されたクライアントに返される場合があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.
XMLでは大文字と小文字が区別されます。特に明記しない限り、このドキュメントで提供されるXMLの仕様と例は、準拠する実装を開発するために、大文字と小文字を区別して解釈する必要があります。
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Indentation and white space in the examples are provided only to illustrate element relationships and are not REQUIRED in the protocol.
例では、「C：」はプロトコルクライアントによって送信された行を表し、「S：」はプロトコルサーバーによって返された行を表します。例のインデントと空白は、要素の関係を示すためにのみ提供されており、プロトコルでは必要ありません。
The XML namespace prefix "allocationToken" is used for the namespace "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.
名前空間「urn：ietf：params：xml：ns：allocationToken-1.0」にはXML名前空間接頭辞「allocationToken」が使用されますが、実装はこれに依存してはならず、適切な名前空間対応XMLパーサーとシリアライザを使用して解釈し、 XMLドキュメントを出力します。
The "abc123" token value is used as a placeholder value in the examples. The server MUST support token values that follow the Security Considerations (Section 6).
例では、「abc123」トークン値がプレースホルダー値として使用されています。サーバーは、セキュリティの考慮事項（セクション6）に従うトークン値をサポートする必要があります。
The domain-object attribute values, including the "2fooBAR" <domain:pw> value, in the examples are provided for illustration purposes only. Refer to [RFC5731] for details on the domain-object attributes.
例にある「2fooBAR」<domain：pw>値を含むドメインオブジェクト属性値は、説明のみを目的として提供されています。ドメインオブジェクト属性の詳細については、[RFC5731]を参照してください。
This extension adds additional elements to EPP object mappings similar to the EPP domain name mapping [RFC5731]. Only those new elements are described here.
この拡張機能は、EPPドメイン名マッピング[RFC5731]と同様の要素をEPPオブジェクトマッピングに追加します。ここでは、それらの新しい要素のみを説明します。
The Allocation Token is a simple XML "token" type. The exact format of the Allocation Token is up to server policy. The server MAY have the Allocation Token for each object to match against the Allocation Token passed by the client to authorize the allocation of the object. The <allocationToken:allocationToken> element is used for all of the supported EPP commands as well as the info response. If the supplied Allocation Token passed to the server does not apply to the object, the server MUST return an EPP error result code of 2201.
割り当てトークンは、単純なXML「トークン」タイプです。割り当てトークンの正確な形式は、サーバーポリシー次第です。サーバーは、オブジェクトの割り当てを承認するためにクライアントから渡された割り当てトークンと照合するために、各オブジェクトの割り当てトークンを持っている場合があります。 <allocationToken：allocationToken>要素は、サポートされているすべてのEPPコマンドと情報応答に使用されます。サーバーに渡された割り当てトークンがオブジェクトに適用されない場合、サーバーは2201のEPPエラー結果コードを返す必要があります。
Authorization information, similar to what is defined in the EPP domain name mapping [RFC5731], is associated with objects to facilitate transfer operations. The authorization information is assigned when an object is created. The Allocation Token and the authorization information are both credentials but are used for different purposes and in different ways. The Allocation Token is used to facilitate the allocation of an object instead of transferring the sponsorship of the object. The Allocation Token is not managed by the client but is validated by the server to authorize assigning the initial sponsoring client of the object.
EPPドメイン名マッピング[RFC5731]で定義されているものと同様の承認情報は、転送操作を容易にするためにオブジェクトに関連付けられています。許可情報は、オブジェクトの作成時に割り当てられます。割り当てトークンと承認情報はどちらも資格情報ですが、さまざまな目的でさまざまな方法で使用されます。割り当てトークンは、オブジェクトのスポンサーシップを転送する代わりに、オブジェクトの割り当てを容易にするために使用されます。割り当てトークンはクライアントによって管理されませんが、オブジェクトの初期スポンサークライアントの割り当てを承認するためにサーバーによって検証されます。
An example <allocationToken:allocationToken> element with value of "abc123":
値が「abc123」の<allocationToken：allocationToken>要素の例：
<allocationToken:allocationToken xmlns:allocationToken=
"urn:ietf:params:xml:ns:allocationToken-1.0">
abc123
</allocationToken:allocationToken>
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730].
EPP構文とセマンティクスの詳細な説明は、EPPコアプロトコル仕様[RFC5730]にあります。
EPP provides three commands to retrieve object information: <check> to determine if an object can be provisioned, <info> to retrieve information associated with an object, and <transfer> to retrieve object-transfer status information.
EPPは、オブジェクト情報を取得するための3つのコマンドを提供します。オブジェクトをプロビジョニングできるかどうかを判断する<check>、オブジェクトに関連付けられた情報を取得する<info>、オブジェクト転送ステータス情報を取得する<transfer>です。
This extension defines additional elements to extend the EPP <check> command of an object mapping similar to the mapping specified in [RFC5731].
この拡張は、[RFC5731]で指定されたマッピングと同様のオブジェクトマッピングのEPP <check>コマンドを拡張するための追加要素を定義します。
This extension allows clients to check the availability of an object with an Allocation Token, as described in Section 2.1. Clients can check if an object can be created using the Allocation Token. The Allocation Token is applied to all object names included in the EPP <check> command.
セクション2.1で説明されているように、この拡張機能により、クライアントは割り当てトークンを使用してオブジェクトの可用性を確認できます。クライアントは、割り当てトークンを使用してオブジェクトを作成できるかどうかを確認できます。割り当てトークンは、EPP <check>コマンドに含まれるすべてのオブジェクト名に適用されます。
The following is an example <check> command for the allocation.example domain name using the <allocationToken:allocationToken> extension with the allocation token of 'abc123':
以下は、割り当てトークンが「abc123」の<allocationToken：allocationToken>拡張を使用した、allocation.exampleドメイン名の<check>コマンドの例です。
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <check>
C: <domain:check
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>allocation.example</domain:name>
C: </domain:check>
C: </check>
C: <extension>
C: <allocationToken:allocationToken
C: xmlns:allocationToken=
C: "urn:ietf:params:xml:ns:allocationToken-1.0">
C: abc123
C: </allocationToken:allocationToken>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
If the query was successful, the server replies with a <check> response providing the availability status of the queried object based on the following Allocation Token cases where the object is otherwise available:
クエリが成功した場合、サーバーは<check>応答で応答し、オブジェクトが他の方法で利用可能な次の割り当てトークンのケースに基づいて、クエリされたオブジェクトの可用性ステータスを提供します。
1. If an object requires an Allocation Token and the Allocation Token does apply to the object, then the server MUST return the availability status as available (e.g., the "avail" attribute is "1" or "true"). 2. If an object requires an Allocation Token and the Allocation Token does not apply to the object, then the server SHOULD return the availability status as unavailable (e.g., the "avail" attribute is "0" or "false"). 3. If an object does not require an Allocation Token, the server MAY return the availability status as available (e.g., the "avail" attribute is "1" or "true").
1. オブジェクトが割り当てトークンを必要とし、割り当てトークンがオブジェクトに適用される場合、サーバーは可用性ステータスを利用可能として返す必要があります（たとえば、「avail」属性が「1」または「true」）。 2.オブジェクトが割り当てトークンを必要とし、割り当てトークンがオブジェクトに適用されない場合、サーバーは可用性ステータスを利用不可として返す必要があります（たとえば、「avail」属性が「0」または「false」）。 3.オブジェクトが割り当てトークンを必要としない場合、サーバーは可用性ステータスを利用可能として返すことができます（たとえば、「avail」属性が「1」または「true」）。
The following is an example <check> domain response for a <check> command using the <allocationToken:allocationToken> extension:
以下は、<allocationToken：allocationToken>拡張を使用した<check>コマンドの<check>ドメイン応答の例です。
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg lang="en-US">Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:chkData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:cd>
S: <domain:name avail="1">allocation.example</domain:name>
S: </domain:cd>
S: </domain:chkData>
S: </resData>
S: <trID>
S: <clTRID>ABC-DEF-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
The following is an example <check> command with the
<allocationToken:allocationToken> extension for the
allocation.example and allocation2.example domain names.
Availability of allocation.example and allocation2.example domain
names are based on the Allocation Token 'abc123':
C:<?xml version="1.0" encoding="UTF-8"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <check>
C: <domain:check
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>allocation.example</domain:name>
C: <domain:name>allocation2.example</domain:name>
C: </domain:check>
C: </check>
C: <extension>
C: <allocationToken:allocationToken
C: xmlns:allocationToken=
C: "urn:ietf:params:xml:ns:allocationToken-1.0">
C: abc123
C: </allocationToken:allocationToken>
C: </extension>
C: <clTRID>ABC-DEF-12345</clTRID>
C: </command>
C:</epp>
The following is an example <check> domain response for multiple
domain names in the <check> command using the
<allocationToken:allocationToken> extension, where the Allocation
Token 'abc123' matches allocation.example but does not match
allocation2.example:
S:<?xml version="1.0" encoding="UTF-8"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg lang="en-US">Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:chkData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:cd>
S: <domain:name avail="1">allocation.example</domain:name>
S: </domain:cd>
S: <domain:cd>
S: <domain:name avail="0">allocation2.example</domain:name>
S: <domain:reason>Allocation Token mismatch</domain:reason>
S: </domain:cd>
S: </domain:chkData>
S: </resData>
S: <trID>
S: <clTRID>ABC-DEF-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
This extension does not add any elements to the EPP <check> response described in [RFC5730].
この拡張機能は、[RFC5730]で説明されているEPP <check>応答に要素を追加しません。
This extension defines additional elements to extend the EPP <info> command of an object mapping similar to the mapping specified in [RFC5731].
この拡張は、[RFC5731]で指定されたマッピングと同様のオブジェクトマッピングのEPP <info>コマンドを拡張するための追加要素を定義します。
The EPP <info> command allows a client to request information associated with an existing object. Authorized clients MAY retrieve the Allocation Token (Section 2.1) along with the other object information by supplying the <allocationToken:info> element in the command. The <allocationToken:info> element is an empty element that serves as a marker to the server to return the <allocationToken:allocationToken> element in the info response. If the client is not authorized to receive the Allocation Token, the server MUST return an EPP error result code of 2201. If the client is authorized to receive the Allocation Token, but there is no Allocation Token associated with the object, the server MUST return an EPP error result code of 2303. The authorization is subject to server policy.
EPP <info>コマンドを使用すると、クライアントは既存のオブジェクトに関連付けられている情報を要求できます。承認されたクライアントは、コマンドで<allocationToken：info>要素を指定することにより、他のオブジェクト情報と共に割り当てトークン（セクション2.1）を取得できます（MAY）。 <allocationToken：info>要素は、サーバーへのマーカーとして機能し、情報応答で<allocationToken：allocationToken>要素を返す空の要素です。クライアントが割り当てトークンの受信を承認されていない場合、サーバーは2201のEPPエラー結果コードを返す必要があります。クライアントが割り当てトークンの受信を承認されているが、オブジェクトに関連付けられている割り当てトークンがない場合、サーバーは返す必要があります。 EPPエラー結果コード2303。認証にはサーバーポリシーが適用されます。
The following is an example <info> command with the allocationToken:info extension for the allocation.example domain name:
次は、allocation.exampleドメイン名のallocationToken：info拡張を使用した<info>コマンドの例です。
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <info>
C: <domain:info
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>allocation.example</domain:name>
C: </domain:info>
C: </info>
C: <extension>
C: <allocationToken:info
C: xmlns:allocationToken=
C: "urn:ietf:params:xml:ns:allocationToken-1.0"/>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
If the query was successful, the server replies with an <allocationToken:allocationToken> element along with the regular EPP <resData>. The <allocationToken:allocationToken> element is described in Section 2.1.
クエリが成功した場合、サーバーは通常のEPP <resData>とともに<allocationToken：allocationToken>要素で応答します。 <allocationToken：allocationToken>要素については、セクション2.1で説明します。
The following is an example <info> domain response using the <allocationToken:allocationToken> extension:
以下は、<allocationToken：allocationToken>拡張を使用した<info>ドメイン応答の例です。
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <resData>
S: <domain:infData
S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
S: <domain:name>allocation.example</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="pendingCreate"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <allocationToken:allocationToken
S: xmlns:allocationToken=
S: "urn:ietf:params:xml:ns:allocationToken-1.0">
S: abc123
S: </allocationToken:allocationToken>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
This extension does not add any elements to the EPP <transfer> query command or <transfer> query response described in [RFC5730].
この拡張機能は、[RFC5730]で説明されているEPP <転送>クエリコマンドまたは<転送>クエリ応答に要素を追加しません。
EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.
EPPは、オブジェクトを変換する5つのコマンドを提供します。<create>はオブジェクトのインスタンスを作成し、<delete>はオブジェクトのインスタンスを削除し、<renew>はオブジェクトの有効期間を延長し、<transfer>はオブジェクトのスポンサーシップの変更を管理します、および<update>は、オブジェクトに関連付けられた情報を変更します。
This extension defines additional elements to extend the EPP <create> command of an object mapping similar to the mapping specified in [RFC5731].
この拡張は、[RFC5731]で指定されたマッピングと同様のオブジェクトマッピングのEPP <create>コマンドを拡張するための追加要素を定義します。
The EPP <create> command provides a transform operation that allows a client to create an instance of an object. In addition to the EPP command elements described in an object mapping similar to the mapping specified in [RFC5731], the command MUST contain a child <allocationToken:allocationToken> element for the client to be authorized to create and allocate the object. If the Allocation Token does not apply to the object, the server MUST return an EPP error result code of 2201.
EPP <create>コマンドは、クライアントがオブジェクトのインスタンスを作成できるようにする変換操作を提供します。 [RFC5731]で指定されたマッピングと同様のオブジェクトマッピングで説明されているEPPコマンド要素に加えて、コマンドには、クライアントがオブジェクトの作成と割り当てを許可される子<allocationToken：allocationToken>要素が含まれている必要があります。割り当てトークンがオブジェクトに適用されない場合、サーバーはEPPエラー結果コード2201を返す必要があります。
The following is an example <create> command to create a domain object with an Allocation Token:
次に、割り当てトークンを使用してドメインオブジェクトを作成する<create>コマンドの例を示します。
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <create>
C: <domain:create
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>allocation.example</domain:name>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <allocationToken:allocationToken
C: xmlns:allocationToken=
C: "urn:ietf:params:xml:ns:allocationToken-1.0">
C: abc123
C: </allocationToken:allocationToken>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
This extension does not add any elements to the EPP <create> response described in [RFC5730].
この拡張機能は、[RFC5730]で説明されているEPP <create>応答に要素を追加しません。
This extension does not add any elements to the EPP <delete> command or <delete> response described in [RFC5730].
この拡張機能は、[RFC5730]で説明されているEPP <delete>コマンドまたは<delete>応答に要素を追加しません。
This extension does not add any elements to the EPP <renew> command or <renew> response described in [RFC5730].
この拡張機能は、[RFC5730]で説明されているEPP <renew>コマンドまたは<renew>応答に要素を追加しません。
This extension defines additional elements to extend the EPP <transfer> command of an object mapping similar to the mapping specified in [RFC5731].
この拡張は、[RFC5731]で指定されたマッピングと同様のオブジェクトマッピングのEPP <transfer>コマンドを拡張するための追加要素を定義します。
The EPP <transfer> command provides a transform operation that allows a client to request the transfer of an object. In addition to the EPP command elements described in an object mapping similar to the mapping specified in [RFC5731], the command MUST contain a child <allocationToken:allocationToken> element for the client to be authorized to transfer and allocate the object. The authorization associated with the Allocation Token is in addition to, and does not replace, the authorization mechanism defined for the object's <transfer> command. If the Allocation Token is invalid or not required for the object, the server MUST return an EPP error result code of 2201.
EPP <転送>コマンドは、クライアントがオブジェクトの転送を要求できるようにする変換操作を提供します。 [RFC5731]で指定されたマッピングと同様のオブジェクトマッピングで説明されているEPPコマンド要素に加えて、コマンドには、クライアントがオブジェクトの転送と割り当てを許可されるための子<allocationToken：allocationToken>要素が含まれている必要があります。割り当てトークンに関連付けられている承認は、オブジェクトの<transfer>コマンドに定義されている承認メカニズムに追加され、それに代わるものではありません。割り当てトークンが無効であるか、オブジェクトに必要でない場合、サーバーはEPPエラー結果コード2201を返さなければなりません（MUST）。
The following is an example <transfer> command to allocate the domain object with the Allocation Token:
以下は、割り当てトークンを使用してドメインオブジェクトを割り当てる<transfer>コマンドの例です。
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <transfer op="request">
C: <domain:transfer
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example1.tld</domain:name>
C: <domain:period unit="y">1</domain:period>
C: <domain:authInfo>
C: <domain:pw>2fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:transfer>
C: </transfer>
C: <extension>
C: <allocationToken:allocationToken
C: xmlns:allocationToken=
C: "urn:ietf:params:xml:ns:allocationToken-1.0">
C: abc123
C: </allocationToken:allocationToken>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
This extension does not add any elements to the EPP <transfer> response described in [RFC5730].
この拡張機能は、[RFC5730]で説明されているEPP <転送>応答に要素を追加しません。
This extension does not add any elements to the EPP <update> command or <update> response described in [RFC5730].
この拡張機能は、[RFC5730]で説明されているEPP <update>コマンドまたは<update>応答に要素を追加しません。
One schema is presented here: the EPP Allocation Token Extension schema.
ここに1つのスキーマを示します。EPP割り当てトークン拡張スキーマです。
The formal syntax presented here is a complete schema representation of the object mapping suitable for automated validation of EPP XML instances. The BEGIN and END tags are not part of the schema; they are used to note the beginning and ending of the schema for URI registration purposes.
ここに示す正式な構文は、EPP XMLインスタンスの自動検証に適したオブジェクトマッピングの完全なスキーマ表現です。 BEGINタグとENDタグはスキーマの一部ではありません。これらは、URI登録の目的でスキーマの開始と終了を示すために使用されます。
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:allocationToken="urn:ietf:params:xml:ns:allocationToken-1.0"
targetNamespace="urn:ietf:params:xml:ns:allocationToken-1.0"
elementFormDefault="qualified">
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
Allocation Token Extension
</documentation>
</annotation>
<!-- Element used in info command to get allocation token. -->
<element name="info">
<complexType>
<complexContent>
<restriction base="anyType" />
</complexContent>
</complexType>
</element>
<!-- Allocation Token used in transform
commands and info response -->
<element name="allocationToken"
type="allocationToken:allocationTokenType" />
<simpleType name="allocationTokenType">
<restriction base="token">
<minLength value="1" />
</restriction>
</simpleType>
<!-- End of schema. -->
</schema>
END
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688].
このドキュメントでは、URNを使用して、[RFC3688]で説明されているレジストリメカニズムに準拠するXML名前空間とXMLスキーマについて説明します。
The allocationToken namespace has been registered as follows.
allocationTokenネームスペースは以下のように登録されています。
URI: urn:ietf:params:xml:ns:allocationToken-1.0 Registrant Contact: IESG XML: None. Namespace URIs do not represent an XML specification.
URI：urn：ietf：params：xml：ns：allocationToken-1.0登録者の連絡先：IESG XML：なし。名前空間URIはXML仕様を表していません。
The allocationToken XML schema has been registered as follows.
allocationToken XMLスキーマは以下のように登録されています。
URI: urn:ietf:params:xml:schema:allocationToken-1.0 Registrant Contact: IESG XML: See the "Formal Syntax" section of this document.
URI：urn：ietf：params：xml：schema：allocationToken-1.0登録者の連絡先：IESG XML：このドキュメントの「正式な構文」セクションをご覧ください。
The following entry has been added to the Extensions for the Extensible Provisioning Protocol (EPP) registry, as described in [RFC7451].
[RFC7451]で説明されているように、Extensible Provisioning Protocol（EPP）レジストリの拡張機能に次のエントリが追加されました。
Name of Extension: Allocation Token Extension for the Extensible Provisioning Protocol (EPP)
拡張機能の名前：Extensible Provisioning Protocol（EPP）の割り当てトークン拡張機能
Document Status: Standards Track
ドキュメントのステータス：標準化過程
Reference: RFC 8495
リファレンス：RFC 8495
Registrant: IESG <iesg@ietf.org>
TLDs: Any
TLD：任意
IPR Disclosure: None
IPR開示：なし
Status: Active
ステータス：アクティブ
Notes: None
注：なし
The mapping described in this document does not provide any security services beyond those described by EPP [RFC5730] and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.
このドキュメントで説明されているマッピングは、EPP [RFC5730]およびEPPで使用されるプロトコルレイヤーで説明されているものを超えるセキュリティサービスを提供しません。これらの他の仕様で説明されているセキュリティの考慮事項は、この仕様にも適用されます。
The mapping acts as a conduit for the passing of Allocation Tokens between a client and a server. The definition of the Allocation Token SHOULD be defined outside of this mapping. The following are security considerations in the definition and use of an Allocation Token:
マッピングは、クライアントとサーバー間で割り当てトークンを渡すためのパイプとして機能します。割り当てトークンの定義は、このマッピングの外で定義する必要があります（SHOULD）。以下は、割り当てトークンの定義と使用におけるセキュリティの考慮事項です。
1. An Allocation Token should be considered secret information by the client; it SHOULD be protected at rest and MUST be protected in transit. 2. An Allocation Token should be single use, meaning it should be unique per object and per allocation operation. 3. An Allocation Token should have a limited life with some form of expiry in the Allocation Token, if generated by a trusted third party, or with a server-side expiry, if generated by the server. 4. An Allocation Token should use a strong random value if it is based on an unsigned code. 5. An Allocation Token should leverage digital signatures to confirm its authenticity if generated by a trusted third party. 6. An Allocation Token that is signed XML should be encoded (e.g., base64 [RFC4648]) to mitigate server validation issues.
1. 割り当てトークンは、クライアントによって秘密情報と見なされます。安静時に保護する必要があり、輸送中に保護する必要があります。 2.割り当てトークンは使い捨てである必要があります。つまり、オブジェクトごと、および割り当て操作ごとに一意である必要があります。 3.アロケーショントークンは、信頼できるサードパーティによって生成された場合はアロケーショントークンに有効期限があり、サーバーによって生成された場合はサーバー側の有効期限がある、寿命が限られている必要があります。 4.割り当てトークンは、署名されていないコードに基づいている場合、強力なランダム値を使用する必要があります。 5.アロケーショントークンは、デジタル署名を利用して、信頼できるサードパーティによって生成された場合、その信頼性を確認する必要があります。 6.サーバー検証の問題を軽減するために、XMLで署名された割り当てトークンをエンコードする必要があります（例：base64 [RFC4648]）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <https://www.rfc-editor.org/info/rfc5730>.
[RFC5730] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）」、STD 69、RFC 5730、DOI 10.17487 / RFC5730、2009年8月、<https://www.rfc-editor.org/info/rfc5730>。
[RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, <https://www.rfc-editor.org/info/rfc5731>.
[RFC5731] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）Domain Name Mapping」、STD 69、RFC 5731、DOI 10.17487 / RFC5731、2009年8月、<https://www.rfc-editor.org/info/rfc5731 >。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
[RFC7451] Hollenbeck, S., "Extension Registry for the Extensible Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, February 2015, <https://www.rfc-editor.org/info/rfc7451>.
[RFC7451] Hollenbeck、S。、「Extensible Registry for the Extensible Provisioning Protocol」、RFC 7451、DOI 10.17487 / RFC7451、2015年2月、<https://www.rfc-editor.org/info/rfc7451>。
Acknowledgements
謝辞
The authors wish to acknowledge the original concept for this document and the efforts in the initial draft versions of this document by Trung Tran and Sharon Wodjenski.
著者は、このドキュメントの元の概念と、Trung TranおよびSharon Wodjenskiによるこのドキュメントの最初のドラフトバージョンでの取り組みを認めたいと思います。
Special suggestions that have been incorporated into this document were provided by Ben Campbell, Scott Hollenbeck, Benjamin Kaduk, Mirja Kuehlewind, Rubens Kuhl, Alexander Mayrhofer, Patrick Mevzek, Eric Rescoria, and Adam Roach.
このドキュメントに組み込まれている特別な提案は、ベンキャンベル、スコットホレンベック、ベンジャミンカドゥック、ミルジャキューレウィンド、ルーベンスキュール、アレクサンダーマイヤーホーファー、パトリックメヴゼク、エリックレスコリア、アダムローチによって提供されました。
Authors' Addresses
著者のアドレス
James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 United States of America
James Gould VeriSign、Inc. 12061 Bluemont Way Reston、VA 20190アメリカ合衆国
Email: jgould@verisign.com
URI: http://www.verisign.com
Kal Feher Neustar lvl 8/10 Queens Road Melbourne, VIC 3004 Australia
Kal Feher Neustar lvl 8/10 Queens Road Melbourne、VIC 3004 Australia
Email: ietf@feherfamily.org
URI: http://www.neustar.biz