Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
Extracted elements (28)
The extension was created because the expansion of the DNS namespace and novel business models made it impractical for EPP clients to obtain fee information out of band. A standardized protocol mechanism is needed for querying fees associated with billable transactions directly through EPP.
For the <transfer> query command, the server MAY include a <fee:trnData> element in the response only if the client is authorized to view transfer information. Servers SHOULD omit <fee:credit> when responding to the gaining client and omit <fee:fee> when responding to the losing client. If no <fee:trnData> is included, no fee is assessed.
Servers implementing this extension SHOULD support older versions in parallel during a migration period and allow clients to select their preferred version via the <svcExtension> element of the <login> command. When responding to commands that include extension elements, the server SHOULD include only extension elements matching the version present in the command.
A <fee:fee> element MUST have a zero or greater (non-negative) value; a <fee:credit> element MUST have a negative value. When multiple such elements appear in a response, the net fee or credit is the arithmetic sum of all values.
For <fee:period> in <check> responses: if the parent <fee:command> is 'restore', the <fee:period> element MUST NOT be included; otherwise it MUST be included. If no period appeared in the client command, the server MUST return its default period value.
If a <fee:fee> element has a 'grace-period' attribute, it MUST also be refundable (the 'refundable' attribute MUST be true). If the 'refundable' attribute is false, the element MUST NOT have a 'grace-period' attribute. These two attributes are mutually constrained.
If a server implements the registry grace period extension (RFC 3915), it MUST specify the 'grace-period' attribute for all relevant <fee:fee> elements. If the 'refundable' attribute is omitted, clients SHOULD NOT make any assumptions about refundability.
If a server receives a command without required fee extension data, it MUST respond with a 2003 'Required parameter missing' error. If the client-provided total fee is less than the server's calculation or the currency is inappropriate, the server MUST reject with a 2004 'Parameter value range error'.
If a server supports the registry grace period mapping (RFC 3915), it MUST also support the 'restore' value for the fee:command 'name' attribute.
If the 'applied' attribute of a <fee:fee> element is 'delayed', then the <fee:balance> in the response MUST reflect the client's account balance without any fees or credits associated with that command applied.
In both fast-fail and partial-fail error scenarios for <check>, the server MUST set the <fee:cd> 'avail' attribute to false (0) and MUST process all objects in the client request. All failed <fee:command> elements MUST include a <fee:reason> element detailing the failure.
In <check> responses, if the <fee:cd> 'avail' attribute is true and no <fee:fee> elements are present in a <fee:command> element, this indicates no fee will be assessed. If 'avail' is true, the <fee:command> element MUST NOT contain a <fee:reason> element.
In the <check> command, the <fee:check> element MUST contain one or more <fee:command> elements. The server response MUST contain a <fee:chkData> element with a <fee:currency> element and a <fee:cd> element for each object referenced in the client <check> command.
Phase/subphase handling: if the client provides a supported phase/subphase combination, the server MUST return fee data for that combination. If ambiguous (no attributes, multiple active phases), the server MUST respond with 2003 'Required parameter missing'. Unsupported phase or subphase values MUST result in a 2004 'Parameter value range error'. A subphase without a phase MUST also return 2003.
Servers that use the <fee:class> element MUST use the value 'standard' for all objects subject to the standard or default fee, and MUST NOT use values not included in the out-of-band documentation provided to clients.
The <fee:currency> element is OPTIONAL in client commands; if absent, the server MUST determine the currency from server defaults or client account settings agreed via an out-of-band channel. However, the <fee:currency> element MUST be present in all server responses.
The server MUST return avail='0' in a <check> response for any object lacking a <fee:check> extension when the server would fail a domain <create> command without fee data for that object. If fees are ambiguous (multiple possible combinations), the server MUST reject the command with a 2003 error.
The value of <fee:currency> MUST be a three-character currency code from ISO 4217. Servers SHOULD NOT perform currency conversion if a client uses an incorrect currency code; instead, servers SHOULD return a 2004 'Parameter value range error'.
When a <create> command is processed successfully, a fee was assessed, and the client included the fee extension at login, the server MUST include a <fee:creData> element in the response containing fee:currency, zero or more fee:fee and fee:credit elements, and optionally fee:balance and fee:creditLimit.
The <fee:balance> element is an OPTIONAL element in transform command responses indicating the client's remaining account balance, which MAY be negative (indicating an extended line of credit). If a server supports this element, it MUST be included in responses to all transform/billable commands.
The <fee:command> element is used in the EPP <check> command to query fees for a specific command type. Its required 'name' attribute specifies the command (create, delete, renew, update, transfer, restore, or custom), with optional 'phase' and 'subphase' attributes for launch phases and an optional 'customName' attribute when name is 'custom'.
The <fee:creditLimit> element is OPTIONAL in transform responses and indicates the maximum credit available to a client. If a server supports this element, it MUST be included in all transform command responses. A server MAY reject transactions when the absolute value of <fee:balance> equals or exceeds <fee:creditLimit>.
The <fee:period> element specifies a validity period in years ('y') or months ('m') via the 'unit' attribute, derived from <domain:period> of RFC 5731. It is OPTIONAL in <check> commands (server uses default if absent) but MUST be present in <check> responses.
This document registers the 'Registry Fee Extension for the Extensible Provisioning Protocol (EPP)' in the IANA 'Extensions for the Extensible Provisioning Protocol (EPP)' registry (RFC 7451), with status Active and applicability to any TLDs.
This document registers the XML namespace 'urn:ietf:params:xml:ns:epp:fee-1.0' and the XML schema 'urn:ietf:params:xml:schema:epp:fee-1.0' in the IETF XML Registry (RFC 3688), with IESG as the registrant contact.
The fee extension passes financial information over EPP, so confidentiality and integrity protection must be provided by the transport mechanism. All RFC 5730-compliant transports provide the needed protections. The server will only provide financial information relevant to the authenticated client.
The commandEnum simpleType restricts valid 'name' attribute values to: create, delete, renew, update, transfer, restore, and custom. The balanceType and creditLimitType are unrestricted decimals; nonNegativeDecimal has minInclusive of 0; negativeDecimal has maxInclusive of 0.
The fee extension XML namespace is 'urn:ietf:params:xml:ns:epp:fee-1.0'. The currencyType is restricted to exactly three uppercase letters ([A-Z]{3}). The feeType is a nonNegativeDecimal with optional attributes: description (string), lang (language, default 'en'), refundable (boolean), grace-period (duration), and applied ('immediate' or 'delayed').