On Dec. 12, 2013, the Internet Engineering Steering Group (IESG) announced the formation of a new working group, Extensible Provisioning Protocol Extensions (eppext). The working group was formed to create an internet Assigned Numbers Authority (IANA) registry of Extensible Provisioning Protocol (EPP) extensions and to review specifications of extensions for inclusion in the registry. EPP is the standard domain name provisioning protocol for generic top-level domain (gTLD) name registries that operate under the auspices of the Internet Corporation for Assigned Names and Numbers (ICANN). It is also used by a number of country code top-level domain (ccTLD) registries.
The “E” in EPP has been both a blessing and a curse. EPP uses features of the Extensible Markup Language (XML) that provide “hooks” for protocol extensions. These hooks make it easy to specify new functionality without having to modify EPP itself. That’s the blessing. The curse has been that easy extensibility has led to multiple independent specifications that describe similar functionality. In a 2010 presentation, Patrick Mevzek (developer of the Net::DRI Perl library that implements EPP) described XML namespaces used in 68 distinct extensions. He further described three different extensions created by different registry operators to provide domain “undelete” functionality. This duplicity of effort makes implementation much more complicated for anyone developing EPP clients.
Some background information will help explain how we got here.
I published the first draft Internet-Draft specifications for the EPP in November 2000. Using my drafts as inputs, the Internet Engineering Task Force (IETF) formed the Provisioning Registry Protocol (provreg) working group in February 2001 to develop a specification that “will allow multiple registrars to register and maintain domain names within multiple Top-Level Domains (TLDs).” EPP was published as a Proposed Standard (RFCs 3730, 3731, 3732, 3733, and 3734) in March 2004. It became a Draft Standard (RFCs 4930, 4931, 4932, 4933, and 4934) in May 2007 and a Standard (Standard 69; RFCs 5730, 5731, 5732, 5733, and 5734) in August 2009.
Domain name registries implement a variety of business models. The difference in these models made it very difficult to come up with a “one-size-fits-all” provisioning protocol, so the provreg working group made a conscious decision to focus on a minimal set of common functionality. EPP was designed to be extensible to allow additional features to be specified on an “as-needed” basis. Guidelines for extending EPP were published as Informational RFC 3735 in March 2004.
The provreg working group was chartered to develop EPP, but not additional extensions, so the working group was closed soon after RFC 3735 was published. As registries began to implement and deploy EPP, the need for extensions became real, and implementers found that multiple extensions were being developed by registries to solve the same basic problems, such as undeleting domain names as noted earlier.
EPP is widely implemented by both gTLD and ccTLD registry operators. ICANN has an active program to delegate a large number of new gTLDs. EPP will be used to provision those domains, and new registry operators will almost certainly develop additional protocol extensions. With no way to coordinate the development of these extensions, the duplication problem is only expected to become worse.
So why is this work important?
It’s important because we’re trying to make it easier for domain name registries and registrars to provide services to registrants. Every protocol extension used by a registry represents a potential implementation obligation for a registrar. If a registrar can implement that obligation once to work with multiple registries, there are benefits to all members of the ecosystem, including:
- Common protocol interfaces to make it easier for registries to attract registrar business partners
- Registrar implementation costs are reduced, allowing registrars to efficiently bring new services to market for multiple TLDs
- Registrants gain access to new services
In addition to defining a specification for registering extensions, the group is reviewing four extension proposals:
- Key Relay Mapping for the Extensible Provisioning Protocol, an extension that describes a method of relaying DNSSEC key material from one DNS operator to another.
- Launch Phase Mapping for the Extensible Provisioning Protocol, an extension that describes provisioning and management of domain name registrations and applications during the launch of a domain name registry.
- Mark and Signed Mark Objects Mapping, an object mapping that describes the format of a mark and a digitally signed mark, referred to as a signed mark and the Signed Mark Data (SMD) file as defined by the ICANN Trademark Clearinghouse.
- Internationalized Domain Name Mapping Extension for the Extensible Provisioning Protocol, an extension that describes the provisioning of Internationalized Domain Names.
This working group is one you should pay attention to if you’re at all interested in the way domain name registries and registrars exchange domain management information. IETF working groups are open to everyone, and all of our work is discussed on public mailing lists. Please join us! The web interface for the eppext mailing list can be found at https://www.ietf.org/mailman/listinfo/eppext.
