Re: Registry Fee Extension for the Extensible Provisioning Protocol

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