On Tue, Jul 14, 2020, at 07:26, Thomas Corte (TANGO support) wrote: > Based on this experience, I'm afraid it will take a long time until > fee-1.0 will be widely adopted by registries or registrars, if ever.
It was exactly the same situation when EPP was being specified, registries implemented it before epp-1.0 went out as an RFC, and it took several years for "EPP 0.7" to disappear (its most notable difference was on the transport part, where the frame didn't have the length prefixed). But it did disappear finally, so not all hopes are lost :-) It is a classical chicken and egg problem based on the fact that registries, once they got one version working have no or very little incentive to change (being similar as other registries is not a strong force for them) and for registrars as long as not all registries do the same thing they have anyway to code for the extra case and then once they done it for one registry they could as well use that for others. So for registries they have only one case to handle, where registrars have many but for registries each registrar is like any other, besides its market position eventually. However, for a non trivial number of players in this game they are bound by contracts that can basically force them to implement new standards after some given delay. But that wouldn't apply for ccTLDs where each registry is king in its kingdom. Besides market pressure, that has its limits here, I see only contractual forces able to move things around. As for the technical level, I am not sure anything can be done. Even if you add in all drafts something like "this draft version 0.971268413 MUST NOT be used after the RFC is published with version 1.0", it wouldn't prevent the current situation in practice (you would just have stronger text in the RFC to point implementors to). Maintaining a public list of what each registries support (as a gentle nudge) may not help, nor something like https://github.com/dns-violations/ I would eye towards something close to TLS "Grease" framework, but I am really not sold that any technical solution can solve the problem there. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
