Proposal: A method in EPP for registry policy discovery

This proposal comes out of the comments Jothan has been making recently, which
I agree wholeheartedly with.

As a registrar, one of our great problems registry policy discovery. This is
of particular importance with it comes to ccTLDs, whose policies can vary
drastically. For instance:

 * what commands does the registry support with particular objects,
 * what is the lifecycle of a domain in a particular zone,
 * does removing a domain from redemption incur a cost to the registrar,
 * how long after registration, transfer, and renewal must it be before a
   domain can be transferred or renewed,
 * what periods does a registry support for registrations, transfers, and
   renewals,
 * does the registry support the poll command,
 * for contacts, which types does the <postalInfo> element support (this is a
   crapshoot and registries, in my experience, never document this),
 * does the registry support registrant modification,
 * are there per-command limits.

These are just the ones I could think of off the top of my head.

For this, I'd propose a command, possibly called <policy>, which would work
along the following lines. This would take a single child element, either
<objURI> or <extURI>, which would contain the URI of the object or extension
whose policy is being queried. For example, here are some rough sketches of
response:

REQ:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <policy>
    <objURI>urn:ietf:params:xml:ns:epp-1.0</objURI>
  </policy>
</epp>

RES:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <polData>
      <policy>
        <supports>
          <hello/>
          <login/>
          <logout/>
          <poll/>
        </supports>
      </policy>
    </polData>
  </response>
</epp>

REQ:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <policy>
    <objURI>urn:ietf:params:xml:ns:domain-1.0</objURI>
  </policy>
</epp>

RES:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <polData>
      <domain:policy xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:supports>
          <!-- No support for <domain:check> as the registry expects
               registrars to use an external DAC service -->
          <domain:info/>
          <domain:create/>
          <domain:transfer/>
          <!-- This registry supports autorenewal, but not renewal,
               thus <domain:renew> is omitted. -->
          <!-- Omitting <domain:delete> would be like declaring that
               registry requires explicit renewal -->
          <domain:delete/>
          <domain:update/>
        </domain:supports>
        <!-- One or more of these, one for each supported zone -->
        <domain:zone name="gy">
          <!-- Information on the lifecycle such as, supported extension
               periods, maximum period a domain may be renewed up to, &c.
               -->
          <domain:create>
            <domain:period unit="y" default="yes">1</domain:period>
          </domain:create>
          <domain:transfer>
            <!-- Registry supports free transfers only -->
            <domain:period default="yes">0</domain:period>
          </domain:transfer>
          <!-- &c. -->
        </domain:zone>
      </domain:policy>
    </polData>
  </response>
</epp>

REQ:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <policy>
    <extURI>urn:ietf:params:xml:ns:rgp-1.0</extURI>
  </policy>
</epp>

RES:
<?xml version="1.0" encoding="UTF-8"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <polData>
      <rgp:policy xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0">
        <!-- One or more of these, one for each supported zone -->
        <rgp:zone name="gy">
          <!-- Subset of statusValueType - I'm riffing off of CoCCA's
               Pricing and Policy pages here -->
          <rgp:period s="addPeriod" length="1" refund="14"/>
          <rgp:period s="renewPeriod" length="1" refund="14"/>
          <rgp:period s="autoRenewPeriod" length="0" refund="0"/>
          <rgp:period s="transferPeriod" length="0" refund="0"/>
          <rgp:period s="redemptionPeriod" length="28" refund="0"
                      hasRestoreFee="yes"/>
        </rgp:zone>
      </rgp:policy>
    </polData>
  </response>
</epp>

As I said, this is just a rough sketch and needs a lot of work, but I believe
the basic idea to be sound. I'm very much open to any input.

If this is too invasive to the protocol, an alternative would be to have a
standard machine-readable format for registries to publish this information.

-- 
Keith Gaughan, Software Developer
PGP/GPG key ID: 3E896381
Blacknight Internet Solutions Ltd. <http://blacknight.com/>
12A Barrowside Business Park, Carlow, Ireland
Registered in Ireland, Company No.: 370845
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg