Thank you for your perspective for use case #2 (info response of EAI address with non-EAI supporting client). Do you have any thoughts related to use case #1 (create command of EAI address with non-EAI supporting server), with the following options:
1. 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. 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 of 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. 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/4/21, 2:21 AM, "Taras Heichenko" <[email protected]> wrote: > 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://secure-web.cisco.com/1PHuclgRnODnxi08jze4h0Fc6ZDfqcf71AxEZJQwD1h-ADa8Fui9DXZeDCapk7W9UO0YsaVHOEocbt0xlvpEzcy1bIaZjrRhsxv5m-uTvMv3KJQ9bccE2avzNV2nquwEiLrhqo5pEYQhFrbHPzdgYW-SPkeWrW0oNO0KiRIQOAlC8-m-aEpz-TxsSK3N8bJRP0JgeZQzX4mt2xsoB6vMATbG5H_DN3unVvgoFh4FdvhnxPtowM_YcsNCcCjnsBDgp/http%3A%2F%2Fverisigninc.com%2F> > > 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://secure-web.cisco.com/1-wLqPO0ixnhSnv1bDHgAd4KDuL9XlUf2kLemKcLN1uOGg1Zcxdue7KVINRgsoiqMJLodH1xVHDovABPgsnQ2NWGWNDNEsTE4mEjmJ_1cidAJDGry0Cu-9UTKV6iJSwYj_etvg8wVYXmOFarHFW_9Jk-5Mj47BW0F4-cRfAoaszOvMAC2uMGkyBZ1C6wucOpCAtWYUtdifA9J40SBzM0JxIcF1OA1HvrVSbCnC_UAE6s_bMEBfz_5KWstPbEVOroi/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext -- Taras Heichenko [email protected]
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
