@Tomas I could see someone submitting a non-conforming fee extension in the check command to trick the registry into providing basic availability or taken of a name.
Possible: perhaps Probable: unlikely You make a good point that the respective command, especially billable events, should perhaps check that the appropriate fee extension was sent. Depending upon the registry implementation, this could theoretically work, but a registrar would still have to pay the respective registry designated fee for a create/renew/transfer, I am working very hard to imagine why someone would go to the trouble of sending the wrong fee extension with a command if they were going to be sending one at all. Jothan Frakes On Fri, Jun 26, 2020 at 7:47 AM Gould, James <jgould= 40verisign....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
