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://www.ietf.org/mailman/listinfo/regext
