Marco,
The issue is associated with a transition state when one side of the connection (registrar or registry) supports EAI while the other does not, the email element is required by the protocol, and the only value available is an EAI address. The EAI-supporting side can’t pass the EAI value since is known that the other side doesn’t support it based on the EPP greeting or login services. The proposal in the draft is to pass a predefined placeholder value ([email protected]<mailto:[email protected]>) to signal the existence of an EAI value to a non-EAI supporting party, which is temporary until both parties support EAI. This is a corner case that needs to be considered until both sides support EAI. Let's consider some specific examples: 1. EPP Contact <create> Command (https://datatracker.ietf.org/doc/html/rfc5733#section-3.2.1) – The <contact:email> element is required, which poses an issue when the registrar supports EAI and the registry does not support EAI. What should the registrar pass to the non-EAI supporting registry? Collecting an ASCII and EAI email address for this case may be logical, but it’s counter to the goal of supporting EAI, since the registries that the registrar interfaces with can have a mix of EAI support. 2. EPP Contact <info> Response (https://datatracker.ietf.org/doc/html/rfc5733#section-3.1.2) - The <contact:email> element is required, which poses an issue when the registry supports EAI and the querying registrar does not support EAI. The querying registrar could be any registrar and not just the sponsoring registrar, where there is only a single email value in the registry that is an EAI address for this use case. What should the registry return to the non-EAI supporting registrar? This case is even more challenging then case #1 since registry has a single value and there can be a mix of EAI supporting querying registrars. One alternative is to return an error response (e.g., 2308 “data management policy violation”) instead of a successful response with a predefined placeholder value, but that seems harsh to me. I believe the use of a predefined placeholder value is the best approach to handle this transition corner case in the protocol, but I would like to hear viable alternates from the working group to incorporate into the draft. Thanks, -- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/2/21, 9:12 AM, "regext on behalf of InterNetX - Marco Schrieck" <[email protected] on behalf of [email protected]> wrote: Hi All, I am completely with Ulrich. >From policy side and also from aspect of clean data. Using dummy values in objects was always a bad idea. And even in GTLD space, the registrar usually have requirements to verify the contacts. So not only registry must support the EAI also the registrar have to do it. Regards Marco Am 02.08.21 um 14:47 schrieb Dmitry Belyavsky: > Hello Regext, > > First, many thanks to James for his presentation of the draft update. > As it was suggested, let's move the discussion to the ML. > > As usual with EAI, we have a chicken-and-egg problem. I agree with > Ulrich, that using a placeholder instead of a regular address doesn't > leave a Registry any option to communicate with a domain administrator > via email. But enforcing the domain administrator using a valid ASCII > address effectively stops it from moving to EAI. So placeholder is > implied to be a temporary measure until EAI is not widely supported. I > understand that the support of EAI will be different in different CC > TLDs, but I think it's worth supporting such addresses in the GTLDs. > > I agree that the question is about the intersection of the technical > aspects (where it's reasonable to provide the placeholder to make the > object created), legal stuff (where the valid address may be required) > and policy stuff (that imply the EAI addresses should be treated as just > email addresses). > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > regext mailing list > [email protected] > https://secure-web.cisco.com/1knrAJeJSAijatcnZRFL2-q2sa9iAqop6c6aXEBkL5u98WhGqbukYOUR__gp59Q-GPk2aFY1BoKzb6RlNpmY12zqTx4AeARpNRf5ZNCoFRN9Nedd7nMTqIDLZrfj5EITKSKGL_pUoITxWiuxLvHGVhT7Hp_XNuKkpIe9HRifjofrBMrGzk3MoG1Fd6Of8Iw4VRUlKNTt5fmkSfKcfkwApqjGCFzFx86_1QIEGwora_SXwhwOpVIZb1Ter2ZZdWvy0N-TnIZceYeRBalZr7K1nnA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext > _______________________________________________ regext mailing list [email protected] https://secure-web.cisco.com/1knrAJeJSAijatcnZRFL2-q2sa9iAqop6c6aXEBkL5u98WhGqbukYOUR__gp59Q-GPk2aFY1BoKzb6RlNpmY12zqTx4AeARpNRf5ZNCoFRN9Nedd7nMTqIDLZrfj5EITKSKGL_pUoITxWiuxLvHGVhT7Hp_XNuKkpIe9HRifjofrBMrGzk3MoG1Fd6Of8Iw4VRUlKNTt5fmkSfKcfkwApqjGCFzFx86_1QIEGwora_SXwhwOpVIZb1Ter2ZZdWvy0N-TnIZceYeRBalZr7K1nnA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
