[要約] RFC 8544は、EPP（Extensible Provisioning Protocol）のための組織拡張機能を定義しています。このRFCの目的は、EPPを使用してドメイン名やIPアドレスなどのリソースを管理する際に、組織情報を効果的に扱うための拡張機能を提供することです。
Internet Engineering Task Force (IETF) L. Zhou
Request for Comments: 8544 CNNIC
Category: Standards Track N. Kong
ISSN: 2070-1721 Consultant
J. Wei
J. Yao
CNNIC
J. Gould
VeriSign, Inc.
April 2019
Organization Extension for the Extensible Provisioning Protocol (EPP)
Extensible Provisioning Protocol（EPP）の組織拡張
Abstract
概要
This document describes an extension to Extensible Provisioning Protocol (EPP) object mappings that is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects.
このドキュメントでは、既存のオブジェクト（ドメイン、ホスト、連絡先）および将来のオブジェクトへの組織の割り当てをサポートするように設計されたExtensible Provisioning Protocol（EPP）オブジェクトマッピングの拡張機能について説明します。
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/rfc8544.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8544で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Organization Identifier . . . . . . . . . . . . . . . . . 4
4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4
4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4
4.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 4
4.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 4
4.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 8
4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8
4.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 8
4.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 10
4.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 10
4.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 11
4.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 11
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Internationalization Considerations . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 18
7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
There are many entities, such as registrars, resellers, DNS service operators, and privacy proxies, involved in the domain registration business. These kinds of entities are supported in the Extensible Provisioning Protocol (EPP) by the "organization" entities in [RFC8543]. This document provides a way to associate any EPP object such as domain names in [RFC5731], hosts in [RFC5732], and contacts in [RFC5733] to "organization" entities in [RFC8543]. The examples provided in this document are used for the domain object for illustration purposes. The host and contact object could be extended in the same way as the domain object.
レジストラ、リセラー、DNSサービスオペレータ、プライバシープロキシなど、ドメイン登録ビジネスに関わる多くのエンティティがあります。これらの種類のエンティティは、[RFC8543]の「組織」エンティティによってExtensible Provisioning Protocol（EPP）でサポートされています。このドキュメントは、[RFC5731]のドメイン名、[RFC5732]のホスト、[RFC5733]の連絡先などのEPPオブジェクトを[RFC8543]の「組織」エンティティに関連付ける方法を提供します。このドキュメントで提供されている例は、説明の目的でドメインオブジェクトに使用されています。ホストおよび連絡先オブジェクトは、ドメインオブジェクトと同じ方法で拡張できます。
Organization object identifiers, defined in [RFC8543], MUST be known to the server before the organization object can be associated with the EPP object.
[RFC8543]で定義されている組織オブジェクト識別子は、組織オブジェクトをEPPオブジェクトに関連付ける前に、サーバーに認識されていなければなりません（MUST）。
This document is specified using XML 1.0 as described in [W3C.REC-xml-20081126] and XML Schema notation as described in [W3C.REC-xmlschema-1-20041028] and [W3C.REC-xmlschema-2-20041028].
このドキュメントは、[W3C.REC-xml-20081126]で説明されているXML 1.0と、[W3C.REC-xmlschema-1-20041028]および[W3C.REC-xmlschema-2-20041028]で説明されているXMLスキーマ表記を使用して指定されます。
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]で説明されているように解釈されます。
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 are provided only to illustrate element relationships and are not a required feature of this specification.
例では、「C：」はプロトコルクライアントによって送信された行を表し、「S：」はプロトコルサーバーによって返された行を表します。例のインデントと空白は、要素の関係を示すためにのみ提供されており、この仕様の必須機能ではありません。
XML is case sensitive. Unless stated otherwise, XML specifications and examples provided in this document MUST be interpreted in the character case presented.
XMLでは大文字と小文字が区別されます。特に明記しない限り、このドキュメントで提供されるXMLの仕様と例は、提示された大文字と小文字を区別して解釈する必要があります。
The XML namespace prefix "orgext" is used for the namespace "urn:ietf:params:xml:ns:epp:orgext-1.0", but implementations MUST NOT depend on it; instead, they should employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.
名前空間「urn：ietf：params：xml：ns：epp：orgext-1.0」には、XML名前空間接頭辞「orgext」が使用されますが、実装はそれに依存してはなりません。代わりに、適切な名前空間を認識するXMLパーサーとシリアライザーを使用して、XMLドキュメントを解釈および出力する必要があります。
This extension adds additional elements to EPP object mappings such as the EPP domain name mapping [RFC5731]. Only the new elements are described here.
この拡張機能は、EPPドメイン名マッピング[RFC5731]などのEPPオブジェクトマッピングに要素を追加します。ここでは、新しい要素のみを説明します。
The organization identifier provides the ID of an organization. Its corresponding element is <orgext:id>, which refers to the <org:id> element defined in [RFC8543]. All organization objects are identified by a server-unique identifier. A "role" attribute is used to represent the relationship that the organization has to the EPP object. Any given object MUST have at most one associated organization ID for any given role value.
組織識別子は、組織のIDを提供します。対応する要素は<orgext：id>であり、[RFC8543]で定義されている<org：id>要素を参照します。すべての組織オブジェクトは、サーバー固有の識別子によって識別されます。 「役割」属性は、組織とEPPオブジェクトとの関係を表すために使用されます。指定されたオブジェクトは、指定されたロール値に対して最大で1つの関連する組織IDを持つ必要があります。
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for assigning organizations to EPP objects.
EPP構文とセマンティクスの詳細な説明は、EPPコアプロトコル仕様[RFC5730]にあります。ここで説明するコマンドマッピングは、特に組織をEPPオブジェクトに割り当てるためのものです。
EPP provides three commands to retrieve EPP object information: <check> to determine if an object can be provisioned within a repository, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.
EPPは、EPPオブジェクト情報を取得するための3つのコマンドを提供します。<check>は、オブジェクトをリポジトリ内でプロビジョニングできるかどうかを決定し、<info>はオブジェクトに関連付けられた詳細情報を取得し、<transfer>はオブジェクト転送ステータス情報を取得します。
This extension does not add any elements to the EPP <check> command or <check> response described in the EPP object mapping.
この拡張機能は、EPPオブジェクトマッピングで説明されているEPP <check>コマンドまたは<check>応答に要素を追加しません。
This extension does not add any elements to the EPP <info> command described in the EPP object mapping. However, additional elements are defined for the <info> response in the EPP object mapping.
この拡張機能は、EPPオブジェクトマッピングで説明されているEPP <info>コマンドに要素を追加しません。ただし、EPPオブジェクトマッピングの<info>応答には追加の要素が定義されています。
When an <info> command has been processed successfully, the EPP <resData> element MUST contain child elements as described in the EPP object extensions. In addition, the EPP <extension> element SHOULD contain a child <orgext:infData> element. This element is returned if the object has data that is associated with this extension and that is based on server policy. This element or its ancestor element MUST identify the extension namespace "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:infData> element contains the following child elements:
<info>コマンドが正常に処理された場合、EPPオブジェクト拡張で説明されているように、EPP <resData>要素には子要素が含まれている必要があります。さらに、EPP <extension>要素には、子<orgext：infData>要素を含める必要があります（SHOULD）。この要素が返されるのは、オブジェクトに、この拡張機能に関連付けられ、サーバーポリシーに基づくデータがある場合です。この要素またはその祖先要素は、拡張名前空間「urn：ietf：params：xml：ns：epp：orgext-1.0」を識別する必要があります。 <orgext：infData>要素には、次の子要素が含まれます。
o Zero or more <orgext:id> elements are allowed that contain the identifier of the organization, as defined in Section 3.1. The "role" attribute is used to represent the relationship that the organization has to the object. See Section 7.3 of [RFC8543] for a list of values.
o セクション3.1で定義されているように、組織の識別子を含む0個以上の<orgext：id>要素が許可されます。 「ロール」属性は、組織とオブジェクトとの関係を表すために使用されます。値のリストについては、[RFC8543]のセクション7.3を参照してください。
Example <info> response for an authorized client with multiple
organizations:
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 lang="en-US">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>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="billing">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: </domain:ns>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>2015-02-06T04:01:21.0Z</domain:crDate>
S: <domain:exDate>2018-02-06T04:01:21.0Z</domain:exDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <orgext:infData
S: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
S: <orgext:id role="reseller">reseller1523</orgext:id>
S: <orgext:id role="privacyproxy">proxy2935</orgext:id>
S: </orgext:infData>
S: </extension>
S: <trID>
S: <clTRID>ngcl-IvJjzMZc</clTRID>
S: <svTRID>test142AWQONJZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example <info> response for an authorized client with no
organization:
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 lang="en-US">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>example.com</domain:name>
S: <domain:roid>EXAMPLE1-REP</domain:roid>
S: <domain:status s="ok"/>
S: <domain:registrant>jd1234</domain:registrant>
S: <domain:contact type="admin">sh8013</domain:contact>
S: <domain:contact type="billing">sh8013</domain:contact>
S: <domain:contact type="tech">sh8013</domain:contact>
S: <domain:ns>
S: <domain:hostObj>ns1.example.com</domain:hostObj>
S: </domain:ns>
S: <domain:clID>ClientX</domain:clID>
S: <domain:crID>ClientY</domain:crID>
S: <domain:crDate>2015-02-06T04:01:21.0Z</domain:crDate>
S: <domain:exDate>2018-02-06T04:01:21.0Z</domain:exDate>
S: <domain:authInfo>
S: <domain:pw>2fooBAR</domain:pw>
S: </domain:authInfo>
S: </domain:infData>
S: </resData>
S: <extension>
S: <orgext:infData
S: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"/>
S: </extension>
S: <trID>
S: <clTRID>ngcl-IvJjzMZc</clTRID>
S: <svTRID>test142AWQONJZ</svTRID>
S: </trID>
S: </response>
S:</epp>
An EPP error response MUST be returned if an <info> command cannot be processed for any reason.
何らかの理由で<info>コマンドを処理できない場合は、EPPエラー応答を返す必要があります。
This extension does not add any elements to the EPP <transfer> query command or <transfer> query response described in the EPP object mapping.
この拡張機能は、EPPオブジェクトマッピングで説明されているEPP <転送>クエリコマンドまたは<転送>クエリ応答に要素を追加しません。
EPP provides five commands to transform EPP 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 the object sponsorship changes, and <update> to change information associated with an object.
EPPは、EPPオブジェクトを変換する5つのコマンドを提供します。<create>はオブジェクトのインスタンスを作成し、<delete>はオブジェクトのインスタンスを削除し、<renew>はオブジェクトの有効期間を延長し、<transfer>はオブジェクトを管理しますスポンサーシップが変更され、<update>がオブジェクトに関連付けられた情報を変更します。
This extension defines additional elements for the EPP <create> command described in the EPP object extensions. No additional elements are defined for the EPP <create> response.
この拡張は、EPPオブジェクト拡張で説明されているEPP <create>コマンドの追加要素を定義します。 EPP <create>応答には追加の要素は定義されていません。
The EPP <create> command provides a transform operation that allows a client to create an object. In addition to the EPP command elements described in the EPP object extensions, the command MUST contain an <extension> element, and the <extension> element MUST contain a child <orgext:create> element. This element is used if the client wants to associate data defined in this extension to the object. This element or its ancestor element MUST identify the extension namespace "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:create> element contains the following child elements:
EPP <create>コマンドは、クライアントがオブジェクトを作成できるようにする変換操作を提供します。 EPPオブジェクト拡張で説明されているEPPコマンド要素に加えて、コマンドには<extension>要素を含める必要があり、<extension>要素には子<orgext：create>要素を含める必要があります。この要素は、クライアントがこの拡張で定義されたデータをオブジェクトに関連付けたい場合に使用されます。この要素またはその祖先要素は、拡張名前空間「urn：ietf：params：xml：ns：epp：orgext-1.0」を識別する必要があります。 <orgext：create>要素には、次の子要素が含まれます。
o One or more <orgext:id> elements that contain the identifier of the organization, as defined in Section 3.1. The "role" attribute is used to represent the relationship that the organization has to the object. See Section 7.3 of [RFC8543] for a list of values.
o セクション3.1で定義されている、組織の識別子を含む1つ以上の<orgext：id>要素。 「ロール」属性は、組織とオブジェクトとの関係を表すために使用されます。値のリストについては、[RFC8543]のセクション7.3を参照してください。
Example <create> command with only one organization:
組織が1つだけの<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>example.com</domain:name>
C: <domain:period unit="y">3</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: </domain:ns>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:contact type="billing">sh8013</domain:contact>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <orgext:create
C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
C: <orgext:id role="reseller">reseller1523</orgext:id>
C: </orgext:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <create> command with multiple organizations:
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>example.com</domain:name>
C: <domain:period unit="y">3</domain:period>
C: <domain:ns>
C: <domain:hostObj>ns1.example.com</domain:hostObj>
C: </domain:ns>
C: <domain:registrant>jd1234</domain:registrant>
C: <domain:contact type="tech">sh8013</domain:contact>
C: <domain:contact type="billing">sh8013</domain:contact>
C: <domain:contact type="admin">sh8013</domain:contact>
C: <domain:authInfo>
C: <domain:pw>fooBAR</domain:pw>
C: </domain:authInfo>
C: </domain:create>
C: </create>
C: <extension>
C: <orgext:create
C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
C: <orgext:id role="reseller">reseller1523</orgext:id>
C: <orgext:id role="privacyproxy">proxy2935</orgext:id>
C: </orgext:create>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When a <create> command has been processed successfully, the EPP response is as described in the EPP object extension.
<create>コマンドが正常に処理されると、EPP応答はEPPオブジェクト拡張で説明されているとおりになります。
An EPP error response MUST be returned if a <create> command cannot be processed for any reason.
<create>コマンドが何らかの理由で処理できない場合は、EPPエラー応答を返す必要があります。
This extension does not add any elements to the EPP <delete> command or <delete> response described in the EPP object mapping.
この拡張機能は、EPPオブジェクトマッピングで説明されているEPP <delete>コマンドまたは<delete>応答に要素を追加しません。
This extension does not add any elements to the EPP <renew> command or <renew> response described in the EPP object mapping.
この拡張機能は、EPPオブジェクトマッピングで説明されているEPP <renew>コマンドまたは<renew>応答に要素を追加しません。
This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the EPP object mapping, but after a successful transfer of an object with an assigned organization, the handling of the assigned organization is dependent on the organization roles and server policy.
この拡張機能は、EPPオブジェクトのマッピングで説明されているEPP <転送>コマンドまたは<転送>応答に要素を追加しませんが、割り当てられた組織でオブジェクトが正常に転送された後、割り当てられた組織の処理は組織に依存します役割とサーバーポリシー。
This extension defines additional elements for the EPP <update> command described in the EPP domain mapping [RFC5731], host mapping [RFC5732], and contact mapping [RFC5733]. No additional elements are defined for the EPP <update> response.
この拡張機能は、EPPドメインマッピング[RFC5731]、ホストマッピング[RFC5732]、および連絡先マッピング[RFC5733]で説明されているEPP <update>コマンドの追加要素を定義します。 EPP <update>応答には追加の要素は定義されていません。
The EPP <update> command provides a transform operation that allows a client to modify the attributes of an object. In addition to the EPP <update> command elements, the command MUST contain an <extension> element, and the <extension> element MUST contain a child <orgext:update> element. This element is used if the client wants to update the object with data defined in this extension. This element or its ancestor element MUST identify the extension namespace "urn:ietf:params:xml:ns:epp:orgext-1.0". The <orgext:update> element contains the following child elements:
EPP <update>コマンドは、クライアントがオブジェクトの属性を変更できるようにする変換操作を提供します。 EPP <update>コマンド要素に加えて、コマンドには<extension>要素が含まれている必要があり、<extension>要素には子<orgext：update>要素が含まれている必要があります。この要素は、クライアントがこの拡張で定義されたデータでオブジェクトを更新する場合に使用されます。この要素またはその祖先要素は、拡張名前空間「urn：ietf：params：xml：ns：epp：orgext-1.0」を識別する必要があります。 <orgext：update>要素には、次の子要素が含まれます。
o An OPTIONAL <orgext:add> element that contains one or more <orgext:id> elements, as defined in Section 3.1, that add nonexistent organization roles to the object. The <orgext:id> element MUST have a non-empty organization identifier value. The server SHOULD validate that the <orgext:id> element role does not exist.
o オブジェクトに存在しない組織の役割を追加する、セクション3.1で定義されている1つ以上の<orgext：id>要素を含むオプションの<orgext：add>要素。 <orgext：id>要素には、空でない組織識別子の値が必要です。サーバーは、<orgext：id>要素の役割が存在しないことを検証する必要があります（SHOULD）。
o An OPTIONAL <orgext:rem> element that contains one or more <orgext:id> elements, as defined in Section 3.1, that remove organization roles from the object. The <orgext:id> element MAY have an empty organization identifier value. The server SHOULD validate the existence of the <orgext:id> element role and the organization identifier if provided.
o セクション3.1で定義されているように、オブジェクトから組織の役割を削除する1つ以上の<orgext：id>要素を含むオプションの<orgext：rem>要素。 <orgext：id>要素には、空の組織識別子の値が含まれる場合があります。サーバーは、<orgext：id>要素の役割の存在と、提供されている場合は組織識別子を検証する必要があります（SHOULD）。
o An OPTIONAL <orgext:chg> element that contains one or more <orgext:id> elements, as defined in Section 3.1, that change organization role identifiers for the object. The existing organization identifier value will be replaced for the defined role. The server SHOULD validate the existence of the <orgext:id> element role.
o オブジェクトの組織の役割識別子を変更する、セクション3.1で定義されている1つ以上の<orgext：id>要素を含むオプションの<orgext：chg>要素。定義された役割の既存の組織ID値が置き換えられます。サーバーは、<orgext：id>要素の役割の存在を検証する必要があります（SHOULD）。
At least one <orgext:add>, <orgext:rem>, or <orgext:chg> element MUST be provided.
少なくとも1つの<orgext：add>、<orgext：rem>、または<orgext：chg>要素を指定する必要があります。
Example <update> command, adding a reseller:
リセラーを追加する<update>コマンドの例：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <orgext:update
C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
C: <orgext:add>
C: <orgext:id role="reseller">reseller1523</orgext:id>
C: </orgext:add>
C: </orgext:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> command, adding multiple organizations:
複数の組織を追加する<update>コマンドの例：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <orgext:update
C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
C: <orgext:add>
C: <orgext:id role="reseller">reseller1523</orgext:id>
C: <orgext:id role="privacyproxy">proxy2935</orgext:id>
C: </orgext:add>
C: </orgext:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> command, removing a reseller:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <orgext:update
C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
C: <orgext:rem>
C: <orgext:id role="reseller"/>
C: </orgext:rem>
C: </orgext:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> command, removing multiple organizations:
<update>コマンドの例、複数の組織を削除：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <orgext:update
C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
C: <orgext:rem>
C: <orgext:id role="reseller"/>
C: <orgext:id role="privacyproxy"/>
C: </orgext:rem>
C: </orgext:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> command, updating reseller identifier:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <orgext:update
C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
C: <orgext:chg>
C: <orgext:id role="reseller">reseller1523</orgext:id>
C: </orgext:chg>
C: </orgext:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example <update> command, updating multiple organization identifiers:
複数の組織識別子を更新する<update>コマンドの例：
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <update>
C: <domain:update
C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
C: <domain:name>example.com</domain:name>
C: </domain:update>
C: </update>
C: <extension>
C: <orgext:update
C: xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0">
C: <orgext:chg>
C: <orgext:id role="reseller">reseller1523</orgext:id>
C: <orgext:id role="privacyproxy">proxy2935</orgext:id>
C: </orgext:chg>
C: </orgext:update>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
When an extended <update> command has been processed successfully,
the EPP response is as described in the EPP object extension.
An EPP error response MUST be returned if an <update> command cannot be processed for any reason. An attempt to add one organization ID or multiple organization IDs with a particular role value when at least one of them already exists does not change the object at all. A server SHOULD notify clients that object relationships exist by sending a 2305 error response code. An attempt to remove an organization ID or multiple organization IDs with a particular role value when at least one of them does not exist does not change the object at all. A server SHOULD notify clients that object relationships do not exist by sending a 2305 error response code. An attempt to change an organization ID or multiple organization IDs with a particular role value when at least one of them does not exist does not change the object at all. A server SHOULD notify clients that object relationships do not exist by sending a 2305 error response code. Response format with error value elements is defined in Section 2.6 of [RFC5730].
何らかの理由で<update>コマンドを処理できない場合は、EPPエラー応答を返す必要があります。 1つ以上の組織IDを特定のロール値で追加しようとしても、それらの少なくとも1つがすでに存在している場合、オブジェクトはまったく変更されません。サーバーは、2305エラー応答コードを送信して、オブジェクト関係が存在することをクライアントに通知する必要があります（SHOULD）。少なくとも1つの組織IDが存在しない場合に、特定のロール値を持つ組織IDまたは複数の組織IDを削除しようとしても、オブジェクトはまったく変更されません。サーバーは、2305エラー応答コードを送信して、オブジェクト関係が存在しないことをクライアントに通知する必要があります（SHOULD）。少なくとも1つが存在しない場合に、特定のロール値を持つ組織IDまたは複数の組織IDを変更しようとしても、オブジェクトはまったく変更されません。サーバーは、2305エラー応答コードを送信して、オブジェクト関係が存在しないことをクライアントに通知する必要があります（SHOULD）。エラー値要素を含む応答形式は、[RFC5730]のセクション2.6で定義されています。
An EPP object mapping is specified in XML Schema notation. 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スキーマ表記で指定されます。ここに示す正式な構文は、EPP XMLインスタンスの自動検証に適したオブジェクトマッピングの完全なスキーマ表現です。 BEGINタグとENDタグはスキーマの一部ではありません。これらは、URI登録の目的でスキーマの開始と終了を示すために使用されます。
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="urn:ietf:params:xml:ns:epp:orgext-1.0"
xmlns:orgext="urn:ietf:params:xml:ns:epp:orgext-1.0"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
>
<annotation>
<documentation>
Extensible Provisioning Protocol v1.0
Organization Extension Schema v1.0
</documentation>
</annotation>
<!-- Child elements found in EPP commands -->
<element
name="create"
type="orgext:createType"/>
<element
name="update"
type="orgext:updateType"/>
<!--
Organization identifier with required role
-->
<complexType name="orgIdType">
<simpleContent>
<extension base="token">
<attribute
name="role"
type="token"
use="required"/>
</extension>
</simpleContent>
</complexType>
<!--
Child elements of the <orgext:create> command.
All elements must be present at time of creation.
-->
<complexType name="createType">
<sequence>
<!-- Agent identifier or the organization,
e.g., registrar, reseller, privacy proxy, etc. -->
<element
name="id"
type="orgext:orgIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!--
Child elements of <orgext:update> command
-->
<complexType name="updateType">
<sequence>
<element
name="add"
type="orgext:addRemChgType"
minOccurs="0"
/>
<element
name="rem"
type="orgext:addRemChgType"
minOccurs="0"
/>
<element
name="chg"
type="orgext:addRemChgType"
minOccurs="0"
/>
</sequence>
</complexType>
<complexType name="addRemChgType">
<sequence>
<!-- Agent identifier of the organization,
e.g., registrar, reseller, privacy proxy, etc. -->
<element
name="id"
type="orgext:orgIdType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!-- Child response element -->
<element
name="infData"
type="orgext:infDataType"/>
<!-- <orgext:infData> response elements -->
<complexType name="infDataType">
<sequence>
<!-- Agent identifier the organization,
e.g., registrar, reseller, privacy proxy, etc. -->
<element
name="id"
type="orgext:orgIdType"
minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
<!-- End of schema -->
</schema>
END
EPP is represented in XML, which provides native support for encoding information using the Unicode character set [UNICODE] and its more compact representations, including UTF-8. Conformant XML processors recognize both UTF-8 [RFC3629] and UTF-16 [RFC2781]. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is RECOMMENDED.
EPPはXMLで表されます。これは、Unicode文字セット[UNICODE]とUTF-8を含むそのよりコンパクトな表現を使用して情報をエンコードするためのネイティブサポートを提供します。適合XMLプロセッサは、UTF-8 [RFC3629]とUTF-16 [RFC2781]の両方を認識します。 XMLには、<？xml？>宣言で「エンコーディング」属性を使用して他の文字エンコーディングを識別および使用するための規定が含まれていますが、UTF-8の使用が推奨されています。
As an extension of the EPP object mapping, the elements and element content described in this document MUST inherit the internationalization conventions used to represent higher-layer domain and core protocol structures present in an XML instance that includes this extension.
EPPオブジェクトマッピングの拡張として、このドキュメントで説明されている要素と要素のコンテンツは、この拡張を含むXMLインスタンスに存在する上位層ドメインとコアプロトコル構造を表すために使用される国際化規則を継承する必要があります。
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. IANA has assigned the following URI.
このドキュメントでは、URNを使用して、[RFC3688]で説明されているレジストリメカニズムに準拠するXML名前空間とXMLスキーマについて説明します。 IANAは次のURIを割り当てました。
The organization extension namespace:
組織拡張の名前空間：
URI: urn:ietf:params:xml:ns:epp:orgext-1.0
Registrant Contact: IESG
登録者の連絡先：IESG
XML: None. Namespace URIs do not represent an XML specification.
XML：なし。名前空間URIはXML仕様を表していません。
The organization XML schema:
組織のXMLスキーマ：
URI: urn:ietf:params:xml:schema:epp:orgext-1.0
Registrant Contact: IESG
登録者の連絡先：IESG
XML: See the "Formal Syntax" section of RFC 8544 (this document).
XML：RFC 8544（このドキュメント）の「正式な構文」セクションを参照してください。
The EPP extension described in this document has been registered by IANA in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry described in [RFC7451]. The details of the registration are as follows:
このドキュメントで説明されているEPP拡張機能は、[RFC7451]で説明されている "Extensions for the Extensible Provisioning Protocol（EPP）"レジストリにIANAによって登録されています。登録内容は以下のとおりです。
Name of Extension: Organization Extension for the Extensible Provisioning Protocol (EPP)
拡張機能の名前：Extensible Provisioning Protocol（EPP）の組織拡張機能
Document Status: Standards Track
ドキュメントのステータス：標準化過程
Reference: RFC 8544
リファレンス：RFC 8544
Registrant Name and Email Address: IESG, iesg@ietf.org
登録者名とメールアドレス：IESG、iesg @ ietf.org
TLDs: Any
TLD：任意
IPR Disclosure: None
IPR開示：なし
Status: Active
ステータス：アクティブ
Notes: None
注：なし
The object mapping extension described in this document does not provide any other security services or introduce any additional considerations beyond those described by [RFC5730], [RFC5731], [RFC5732], and [RFC5733] or those caused by the protocol layers used by EPP.
このドキュメントで説明されているオブジェクトマッピング拡張機能は、他のセキュリティサービスを提供せず、[RFC5730]、[RFC5731]、[RFC5732]、および[RFC5733]で説明されているもの、またはEPPで使用されるプロトコルレイヤーによって引き起こされるものを超える追加の考慮事項を導入しません。 。
[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>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[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 >。
[RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, August 2009, <https://www.rfc-editor.org/info/rfc5732>.
[RFC5732] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）Host Mapping」、STD 69、RFC 5732、DOI 10.17487 / RFC5732、2009年8月、<https://www.rfc-editor.org/info/rfc5732> 。
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, <https://www.rfc-editor.org/info/rfc5733>.
[RFC5733] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）Contact Mapping」、STD 69、RFC 5733、DOI 10.17487 / RFC5733、2009年8月、<https://www.rfc-editor.org/info/rfc5733> 。
[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>。
[UNICODE] The Unicode Consortium, "The Unicode Standard", <http://www.unicode.org/versions/latest/>.
[UNICODE] Unicodeコンソーシアム、「The Unicode Standard」、<http://www.unicode.org/versions/latest/>。
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <https://www.w3.org/TR/xml/>.
[W3C.REC-xml-20081126] Bray、T.、Paoli、J.、Sperberg-McQueen、C.、Maler、E。、およびF. Yergeau、「Extensible Markup Language（XML）1.0（Fifth Edition）」、 World Wide Web Consortium Recommendation REC-xml-20081126、2008年11月、<https://www.w3.org/TR/xml/>。
[W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-1-20041028] Thompson、H.、Beech、D.、Maloney、M。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、World Wide Web Consortium Recommendation REC-xmlschema -1-20041028、2004年10月、<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>。
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-xmlschema-2-20041028] Biron、P.およびA. Malhotra、「XML Schema Part 2：Datatypes Second Edition」、World Wide Web Consortium Recommendation REC-xmlschema-2-20041028、2004年10月、<http： //www.w3.org/TR/2004/REC-xmlschema-2-20041028>。
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", RFC 2781, DOI 10.17487/RFC2781, February 2000, <https://www.rfc-editor.org/info/rfc2781>.
[RFC2781] Hoffman、P。およびF. Yergeau、「UTF-16、ISO 10646のエンコーディング」、RFC 2781、DOI 10.17487 / RFC2781、2000年2月、<https://www.rfc-editor.org/info/ rfc2781>。
[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>。
[RFC8543] Zhou, L., Kong, N., Yao, J., Gould, J., and G. Zhou, "Extensible Provisioning Protocol (EPP) Organization Mapping", RFC 8543, DOI 10.17487/RFC8543, March 2019, <https://www.rfc-editor.org/info/rfc8543>.
[RFC8543] Zhou、L.、Kong、N.、Yao、J.、Gould、J。、およびG. Zhou、「Extensible Provisioning Protocol（EPP）Organization Mapping」、RFC 8543、DOI 10.17487 / RFC8543、2019年3月、 <https://www.rfc-editor.org/info/rfc8543>。
Acknowledgments
謝辞
The authors would like to thank Rik Ribbers, Marc Groeneweg, Patrick Mevzek, Antoin Verschuren, and Scott Hollenbeck for their careful review and valuable comments.
著者は、慎重なレビューと貴重なコメントを提供してくれたRik Ribbers、Marc Groeneweg、Patrick Mevzek、Antoin Verschuren、Scott Hollenbeckに感謝します。
Authors' Addresses
著者のアドレス
Linlin Zhou CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China
Lin Lin Zhou CNNIC 4 South 4TH street、Z Macro Village、H Short Point District Beijing、Beijing 100190 China
Email: zhoulinlin@cnnic.cn
Ning Kong Consultant
ニンコンコンサルタント
Email: ietfing@gmail.com
Junkai Wei CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China
Junkai Wei CNNIC 4 south 4TH street、Z Macro Village、H Short Point District Beijing、Beijing 100190 China
Email: weijunkai@cnnic.cn
Jiankang Yao CNNIC 4 South 4th Street, Zhongguancun, Haidian District Beijing, Beijing 100190 China
J i安康Y AO CNNIC 4南4THストリート、Zマクロビレッジ、Hショートポイント地区北京、北京100190中国
Email: yaojk@cnnic.cn
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