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

From: "Gould, James" <[email-masked]>
Date: Mon, 2 Aug 2021 15:13:47 +0000

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-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, 10:49 AM, "InterNetX - Marco Schrieck" <[email-masked]> 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-masked]
    > <mailto:[email-masked]>) 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-masked]
    > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>
    > 
    >  
    > 
    > 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-masked] on behalf of [email-masked]> 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-masked]
    > 
    >     >
    > 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-masked]
    > 
    >    
    > 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

---

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

Patrick, 

We're discussing options other than the use of placeholder text, so feel free to weigh in.  We will be adding an Implementation Status section as we know more about implementation experience of the draft.

-- 
 
JG

James Gould
Fellow Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 8/2/21, 2:32 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    On Mon, Aug 2, 2021, at 13:22, Gould, James wrote:
    > You can reply to my reply to 
    > Thomas Corte with your thoughts on how best to handle it.    

    As stated, I am personally not seeing using a placeholder to be a good direction,
    so I can not really help in that way and I would prefer the WG to concentrate
    on alternate directions, as difficult as they might be. Just a personal view.

    Also, I am still curious to roughly know which registries have interest to 
    deploy this extension as it is currently. I think this should help defining if this
    would be "Standards Track" or "Informational".
    Without any clear signal we would have just to infer things based on who interacts
    on the subject and opinions expressed. And right now I don't see a clear signal
    on going ahead with placeholders, the discussion seems pretty mixed on the issue.

    -- 
      Patrick Mevzek
      [email-masked]

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1PoYxoekGPglMXo8DFcwz7eitqgGVpOSXwF98hN5pbeMkK14QP5fRGJYU835-7nb35t-fOMl9-ZAsSfuUDieMj41sC7rgDtVbqFGYTcdbuI23fquiIkUSDoFqfMHh69AJDyIOPocZzD8o32-82CpowgHI1mr_g290CnTb1C9f1u4a4Zr3m2dmvTVuuycM4fj29ubbLCfQEcfzn0FQ7SiZt912dNhwaZ80F_XvN--vc5gu1Stz_kK9v_WKI_CgqCUw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Gould, James" <[email-masked]>
Date: Tue, 3 Aug 2021 12:42:58 +0000

Thomas,

Thank you for your feedback.  My responses are embedded below.

--

JG

James Gould

Fellow Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 8/3/21, 5:15 AM, "Thomas Corte (TANGO support)" <[email-masked]> wrote:

    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.

JG - In re-reviewing the list of possible error codes, it looks like 2308 "Data management policy violation" with the below description best matches the use case:

This response code MUST be returned when a server receives

a command whose execution results in a violation of server

data management policies.  For example, removing all

attribute values or object associations from an object

might be a violation of a server's data management

policies.

The data management policy violation is retuning a data format that is not supported by the querying client.  Data management does not need to be isolated to an issue on the server-side, but could apply to proactively addressing a data issue in the client by returning a known unsupported data element.  It’s not a perfect match but it’s the closest one in my opinion.

    > 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.

    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.

JG – I’m believe option 2 is counter to the support of EAI, but this is only during a transition period.  My thought is to provide option 2 and 3 for the registrar to choose from for this corner case where the server doesn’t support EAI but the registrar has EAI data.

    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.

JG – The approach had been discussed in the WG.  The EAI issue goes beyond RFC 5733, since there is the use of an email element in RFC 8543, as well as proprietary extensions such as the Email Forwarding Mapping (https://www.verisign.com/assets/email-forwarding-mapping.pdf?inc=www.verisigninc.com).  EAI support is a crosscutting EPP issue that is served by the definition of the functional extension in draft-ietf-regext-epp-eai.  The case for a contact mapping update can be handled separately.

    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

---

From: "Gould, James" <[email-masked]>
Date: Thu, 5 Aug 2021 13:59:17 +0000

Taras,

Thank you for your feedback.  

It looks like for use case #1 (create command of EAI address with non-EAI supporting server) the preference is for a mix of "Collect ASCII value from registrant" and " Use proxy ASCII value" based on registrar policy, where a valid email address MUST be provided.  For use case #2 (info response of EAI address with non-EAI supporting client) the preference is for the registry to return a 2308 “data management policy violation” error to fast-fail for a non-EAI registrar.  

Based on the above, the definition and use of the predefined placeholder value would be removed from the draft and updated with the preferred approaches to address use case #1 and #2. 

Are there any other thoughts on how to address these two use cases?

Thanks,

-- 
 
JG

James Gould
Fellow Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 8/4/21, 4:18 PM, "Taras Heichenko" <[email-masked]> wrote:

    Hi James, all.

    > On 4 Aug 2021, at 15:38, Gould, James <jgould=[email-masked]> wrote:
    > 
    > 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:
    >  
    > 	• 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 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.
    > 	• A mix of the above options.

    I think that the main point is registrar must do everything to set an email address that provides the registrant with mail concerning the domain. Placeholder is not the case. All other looks appropriate. The registrar should explain to a registrant that the correct email address is much more important than EAI. If a registrar has good marketing it can make an ASCII proxy email for a registrant (and offer it as an additional but free service :) ). But provide a valid working address in registrant information is a must minimum.

    > Verisign.com <http://secure-web.cisco.com/1XcmZvNWKvKNxdkB8z9Dw9YSZBqD0qjFxHnTJENRM6aia1UGFckfv2xd1T2taB2RX7Qltk_3csqItb58nEI3a56xblluH6M8_RLGPcslIHCuck5CGMwcwSC6JXoLS2IJDAZPuptkZfsxypIEh-5oBUpz2td7RVUg5RRwNu0NMd0PipYr-0weoOnzSYvXYwLE0vY8Z_C_s2WnErwRrlmj36mKRtYgV1o_QNCS8YjR_bcLALBYhqUDGELAtxzXiSfk9AaikKoMmO5gGwRqUAxGZwQ/http%3A%2F%2Fverisigninc.com%2F>
    >  
    > On 8/4/21, 2:21 AM, "Taras Heichenko" <[email-masked]> wrote:
    >  
    >  
    >     > On 2 Aug 2021, at 21:08, Gould, James <jgould=[email-masked]> 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-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.
    >     > 
    >     > Are there other options to consider?  Do you have a preference for the options?
    >     > 
    >     > Thanks,
    >     > 
    >     > --
    >     > 
    >     > JG
    >     > 
    >     > 
    >     > 
    >     > James Gould
    >     > Fellow Engineer
    >     > 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-masked] on behalf of [email-masked]> wrote:
    >     > 
    >     >     Hello,
    >     > 
    >     >     On 8/2/21 15:50, Gould, James wrote:
    >     > 
    >     >     >     (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
    >     >     >     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
    >     > 
    >     >     --
    >     >     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
    >     > 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-masked]
    >  
    >  
    >  
    >  
    >  
    > https://secure-web.cisco.com/1ZLroGD5rLvS_7JbtpLLl1m_Zl3YBt7rskEI7_7UoW-3Yx6zn12XE1rNRYd4qtONsCDr0dcskptt48GGZMVuXs1yc3qdG1RiAGN2rT1g8jt2bwDWEwE9gCXBZoloEX7xvXy_uQjbi3625X2QnVqfiuW8VwK542JPW5YCs0mNx6sMFF5u6tspyM75YcJaco9Zts2ntKUEQnUdqFQgjP9ipXhG-RSawD29XQgNzOkvF1JQJHqIeXbXC09GmVdJKnFr8AkcMDcHapjc65wpvI85wlw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

    --
    Taras Heichenko
    [email-masked]