On Mon, Nov 23, 2020, at 08:59, Hollenbeck, Scott wrote: > This may be the path of least resistance. I'm still trying to think > through hat would happen if a registry returns an internationalized > email address to a registrar that doesn't expect one. This could happen > after a domain transfer, for example. Is this a problem? If not, maybe > we could just get by without any other protocol changes or extensions.
It may not be a problem in real life, but probably difficult to completely exclude it if we want to make sure the protocol is adapted to all registries' cases out there. There may be a majority (I can't give numbers of course so treat it as an assumption) of cases where registrars do the following: - do the transfer - upon success, create new contacts - update domain with new contacts Whatever case the previous contacts were is then irrelevant for that registrar. The above case solves multiple problems for registrars (retrieving data out of current contacts can be a problem), and creates a new one for registry (explosion of unused contacts, as to solve privacy and association issues registries typically copy contacts upon transfer, so that contacts with the same data can now be in new registrar's portfolio of objects). Note that some registries do solve it differently: the registrar HAS TO provide the new contact IDs at transfer time, ie a transfer can not start before the registrar created its own contacts and associate them with the domain at transfer time. Due to laws like GDPR, maybe this case makes more sense, but part of this space is also more policy than protocol. I would have been happy (but I do not hold my breadth) if there would have been a singular extension or design that would permit any policy such as: - transfer with copy of contacts - transfer except if contacts can not be transfered at the same time (if they are used by multiple domains; it won't be something new, host objects are automatically transferred already) - transfer and set new contacts (either full set provided or only the one to change, I don't know). -- Patrick Mevzek [email protected] _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
