From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8748.txt | 1578 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1578 insertions(+) create mode 100644 doc/rfc/rfc8748.txt (limited to 'doc/rfc/rfc8748.txt') 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 Command + 5.1.2. EPP Transfer Query Command + 5.2. EPP Transform Commands + 5.2.1. EPP Command + 5.2.2. EPP Command + 5.2.3. EPP Command + 5.2.4. EPP Command + 5.2.5. EPP 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 , , , 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 + element of the 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 element is used in the EPP command to + determine the fee that is applicable to the given command. + + The "name" attribute of the is used to define which + transform fees the client is requesting information about. The + possible values for the "name" attribute are: + + * "create", indicating a command as defined in [RFC5730]. + + * "delete", indicating a command as defined in [RFC5730]. + + * "renew", indicating a command as defined in [RFC5730]. + + * "update", indicating a command as defined in [RFC5730]. + + * "transfer", indicating a 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 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 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 elements in client commands is OPTIONAL: if + a 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 + 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 command, the + element is used to indicate the validity period, which + is to be added to extend the registration period of objects by the + , , and 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 element described in [RFC5731]. + + The element is OPTIONAL in commands; if omitted, + the server MUST determine the fee(s) using the server default period. + The element MUST be present in 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 and elements are used to provide this + information. The presence of a element in a response + indicates a debit against the client's account balance; a + element indicates a credit. A element MUST + have a zero or greater (non-negative) value. A element + MUST have a negative value. + + A server MAY respond with multiple and + 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 and/or elements. This amount + applies to the total additional validity period for the object (where + applicable). + + The following attributes are defined for the 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 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 + + 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 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 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 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 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 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., , , , , + ). + + The value of the 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 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 element is + "delayed", then the 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 + with a negative value, then the server has extended a + line of credit to the client. A server MAY also include in responses + a element that indicates the maximum credit + available to a client. A server MAY reject certain transactions if + the absolute value of the is equal to or exceeds the + value of the element. + + Whether or not the 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., , , , , + ). + +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 element, which MAY appear in 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 element + with the value "standard" for all objects that are subject to the + standard or default fee. + +3.8. "Phase" and "Subphase" Attributes + + The 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 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 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 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 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 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 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 contains a subphase with no phase + attribute, the server MUST respond with a 2003 "Required parameter + missing" error. + + If the client 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 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 element is used to provide server-specific text in + an effort to better explain why a 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 element can be used within the server response + element or within the element. See + Section 5.1.1 for details on the "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 element(s): + + 1. Fast-fail: The server, upon error identification, MAY stop + processing elements and return a to the + client containing the and a element + detailing the reason for failure. + + S: + S: example.xyz + S: Only 1 year registration periods are + S: valid. + S: + + 2. Partial-fail: The server, upon error identification, MAY continue + processing elements and return a to the + client containing the successfully processed + elements and failed elements. All returned failed + elements MUST have a element detailing + the reason for failure, and the server MAY additionally include a + element at the level. + + S: + S: example.xyz + S: + S: 2 + S: Only 1 year registration periods are + S: valid. + S: + S: + + In either failure scenario, the server MUST set the "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 command + for any object in the command that does not include the + extension where the server would fail a domain + command when no extension is provided for that same object. + + If a server receives a command from a client that results in + no possible fee combination, the server MUST set the "avail" + attribute of the element to false (0) and provide a + . + + If a server receives a 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 or + commands or responses. + +5.1.1. EPP Command + + This extension defines a new command called the Fee Check Command + that defines additional elements for the EPP command to + provide fee information. + + The command MAY contain an element, which MAY contain a + element. The element MAY contain one + element and MUST contain one or more + elements. + + The 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 element(s) + MAY have the following child elements: + + * An OPTIONAL element (as described in Section 3.3). + + Example command: + + C: + C: + C: + C: + C: + C: example.com + C: example.net + C: example.xyz + C: + C: + C: + C: + C: USD + C: + C: 2 + C: + C: + C: + C: + C: + C: + C: ABC-12345 + C: + C: + + When the server receives a command that includes the + extension elements described above, its response MUST contain an + element, which MUST contain a child + element. The element MUST contain a + element and a element for each object referenced in the + client command. + + Each (check data) element MUST contain the following child + elements: + + * A element, which MUST match an element referenced in + the client command. + + * An OPTIONAL element (as described in Section 3.7). + + * A element matching each (unless the + "avail" attribute of the is false) that appeared in the + corresponding 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 element of the + client command if sent by the client. + + The 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 or + the element MUST contain a element (as + described in Section 3.9), and the server MAY eliminate some or all + of the element(s). + + The element(s) MAY have the following child elements: + + * An OPTIONAL element (as described in Section 3.3), + which contains the same unit, if present, that appeared in the + element of the command. If the value of the parent + element is "restore", this element MUST NOT be + included; otherwise, it MUST be included. If no + appeared in the client command (and the command is not "restore"), + then the server MUST return its default period value. + + * Zero or more elements (as described in Section 3.4). + + * Zero or more elements (as described in Section 3.4). + + * An OPTIONAL element (as described in Section 3.9). + + If the "avail" attribute of the element is true (1) and if + no elements are present in a element, this + indicates that no fee will be assessed by the server for this + command. + + If the "avail" attribute of the element is true (1), then + the element MUST NOT contain a element. + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: + S: example.com + S: + S: + S: example.net + S: + S: + S: example.xyz + S: + S: + S: + S: + S: + S: USD + S: + S: example.com + S: Premium + S: + S: 2 + S: 10.00 + S: + S: + S: 1 + S: 10.00 + S: + S: + S: 1 + S: 10.00 + S: + S: + S: 15.00 + S: + S: + S: + S: example.net + S: standard + S: + S: 2 + S: 5.00 + S: + S: + S: 1 + S: 5.00 + S: + S: + S: 1 + S: 5.00 + S: + S: + S: 5.00 + S: + S: + S: + S: example.xyz + S: + S: 2 + S: Only 1 year registration periods are + S: valid. + S: + S: + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + +5.1.2. EPP Transfer Query Command + + This extension does not add any elements to the EPP query + command, but it does include elements in the response when the + extension is included in the command service extensions. + + When the query command has been processed successfully, if + the client has included the extension in the command service + element, and if the client is authorized by the server + to view information about the transfer, then the server MAY include + in the section of the EPP response a + element, which contains the following child elements: + + * A element (as described in Section 3.2). + + * A element (as described in Section 3.3). + + * Zero or more elements (as described in Section 3.4) + containing the fees that will be charged to the gaining client. + + * Zero or more elements (as described in Section 3.4) + containing the credits that will be refunded to the losing client. + + Servers SHOULD omit when returning a response to the + gaining client and omit elements when returning a response + to the losing client. + + If no element is included in the response, then no fee + will be assessed by the server for the transfer. + + Example query response: + + S: + S: + S: + S: + S: Command completed successfully; action pending + S: + S: + S: + S: example.com + S: pending + S: ClientX + S: 2019-06-08T22:00:00.0Z + S: ClientY + S: 2019-06-13T22:00:00.0Z + S: 2021-09-08T22:00:00.0Z + S: + S: + S: + S: + S: USD + S: 1 + S: 5.00 + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + +5.2. EPP Transform Commands + +5.2.1. EPP Command + + This extension adds elements to both the EPP command and + response when the extension is included in the command + service extensions. + + When submitting a command to the server, the client MAY + include in the element a element, which + includes the following child elements: + + * An OPTIONAL element (as described in Section 3.2). + + * One or more elements (as described in Section 3.4). + + When the command has been processed successfully, the client + included the extension in the command service extensions, and + a fee was assessed by the server for the transaction, the server MUST + include in the section of the EPP response a + element, which contains the following child elements: + + * A element (as described in Section 3.2). + + * Zero or more elements (as described in Section 3.4). + + * Zero or more elements (as described in Section 3.4). + + * An OPTIONAL element (as described in Section 3.5). + + * An OPTIONAL element (as described in + Section 3.6). + + Example command: + + C: + C: + C: + C: + C: + C: example.com + C: 2 + C: + C: ns1.example.net + C: ns2.example.net + C: + C: jd1234 + C: sh8013 + C: sh8013 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: USD + C: 5.00 + C: + C: + C: ABC-12345 + C: + C: + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: example.com + S: 2019-04-03T22:00:00.0Z + S: 2021-04-03T22:00:00.0Z + S: + S: + S: + S: + S: USD + S: 5.00 + S: -5.00 + S: 1000.00 + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + +5.2.2. EPP Command + + This extension does not add any elements to the EPP command, + but it does include elements in the response when the extension is + included in the command service extensions. + + When the command has been processed successfully and the + client included the extension in the command service + extensions, the server MAY include in the section of the + EPP response a element, which contains the following + child elements: + + * A element (as described in Section 3.2). + + * Zero or more elements (as described in Section 3.4). + + * Zero or more elements (as described in Section 3.4). + + * An OPTIONAL element (as described in Section 3.5). + + * An OPTIONAL element (as described in + Section 3.6). + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: USD + S: -5.00 + S: 1005.00 + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + +5.2.3. EPP Command + + This extension adds elements to both the EPP command and + response when the extension is included in the command + service extensions. + + When submitting a command to the server, the client MAY + include in the element a element, which + includes the following child elements: + + * An OPTIONAL element (as described in Section 3.2). + + * One or more elements (as described in Section 3.4). + + When the command has been processed successfully and the + client included the extension in the command service + extensions, the server MAY include in the section of the + EPP response a element, which contains the following + child elements: + + * A element (as described in Section 3.2). + + * Zero or more elements (as described in Section 3.4). + + * Zero or more elements (as described in Section 3.4). + + * An OPTIONAL element (as described in Section 3.5). + + * An OPTIONAL element (as described in + Section 3.6). + + Example command: + + C: + C: + C: + C: + C: + C: example.com + C: 2019-04-03 + C: 5 + C: + C: + C: + C: + C: USD + C: 5.00 + C: + C: + C: ABC-12345 + C: + C: + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: example.com + S: 2024-04-03T22:00:00.0Z + S: + S: + S: + S: + S: USD + S: 5.00 + S: 1000.00 + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + +5.2.4. EPP Command + + This extension adds elements to both the EPP command and + response when the value of the "op" attribute of the + command element is "request" and the extension is included in the + command service extensions. + + When submitting a command to the server, the client MAY + include in the element a element, which + includes the following child elements: + + * An OPTIONAL element (as described in Section 3.2). + + * One or more elements (as described in Section 3.4). + + When the command has been processed successfully and the + client included the extension in the command service + extensions, the server MAY include in the section of the + EPP response a element, which contains the following + child elements: + + * A element (as described in Section 3.2). + + * Zero or more elements (as described in Section 3.4). + + * Zero or more elements (as described in Section 3.4). + + * An OPTIONAL element (as described in Section 3.5). + + * An OPTIONAL element (as described in + Section 3.6). + + Example command: + + C: + C: + C: + C: + C: + C: example.com + C: 1 + C: + C: 2fooBAR + C: + C: + C: + C: + C: + C: USD + C: 5.00 + C: + C: + C: ABC-12345 + C: + C: + + Example response: + + S: + S: + S: + S: + S: Command completed successfully; action pending + S: + S: + S: + S: example.com + S: pending + S: ClientX + S: 2019-06-08T22:00:00.0Z + S: ClientY + S: 2019-06-13T22:00:00.0Z + S: 2021-09-08T22:00:00.0Z + S: + S: + S: + S: + S: USD + S: 5.00 + S: + S: + S: + S: ABC-12345 + S: 54322-XYZ + S: + S: + S: + +5.2.5. EPP Command + + This extension adds elements to both the EPP command and + response when the extension is included in the command + service extensions. + + When submitting an command to the server, the client MAY + include in the element a element, which + includes the following child elements: + + * An OPTIONAL element (as described in Section 3.2). + + * One or more elements (as described in Section 3.4). + + When the command has been processed successfully and the + client included the extension in the command service + extensions, the server MAY include in the section of the + EPP response a element, which contains the following + child elements: + + * A element (as described in Section 3.2). + + * Zero or more elements (as described in Section 3.4). + + * Zero or more elements (as described in Section 3.4). + + * An OPTIONAL element (as described in Section 3.5). + + * An OPTIONAL element (as described in + Section 3.6). + + Example command: + + C: + C: + C: + C: + C: + C: example.com + C: + C: sh8013 + C: + C: + C: + C: + C: + C: USD + C: 5.00 + C: + C: + C: ABC-12345 + C: + C: + + Example response: + + S: + S: + S: + S: + S: Command completed successfully + S: + S: + S: + S: USD + S: 5.00 + S: + S: + S: + S: ABC-12345 + S: 54321-XYZ + S: + S: + S: + +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 and + tags are not part of the schema; they are used to note + the beginning and end of the schema for URI registration purposes. + + + + + + + + + + + Extensible Provisioning Protocol v1.0 Fee Extension + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +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 + + 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, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, + DOI 10.17487/RFC3688, January 2004, + . + + [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for + the Extensible Provisioning Protocol (EPP)", RFC 3915, + DOI 10.17487/RFC3915, September 2004, + . + + [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying + Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, + September 2009, . + + [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", + STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, + . + + [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) + Domain Name Mapping", STD 69, RFC 5731, + DOI 10.17487/RFC5731, August 2009, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [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, + . + + [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, + . + +9.2. Informative References + + [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible + Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, + February 2015, . + +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 -- cgit v1.2.3