Re: Registry Fee Extension for the Extensible Provisioning Protocol

On 01/11/2013 19:10, Gould, James wrote:
>>>  1. Why extend the check instead of info (e.g. fee info)?
>>
>> Because if the object doesn't exist, the server would have to return a
>> response with a 2303 error, and an <extension> element. While this is
>> permitted, my guess is that most EPP client libraries would see the
>> error first, and therefore would require a special case in order to
>> provide the extension data to the consuming application.
>>
>> Also, by extending the <check> command, you avoid multiple round-trips:
>> the client can query availability and the fee for a <create> in a single
>> command.
>
> I see this a fee info and not either a domain info or a fee check. [snip]

I am now agnostic on whether to use <info> or <check> for this extension
(having previously been in favour of <info>). When I originally wrote
the predecessor to this extension back in 2011, I did have some
reservations about which command to use, and spoke to Patrick Mevzek who
(at the time) agreed with my decision to use <check>.

If anyone else has thoughts about the choice of command to extend,
please speak now!

> Yes I see both cases, since the price might be a factor prior to sending
> the billable command, while returning what the fee was in the billable
> command response would help ensure that the right price was charged.

The latest version adds elements to the responses for <create>, <renew>,
<transfer> and <update>.

>>> 3. It would be good to support a more flexible set of commands, like we
>>> support the concept of sync (consolidate extension) that is also
>>> billable.  There might be other billable commands.
>>
>> This could be achieved by changing the <fee:action> to allow any token,
>> dictated by server policy.
>
> Yes, that is a good idea.

I have an update in the pipe which changes <fee:action> to a token. The
text of the draft requires servers to support the basic EPP command set
as a minimum, plus "restore" if RFC3915 is implemented.

>> The extension isn't designed to allow clients to enumerate the server's
>> fee structure, just to determine the fee associated with a given
>> transaction: this is in line with EPP's status as a provisioning
>> protocol rather than a general purpose information-sharing system.
>
> I see this as a real grey area, since you could have a targeted info
> command for the fee for a specific period or you could have a info command
> for the fee information of an individual billable command.  Knowing
> whether or not there are different fees based on a range of periods may be
> useful as well.  I don't imagine that the ranges will be that many, where
> most will consist of a single range (e.g. Fee X per year from 1 to 10 year
> periods).  The default could be all periods, but supporting multiple
> variable fees with optional period range values and an optional fixed fee
> value could be supported.

I suppose the <fee:fee> element could be allowed to have multiple
occurences, each with a description. For example:

   S:        <fee:chkData xmlns:fee="urn:ietf:params:xml:ns:fee-0.3">
   S:          <fee:domain>example.com</fee:domain>
   S:          <fee:currency>EUR</fee:currency>
   S:          <fee:action phase="sunrise">create</fee:action>
   S:          <fee:period unit="y">3</fee:period>
   S:          <fee:fee desc="Base fee">2.50</fee:fee>
   S:          <fee:fee desc="Sunrise application fee">10.00</fee:fee>
   S:          <fee:fee desc="Multi-year discount">-2.50</fee:fee>
   S:        </fee:chkData>

The client would determine the final fee by totalling the value of each
<fee:fee> element.

Servers would be under no obligation to send more than a single
<fee:fee> element, but could do so if desired.

G.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg