Thomas, The versions of the fee extension that you reference have similar language associated with returning avail="0" for premium domains:
1. fee-0.23 - https://tools.ietf.org/html/draft-ietf-regext-epp-fees-08#section-4 2. fee-0.21 - https://tools.ietf.org/html/draft-ietf-regext-epp-fees-05#section-4 In both cases it reads: The server MUST return avail="0" in its response to a <check> command for any domain name in the <check> command that does not include the <fee:check> extension for which the server would likewise fail a domain <create> command when no <fee> extension is provided for that same domain name. The very old fee-0.8 version specifies in https://tools.ietf.org/html/draft-brown-epp-fees-05#section-4 "Servers MUST provide clear documentation to clients about the circumstances in which this extension must be used.", which provides flexibility for the server to normalize the behavior as defined in draft-ietf-regext-epp-fees-05, draft-ietf-regext-epp-fees-08, and RFC 8748. This use case was discussed at length in the working group, where returning a premium domain name as available without the required fee to use on create will result in a failure downstream. This is the reason for the language starting in draft-ietf-regext-epp-fees-04. Thanks, -- 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 7/14/20, 5:52 AM, "regext on behalf of Thomas Corte (TANGO support)" <regext-boun...@ietf.org on behalf of thomas.co...@knipp.de> wrote: James, On 7/13/20 21:46, Gould, James wrote: > Thomas, > > Signaling support for fee-1.0 in the login services is not material for this use case. The key element is whether the create of the premium domain name will fail if the client does not know the correct fee and the fee extension is required to be passed on create. I don't see a code breakage scenario here, but I don't know what mix of extensions you're dealing with. So, case in point: once we roll out support for fee-1.0, TANGO will also keep supporting the older fee extension versions fee-0.8, fee-0.21 and fee-0.23 (the RFC recommends to allow older versions to facilitate migration to new versions). Now, none of these old versions had the requirement to report "domain not available" if no fee extension is included in a premium domain check. So, registrars currently using fee-0.21 for example will expect availability checks to truthfully report avail=1 for premium domains in such a scenario. Just the fact that the registry system was updated to also support fee-1.0 should not change the system's behavior from their point of view, should it? Otherwise, they would be forced to change their <domain:check> clients to include the fee extension to get the previous availability results - to accommodate a change caused by a fee extension version they don't even use. 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://secure-web.cisco.com/1tS78h3zvnAPOtomCdUHVDM7D17WfX22p7Pd6zVlMsgS7lzILKOFXHeNh8Isr52cCXcvBSyQkAjKy5zjYK_vBbzpvnNtdI0R5NVrFQzRfv8jgv9C-99xdcmRQKwkeUqvWb4lnu8Tw8WH4t_lgA2ZF8VF4zgoPcDVKXKjN7HgN1owdVTlosmxBYewNDGlYXWIXhTuj4owNa0-n7d-SrGRBiT1FzRcNuu_UpoGGAx_fcq6fRKp8O3O3l_i7I9UzKI0fDJ2m4-Zj8evpLArNgCwbUuU_H8ynwmD9WouiD4aDy68/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
