Re: Proposal: A method in EPP for registry policy discovery

I'm not sure that server policy should be communicated via EPP. EPP is not a general-purpose registry-registrar communications protocol, it's an object provisioning and management protocol.

As an alternative solution, how about this: an additional element in the server <greeting> element that contains a URI, which points to an XML document that describes the policy elements you've suggested? This would have the advantage of being reusable: eg, every CoCCA based registry could point to a policy document on CoCCA's web site.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Global Registry Services
Innovative Registry Services for ccTLD and gTLD registries
https://www.centralnic.com/grs

CentralNic Ltd is a company registered in England and Wales with company
number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.

On 16 Jun 2011, at 17:55, Keith Gaughan <[email protected]> wrote:

> 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
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg