Re: [regext] RFC 8748, EPP Registry Fee Extension: availability check result depending on fee extension?

[Jothan Frakes <[e-mail]>]

@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=
[e-mail]> 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
> [e-mail]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 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)" <
> [e-mail]> 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: [phone]
>     Martin-Schmeisser-Weg 9                       Fax: [phone]
>     D-44227 Dortmund                       E-Mail: [e-mail]
>     Germany
>
>
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>