For Donuts, it would be very important that if the registrar does not pass in the fee extension on the check, that the domain return unavailable when premium. The response reason should indicate that it is unavailable because the name is premium and no fee extension was present in the request.
The check command is a hint that indicates success of a create command. We don't want to indicate that a create will succeed in the case of a premium name and no fee extension. I foresee the lack of that breaking many registrars as we have many that do not participate in selling premium names. I apologize that I could not attend to discuss in person. On Thu, Mar 30, 2017 at 6:09 AM Thomas Corte <thomas.co...@knipp.de> wrote: > Hello Jody, > > On 2017-03-30 14:49, Jody Kolker wrote: > > >> I hope we can agree that in such a situation, the *only* useful fee > >> information (e.g. about the cost for a transfer of an affected > >> domain) is the *actual* fee attached to the existing domain object, > >> and not the *theoretical* (lower) fee that would be charged if the > >> same name was recreated in the system that was reconfigured since > >> the domain was created, no? > > > > Thomas - as a registrar that might be able to register/renew/transfer > > the domain, I only care what the domain would cost for be to perform > > those actions at the current time or a phase in the future. I'm not > > concerned with the cost in the past as I have already been charged > > for that cost and I should have logging or other form of > > documentation to prove it. > > Sure, that's reasonable (and trust me, I'm wearing my registrar hat > often enough to be very aware of a registrar's needs when it comes to EPP). > But I'm not talking about returning fees from the past, I'm talking > about returning future fees that are determined by a specific domain's > past, such as the point in time when it was created. > > In the real-world scenario I described, it is possible that the monthly > transfer/renewal fee for a domain is f1, and to find f1 the server has > to actually look at the domain in the database to retrieve the launch > phase lp1 in which the domain was originally created. Note that lp1 may > already be over, but still determines the fee f1 charged for domains > created in it. If the same domain was deleted and recreated after the > RGP (then in a different launch phase lp2), the monthly transfer/renewal > fee would be f2 instead, with f2 potentially being different from f1. > > Now, what I'm saying is that a <fee:check> command asking for the costs > for a transfer/renewal of the domain created in lp1 should return f1 > rather than f2, since only f1 represents the actual fee the server will > charge for the domain. This speaks in favor of a "dynamic" fee lookup > potentially involving the actually registered domain, rather than just > looking at the system's current "static" fee configuration. > > 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 > -- Chris Cowherd, CTO Donuts Inc.
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
