| Internet-Draft | balance | July 2025 |
| Gould | Expires 29 January 2026 | [Page] |
This document describes an Extensible Provisioning Protocol (EPP) mapping for retrieving the client balance and other financial information.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 January 2026.¶
Copyright (c) 2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
This document describes an extension mapping for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730]. This EPP mapping enables a client to get their financial information including the balance, credit limit, available credit, and credit threshold.¶
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, XML specifications and examples provided in this document MUST be interpreted in the character case presented in order to develop a conforming implementation.¶
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. In examples, indentation and whitespace are provided only to illustrate element relationships and are not a required feature of this protocol.¶
"balance-0.1" is used as an abbreviation for "urn:ietf:params:xml:ns:epp:balance-0.1". The XML namespace prefix "balance" is used, but implementations MUST NOT depend on it. Instead, they are to employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents.¶
All of the EPP Balance currency object attributes use the XML decimal data type to represent the currency value in the currency of the server. The precision is restricted to 2 fractional digits.¶
Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in XML Schema Part 2 MUST be used to represent date-time values, as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters.¶
The EPP <poll> command and response is defined in section 2.9.2.3 of [RFC5730]. For servers that support a credit threshold, the Balance Info Response, as defined in Section 3.1.2, is inserted into the poll queue whenever the available credit for an account reaches or goes below the credit threshold.¶
Example <poll> 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: <poll op="req"/> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>¶
Example low balance <poll> response:¶
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
<response>
<result code="1301">
<msg>Command completed successfully; ack to dequeue</msg>
</result>
<msgQ count="1" id="12345">
<qDate>2020-09-01T15:25:01.0078Z</qDate>
<msg>Low Account Balance</msg>
</msgQ>
<resData>
<balance:infData
xmlns:balance="urn:ietf:params:xml:ns:epp:balance-0.1">
<balance:currency>USD</balance:currency>
<balance:creditLimit>1000.00</balance:creditLimit>
<balance:balance>800.00</balance:balance>
<balance:availableCredit>200.00</balance:availableCredit>
<balance:creditThreshold>500.00</balance:creditThreshold>
</balance:infData>
</resData>
<trID>
<clTRID>ABC-12345</clTRID>
<svTRID>54322-XYZ</svTRID>
</trID>
</response>
</epp>¶
A detailed description of the EPP syntax and semantics can be found in the EPP core protocol specification [RFC5730]. The command mappings described here are specifically for use with the Balance Object Mapping.¶
EPP [RFC5730] provides three commands to retrieve object information: <check> to determine if an object is known to the server, <info> to retrieve detailed information associated with an object, and <transfer> to retrieve object transfer status information.¶
Available check semantics do not apply to balance objects, so there is no mapping defined for the EPP <check> command.¶
EPP provides the <info> command that is used to retrieve client balance and other financial information for the currently logged-in client. In addition to the standard EPP command elements, the <info> command MUST contain a <balance:info> element that identifies the balance namespace. The <balance:info> element does not contain any child elements.¶
Example <info> 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: <info> C: <balance:info C: xmlns:balance="http://www.verisign.com/epp/balance-0.1"/> C: </info> C: <clTRID>ABC-12345</clTRID> C: </command> C:</epp>¶
When an <info> command has been processed successfully, the EPP <resData> element MUST contain a child <balance:infData> element that identifies the balance namespace. The <balance:infData> element contains the following child elements:¶
Example <info> response 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: <balance:infData S: xmlns:balance="urn:ietf:params:xml:ns:epp:balance-0.1"> S: <balance:currency>USD</balance:currency> S: <balance:creditLimit>1000.00</balance:creditLimit> S: <balance:balance>200.00</balance:balance> S: <balance:availableCredit>800.00</balance:availableCredit> S: <balance:creditThreshold>500.00</balance:creditThreshold> S: </balance:infData> S: </resData> S: <trID> S: <clTRID>ABC-12345</clTRID> S: <svTRID>54322-XYZ</svTRID> S: </trID> S: </response> S:</epp>¶
Transfer semantics do not apply to balance objects, so there is no mapping defined for the EPP <transfer> command.¶
EPP provides five commands to transform objects: <create> to create an instance of an object, <delete> to delete an instance of an object, <renew> to extend the validity period of an object, <transfer> to manage object sponsorship changes, and <update> to change information associated with an object.¶
Create semantics do not apply to balance objects, so there is no mapping defined for the EPP <create> command.¶
Delete semantics do not apply to balance objects, so there is no mapping defined for the EPP <delete> command.¶
Renew semantics do not apply to balance objects, so there is no mapping defined for the EPP <renew> command.¶
Transfer semantics do not apply to balance objects, so there is no mapping defined for the EPP <transfer> command.¶
Update semantics do not apply to balance objects, so there is no mapping defined for the EPP <update> command.¶
The EPP Balance Mapping schema is presented here.¶
The formal syntax shown here is a complete XML 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 XML Schema; they are used to note the beginning and ending of the XML Schema for URI registration purposes.¶
<CODE BEGINS>
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:balance="urn:ietf:params:xml:ns:epp:balance-0.1"
targetNamespace="urn:ietf:params:xml:ns:epp:balance-0.1"
elementFormDefault="qualified">
<annotation>
<documentation>Extensible Provisioning Protocol v1.0
Account balance and other financial information mapping.
</documentation>
</annotation>
<!--
Child elements found in EPP commands.
-->
<!-- Empty balance:info command element -->
<element name="info" />
<!--
Child response elements.
-->
<element name="infData"
type="balance:infDataType" />
<!--Child elements of the balance:infData element -->
<complexType name="infDataType">
<sequence>
<element name="currency"
type="balance:currencyType" />
<element name="creditLimit"
type="balance:currencyValueType" />
<element name="balance"
type="balance:currencyValueType" />
<element name="availableCredit"
type="balance:currencyValueType" />
<element name="creditThreshold"
type="balance:currencyValueType"
minOccurs="0"/>
</sequence>
</complexType>
<simpleType name="currencyType">
<restriction base="string">
<pattern value="[A-Z]{3}" />
</restriction>
</simpleType>
<simpleType name="currencyValueType">
<restriction base="decimal">
<fractionDigits value="2" />
</restriction>
</simpleType>
</schema>
<CODE ENDS>¶
This document uses URNs to describe XML namespaces and XML schemas conforming to a registry mechanism described in [RFC3688]. The following URI assignment has been made by IANA:¶
Registration request for the balance namespace:¶
Registration request for the balance XML Schema:¶
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:¶
The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730] and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well.¶
Financial information is confidential information for a client, so the server MUST have access control restrictions in place to limit access to financial information of the currently logged-in client.¶