Thomas,
For use case #2 (info response of EAI address with non-EAI supporting client), your preference is to return a failure. Is 2308 “data management policy violation” the best error code in your opinion? Do others agree that for this use case the server should return an error to a non-EAI supporting client in place of returning a successful response with a predefined placeholder value for the required email element when the value is an EAI address? For this use case the most likely scenario is that the querying client is the non-sponsoring client, since they didn't create the contact. For use case #1, what is your proposal for the value that the sponsoring registrar should provide with the create command to a non-EAI supporting server? I see the following options: 1. ASCII placeholder value – The current proposal is the use of [email protected]<mailto:[email protected]>. The assumption is that using a placeholder value is not the preferred option based on your feedback on use case 2. 2. Collect ASCII value from registrant – This is counter to the goal of supporting EAI, so it would only be done to pass a compliant value to a non-EAI supporting server. 3. Use proxy ASCII value – The EAI registrar would need to be able to support EAI registrants and mix for EAI-supporting registries by providing a ASCII proxy value to a non-EAI-supporting registry. The proxy value to use would be up to registrar policy. 4. A mix of the above options. Are there other options to consider? Do you have a preference for the options? 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, 11:42 AM, "regext on behalf of Thomas Corte (TANGO support)" <[email protected] on behalf of [email protected]> wrote: Hello, On 8/2/21 15:50, Gould, James wrote: > 2. EPP Contact <info> Response > (https://secure-web.cisco.com/1FgtS7m-xW-ZevXhWmnVO4Srd-o3ZnXlxd56BLZKCbdGU5qI0hxTWtvLd4sUE43gHtwFpwFZGUHjTdiQysEwr5nt_BCtNz9doKwi9fntdIrIA-c0BaLLhweuIYp6sCPoQsk7eOpDme8ANbDJf1TEXNsr91wlDi4uSjIj_yXdgrWgnC9PwEyVsz7W5uXKw5DmWUwHTTvBRoHg2eGd1PcDa5yzzl7BOcS0X1u0jhWnlWSi2BOhu08sa4CvC82wkjwqz/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc5733%23section-3.1.2 > <https://secure-web.cisco.com/1FgtS7m-xW-ZevXhWmnVO4Srd-o3ZnXlxd56BLZKCbdGU5qI0hxTWtvLd4sUE43gHtwFpwFZGUHjTdiQysEwr5nt_BCtNz9doKwi9fntdIrIA-c0BaLLhweuIYp6sCPoQsk7eOpDme8ANbDJf1TEXNsr91wlDi4uSjIj_yXdgrWgnC9PwEyVsz7W5uXKw5DmWUwHTTvBRoHg2eGd1PcDa5yzzl7BOcS0X1u0jhWnlWSi2BOhu08sa4CvC82wkjwqz/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. It does seem harsh, but it's (in my opinion) the better option than to return a syntactically valid placeholder value for the e-mail, as that placeholder value will - for registrars not supporting EAI - most likely end up being used as the "real" e-mail address for the contact, causing problems down the line, for example when the registrar tries to send verification e-mails to the contact for ICANN WAP compliance. These mails will bounce, which very often goes unnoticed, and domains may be suspended as a result. In this scenario, it's better to "fail fast", i.e. let the inquiry of the contact's data fail with the 2308 error, which will immediately point the registrar to a systemic problem that needs to be addressed. Best regards, Thomas -- TANGO REGISTRY SERVICES® is a product of: Knipp Medien und Kommunikation GmbH Technologiepark Phone: +49 231 9703-222 Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200 D-44227 Dortmund E-Mail: [email protected] Germany _______________________________________________ regext mailing list [email protected] https://secure-web.cisco.com/1KZbdbAPsaLa4OVdLtJihtpwdRk9fr_3G8g2mwx2jxOLL1sJ-eNhJwsOpo6W7ol32J_DzfjBAXa_Cw90o-bJSF0gBmXB6ESXuldajgmC3M50OyC92n_wRtUNo_XZxV-q617Ou591BoL72Nkten6pxWXT59Gx3wDODJPp1wp7OaV-Z6cj2rlRN7NM8UF2_IkjVUpxBNnG1Yxn7iIr2ZZbbgcQT_95-2rVq6WMVlGKV4PAAoyx95sLzddSZb6G18znD/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
