Re: Registry Fee Extension for the Extensible Provisioning Protocol

Hi Gavin,

I'd rather leverage the extension off of the info command and expect the sequence used would be check the info <extension> to see if a domain is available and then check its price.

Why?

The principle of the check command originally was to keep a very cheap command just to verify availability.

In those registries that drop their domains in sequence (versus all at once), the check command is a cheap command that allows registrars competing for a dropped name to verify availability before they trigger a create. (much better than add storms)

Now I know we are talking about an optional extension, but if you want to not have this spiral, then I think you put the extension elsewhere.

We are talking about retrieving clarifying information and it just makes sense that goes under domaininfo (although I totally understand your efficiency argument Gavin, but I think that particular optimization is at the expense of organization)

All Best

Michael Young

On 2013-11-01, at 6:12 AM, Gavin Brown <[email protected]> wrote:

> Hi Jim,
> 
>> 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.
> 
>> 2. How about supporting the use of the extension with the billable
>>    commands themselves as well, where the client can ask for the fee
>>    information and the server can return the information in the
>>    response upon successful execution?  
> 
> That's potentially useful, but my belief was that clients would
> generally prefer to know the cost of a transaction *before* submitting
> it, rather than after it had been received by the server. It would still
> be desirable to include the fee information in the response however, to
> cover the edge case where the fee had changed since it was last checked.
> 
>> 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.
> 
>> 4. The fee could have an optional breakdown as well, where some
>>    billable commands include a fixed fee plus another variable fee
>>    (e.g. based on period extended).  The total fee should obviously be
>>    a total of the more detailed fees.  The type of fees might need to
>>    be flexible as well to support various billing models.  The
>>    Registrar might only be interested in the resulting fee, but having
>>    the breakdown could be useful. 
>> 
>> 5. The client might be interested in any variable pricing based on
>>    periods.
> 
> 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.
> 
> 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



MICHAEL W YOUNG
[email protected]

_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg