> On 2 Aug 2021, at 21:08, Gould, James <[email protected]> > wrote: > > 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.
Just my 2 cents. There are two kinds of registrar-registry participants in the registration process. The first type tries to keep eye on the changes and go according to fresh standards. The second one once made a system and the system still works. If we propose to use a placeholder we make the domains of clients of second-type organizations in danger (as reasonably stated in some previous letters). The 2308 error will make the second type of organization do something to fix this error. I think it is fairer towards clients. > > 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: > > • ASCII placeholder value – The current proposal is the use of > [email protected]. The assumption is that using a placeholder value is > not the preferred option based on your feedback on use case 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. > • 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. > • 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 -- Taras Heichenko [email protected] _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
