Patrick, Do you mean it's better to fail the login if the client doesn't support all of the possible EPP extensions supported by the poll queue? I view that option as being highly impactful to the clients and it would morph a certain set of services as required by the client at login, which does not currently exist in EPP. The approach taken in draft-ietf-regext-unhandled-namespaces will not impact clients at login, will not cause a poison message in the poll queue, provides an indication that an extension is not supported, and provides the extension to the client in a protocol compliant manner for later processing if desired.
There has been no indication from the working group of a technical risk with implementing draft-ietf-regext-unhandled-namespaces. I agreed to add text to explicitly state that draft-ietf-regext-unhandled-namespaces extends the use of the <extValue> element within section 3 "Use of EPP <extValue> for Unhandled Namespace Data", and to add an Implementation Considerations section to cover the recommendation of client and server monitoring to mitigate a client ignoring content returned by the server. -- 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 11/2/20, 10:16 AM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Tue, Oct 27, 2020, at 10:55, Thomas Corte wrote: > If a registry really wants registrars to understand and process their > custom poll messages, it can still resort to simply reject the <login> > command if it doesn't contain the namespace in question. That would certainly have my preference and it has one big bonus attached to it: no need of any change in the protocol, no need of any new extension/namespace, no need of any new specification. Sometimes the best solutions are not the technical ones. And it is not so much a stretch: many, but not all, registries mandate a "technical accreditation" at the beginning of the relationship with a given registrar. Adding a requirement there to support some namespaces is not a big change (a registrar is free of course to signal it during login and then just ignore those messages if he wants to ignore them, but then the responsibility clearly falls on his end and he is in control of his fate because he signaled the namespaces at login, without the registry forcing delivery to it of messages with "dubious" validity per RFC 5730). -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1E73rcs2l3iOpYDTtf4HlaAiULSq3R3UdqpRjAi55QTW-RXUeEqWrgJtJdDriw22K3nr_pIqXo325kguNJzfXgsWVhWpk0DOwWVtdVTf30Hn82dNXT4Z2n97-z9SnE-ijPC04qfQvvCuEAh1sYF37hFY24wfhhiHkw-4M52Qtd4y_nwedk3GWSHBTay1c-esqKc8GULE6Gbg-FftXmkyWGwsB_2u9YIo962MahDtgLBC-cfmAE1pB3G4x_UfFpQW2Ma4oLvOL4HgbKxIQ5xD4Q915Y9uxCivhZWiAE36XUuw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
