Registry Fee Extension for the Extensible Provisioning Protocol (EPP)
RFC 8748
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
Show full document text