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 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 8/18/21, 8:52 AM, "regext on behalf of Martin Casanova" <regext-boun...@ietf.org on behalf of martin.casan...@switch.ch> 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 regext@ietf.org https://secure-web.cisco.com/119ah4BYqrfpTnBxlYSvz5EA6vhpAgQTUeZQpQrJpUUWUqAl7TN8oBw3TlQdnvRDclpo1xjtBtvVGPE6KBPBc3mCXNS_UTyGxtp5lvv1CiEDjXplfeAxAU6Wy_5md5fz2oNdtvJhhxBNF6jiFsseexLYsfezkbHyJ9Dc-GfZH39p_WyeaAy6EB4gAnaSkUZLFN9_OA3ifh3FE-D65eKH9b_2I7CfeAgySpKZF_79jMTXbKXBvkzwgUtQRXQdKluGL/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
