Marco, I fully understand the need and desire for a valid email address, but the protocol is forcing us to consider this corner case during the EAI transition with the communication between the registrar and registry. RFC 5733 requires a non-empty email element in a create command and info response, so having a nonexistent value is not an option. Adding another extension that contains the actual value runs into the same EAI support corner case, where a placeholder value will be needed to satisfy RFC 5733. Do you have a proposal on how to handle the two cases (create command when the registry doesn't support EAI and info response when the registrar doesn't support EAI) in RFC 5733 when there is a EAI support mismatch? A non-empty value is needed and all that is available is an EAI value.
Any thoughts or proposals is appreciated. 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, 10:49 AM, "InterNetX - Marco Schrieck" <[email protected]> wrote: Hi James, I have an example how such information is used. For example a system that parse this information before transfer so that have a domain with complete contact data. That system do not get any error and would automatically receive an valid email. After that the system try to validate the email adress if email adresse cant get validated maybe the domain get deactivated. Maybe there are also such process, at registry side. That remind me a little on the "REDACTED FOR PRIVACY" in whois as email. :) But here the client parsing was broken, so you can see the errors. So from my perspective its better to have an no existient value than a wrong one. And I think clients should be aware of it because we have also a disclose feature. So if you have a EAI on registry and client do support it, it should be empty and maybe add an extension where the real value is. For the other side, client support EAI and Server not it can only be prohibited. Regards Marco Am 02.08.21 um 15:50 schrieb Gould, James: > 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://secure-web.cisco.com/1f1Ax9pnY3mVz-CMgO2kjfekBxVFdzs69vEHKtnW1Ig5DhfsMABiI9JSHLEzfDBso-nsXfgKONE2O6J6wiuJQatSCKd9_KdDaj7mhleLFPghcrhjG8I4FA287-9m5VbcZgELFp7FzgKqWMCgt4dqJ315XOV39n57QUY2d8ZQf8TfSU3tCmPlV9UWYemkcceq94pLLz4ohcp9cEEcR9nMHF6hM6xgfrfjyIqq4wK16myMbs5_XU5aDPjN3AByXtYLjxNgS-iOhb92vTIJfRnxyqQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5733%23section-3.2.1 > <https://secure-web.cisco.com/1f1Ax9pnY3mVz-CMgO2kjfekBxVFdzs69vEHKtnW1Ig5DhfsMABiI9JSHLEzfDBso-nsXfgKONE2O6J6wiuJQatSCKd9_KdDaj7mhleLFPghcrhjG8I4FA287-9m5VbcZgELFp7FzgKqWMCgt4dqJ315XOV39n57QUY2d8ZQf8TfSU3tCmPlV9UWYemkcceq94pLLz4ohcp9cEEcR9nMHF6hM6xgfrfjyIqq4wK16myMbs5_XU5aDPjN3AByXtYLjxNgS-iOhb92vTIJfRnxyqQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5733%23section-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://secure-web.cisco.com/1ZThw4WQCkkLyu3sS7SOYdtQ2Eycz-H6_o7zviuFVp5w2LiAn8fQFZNjm7VjB-dzQLRnQKEVR8KDLJxgTHqrrJP45WKuIIanHZbhVXgMJgv5VAUqy7qrpt0eewwW9r2eVYm9AlLu8Db7spIXUr9HvaPhpYRUCqGEhVQCjal5YvDGDCMeitTEOhT2faEW_ws82fCthqhHcs2C-xufPdccbDHFmE-6XIOwrGhCXRltimEwb1JFpEjYYiad64r67BLIb6xRrbudIrRYleLQDFUmqiQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5733%23section-3.1.2 > <https://secure-web.cisco.com/1ZThw4WQCkkLyu3sS7SOYdtQ2Eycz-H6_o7zviuFVp5w2LiAn8fQFZNjm7VjB-dzQLRnQKEVR8KDLJxgTHqrrJP45WKuIIanHZbhVXgMJgv5VAUqy7qrpt0eewwW9r2eVYm9AlLu8Db7spIXUr9HvaPhpYRUCqGEhVQCjal5YvDGDCMeitTEOhT2faEW_ws82fCthqhHcs2C-xufPdccbDHFmE-6XIOwrGhCXRltimEwb1JFpEjYYiad64r67BLIb6xRrbudIrRYleLQDFUmqiQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5733%23section-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://secure-web.cisco.com/12V5fLrqtpewQUvmvjQt6AKoYfM1ksyWkW0pemYtk6ES-nHane5xJc3qfp8rmJWhzprO7EaiXwqko_278ZwBGThURJwQdohV7GOG-m-0tbC8w_QzosigLLQFqX2YPhyjAxjtR6KD83a6UEix97TcJqvkQgqh-rJK5GSTY4LQ_VzMRzBUdh6B1pjTiSeXGzXa33i0RJruvlgu87CZA5ySXXfeLX9QKEgJleqU-OLvebfTcyfd5Q-fGo76kmriJa5A2ebvk9e3zHxxl55cElKy-bQ/http%3A%2F%2Fverisigninc.com%2F> > > > > 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 > Marco Schrieck Bereichsleiter Entwicklung -- InterNetX GmbH Johanna-Dachs-Str. 55 93055 Regensburg Germany Tel. +49 941 59559-0 Fax +49 941 59579-050 http://secure-web.cisco.com/15Vt7lICAcSpEzZIi0rp3EfGBkFHphaJ1afHO74024rJ3mrxt6u26Y1qBURaZ4GLYzP5jZvCdZ5njuwgT2WXXNpUtHPjUiy4Qa98boCcM45lGW04Q1DQ5RYvxkcMflrpt_P3CzfkxjSrDpffM7z6fENWJwLQoyjx6XiLicbUbN8Rox1mlJqL2MZJalPEsp2zVndSR2Lo2hFM7Pzldjy-haXqfFPbH6UrB8E12t8mhjlfctxvsdZ9pBL87F_mGgqFFabWY7uoowHvsUq_9IHiquA/http%3A%2F%2Fwww.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 [email protected] https://www.ietf.org/mailman/listinfo/regext
