Thomas, Yes, to cover the corner case, avail="0" is the best response when the client does not include "create" in the fee extension of the check command of a premium domain name. Without knowing the create fee of the premium, the create will likely fail, thus avail="0" is the correct answer. The intent of the language in the RFC was to cover the broader case of a client that doesn't pass the fee extension at all in the check command, but your corner case is applicable.
-- 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/26/20, 10:41 AM, "Thomas Corte (TANGO support)" <thomas.co...@knipp.de> wrote: Hello James, On 6/26/20 16:18, Gould, James wrote: > but to cover the intent of the RFC the safest approach is to return avail="0" for a premium domain if the fee extension is not passed in the check command. In my example, the fee extension was passed, but only asking for the *renew* fee (which may be standard), not for the *create* fee (which may be non-standard). Based on your answer above, the server would have to return avail=1" then (because *some* fee extension was passed), however the client would still be unaware that the create fee is non-standard. If the "safest approach" is the goal here, it would probably be better (albeit indeed more implementation effort) to not only require the fee extension, but to specifically require the fee extension checking the "create" price, no? In this case, the RFC text may need a clarification, as it currently doesn't reflect such a specific requirement. I'm aware this is a rare corner case, but still one that should be covered. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: supp...@tango-rs.com Germany _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
