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. -- 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/10/20, 5:48 AM, "regext on behalf of Thomas Corte (TANGO support)" <regext-boun...@ietf.org on behalf of thomas.co...@knipp.de> wrote: Hello, On 6/26/20 16:18, Gould, James wrote: > The goal is to cover the case of a client not passing the fee extension at all, with the assumption that the fee extension would reference the create command. It's simpler to make the case based on the existence or non-existence of the fee extension in the check command, but there may be cases were the renew fee matches the create fee. It's up to the server to determine whether a particular domain will fail on create without the client having the correct non-standard fee. I realize that there are corner cases where the client may know the fee, based on assuming that the create fee matches the renew fee, or the fees are provided out-of-band to EPP, 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. > > 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 for which the server would likewise fail a > domain <create> command when no <fee> extension is provided for that > same object. Another clarifying question: the above only needs to happen if the client at least signaled its general understanding of the fee-1.0 extension in the EPP <login> command, correct? Otherwise (i.e., if the server needs to report premiums as unavailable even to clients who are not aware of fee-1.0), this RFC would be asking for a change in a server's behavior just by virtue of introducing support for fee-1.0, which would mean that clients not using any fee extension (or an older version which didn't yet have this requirement) would see an unexpected code-breaking change, no? 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/1XzwM8MKi6M1-HWG_c8XsyUrX-tt-VgbAlfTCUGb9Lx3MPgi6UDluTdlcRJFP7royaFdSgSNGny3bfC_scy0lFWmNl2_VVRop-NJI7XZAzEB1O09cQoiuiWOf9SYkj1kOJgngNMpWzGKkNFu2Lq7fRoaaJuKQ-dMEeX6ea3dw76nsG7kwWiPr5kvbge0cv48mJ2SaTaGuPbv5QK-_UsaJLuvPu58h3fo0Q3TqOm2Pj_lwO3Bi490P_YnBubP0klINpMjZwVB12xL3FsXgxjU9vQ/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
