diff options
Diffstat (limited to 'doc/rfc/rfc8748.txt')
| -rw-r--r-- | doc/rfc/rfc8748.txt | 1578 |
1 files changed, 1578 insertions, 0 deletions
diff --git a/doc/rfc/rfc8748.txt b/doc/rfc/rfc8748.txt new file mode 100644 index 0000000..c7fc8cf --- /dev/null +++ b/doc/rfc/rfc8748.txt @@ -0,0 +1,1578 @@ + + + + +Internet Engineering Task Force (IETF) R. Carney +Request for Comments: 8748 GoDaddy Inc. +Category: Standards Track G. Brown +ISSN: 2070-1721 CentralNic Group plc + J. Frakes + March 2020 + + + Registry Fee Extension for the Extensible Provisioning Protocol (EPP) + +Abstract + + Given the expansion of the DNS namespace and the proliferation of + novel business models, it is desirable to provide a method for + Extensible Provisioning Protocol (EPP) clients to query EPP servers + for the fees and credits associated with various billable + transactions and provide expected fees and credits for certain + commands and objects. This document describes an EPP extension + mapping for registry fees. + +Status of This Memo + + This is an Internet Standards Track document. + + 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. + + 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/rfc8748. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +Table of Contents + + 1. Introduction + 1.1. Conventions Used in This Document + 2. Migrating to Newer Versions of This Extension + 3. Extension Elements + 3.1. Client Commands + 3.2. Currency Codes + 3.3. Validity Periods + 3.4. Fees and Credits + 3.4.1. Refunds + 3.4.2. Grace Periods + 3.4.3. Correlation between Refundability and Grace Periods + 3.4.4. Applicability + 3.5. Account Balance + 3.6. Credit Limit + 3.7. Classification of Objects + 3.8. "Phase" and "Subphase" Attributes + 3.9. Reason + 4. Server Handling of Fee Information + 5. EPP Command Mapping + 5.1. EPP Query Commands + 5.1.1. EPP <check> Command + 5.1.2. EPP Transfer Query Command + 5.2. EPP Transform Commands + 5.2.1. EPP <create> Command + 5.2.2. EPP <delete> Command + 5.2.3. EPP <renew> Command + 5.2.4. EPP <transfer> Command + 5.2.5. EPP <update> Command + 6. Formal Syntax + 6.1. Fee Extension Schema + 7. Security Considerations + 8. IANA Considerations + 8.1. XML Namespace + 8.2. EPP Extension Registry + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + Historically, domain name registries have applied a simple fee + structure for billable transactions, namely a basic unit price + applied to domain <create>, <renew>, <transfer>, and Redemption Grace + Period (RGP) [RFC3915] restore commands. Given the relatively small + number of EPP servers to which EPP clients have been required to + connect, it has generally been the case that client operators have + been able to obtain details of these fees out of band by contacting + the server operators. + + Given the expansion of the DNS namespace and the proliferation of + novel business models, it is desirable to provide a method for EPP + clients to query EPP servers for the fees and credits associated with + various billable transactions and certain commands and specific + objects. + + This document describes an extension mapping for version 1.0 of the + Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping + provides a mechanism by which EPP clients may query the fees and + credits associated with various billable transactions and obtain + their current account balance. + +1.1. Conventions Used in This Document + + 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. + + XML is case sensitive. Unless stated otherwise, the XML + specifications and examples provided in this document MUST be + interpreted in the character case presented in order to develop a + conforming implementation. + + "fee" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:fee- + 1.0". The XML namespace prefix "fee" is used, 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. + + In the 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 a required feature of this protocol. + +2. Migrating to Newer Versions of This Extension + + Servers that implement this extension SHOULD provide a way for + clients to progressively update their implementations when a new + version of the extension is deployed. + + Servers SHOULD (for a temporary migration period) provide support for + older versions of the extension in parallel to the newest version and + allow clients to select their preferred version via the + <svcExtension> element of the <login> command. + + If a client requests multiple versions of the extension at login, + then, when preparing responses to commands that do not include + extension elements, the server SHOULD only include extension elements + in the namespace of the newest version of the extension requested by + the client. + + When preparing responses to commands that do include extension + elements, the server SHOULD only include extension elements for the + extension versions present in the command. + +3. Extension Elements + +3.1. Client Commands + + The <fee:command> element is used in the EPP <check> command to + determine the fee that is applicable to the given command. + + The "name" attribute of the <fee:command> is used to define which + transform fees the client is requesting information about. The + possible values for the "name" attribute are: + + * "create", indicating a <create> command as defined in [RFC5730]. + + * "delete", indicating a <delete> command as defined in [RFC5730]. + + * "renew", indicating a <renew> command as defined in [RFC5730]. + + * "update", indicating a <update> command as defined in [RFC5730]. + + * "transfer", indicating a <transfer> command as defined in + [RFC5730]. + + * If the server supports registry grace period mapping [RFC3915], + then the server MUST also support the "restore" value as defined + in [RFC3915]. + + * "custom", indicating a custom command that MUST set the + "customName" attribute with a custom command name. The possible + set of custom command name values is dictated by the server + policy. + + The <fee:command> element MAY have an OPTIONAL "phase" attribute + specifying a launch phase as described in [RFC8334]. It may also + contain an OPTIONAL "subphase" attribute identifying the custom or + subphase as described in [RFC8334]. + +3.2. Currency Codes + + The <fee:currency> element is used to indicate the currency in which + fees are charged. The value of this element MUST be a three- + character currency code from [ISO4217_2015]. + + Note that [ISO4217_2015] provides the special "XXX" code, which MAY + be used if the server uses a non-currency-based system for assessing + fees, such as a system of credits. + + The use of <fee:currency> elements in client commands is OPTIONAL: if + a <fee:currency> element is not present in a command, the server MUST + determine the currency based on the server default currency or on the + client's account settings, which are agreed to by the client and + server via an out-of-band channel. However, the <fee:currency> + element MUST be present in the responses. + + Servers SHOULD NOT perform a currency conversion if a client uses an + incorrect currency code. Servers SHOULD return a 2004 "Parameter + value range error" instead. + +3.3. Validity Periods + + When querying for fee information using the <check> command, the + <fee:period> element is used to indicate the validity period, which + is to be added to extend the registration period of objects by the + <create>, <renew>, and <transfer> commands. Validity periods are + measured in years or months, with the appropriate units specified + using the "unit" attribute. Valid values for the "unit" attribute + are "y" for years and "m" for months. This element is derived from + the <domain:period> element described in [RFC5731]. + + The <fee:period> element is OPTIONAL in <check> commands; if omitted, + the server MUST determine the fee(s) using the server default period. + The <fee:period> element MUST be present in <check> responses. + +3.4. Fees and Credits + + Servers that implement this extension will include elements in + responses that provide information about the fees and/or credits + associated with a given billable transaction. A fee will result in + subtracting from the Account Balance (described in Section 3.5), and + a credit will result in adding to the Account Balance (described in + Section 3.5). + + The <fee:fee> and <fee:credit> elements are used to provide this + information. The presence of a <fee:fee> element in a response + indicates a debit against the client's account balance; a + <fee:credit> element indicates a credit. A <fee:fee> element MUST + have a zero or greater (non-negative) value. A <fee:credit> element + MUST have a negative value. + + A server MAY respond with multiple <fee:fee> and <fee:credit> + elements in the same response. In such cases, the net fee or credit + applicable to the transaction is the arithmetic sum of the values of + each of the <fee:fee> and/or <fee:credit> elements. This amount + applies to the total additional validity period for the object (where + applicable). + + The following attributes are defined for the <fee:fee> element. + These are described in detail below: + + description: an OPTIONAL attribute that provides a human-readable + description of the fee. Servers should provide documentation on + the possible values of this attribute and their meanings. An + OPTIONAL "lang" attribute MAY be present, per the language + structure in [RFC5646], to identify the language of the returned + text and has a default value of "en" (English). If the + "description" attribute is not present, the "lang" attribute can + be ignored. + + refundable: an OPTIONAL boolean attribute indicating whether the fee + is refundable if the object is deleted. + + grace-period: an OPTIONAL attribute that provides the time period + during which the fee is refundable. + + applied: an OPTIONAL attribute indicating when the fee will be + deducted from the client's account. + + The <fee:credit> element can take a "description" attribute as + described above. An OPTIONAL "lang" attribute MAY be present to + identify the language of the returned text and has a default value of + "en" (English). + +3.4.1. Refunds + + <fee:fee> elements MAY have an OPTIONAL "refundable" attribute that + takes a boolean value. Fees may be refunded under certain + circumstances, such as when a domain application is rejected (as + described in [RFC8334]) or when an object is deleted during the + relevant grace period (see Section 3.4.2). + + If the "refundable" attribute is omitted, then clients SHOULD NOT + make any assumptions about the refundability of the fee. + +3.4.2. Grace Periods + + [RFC3915] describes a system of "grace periods", which are time + periods following a billable transaction during which, if an object + is deleted, the client receives a refund. + + The "grace-period" attribute MAY be used to indicate the relevant + grace period for a fee. If a server implements the registry grace + period extension [RFC3915], it MUST specify the grace period for all + relevant transactions. + + If the "grace-period" attribute is omitted, then clients SHOULD NOT + make any assumptions about the grace period of the fee. + +3.4.3. Correlation between Refundability and Grace Periods + + If a <fee:fee> element has a "grace-period" attribute, then it MUST + also be refundable, and the "refundable" attribute MUST be true. If + the "refundable" attribute of a <fee:fee> element is false, then it + MUST NOT have a "grace-period" attribute. + +3.4.4. Applicability + + Fees may be applied immediately upon receipt of a command from a + client or may only be applied once an out-of-band process (such as + the processing of applications at the end of a launch phase) has + taken place. + + The "applied" attribute of the <fee:fee> element allows servers to + indicate whether a fee will be applied immediately or whether it will + be applied at some point in the future. This attribute takes two + possible values: "immediate" or "delayed". + +3.5. Account Balance + + The <fee:balance> element is an OPTIONAL element that MAY be included + in server responses to transform commands. If present, it can be + used by the client to determine the remaining credit at the server. + + Whether or not the <fee:balance> is included in responses is a matter + of server policy. However, if a server chooses to offer support for + this element, it MUST be included in responses to all "transform" or + billable commands (e.g., <create>, <renew>, <update>, <delete>, + <transfer op="request">). + + The value of the <fee:balance> MAY be negative. A negative balance + indicates that the server has extended a line of credit to the client + (see Section 3.6). + + If a server includes a <fee:balance> element in response to transform + commands, the value of the element MUST reflect the client's account + balance after any fees or credits associated with that command have + been applied. If the "applied" attribute of the <fee:fee> element is + "delayed", then the <fee:balance> MUST reflect the client's account + balance without any fees or credits associated with that command. + +3.6. Credit Limit + + As described above, if a server returns a response containing a + <fee:balance> with a negative value, then the server has extended a + line of credit to the client. A server MAY also include in responses + a <fee:creditLimit> element that indicates the maximum credit + available to a client. A server MAY reject certain transactions if + the absolute value of the <fee:balance> is equal to or exceeds the + value of the <fee:creditLimit> element. + + Whether or not the <fee:creditLimit> is included in responses is a + matter of server policy. However, if a server chooses to offer + support for this element, it MUST be included in responses to all + "transform" commands (e.g., <create>, <renew>, <update>, <delete>, + <transfer op="request">). + +3.7. Classification of Objects + + Objects may be assigned to a particular class, category, or tier, + each of which has a particular fee or set of fees associated with it. + The <fee:class> element, which MAY appear in <check> and transform + responses, is used to indicate the classification of an object. + + If a server makes use of this element, it should provide clients with + a list of all the values that the element may take via an out-of-band + channel. Servers MUST NOT use values that do not appear on this + list. + + Servers that make use of this element MUST use a <fee:class> element + with the value "standard" for all objects that are subject to the + standard or default fee. + +3.8. "Phase" and "Subphase" Attributes + + The <fee:command> element has two attributes, "phase" and "subphase", + that provide additional information related to a specific launch + phase, as described in [RFC8334]. These attributes are used as + filters that should refine the server processing. + + If the client <fee:command> contains a server-supported combination + of phase/subphase, the server MUST return the fee data (including the + phase/subphase attribute(s)) for the specific combination. + + If the client <fee:command> contains no "phase"/"subphase" attributes + and the server has only one active phase/subphase combination, the + server MUST return the data (including the "phase"/"subphase" + attribute(s)) of the currently active phase/subphase. + + If the client <fee:command> contains no phase/subphase attributes and + the server has more than one active phase/subphase combination, the + server MUST respond with a 2003 "Required parameter missing" error. + + If the client <fee:command> contains no phase/subphase attributes and + the server is currently in a "quiet period" (e.g., not accepting + registrations or applications), the server MUST return data + consistent with the default general availability phase (e.g., "open" + or "claims"), including the appropriate phase/subphase attribute(s). + + If the client <fee:command> contains a phase attribute with no + subphase and the server has only one active subphase (or no subphase) + of this phase, the server MUST return the data (including the phase/ + subphase attribute(s)) of the provided phase and currently active + subphase. + + If the client <fee:command> contains a phase attribute with no + subphase and the server has more than one active subphase combination + of this phase, the server MUST respond with a 2003 "Required + parameter missing" error. + + If the client <fee:command> contains a subphase with no phase + attribute, the server MUST respond with a 2003 "Required parameter + missing" error. + + If the client <fee:command> contains a phase attribute not defined in + [RFC8334] or not supported by the server, the server MUST respond + with a 2004 "Parameter value range error". + + If the client <fee:command> contains a subphase attribute (or phase/ + subphase combination) not supported by the server, the server MUST + respond with a 2004 "Parameter value range error". + +3.9. Reason + + The <fee:reason> element is used to provide server-specific text in + an effort to better explain why a <check> command did not complete as + the client expected. An OPTIONAL "lang" attribute MAY be present to + identify the language, per the language structure in [RFC5646], of + the returned text and has a default value of "en" (English). + + The <fee:reason> element can be used within the server response + <fee:command> element or within the <fee:cd> element. See + Section 5.1.1 for details on the <fee:cd> "check data" element. + + If the server cannot calculate the relevant fees because the object, + command, currency, period, class, or some combination is invalid per + server policy, the server has two ways of handling the error + processing of <fee:command> element(s): + + 1. Fast-fail: The server, upon error identification, MAY stop + processing <fee:command> elements and return a <fee:cd> to the + client containing the <fee:objID> and a <fee:reason> element + detailing the reason for failure. + + S: <fee:cd avail="0"> + S: <fee:objID>example.xyz</fee:objID> + S: <fee:reason>Only 1 year registration periods are + S: valid.</fee:reason> + S: </fee:cd> + + 2. Partial-fail: The server, upon error identification, MAY continue + processing <fee:command> elements and return a <fee:cd> to the + client containing the successfully processed <fee:command> + elements and failed <fee:command> elements. All returned failed + <fee:command> elements MUST have a <fee:reason> element detailing + the reason for failure, and the server MAY additionally include a + <fee:reason> element at the <fee:cd> level. + + S: <fee:cd avail="0"> + S: <fee:objID>example.xyz</fee:objID> + S: <fee:command name="create"> + S: <fee:period unit="y">2</fee:period> + S: <fee:reason>Only 1 year registration periods are + S: valid.</fee:reason> + S: </fee:command> + S: </fee:cd> + + In either failure scenario, the server MUST set the <fee:cd> "avail" + attribute to false (0), and the server MUST process all objects in + the client request. + +4. Server Handling of Fee Information + + Depending on the server policy, a client MAY be required to include + the extension elements described in this document for certain + transform commands. Servers must provide clear documentation to + clients about the circumstances in which this extension must be used. + + The server MUST return avail="0" in its response to a <check> command + for any object in the <check> command that does not include the + <fee:check> extension where the server would fail a domain <create> + command when no <fee> extension is provided for that same object. + + If a server receives a <check> command from a client that results in + no possible fee combination, the server MUST set the "avail" + attribute of the <fee:cd> element to false (0) and provide a + <fee:reason>. + + If a server receives a <check> command from a client that results in + an ambiguous result (i.e., multiple possible fee combinations), the + server MUST reject the command with a 2003 "Required parameter + missing" error. + + If a server receives a command from a client that does not include + the fee extension data elements required by the server for that + command, then the server MUST respond with a 2003 "Required parameter + missing" error. + + If the total fee provided by the client is less than the server's own + calculation of the fee or the server determines the currency is + inappropriate for that command, then the server MUST reject the + command with a 2004 "Parameter value range error". + +5. EPP Command Mapping + + A detailed description of the EPP syntax and semantics can be found + in [RFC5730]. + +5.1. EPP Query Commands + + This extension does not add any elements to the EPP <poll> or <info> + commands or responses. + +5.1.1. EPP <check> Command + + This extension defines a new command called the Fee Check Command + that defines additional elements for the EPP <check> command to + provide fee information. + + The command MAY contain an <extension> element, which MAY contain a + <fee:check> element. The <fee:check> element MAY contain one + <fee:currency> element and MUST contain one or more <fee:command> + elements. + + The <fee:command> element(s) MUST contain a "name" attribute (see + Section 3.1), an OPTIONAL "phase" attribute, and an OPTIONAL + "subphase" attribute (see Section 3.8). The <fee:command> element(s) + MAY have the following child elements: + + * An OPTIONAL <fee:period> element (as described in Section 3.3). + + Example <check> command: + + 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>example.com</domain:name> + C: <domain:name>example.net</domain:name> + C: <domain:name>example.xyz</domain:name> + C: </domain:check> + C: </check> + C: <extension> + C: <fee:check xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + C: <fee:currency>USD</fee:currency> + C: <fee:command name="create"> + C: <fee:period unit="y">2</fee:period> + C: </fee:command> + C: <fee:command name="renew"/> + C: <fee:command name="transfer"/> + C: <fee:command name="restore"/> + C: </fee:check> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C: </epp> + + When the server receives a <check> command that includes the + extension elements described above, its response MUST contain an + <extension> element, which MUST contain a child <fee:chkData> + element. The <fee:chkData> element MUST contain a <fee:currency> + element and a <fee:cd> element for each object referenced in the + client <check> command. + + Each <fee:cd> (check data) element MUST contain the following child + elements: + + * A <fee:objID> element, which MUST match an element referenced in + the client <check> command. + + * An OPTIONAL <fee:class> element (as described in Section 3.7). + + * A <fee:command> element matching each <fee:command> (unless the + "avail" attribute of the <fee:cd> is false) that appeared in the + corresponding <fee:check> of the client command. This element MAY + have the OPTIONAL "standard" attribute, with a default value of + "0" (or "false"), which indicates whether the fee is the standard + or default fee (see Section 3.7). This element MAY have the + OPTIONAL "phase" and "subphase" attributes, which will match the + same attributes in the corresponding <fee:command> element of the + client command if sent by the client. + + The <fee:cd> element also has an OPTIONAL "avail" attribute, which is + a boolean. If the value of this attribute evaluates to false, this + indicates that the server cannot calculate the relevant fees because + the object, command, currency, period, class, or some combination is + invalid per server policy. If "avail" is false, then the <fee:cd> or + the <fee:command> element MUST contain a <fee:reason> element (as + described in Section 3.9), and the server MAY eliminate some or all + of the <fee:command> element(s). + + The <fee:command> element(s) MAY have the following child elements: + + * An OPTIONAL <fee:period> element (as described in Section 3.3), + which contains the same unit, if present, that appeared in the + <fee:period> element of the command. If the value of the parent + <fee:command> element is "restore", this element MUST NOT be + included; otherwise, it MUST be included. If no <fee:period> + appeared in the client command (and the command is not "restore"), + then the server MUST return its default period value. + + * Zero or more <fee:fee> elements (as described in Section 3.4). + + * Zero or more <fee:credit> elements (as described in Section 3.4). + + * An OPTIONAL <fee:reason> element (as described in Section 3.9). + + If the "avail" attribute of the <fee:cd> element is true (1) and if + no <fee:fee> elements are present in a <fee:command> element, this + indicates that no fee will be assessed by the server for this + command. + + If the "avail" attribute of the <fee:cd> element is true (1), then + the <fee:command> element MUST NOT contain a <fee:reason> element. + + Example <check> response: + + 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:chkData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:cd> + S: <domain:name avail="1">example.com</domain:name> + S: </domain:cd> + S: <domain:cd> + S: <domain:name avail="1">example.net</domain:name> + S: </domain:cd> + S: <domain:cd> + S: <domain:name avail="1">example.xyz</domain:name> + S: </domain:cd> + S: </domain:chkData> + S: </resData> + S: <extension> + S: <fee:chkData + S: xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + S: <fee:currency>USD</fee:currency> + S: <fee:cd avail="1"> + S: <fee:objID>example.com</fee:objID> + S: <fee:class>Premium</fee:class> + S: <fee:command name="create"> + S: <fee:period unit="y">2</fee:period> + S: <fee:fee + S: description="Registration Fee" + S: refundable="1" + S: grace-period="P5D">10.00</fee:fee> + S: </fee:command> + S: <fee:command name="renew"> + S: <fee:period unit="y">1</fee:period> + S: <fee:fee + S: description="Renewal Fee" + S: refundable="1" + S: grace-period="P5D">10.00</fee:fee> + S: </fee:command> + S: <fee:command name="transfer"> + S: <fee:period unit="y">1</fee:period> + S: <fee:fee + S: description="Transfer Fee" + S: refundable="1" + S: grace-period="P5D">10.00</fee:fee> + S: </fee:command> + S: <fee:command name="restore"> + S: <fee:fee + S: description="Redemption Fee">15.00</fee:fee> + S: </fee:command> + S: </fee:cd> + S: <fee:cd avail="1"> + S: <fee:objID>example.net</fee:objID> + S: <fee:class>standard</fee:class> + S: <fee:command name="create" standard="1"> + S: <fee:period unit="y">2</fee:period> + S: <fee:fee + S: description="Registration Fee" + S: refundable="1" + S: grace-period="P5D">5.00</fee:fee> + S: </fee:command> + S: <fee:command name="renew" standard="1"> + S: <fee:period unit="y">1</fee:period> + S: <fee:fee + S: description="Renewal Fee" + S: refundable="1" + S: grace-period="P5D">5.00</fee:fee> + S: </fee:command> + S: <fee:command name="transfer" standard="1"> + S: <fee:period unit="y">1</fee:period> + S: <fee:fee + S: description="Transfer Fee" + S: refundable="1" + S: grace-period="P5D">5.00</fee:fee> + S: </fee:command> + S: <fee:command name="restore" standard="1"> + S: <fee:fee + S: description="Redemption Fee">5.00</fee:fee> + S: </fee:command> + S: </fee:cd> + S: <fee:cd avail="0"> + S: <fee:objID>example.xyz</fee:objID> + S: <fee:command name="create"> + S: <fee:period unit="y">2</fee:period> + S: <fee:reason>Only 1 year registration periods are + S: valid.</fee:reason> + S: </fee:command> + S: </fee:cd> + S: </fee:chkData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S: </epp> + +5.1.2. EPP Transfer Query Command + + This extension does not add any elements to the EPP <transfer> query + command, but it does include elements in the response when the + extension is included in the <login> command service extensions. + + When the <transfer> query command has been processed successfully, if + the client has included the extension in the <login> command service + <svcExtension> element, and if the client is authorized by the server + to view information about the transfer, then the server MAY include + in the <extension> section of the EPP response a <fee:trnData> + element, which contains the following child elements: + + * A <fee:currency> element (as described in Section 3.2). + + * A <fee:period> element (as described in Section 3.3). + + * Zero or more <fee:fee> elements (as described in Section 3.4) + containing the fees that will be charged to the gaining client. + + * Zero or more <fee:credit> elements (as described in Section 3.4) + containing the credits that will be refunded to the losing client. + + Servers SHOULD omit <fee:credit> when returning a response to the + gaining client and omit <fee:fee> elements when returning a response + to the losing client. + + If no <fee:trnData> element is included in the response, then no fee + will be assessed by the server for the transfer. + + Example <transfer> query response: + + 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="1001"> + S: <msg>Command completed successfully; action pending</msg> + S: </result> + S: <resData> + S: <domain:trnData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:trStatus>pending</domain:trStatus> + S: <domain:reID>ClientX</domain:reID> + S: <domain:reDate>2019-06-08T22:00:00.0Z</domain:reDate> + S: <domain:acID>ClientY</domain:acID> + S: <domain:acDate>2019-06-13T22:00:00.0Z</domain:acDate> + S: <domain:exDate>2021-09-08T22:00:00.0Z</domain:exDate> + S: </domain:trnData> + S: </resData> + S: <extension> + S: <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + S: <fee:currency>USD</fee:currency> + S: <fee:period unit="y">1</fee:period> + S: <fee:fee>5.00</fee:fee> + S: </fee:trnData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S: </epp> + +5.2. EPP Transform Commands + +5.2.1. EPP <create> Command + + This extension adds elements to both the EPP <create> command and + response when the extension is included in the <login> command + service extensions. + + When submitting a <create> command to the server, the client MAY + include in the <extension> element a <fee:create> element, which + includes the following child elements: + + * An OPTIONAL <fee:currency> element (as described in Section 3.2). + + * One or more <fee:fee> elements (as described in Section 3.4). + + When the <create> command has been processed successfully, the client + included the extension in the <login> command service extensions, and + a fee was assessed by the server for the transaction, the server MUST + include in the <extension> section of the EPP response a + <fee:creData> element, which contains the following child elements: + + * A <fee:currency> element (as described in Section 3.2). + + * Zero or more <fee:fee> elements (as described in Section 3.4). + + * Zero or more <fee:credit> elements (as described in Section 3.4). + + * An OPTIONAL <fee:balance> element (as described in Section 3.5). + + * An OPTIONAL <fee:creditLimit> element (as described in + Section 3.6). + + Example <create> command: + + 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">2</domain:period> + C: <domain:ns> + C: <domain:hostObj>ns1.example.net</domain:hostObj> + C: <domain:hostObj>ns2.example.net</domain:hostObj> + C: </domain:ns> + 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: <fee:create xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + C: <fee:currency>USD</fee:currency> + C: <fee:fee>5.00</fee:fee> + C: </fee:create> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C: </epp> + + Example <create> response: + + 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:creData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:crDate>2019-04-03T22:00:00.0Z</domain:crDate> + S: <domain:exDate>2021-04-03T22:00:00.0Z</domain:exDate> + S: </domain:creData> + S: </resData> + S: <extension> + S: <fee:creData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + S: <fee:currency>USD</fee:currency> + S: <fee:fee + S: description="Registration Fee" + S: lang="en" + S: refundable="1" + S: grace-period="P5D">5.00</fee:fee> + S: <fee:balance>-5.00</fee:balance> + S: <fee:creditLimit>1000.00</fee:creditLimit> + S: </fee:creData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54321-XYZ</svTRID> + S: </trID> + S: </response> + S: </epp> + +5.2.2. EPP <delete> Command + + This extension does not add any elements to the EPP <delete> command, + but it does include elements in the response when the extension is + included in the <login> command service extensions. + + When the <delete> command has been processed successfully and the + client included the extension in the <login> command service + extensions, the server MAY include in the <extension> section of the + EPP response a <fee:delData> element, which contains the following + child elements: + + * A <fee:currency> element (as described in Section 3.2). + + * Zero or more <fee:fee> elements (as described in Section 3.4). + + * Zero or more <fee:credit> elements (as described in Section 3.4). + + * An OPTIONAL <fee:balance> element (as described in Section 3.5). + + * An OPTIONAL <fee:creditLimit> element (as described in + Section 3.6). + + Example <delete> response: + + 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: <extension> + S: <fee:delData + S: xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + S: <fee:currency>USD</fee:currency> + S: <fee:credit + S: description="AGP Credit" + S: lang="en">-5.00</fee:credit> + S: <fee:balance>1005.00</fee:balance> + S: </fee:delData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54321-XYZ</svTRID> + S: </trID> + S: </response> + S: </epp> + +5.2.3. EPP <renew> Command + + This extension adds elements to both the EPP <renew> command and + response when the extension is included in the <login> command + service extensions. + + When submitting a <renew> command to the server, the client MAY + include in the <extension> element a <fee:renew> element, which + includes the following child elements: + + * An OPTIONAL <fee:currency> element (as described in Section 3.2). + + * One or more <fee:fee> elements (as described in Section 3.4). + + When the <renew> command has been processed successfully and the + client included the extension in the <login> command service + extensions, the server MAY include in the <extension> section of the + EPP response a <fee:renData> element, which contains the following + child elements: + + * A <fee:currency> element (as described in Section 3.2). + + * Zero or more <fee:fee> elements (as described in Section 3.4). + + * Zero or more <fee:credit> elements (as described in Section 3.4). + + * An OPTIONAL <fee:balance> element (as described in Section 3.5). + + * An OPTIONAL <fee:creditLimit> element (as described in + Section 3.6). + + Example <renew> command: + + C: <?xml version="1.0" encoding="utf-8" standalone="no"?> + C: <epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> + C: <command> + C: <renew> + C: <domain:renew + C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + C: <domain:name>example.com</domain:name> + C: <domain:curExpDate>2019-04-03</domain:curExpDate> + C: <domain:period unit="y">5</domain:period> + C: </domain:renew> + C: </renew> + C: <extension> + C: <fee:renew xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + C: <fee:currency>USD</fee:currency> + C: <fee:fee>5.00</fee:fee> + C: </fee:renew> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C: </epp> + + Example <renew> response: + + 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:renData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:exDate>2024-04-03T22:00:00.0Z</domain:exDate> + S: </domain:renData> + S: </resData> + S: <extension> + S: <fee:renData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + S: <fee:currency>USD</fee:currency> + S: <fee:fee + S: refundable="1" + S: grace-period="P5D">5.00</fee:fee> + S: <fee:balance>1000.00</fee:balance> + S: </fee:renData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S: </epp> + +5.2.4. EPP <transfer> Command + + This extension adds elements to both the EPP <transfer> command and + response when the value of the "op" attribute of the <transfer> + command element is "request" and the extension is included in the + <login> command service extensions. + + When submitting a <transfer> command to the server, the client MAY + include in the <extension> element a <fee:transfer> element, which + includes the following child elements: + + * An OPTIONAL <fee:currency> element (as described in Section 3.2). + + * One or more <fee:fee> elements (as described in Section 3.4). + + When the <transfer> command has been processed successfully and the + client included the extension in the <login> command service + extensions, the server MAY include in the <extension> section of the + EPP response a <fee:trnData> element, which contains the following + child elements: + + * A <fee:currency> element (as described in Section 3.2). + + * Zero or more <fee:fee> elements (as described in Section 3.4). + + * Zero or more <fee:credit> elements (as described in Section 3.4). + + * An OPTIONAL <fee:balance> element (as described in Section 3.5). + + * An OPTIONAL <fee:creditLimit> element (as described in + Section 3.6). + + Example <transfer> command: + + 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>example.com</domain:name> + C: <domain:period unit="y">1</domain:period> + C: <domain:authInfo> + C: <domain:pw roid="JD1234-REP">2fooBAR</domain:pw> + C: </domain:authInfo> + C: </domain:transfer> + C: </transfer> + C: <extension> + C: <fee:transfer xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + C: <fee:currency>USD</fee:currency> + C: <fee:fee>5.00</fee:fee> + C: </fee:transfer> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C: </epp> + + Example <transfer> response: + + 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="1001"> + S: <msg>Command completed successfully; action pending</msg> + S: </result> + S: <resData> + S: <domain:trnData + S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> + S: <domain:name>example.com</domain:name> + S: <domain:trStatus>pending</domain:trStatus> + S: <domain:reID>ClientX</domain:reID> + S: <domain:reDate>2019-06-08T22:00:00.0Z</domain:reDate> + S: <domain:acID>ClientY</domain:acID> + S: <domain:acDate>2019-06-13T22:00:00.0Z</domain:acDate> + S: <domain:exDate>2021-09-08T22:00:00.0Z</domain:exDate> + S: </domain:trnData> + S: </resData> + S: <extension> + S: <fee:trnData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + S: <fee:currency>USD</fee:currency> + S: <fee:fee + S: refundable="1" + S: grace-period="P5D">5.00</fee:fee> + S: </fee:trnData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54322-XYZ</svTRID> + S: </trID> + S: </response> + S: </epp> + +5.2.5. EPP <update> Command + + This extension adds elements to both the EPP <update> command and + response when the extension is included in the <login> command + service extensions. + + When submitting an <update> command to the server, the client MAY + include in the <extension> element a <fee:update> element, which + includes the following child elements: + + * An OPTIONAL <fee:currency> element (as described in Section 3.2). + + * One or more <fee:fee> elements (as described in Section 3.4). + + When the <update> command has been processed successfully and the + client included the extension in the <login> command service + extensions, the server MAY include in the <extension> section of the + EPP response a <fee:updData> element, which contains the following + child elements: + + * A <fee:currency> element (as described in Section 3.2). + + * Zero or more <fee:fee> elements (as described in Section 3.4). + + * Zero or more <fee:credit> elements (as described in Section 3.4). + + * An OPTIONAL <fee:balance> element (as described in Section 3.5). + + * An OPTIONAL <fee:creditLimit> element (as described in + Section 3.6). + + Example <update> command: + + 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:chg> + C: <domain:registrant>sh8013</domain:registrant> + C: </domain:chg> + C: </domain:update> + C: </update> + C: <extension> + C: <fee:update xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + C: <fee:currency>USD</fee:currency> + C: <fee:fee>5.00</fee:fee> + C: </fee:update> + C: </extension> + C: <clTRID>ABC-12345</clTRID> + C: </command> + C: </epp> + + Example <update> response: + + 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: <extension> + S: <fee:updData xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0"> + S: <fee:currency>USD</fee:currency> + S: <fee:fee>5.00</fee:fee> + S: </fee:updData> + S: </extension> + S: <trID> + S: <clTRID>ABC-12345</clTRID> + S: <svTRID>54321-XYZ</svTRID> + S: </trID> + S: </response> + S: </epp> + +6. Formal Syntax + + One schema is presented here -- the EPP Fee Extension schema. + + The formal syntax presented here is a complete schema representation + of the object mapping suitable for automated validation of EPP XML + instances. + +6.1. Fee Extension Schema + + The formal syntax presented here is a complete schema representation + [W3C.REC-xmlschema-1-20041028] of the object mapping suitable for + automated validation of EPP XML instances. The <CODE BEGINS> and + <CODE ENDS> tags are not part of the schema; they are used to note + the beginning and end of the schema for URI registration purposes. + + <CODE BEGINS> + <?xml version="1.0" encoding="utf-8"?> + <schema xmlns="http://www.w3.org/2001/XMLSchema" + xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0" + xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" + xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" + targetNamespace="urn:ietf:params:xml:ns:epp:fee-1.0" + elementFormDefault="qualified"> + + <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" /> + <import namespace="urn:ietf:params:xml:ns:domain-1.0" /> + + <annotation> + <documentation> + Extensible Provisioning Protocol v1.0 Fee Extension + </documentation> + </annotation> + + <!-- Child elements found in EPP commands and responses --> + <element name="check" type="fee:checkType" /> + <element name="chkData" type="fee:chkDataType" /> + <element name="create" type="fee:transformCommandType" /> + <element name="creData" type="fee:transformResultType" /> + <element name="renew" type="fee:transformCommandType" /> + <element name="renData" type="fee:transformResultType" /> + <element name="transfer" type="fee:transformCommandType" /> + <element name="trnData" type="fee:transformResultType" /> + <element name="update" type="fee:transformCommandType" /> + <element name="updData" type="fee:transformResultType" /> + <element name="delData" type="fee:transformResultType" /> + + <!-- client <check> command --> + <complexType name="checkType"> + <sequence> + <element name="currency" type="fee:currencyType" + minOccurs="0" /> + <element name="command" type="fee:commandType" + minOccurs="1" maxOccurs="unbounded" /> + </sequence> + </complexType> + + <complexType name="objectIdentifierType"> + <simpleContent> + <extension base="eppcom:labelType"> + <attribute name="element" + type="NMTOKEN" default="name" /> + </extension> + </simpleContent> + </complexType> + + <!-- server <check> result --> + <complexType name="chkDataType"> + <sequence> + <element name="currency" type="fee:currencyType" /> + <element name="cd" type="fee:objectCDType" + maxOccurs="unbounded" /> + </sequence> + </complexType> + + <complexType name="objectCDType"> + <sequence> + <element name="objID" type="fee:objectIdentifierType" /> + <element name="class" type="token" minOccurs="0" /> + <element name="command" type="fee:commandDataType" + minOccurs="0" maxOccurs="unbounded" /> + <element name="reason" type="fee:reasonType" minOccurs="0" /> + </sequence> + <attribute name="avail" type="boolean" default="1" /> + </complexType> + + <!-- general transform (create, renew, update, transfer) command--> + <complexType name="transformCommandType"> + <sequence> + <element name="currency" type="fee:currencyType" + minOccurs="0" /> + <element name="fee" type="fee:feeType" + maxOccurs="unbounded" /> + <element name="credit" type="fee:creditType" + minOccurs="0" maxOccurs="unbounded" /> + </sequence> + </complexType> + + <!-- general transform (create, renew, update) result --> + <complexType name="transformResultType"> + <sequence> + <element name="currency" type="fee:currencyType" + minOccurs="0" /> + <element name="period" type="domain:periodType" + minOccurs="0" /> + <element name="fee" type="fee:feeType" + minOccurs="0" maxOccurs="unbounded" /> + <element name="credit" type="fee:creditType" + minOccurs="0" maxOccurs="unbounded" /> + <element name="balance" type="fee:balanceType" + minOccurs="0" /> + <element name="creditLimit" type="fee:creditLimitType" + minOccurs="0" /> + </sequence> + </complexType> + + <!-- common types --> + <simpleType name="currencyType"> + <restriction base="string"> + <pattern value="[A-Z]{3}" /> + </restriction> + </simpleType> + + <complexType name="commandType"> + <sequence> + <element name="period" type="domain:periodType" + minOccurs="0" maxOccurs="1" /> + </sequence> + <attribute name="name" type="fee:commandEnum" use="required"/> + <attribute name="customName" type="token"/> + <attribute name="phase" type="token" /> + <attribute name="subphase" type="token" /> + </complexType> + + <complexType name="commandDataType"> + <complexContent> + <extension base="fee:commandType"> + <sequence> + <element name="fee" type="fee:feeType" + minOccurs="0" maxOccurs="unbounded" /> + <element name="credit" type="fee:creditType" + minOccurs="0" maxOccurs="unbounded" /> + <element name="reason" type="fee:reasonType" + minOccurs="0" /> + </sequence> + <attribute name="standard" type="boolean" default="0" /> + </extension> + </complexContent> + </complexType> + + <complexType name="reasonType"> + <simpleContent> + <extension base="token"> + <attribute name="lang" type="language" default="en"/> + </extension> + </simpleContent> + </complexType> + + <simpleType name="commandEnum"> + <restriction base="token"> + <enumeration value="create"/> + <enumeration value="delete"/> + <enumeration value="renew"/> + <enumeration value="update"/> + <enumeration value="transfer"/> + <enumeration value="restore"/> + <enumeration value="custom"/> + </restriction> + </simpleType> + + <simpleType name="nonNegativeDecimal"> + <restriction base="decimal"> + <minInclusive value="0" /> + </restriction> + </simpleType> + + <simpleType name="negativeDecimal"> + <restriction base="decimal"> + <maxInclusive value="0" /> + </restriction> + </simpleType> + + <complexType name="feeType"> + <simpleContent> + <extension base="fee:nonNegativeDecimal"> + <attribute name="description"/> + <attribute name="lang" type="language" default="en"/> + <attribute name="refundable" type="boolean" /> + <attribute name="grace-period" type="duration" /> + <attribute name="applied"> + <simpleType> + <restriction base="token"> + <enumeration value="immediate" /> + <enumeration value="delayed" /> + </restriction> + </simpleType> + </attribute> + </extension> + </simpleContent> + </complexType> + + <complexType name="creditType"> + <simpleContent> + <extension base="fee:negativeDecimal"> + <attribute name="description"/> + <attribute name="lang" type="language" default="en"/> + </extension> + </simpleContent> + </complexType> + + <simpleType name="balanceType"> + <restriction base="decimal" /> + </simpleType> + + <simpleType name="creditLimitType"> + <restriction base="decimal" /> + </simpleType> + + </schema> + <CODE ENDS> + +7. Security Considerations + + The mapping extensions described in this document do not provide any + security services beyond those described by the EPP [RFC5730], the + EPP domain name mapping [RFC5731], and the protocol layers used by + the EPP. The security considerations described in these other + specifications apply to this specification as well. This extension + passes financial information using the EPP protocol, so + confidentiality and integrity protection must be provided by the + transport mechanism. All transports compliant with [RFC5730] provide + the needed level of confidentiality and integrity protections. The + server will only provide information, including financial + information, that is relevant to the authenticated client. + +8. IANA Considerations + +8.1. XML Namespace + + This document uses URNs to describe XML namespaces and XML schemas + conforming to a registry mechanism described in [RFC3688]. + + Registration request for the fee namespace: + + URI: urn:ietf:params:xml:ns:epp:fee-1.0 + + Registrant Contact: IESG + + XML: None. Namespace URIs do not represent an XML specification. + + Registration request for the fee schema: + + URI: urn:ietf:params:xml:schema:epp:fee-1.0 + + Registrant Contact: IESG + + XML: See Section 6 of this document. + +8.2. EPP Extension Registry + + 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: + + Name of Extension: Registry Fee Extension for the Extensible + Provisioning Protocol (EPP) + + Document status: Standards Track + + Reference: RFC 8748 + + Registrant Name and Email Address: IESG <iesg@ietf.org> + + TLDs: Any + + IPR Disclosure: None + + Status: Active + + Notes: None + +9. References + +9.1. Normative References + + [ISO4217_2015] + ISO, "Codes for the representation of currencies", + ISO 4217:2015, August 2015, + <https://www.iso.org/standard/64758.html>. + + [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>. + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + <https://www.rfc-editor.org/info/rfc3688>. + + [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for + the Extensible Provisioning Protocol (EPP)", RFC 3915, + DOI 10.17487/RFC3915, September 2004, + <https://www.rfc-editor.org/info/rfc3915>. + + [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying + Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, + September 2009, <https://www.rfc-editor.org/info/rfc5646>. + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + <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>. + + [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>. + + [RFC8334] Gould, J., Tan, W., and G. Brown, "Launch Phase Mapping + for the Extensible Provisioning Protocol (EPP)", RFC 8334, + DOI 10.17487/RFC8334, March 2018, + <https://www.rfc-editor.org/info/rfc8334>. + + [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>. + +9.2. Informative References + + [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>. + +Acknowledgements + + The authors wish to thank the following persons for their feedback + and suggestions: + + * James Gould of Verisign Inc. + * Luis Munoz of ISC + * Michael Young + * Ben Levac + * Jeff Eckhaus + * Seth Goldman of Google + * Klaus Malorny and Michael Bauland of Knipp + * Jody Kolker, Joe Snitker, and Kevin Allendorf of GoDaddy + * Michael Holloway of Com Laude + * Santosh Kalsangrah of Impetus Infotech + * Alex Mayrhofer of Nic.at + * Thomas Corte of Knipp Medien und Kommunikation GmbH + +Authors' Addresses + + Roger Carney + GoDaddy Inc. + 14455 N. Hayden Rd. #219 + Scottsdale, AZ 85260 + United States of America + + Email: rcarney@godaddy.com + URI: http://www.godaddy.com + + + Gavin Brown + CentralNic Group plc + 35-39 Moorgate + London + EC2R 6AR + United Kingdom + + Phone: +44 20 33 88 0600 + Email: gavin.brown@centralnic.com + URI: http://www.centralnic.com + + + Jothan Frakes + + Email: jothan@jothan.com + URI: http://jothan.com |