[gnso-vi-feb10] Registrant Choice and EPP extensions

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

All,

Keeping in mind that we're no longer working in the original EPP
universe of six registries and sixty registrars, but a universe in
which the number of possible registries and the number of possible
registrars are of the same order of magnitude, how can a registrar
programatically discover what RSP choices are available for a
namespace, and similarly, what registrars are accredited with the
registry operator?

Restated, how does a registrar select the best choice for the registry
function among a market of registry service providers, which could be
as simple as discovering the lowest available price, and how does a
registrar set its own offer, competitively in the market for registrar
service providers?

Finally, how does a registrant select the best choice for the registry
function among a market of registry service providers, through the
market of registrar choice available to the registrant?

These are naturally incorporated in the EPP services discovery service
element. The <svcMenu> element identifies the services supported by
the server.

A (C)lient (Registrar, acting for a Registrant) sends a hello:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
   C:  <hello/>
   C:</epp>

A (S)server registry services provider (the default, acting for the
Registry Operator) sends a response:

   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
   S:     epp-1.0.xsd">
   S:  <greeting>
   S:    <svID>Example EPP server epp.example.com</svID>
   S:    <svDate>2000-06-08T22:00:00.0Z</svDate>
   S:    <svcMenu>
   S:      <version>1.0</version>
   S:      <lang>en</lang>
   S:      <lang>fr</lang>
   S:      <objURI>urn:ietf:params:xml:ns:obj1</objURI>
   S:      <objURI>urn:ietf:params:xml:ns:obj2</objURI>
   S:      <objURI>urn:ietf:params:xml:ns:obj3</objURI>
   S:      <svcExtension>
   S:        <extURI>urn:ietf:params:xml:ns:nsp-ids</extURI>
   S:        <extURI>urn:ietf:params:xml:ns:rr-ids</extURI>
   S:      </svcExtension>
   S:    </svcMenu>
   S:    <dcp>
   S:      <access><all/></access>
   S:      <statement>
   S:        <purpose><admin/><prov/></purpose>
   S:        <recipient><ours/><public/></recipient>
   S:        <retention><stated/></retention>
   S:      </statement>
   S:    </dcp>
   S:  </greeting>
   S:</epp>

In the example above, the server is announcing the availability of two
extensions:

      urn:ietf:params:xml:ns:rsp-ids

and

      urn:ietf:params:xml:ns:rr-ids

With that, the RSPs are discoverable, and therefore available, to the
registrar, and therefore the registrant, and the competing registrars
are also discoverable to the registrar.

The registrar is now free to make a competitive offer to the
registrant, based upon the offered price of the registry service
provider, and possibly other factors, and is capable of making its
offer with an awareness of what registrar choices are available to the
registrant, and therefore free to make the best offered price on the
data available to it.

Eric