Subject: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

From: Dmitry Belyavsky <[email-masked]>
Date: Sun, 11 Oct 2020 14:39:50 +0300

Dear colleagues,

Here is the updated version of the draft describing the usage of the
Internationalized Email Addresses (EAI) in the EPP protocol.
This version provides a specification to submit EAI to the registries via
the EPP protocol extension.

Any feedback is welcomed!

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sun, Oct 11, 2020 at 2:35 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-01.txt
To: Dmitry Belyavskiy <[email-masked]>

A new version of I-D, draft-belyavskiy-epp-eai-01.txt
has been successfully submitted by Dmitry Belyavskiy and posted to the
IETF repository.

Name:           draft-belyavskiy-epp-eai
Revision:       01
Title:          Use of Internationalized Email Addresses in EPP protocol
Document date:  2020-10-11
Group:          Individual Submission
Pages:          12
URL:            https://www.ietf.org/id/draft-belyavskiy-epp-eai-01.txt
Status:         https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-belyavskiy-epp-eai
Htmlized:       https://tools.ietf.org/html/draft-belyavskiy-epp-eai-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-belyavskiy-epp-eai-01

Abstract:
   This document permits usage of Internationalized Email Addresses in
   the EPP protocol.  The Extensible Provisioning Protocol (EPP), being
   developed before appearing the standards for Internationalized Email
   Addresses (EAI), does not support such email addressed.  This
   document describes an EPP extension that allows EAI addresses to be
   used in contact mapping in the EPP protocol.

   TO BE REMOVED on turning to RFC: The document is edited in the
   dedicated github repo [1].  Please send your submissions via GitHub.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
SY, Dmitry Belyavsky

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Mon, 12 Oct 2020 13:47:07 +0200

Hello,

> Any feedback is welcomed!

As James already pointed out, I'm not sure why the extension is even
necessary to accomplish this on a purely technical (protocol) level.

eppcom:minTokenType is based on xsd:token, which is based on
xsd:normalizedString and adds whitespace collapsing. Unless that
introduces a problem I'm not a aware of, none of this prevents the
specification of internationalized e-mail addresses for contacts in EPP;
in particular, it doesn't limit the available characters to ASCII.

Many registries (like e.g. Neustar for .biz, or the TLDs run by our own
TANGO system) already accept them right now. It would be silly to require
them to use an extension to do the same in the future.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbH                    Thomas Corte
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                      E-Mail: [email-masked]
Germany

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 12 Oct 2020 15:11:24 +0300

Well,

> them to use an extension to do the same in the future.

If the registries work this way, it's great but it means they formally
violate the EPP protocol.

https://tools.ietf.org/html/rfc5733#section-2.6 denotes:

   Email address syntax is defined in [RFC5322].  This mapping does not
   prescribe minimum or maximum lengths for character strings used to
   represent email addresses.

EAI addresses do not fit the RFC 5322.

The 1st version of the draft was basically replacing RFC 5322 to RFC 6530 :)

-- 
SY, Dmitry Belyavsky

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 12 Oct 2020 12:20:47 +0000

From: regext <[email-masked]> On Behalf Of Dmitry Belyavsky
Sent: Monday, October 12, 2020 8:11 AM
To: Thomas Corte (TANGO support) <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

Well,

On Mon, Oct 12, 2020 at 2:47 PM Thomas Corte (TANGO support) <[email-masked]<mailto:[email-masked]>> wrote:

   Hello,

   If the registries work this way, it's great but it means they formally violate the EPP protocol.

   https://tools.ietf.org/html/rfc5733#section-2.6<https://secure-web.cisco.com/1hzu_WlPioMsUO-ycVN-zDMofl2fHO7fLFN8tmG0h1ua4fI7qT4zfOJ3Y4VH3VasUchmJp8BP_rL5zVbgz5Qjdgw93z2s0rn5IOSMAy_ZGBXuMk3s8B3BMGX0d8hicT9dyXOwlkRQnFmzwIgpA5BOd8sbnrlbrKbu8SEciN4EpA5mkN5hpMIjviWULHfq6XuWUUJrZz-20koRV6ebQtU1N9ikjlyYDg1KrqYVSBJlGWY4zva7EQYi3axiAgOibVz7qgLgS7n5UOVj0nDXOzZNApINoxoNmRQDb5ZujVAoo1c/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5733%23section-2.6> denotes:

   [SAH] Perhaps there’s a case to be made for RFC 6530 being an update to RFC 5322. I’m going to see if I can run some tests to confirm it, but I, too, suspect that EPP as-is won’t have any issues with internationalized email addresses.

   Scott

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 12 Oct 2020 15:23:42 +0300

Dear Scott,

On Mon, Oct 12, 2020 at 3:20 PM Hollenbeck, Scott <[email-masked]>
wrote:

> *From:* regext <[email-masked]> *On Behalf Of *Dmitry Belyavsky
> *Sent:* Monday, October 12, 2020 8:11 AM
> *To:* Thomas Corte (TANGO support) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* [EXTERNAL] Re: [regext] Fwd: New Version Notification for
> draft-belyavskiy-epp-eai-01.txt
>
>
>
> Well,
>
>
>
> https://tools.ietf.org/html/rfc5733#section-2.6
> <https://secure-web.cisco.com/1hzu_WlPioMsUO-ycVN-zDMofl2fHO7fLFN8tmG0h1ua4fI7qT4zfOJ3Y4VH3VasUchmJp8BP_rL5zVbgz5Qjdgw93z2s0rn5IOSMAy_ZGBXuMk3s8B3BMGX0d8hicT9dyXOwlkRQnFmzwIgpA5BOd8sbnrlbrKbu8SEciN4EpA5mkN5hpMIjviWULHfq6XuWUUJrZz-20koRV6ebQtU1N9ikjlyYDg1KrqYVSBJlGWY4zva7EQYi3axiAgOibVz7qgLgS7n5UOVj0nDXOzZNApINoxoNmRQDb5ZujVAoo1c/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5733%23section-2.6>
> denotes:
>
>
>
> *[SAH] Perhaps there’s a case to be made for RFC 6530 being an update to
> RFC 5322. I’m going to see if I can run some tests to confirm it, but I,
> too, suspect that EPP as-is won’t have any issues with internationalized
> email addresses.*
>
>
>
> *Scott*
>

I'm sure EPP itself will not. Do you think it's reasonable to indicate such
support via an extension or just leave it as a registry (internal) policy?

-- 
SY, Dmitry Belyavsky

---

From: "John Levine" <[email-masked]>
Date: 12 Oct 2020 11:51:45 -0400

In article <[email-masked]> you write:
>   [SAH] Perhaps there’s a case to be made for RFC 6530 being an update to RFC 5322. I’m going to see if I can run some tests to
>confirm it, but I, too, suspect that EPP as-is won’t have any issues with internationalized email addresses.

Urrgh.  RFC 6530 is not an update to 5322.  Don't go there.  I agree there is no
great technical problem sending UTF-8 address strings through EPP.

I'm getting the impression that what we need is a way for the client
to ask the registry whether it can handle EAI addresses so it knows
what to accept registrants.  I can imagine a variety of ways to do that.

R's,
John

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 12 Oct 2020 22:16:03 +0300

We could update the contact scheme version to indicate the EAI support as
it is relevant for the contract mapping only.

On Mon, 12 Oct 2020, 18:51 John Levine, <[email-masked]> wrote:

> >   [SAH] Perhaps there’s a case to be made for RFC 6530 being an update
> to RFC 5322. I’m going to see if I can run some tests to
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: "Gould, James" <[email-masked]>
Date: Mon, 12 Oct 2020 19:53:19 +0000

Dmitry,

The mechanism that we’ve used in the past is signaling support in the EPP greeting and login services.  Support for an EPP extension is signaled per RFC in the EPP greeting and login services.  We signal support for an operation practice via defining an XML namespace that is included in the EPP greeting and login services.  See https://tools.ietf.org/html/draft-ietf-regext-secure-authinfo-transfer-03#section-3 for signaling support for draft-ietf-regext-secure-authinfo-transfer, and see https://tools.ietf.org/html/draft-ietf-regext-unhandled-namespaces-03#section-4 for signaling support for draft-ietf-regext-unhandled-namespaces.

--

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

From: regext <[email-masked]> on behalf of Dmitry Belyavsky <[email-masked]>
Date: Monday, October 12, 2020 at 3:16 PM
To: John Levine <[email-masked]>
Cc: "Hollenbeck, Scott" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

We could update the contact scheme version to indicate the EAI support as it is relevant for the contract mapping only.

On Mon, 12 Oct 2020, 18:51 John Levine, <[email-masked]<mailto:[email-masked]>> wrote:

R's,
John

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1E2O9BAxjfPFRfBkfkdxxMTw4FeUHvpkoq0D8pXADkch3J8zQcnJFteI9-DnviuVEI5t6W5sTnonl8zXd9JKRrx-gGoGyQXdMImvWtBZf9dYNpujyBnEMqxC1Ly9rBkcppwn1Q8waImJkzHzgPSR5W076Bq_Qj1fvERIlfLyfP1t5QgoTwZ2gpmuX85-A2Z_DzpzUdNJ-F5_W-JNHhs7NJcXcs3bEciqsCWn8Pogs9sG9e5TijoAKpJc7gqcV6DlHoJghQ11jLtbMvnQ48zpr3_uROAOzByjqHEoLAyKKmWY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 12 Oct 2020 22:59:36 +0300

Dear James,

If we indicate in the EPP greeting/Login support
of urn:ietf:params:xml:ns:contact-1.0
for old contact scheme without EAI and urn:ietf:params:xml:ns:contact-1.1
for a new scheme with EAI, will it be enough?

On Mon, Oct 12, 2020 at 10:53 PM Gould, James <[email-masked]> wrote:

> Dmitry,
>
>
>
> The mechanism that we’ve used in the past is signaling support in the EPP
> greeting and login services.  Support for an EPP extension is signaled per
> RFC in the EPP greeting and login services.  We signal support for an
> operation practice via defining an XML namespace that is included in the
> EPP greeting and login services.  See
> https://tools.ietf.org/html/draft-ietf-regext-secure-authinfo-transfer-03#section-3
> for signaling support for draft-ietf-regext-secure-authinfo-transfer, and
> see
> https://tools.ietf.org/html/draft-ietf-regext-unhandled-namespaces-03#section-4
> for signaling support for draft-ietf-regext-unhandled-namespaces.
>
>
>
> --
>
>
>
> JG
>
>
>
>
>
> *James Gould *Fellow Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *regext <[email-masked]> on behalf of Dmitry Belyavsky <
> [email-masked]>
> *Date: *Monday, October 12, 2020 at 3:16 PM
> *To: *John Levine <[email-masked]>
> *Cc: *"Hollenbeck, Scott" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *[EXTERNAL] Re: [regext] Fwd: New Version Notification for
> <https://secure-web.cisco.com/1E2O9BAxjfPFRfBkfkdxxMTw4FeUHvpkoq0D8pXADkch3J8zQcnJFteI9-DnviuVEI5t6W5sTnonl8zXd9JKRrx-gGoGyQXdMImvWtBZf9dYNpujyBnEMqxC1Ly9rBkcppwn1Q8waImJkzHzgPSR5W076Bq_Qj1fvERIlfLyfP1t5QgoTwZ2gpmuX85-A2Z_DzpzUdNJ-F5_W-JNHhs7NJcXcs3bEciqsCWn8Pogs9sG9e5TijoAKpJc7gqcV6DlHoJghQ11jLtbMvnQ48zpr3_uROAOzByjqHEoLAyKKmWY/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
>
>

-- 
SY, Dmitry Belyavsky

---

From: "Gould, James" <[email-masked]>
Date: Mon, 12 Oct 2020 20:20:14 +0000

Dimtry,

I don’t believe there is the need for a new contact XML namespace, but it would be associated with the new XML namespace (urn:ietf:params:xml:ns:epp:eppEAI-1.0) defined in draft-belyavskiy-epp-eai.

--

JG

James Gould
Fellow Engineer

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

From: Dmitry Belyavsky <[email-masked]>
Date: Monday, October 12, 2020 at 3:59 PM
To: James Gould <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

Dear James,

If we indicate in the EPP greeting/Login support of urn:ietf:params:xml:ns:contact-1.0
for old contact scheme without EAI and urn:ietf:params:xml:ns:contact-1.1
for a new scheme with EAI, will it be enough?

On Mon, Oct 12, 2020 at 10:53 PM Gould, James <[email-masked]<mailto:[email-masked]>> wrote:
Dmitry,

The mechanism that we’ve used in the past is signaling support in the EPP greeting and login services.  Support for an EPP extension is signaled per RFC in the EPP greeting and login services.  We signal support for an operation practice via defining an XML namespace that is included in the EPP greeting and login services.  See https://tools.ietf.org/html/draft-ietf-regext-secure-authinfo-transfer-03#section-3<https://secure-web.cisco.com/1kbbME8WxKH25Af398m-OdqUFjso557LWijQiFXQJ0UKuX4cZCZzvDbYaHCY2_clcdljSgNx33sKFt3KGtedibBS3rd7Wn-tjukLzyRje6FwtvocFZuU1taYezRymzvBZLrldkbICauhkSsHRwazoFoHJepPRC6Q29CN67WEfGRnRBhURM55BobSdxDlos3bzBjeAVgNZ2oo3W_D3k7qndME5v-P8RlGiMBYYOnHXTBW6lDhznLqy1qBTvRiOl1ikEZMFhPPlvc7CdrjXu9iJcjMbQnUP7KNOmkd3ipkG-p0/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-secure-authinfo-transfer-03%23section-3> for signaling support for draft-ietf-regext-secure-authinfo-transfer, and see https://tools.ietf.org/html/draft-ietf-regext-unhandled-namespaces-03#section-4<https://secure-web.cisco.com/1fDC9N8uU6IPT_EF_7uAAVznUD8SeRiQfEspxbZ7K462x3pUcWXANQLl65DhwDm42Tnzst5sWdgJoVVwVaV1nwfEeLIyJ84n7hf0no3KNDmr2FSnfWqoUXwz7CcJKtVHxVeqCPxPrSAtXLVXqMNxyXq43d3XwpQocebl_3CR6r5qfOs6MYXycUvkWQIrUmoVDWKVBZrlAb2X9LGj-xHMMzptz9EHkzj73LblhoBU1TlzhwfEE7NZvB629ZmMF3aDzE-uj8tBvwsCTWyPC2vNVAorS3uKjIAJx0Y5lZgMXKV4/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-unhandled-namespaces-03%23section-4> for signaling support for draft-ietf-regext-unhandled-namespaces.

--

JG

James Gould
Fellow Engineer
[email-masked]

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

Verisign.com<http://secure-web.cisco.com/1Itq6Iu9Ce3lRF7_uiaHCucQVya2sg9-ft8Yg6yP0k3-0H1E8iw8Qqmyc31A7wscCr2uY1m-HhwBC5gY9_wQA6GqtaTqqrdWBFlmQbZhx9-EAmD7vYlV5mMkhJwoXIx70fLtS0dHUPlEdGFEPd9k-L5bRtUyRqdp3eV4jrrKZmQfZ4WjKC2Jy8jEh_kWBRrtR_-uXI1DFtzyn2ZmPQoNRfbEYvr-RfL16Esuwi_20hlASRB2BwJchik4sDeE8emLBSZjWDtN4v-s8j7MFzMbKhg/http%3A%2F%2Fverisigninc.com%2F>

From: regext <[email-masked]<mailto:[email-masked]>> on behalf of Dmitry Belyavsky <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 12, 2020 at 3:16 PM
To: John Levine <[email-masked]<mailto:[email-masked]>>
Cc: "Hollenbeck, Scott" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-01.txt

R's,
John

--
SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 12 Oct 2020 23:39:07 +0300

Dear James,

We have some options that sound reasonable (for me)

1. Treat RFC 6530 as an update to RFC 5322 (not the best idea, really).
2. Indicate accepting EAI via new contact namespace, accept in the
<contact:email> tag
3. Indicate accepting EAI via eppEAI namespace, accept in the
<contact:email> tag
4. Indicate accepting EAI via eppEAI namespace, accept in the
<someext:email> tag

There is also an option "Do nothing, silently accept EAI in the
<contact:email>" which is
implemented in Newstar and TANGO registration systems.

I think we need some consensus to prefer any of these options and I don't
see any options to find out such a consensus than submit a draft and get
some feedback.
Personally, I would prefer either option 2 or option 4.

On Mon, Oct 12, 2020 at 11:20 PM Gould, James <[email-masked]> wrote:

> *From: *Dmitry Belyavsky <[email-masked]>
> *Date: *Monday, October 12, 2020 at 3:59 PM
> *To: *James Gould <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "Hollenbeck, Scott" <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *[EXTERNAL] Re: Re: [regext] Fwd: New Version Notification for
> <https://secure-web.cisco.com/1kbbME8WxKH25Af398m-OdqUFjso557LWijQiFXQJ0UKuX4cZCZzvDbYaHCY2_clcdljSgNx33sKFt3KGtedibBS3rd7Wn-tjukLzyRje6FwtvocFZuU1taYezRymzvBZLrldkbICauhkSsHRwazoFoHJepPRC6Q29CN67WEfGRnRBhURM55BobSdxDlos3bzBjeAVgNZ2oo3W_D3k7qndME5v-P8RlGiMBYYOnHXTBW6lDhznLqy1qBTvRiOl1ikEZMFhPPlvc7CdrjXu9iJcjMbQnUP7KNOmkd3ipkG-p0/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-secure-authinfo-transfer-03%23section-3>
> <https://secure-web.cisco.com/1fDC9N8uU6IPT_EF_7uAAVznUD8SeRiQfEspxbZ7K462x3pUcWXANQLl65DhwDm42Tnzst5sWdgJoVVwVaV1nwfEeLIyJ84n7hf0no3KNDmr2FSnfWqoUXwz7CcJKtVHxVeqCPxPrSAtXLVXqMNxyXq43d3XwpQocebl_3CR6r5qfOs6MYXycUvkWQIrUmoVDWKVBZrlAb2X9LGj-xHMMzptz9EHkzj73LblhoBU1TlzhwfEE7NZvB629ZmMF3aDzE-uj8tBvwsCTWyPC2vNVAorS3uKjIAJx0Y5lZgMXKV4/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-regext-unhandled-namespaces-03%23section-4>
> Verisign.com
> <http://secure-web.cisco.com/1Itq6Iu9Ce3lRF7_uiaHCucQVya2sg9-ft8Yg6yP0k3-0H1E8iw8Qqmyc31A7wscCr2uY1m-HhwBC5gY9_wQA6GqtaTqqrdWBFlmQbZhx9-EAmD7vYlV5mMkhJwoXIx70fLtS0dHUPlEdGFEPd9k-L5bRtUyRqdp3eV4jrrKZmQfZ4WjKC2Jy8jEh_kWBRrtR_-uXI1DFtzyn2ZmPQoNRfbEYvr-RfL16Esuwi_20hlASRB2BwJchik4sDeE8emLBSZjWDtN4v-s8j7MFzMbKhg/http%3A%2F%2Fverisigninc.com%2F>
>
>
>

-- 
SY, Dmitry Belyavsky

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 14 Oct 2020 09:28:21 +0200

Hi all,

given that the EPP Schemas already support EAI emails and many EPP 
servers usually accept them, could we simply correct section 2.6 of 
RFC5733  in order to let EPP servers accept either ASCII-only or EAI 
emails depending on their own policies described in out-of-band documents?

Best,

Mario

Il 12/10/2020 22:39, Dmitry Belyavsky ha scritto:
> I think we need some consensus to prefer any of these options and I 
> don't see any options to find out such a consensus than submit a draft 
> and get some feedback.
> On Mon, Oct 12, 2020 at 11:20 PM Gould, James <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dimtry,
>
>     I don’t believe there is the need for a new contact XML namespace,
>     but it would be associated with the new XML namespace
>     (urn:ietf:params:xml:ns:epp:eppEAI-1.0) defined in
>     draft-belyavskiy-epp-eai.
>
>     -- 
>
>     JG
>
>
>
>
>     *James Gould
>     *Fellow Engineer
>     [email-masked]
>
>     703-948-3271
>     12061 Bluemont Way
>     Reston, VA 20190
>
>     *From: *Dmitry Belyavsky <[email-masked]
>     <mailto:[email-masked]>>
>     *To: *James Gould <[email-masked] <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "Hollenbeck, Scott"
>     <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *[EXTERNAL] Re: Re: [regext] Fwd: New Version
>     Notification for draft-belyavskiy-epp-eai-01.txt
>
>     Dear James,
>
>         The mechanism that we’ve used in the past is signaling support
>         in the EPP greeting and login services. Support for an EPP
>         extension is signaled per RFC in the EPP greeting and login
>         services. We signal support for an operation practice via
>         defining an XML namespace that is included in the EPP greeting
>         and login services.  See
>         for signaling support for
>         draft-ietf-regext-secure-authinfo-transfer, and see
>         *From: *regext <[email-masked]
>         <mailto:[email-masked]>> on behalf of Dmitry
>         Belyavsky <[email-masked] <mailto:[email-masked]>>
>         *To: *John Levine <[email-masked] <mailto:[email-masked]>>
>         *Cc: *"Hollenbeck, Scott" <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>         *Subject: *[EXTERNAL] Re: [regext] Fwd: New Version
>         Notification for draft-belyavskiy-epp-eai-01.txt
>
>         We could update the contact scheme version to indicate the EAI
>         support as it is relevant for the contract mapping only.
>
>             In article <[email-masked]
>             <mailto:[email-masked]>>
>             you write:
>             >   [SAH] Perhaps there’s a case to be made for RFC 6530
>             being an update to RFC 5322. I’m going to see if I can run
>             some tests to
>             >confirm it, but I, too, suspect that EPP as-is won’t have
>             any issues with internationalized email addresses.
>
>             [email-masked] <mailto:[email-masked]>

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 14 Oct 2020 11:34:19 +0000

From: Mario Loffredo <[email-masked]>
Sent: Wednesday, October 14, 2020 3:28 AM
To: Dmitry Belyavsky <[email-masked]>; Gould, James <[email-masked]>
Cc: Hollenbeck, Scott <[email-masked]>; [email-masked]; 
[email-masked]
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-01.txt

Hi all,

given that the EPP Schemas already support EAI emails and many EPP servers 
usually accept them, could we simply correct section 2.6 of RFC5733  in order 
to let EPP servers accept either ASCII-only or EAI emails depending on their 
own policies described in out-of-band documents?

[SAH] Not easily, no. On the other hand, it *might* be possible to submit an 
erratum report even though this isn’t an error or an editorial issue. We 
should check with our ADs to see what they think about the situation. I’ll 
ping them.

I’ve confirmed that the Verisign Labs implementation of EPP also accepts 
internationalized email addresses without issue, so I don’t believe any schema 
changes are required.

Scott