Thomas, I provide responses to your questions embedded below.
-- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 6/25/20, 1:33 PM, "regext on behalf of Thomas Corte (TANGO support)" <regext-boun...@ietf.org on behalf of thomas.co...@knipp.de> wrote: Hello, we're currently working on implementing RFC 8748 (EPP Registry Fee Extension) in our registry system, and I just stumbled upon this paragraph in section 4 (Server Handling of Fee Information): "The server MUST return avail="0" in its response to a <check> command for any object in the <check> command that does not include the <fee:check> extension where the server would fail a domain <create> command when no <fee> extension is provided for that same object." If my interpretation of this is correct, this means that the server is supposed to reply avail="0" in a <domain:check> response for all available domains which do not have a standard price, i.e. which require the acceptance of special fees via the fee extension on <domain:create>, unless the client supplies (any?) fee extension in with the <domain:check> command. I admit that I missed this part even in older versions of the draft, so I may be late to the party. Anyhow, I wonder: * Is it a good idea to simply claim that a name is not available, even though it actually *is* available (if the client is ready to pay the special price)? JG - Yes, returning a name as not available is be compliant with the RFC. * Which kind of fee check extension is sufficient to report the name as "available"? What if the registrar merely checks for a renewal price, but not for a create price? Should he still get avail="1", even though he may still be oblivious to the higher registration price? JG - The RFC only specifies that the fee extension needs to be provided to support the create command, so checking the renewal fee is not applicable. I understand that this is maybe another attempt to protect registrars from offering / registering premium names inadvertently, but is it the right way to do this? JG - Yes, returning a premium domain name as unavailable when the create will fail is the right way to do it. Fee-unaware registrars may lose business by reporting names as taken, even though they may be able to register them manually for their customers (without EPP) after determining the price out-of-band. And requiring the fee extension in the transform commands for non-standard prices should be protection enough against inadvertent premium registrations. Also, it seems somewhat questionable to affect the outcome of the plain availability check depending on the presence of the fee extension. JG - There was much discussion around this use case in the working group. Thoughts? Best regards, Thomas -- TANGO REGISTRY SERVICES® Knipp Medien und Kommunikation GmbH Thomas Corte Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: thomas.co...@knipp.de Germany _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1v_YJ06qRdzwmH9Hkg036A-xEBGAaLOxurmipvITWVRFQeyYrMo0C4WbNqva3xaKZcf-i37NRcE9PBISmus8MMBTI9ZMNT9MdtBIiK7wx3eAp5SYV9cZ8nFrBm1ZIfqkduCE3pUYhPuy03eD0w9q4IyIptZBPS2MZ6gWecLS0zbc_3UjY92AFrLuIoldci7mUpZhFAW-PI-AjMLnLmPAYmWMSiIibsygbDVZdcSAZJtZGF0pK-12cQ1zChm4PaAUJ9GSvev_RhbBvNBgyKzFKOg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
