Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
GoDaddy Inc.
14455 N. Hayden Rd. #219
Scottsdale
AZ
85260
United States of America
rcarney@godaddy.com
http://www.godaddy.com
CentralNic Group plc
35-39 Moorgate
London
EC2R 6AR
United Kingdom
+44 20 33 88 0600
gavin.brown@centralnic.com
http://www.centralnic.com
jothan@jothan.com
http://jothan.com
Applications and Real-Time
Registration Protocols Extensions
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.
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)
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) . 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.
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
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.
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.
Extension Elements
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 .
- "delete", indicating a <delete> command as defined in .
- "renew", indicating a <renew> command as defined in .
- "update", indicating a <update> command as defined in .
- "transfer", indicating a <transfer> command as defined in
.
- If the server supports registry grace period mapping ,
then the server MUST also support the "restore" value as defined in
.
- "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
. It may also contain an OPTIONAL
"subphase" attribute identifying the custom or subphase as described in
.
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 .
Note that 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.
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
.
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.
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 ), and a
credit will result in adding to the Account Balance (described in ).
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 ,
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).
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 ) or when an object is
deleted during the relevant grace period (see ).
If the "refundable" attribute is omitted, then clients SHOULD NOT
make any assumptions about the refundability of the fee.
Grace Periods
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 , 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.
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.
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".
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 ).
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.
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">).
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.
"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 . 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 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".
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
, 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
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):
-
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: example.xyz
S: Only 1 year registration periods are
S: valid.
S:
]]>
-
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: 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 <fee:cd>
"avail" attribute to false (0), and the server MUST process all objects in
the client request.
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".
EPP Command Mapping
A detailed description of the EPP syntax and semantics can be found in
.
EPP Query Commands
This extension does not add any elements to the EPP <poll> or
<info> commands or responses.
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 ), an OPTIONAL "phase" attribute, and an OPTIONAL
"subphase" attribute (see ). The <fee:command>
element(s) MAY have the following child elements:
- An OPTIONAL <fee:period> element (as described in ).
Example <check> command:
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 <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 ).
- 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
). 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 ), 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 ), 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 ).
- Zero or more <fee:credit> elements (as described in
).
- An OPTIONAL <fee:reason> element (as described in ).
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:
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:
]]>
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 ).
- A <fee:period> element (as described in ).
- Zero or more <fee:fee> elements (as described in ) containing the fees that will be charged to the gaining client.
- Zero or more <fee:credit> elements (as described in
) 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:
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:
]]>
EPP Transform Commands
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
).
- One or more <fee:fee> elements (as described in ).
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 ).
- Zero or more <fee:fee> elements (as described in ).
- Zero or more <fee:credit> elements (as described in ).
- An OPTIONAL <fee:balance> element (as described in ).
- An OPTIONAL <fee:creditLimit> element (as described in ).
Example <create> command:
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 <create> response:
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:
]]>
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 ).
- Zero or more <fee:fee> elements (as described in ).
- Zero or more <fee:credit> elements (as described in ).
- An OPTIONAL <fee:balance> element (as described in ).
- An OPTIONAL <fee:creditLimit> element (as described in ).
Example <delete> response:
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:
]]>
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 ).
- One or more <fee:fee> elements (as described in ).
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 ).
- Zero or more <fee:fee> elements (as described in ).
- Zero or more <fee:credit> elements (as described in ).
- An OPTIONAL <fee:balance> element (as described in ).
- An OPTIONAL <fee:creditLimit> element (as described in ).
Example <renew> command:
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 <renew> response:
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:
]]>
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 ).
- One or more <fee:fee> elements (as described in ).
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 ).
- Zero or more <fee:fee> elements (as described in ).
- Zero or more <fee:credit> elements (as described in ).
- An OPTIONAL <fee:balance> element (as described in ).
- An OPTIONAL <fee:creditLimit> element (as described in ).
Example <transfer> command:
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 <transfer> response:
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:
]]>
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 ).
- One or more <fee:fee> elements (as described in ).
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 ).
- Zero or more <fee:fee> elements (as described in ).
- Zero or more <fee:credit> elements (as described in ).
- An OPTIONAL <fee:balance> element (as described in ).
- An OPTIONAL <fee:creditLimit> element (as described in ).
Example <update> command:
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 <update> response:
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:
]]>
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.
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. 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.
Extensible Provisioning Protocol v1.0 Fee Extension
]]>
Security Considerations
The mapping extensions described in this document do not provide any
security services beyond those described by the EPP , the EPP domain
name mapping , 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
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.
IANA Considerations
XML Namespace
This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in .
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 of this document.
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 . 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
References
Normative References
Codes for the representation of currencies
ISO
XML Schema Part 1: Structures Second Edition
Informative References
Acknowledgements
The authors wish to thank the following persons for their feedback and
suggestions:
- of Verisign Inc.
- of ISC
- of Google
- and of Knipp
- , , and of GoDaddy
- of Com Laude
- of Impetus Infotech
- of Nic.at
- of Knipp Medien und Kommunikation GmbH