Subject: Re: [regext] pass on the lower fee

From: "Gould, James" <[email-masked]>
Date: Wed, 18 Aug 2021 12:57:33 +0000

Martin,

If you do return the extension in a poll response it should be included in the greeting services.  My recommendation is to fully implement the registry fee extension along with this so not to cause client confusion.

-- 
 
JG

James Gould
Fellow Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 8/18/21, 8:52 AM, "regext on behalf of Martin Casanova" <[email-masked] on behalf of [email-masked]> wrote:

    Thanks a lot Mario, Thomas and James for your helpful feedback and 
    example that point me all to the same solution!

    One more question: We would only be using a snippet of the fee extension 
    and its namespace in this poll message but not fully implement it.

    Therefore should we include it in the greeting services of the server or 
    not? In any case we need to include the XSD of rfc-8748 in our code 
    since we are validating our own responses.
    We are thinking of an out of band opt in feature for clients to receive 
    such poll messages so if they opt in they should be ready to digest it...

    We are still considering if the impact of this feature on reaching our 
    goals would be big enough to justify the implementation effort. However 
    if so we would welcome a revised version of rfc 8784 that includes this 
    approach.

    Best regards

    Martin

    On 17.08.21 16:53, Thomas Corte (TANGO support) wrote:
    > Hello,
    >
    > On 8/17/21 16:30, Mario Loffredo wrote:
    >
    >> Hi Martin,
    >>
    >> at .it we renew every domain automatically but the fee is always the same.
    >>
    >> However, if I understood well, it seems to me that a possible solution
    >> might be a combination of the extensions defined in the two RFCs.
    >>
    >> After all, RFC5730 allows to include more elements in the extension
    >> section of an EPP response.
    > I'd agree that a combination of the changePoll and fee response
    > extensions could be used here, but there are minor problems (see below).
    >
    >> You can use a poll message including as extensions the
    >> changePoll:changeData element, to convey that the operation child is
    >> "autoRenew", plus the fee:renew element, to convey the applied fee.
    > In RFC 8748, <fee:renew> is defined for commands, while <fee:renData> is
    > defined for (transform) responses, so <renData> seems more appropriate.
    >
    > One problem here is that the poll response in this case isn't strictly
    > the response to any (client) transform command.
    >
    > Actually, RFC 8748 explicitly states
    >
    >    "This extension does not add any elements to the EPP <poll> or <info>
    >     commands or responses."
    >
    > which indicates that this use case (delivering fees for unsolicited,
    > server-initiated actions in poll messages) isn't really covered by the
    > EPP fee extension yet, even if including them in poll responses is
    > syntactically allowed as far as the XSD is concerned. However, registrars
    > supporting the fee extension are unlikely to expect fee information in
    > this place.
    >
    > But I think support for this use case should be added to a revised
    > version of RFC 8748.
    >
    > Best regards,
    >
    > Thomas
    >

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/119ah4BYqrfpTnBxlYSvz5EA6vhpAgQTUeZQpQrJpUUWUqAl7TN8oBw3TlQdnvRDclpo1xjtBtvVGPE6KBPBc3mCXNS_UTyGxtp5lvv1CiEDjXplfeAxAU6Wy_5md5fz2oNdtvJhhxBNF6jiFsseexLYsfezkbHyJ9Dc-GfZH39p_WyeaAy6EB4gAnaSkUZLFN9_OA3ifh3FE-D65eKH9b_2I7CfeAgySpKZF_79jMTXbKXBvkzwgUtQRXQdKluGL/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Wed, 18 Aug 2021 15:07:56 +0200

Hello,

> If you do return the extension in a poll response it should be included in the greeting services.  My recommendation is to fully implement the registry fee extension along with this so not to cause…

Agreed, adding it to the greeting and then only implement it where it
isn't really expected (as per this version of the RFC) sounds like bad
practice.
Though I wonder which price the implementation of <fee:check> would even
return for the "renew" command if its price is dependent on a property of
the domain (signed/unsigned) that isn't known at the time of the check...

I'm usually not a fan of proprietary extensions, but this sounds like a
case where it seems prudent to introduce one.

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: [email-masked]
Germany