Hi Martin, I can speak only from my side.
we parse the greating and activate from the response different modules in our software. If the namespace is not included, we have to manually add it somewhere. Regards Marco Am 18.08.21 um 14:51 schrieb Martin Casanova: > > 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://www.ietf.org/mailman/listinfo/regext Marco Schrieck Bereichsleiter Entwicklung -- InterNetX GmbH Johanna-Dachs-Str. 55 93055 Regensburg Germany Tel. +49 941 59559-0 Fax +49 941 59579-050 www.internetx.com www.facebook.com/InterNetX www.twitter.com/InterNetX Geschäftsführer: Thomas Mörz (CEO), Hakan Ali Amtsgericht Regensburg, HRB 7142 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
