Subject: Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

From: "Gould, James" <[email-masked]>
Date: Mon, 2 Aug 2021 18:08:23 +0000

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-masked]<mailto:[email-masked]>.  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-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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-masked] on behalf of [email-masked]> 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-masked]

   Germany

    _______________________________________________

    regext mailing list

    [email-masked]

    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

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Tue, 3 Aug 2021 11:15:18 +0200

Hello,

On 8/2/21 20:08, Gould, James 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?

While not ideal, it seems to be the most suitable one among the codes in
RFC 5730, yes. Semantically, 2305 "Object association prohibits
operation" seems even better, but it's clearly supposed to be used for
responses to transform commands only.

> 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-masked] <mailto:[email-masked]>.  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. 

2. and 3. would be my preferred options.

2. seems OK as it's not unusual for registrars to collect different data
for different registries to represent the same contact due to the varying
data requirements, e.g. for widely differing authinfo string rules.

Also, while I understand the hesitation, I'm inclined to agree with other
participants in this discussion in that, going forward, a new
"contact-2.0" schema version for EPP contacts may be the best option here.
While we're at it, we could also use the opportunity to eliminate some of
the confusion that arose from unclear update semantics for address data,
or to make the contact authinfo optional (as many registries don't
support it anyway), among other things.

Best regards,

Thomas

---

From: Taras Heichenko <[email-masked]>
Date: Wed, 4 Aug 2021 09:20:36 +0300

> On 2 Aug 2021, at 21:08, Gould, James <jgould=[email-masked]> wrote:
> 
> Thomas,
>  

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.

> 	• ASCII placeholder value – The current proposal is the use of [email-masked].  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.
>  
> https://www.ietf.org/mailman/listinfo/regext

--
Taras Heichenko
[email-masked]