Subject: [regext] Internationalized Email Addresses and EPP

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

Barry, Murray:

We have a question about IETF process as it related to updating an Internet Standard document. RFC 5733 ("Extensible Provisioning Protocol (EPP) Contact Mapping", part of Standard 69) was published in August 2009. It includes a normative reference to RFC 5322 for the definition of email address syntax. RFC 6530 ("Overview and Framework for Internationalized Email") was published in 2012. The regext working group is discussing how we can best update the email address syntax specification in RFC 5733 to add support for the local part of internationalized email addresses to EPP. The EPP XML Schema already "works" as it should, so that doesn't need to change. It's just that pesky normative reference to RFC 5322 that isn't updated by RFC 6530. We think we have a couple of options:

Create an EPP extension by writing an Internet-Draft that would explicitly add support for internationalized email address without touching anything associated with 5733.

Write another document that updates 5733 to include the reference to 6530, if it's possible to update an Internet Standard that way.

Submit an errata report to note the additional normative reference to 6530, though this isn't a technical or editorial error.

There may be other possibilities. What are your thoughts on the best way to proceed? I personally think that the first option is the easiest and cleanest, and it's the way we've added additional functionality in the past. I'm wondering if there's an easier way, though.

Scott

---

From: Barry Leiba <[email-masked]>
Date: Mon, 19 Oct 2020 05:48:13 -0400

Hi, Scott,

An interesting question...

I think it depends upon how you want this to appear from an EPP point of view:

1. Do you want the EPP standard to support non-ASCII email addresses?

2. Do you want to *extend* EPP to support non-ASCII email addresses,
as an option for those who implement the extension?

For (2), then the EPP extension would be the easiest option, where the
extension would "update" 5733 and say that the extension changes the
definition to allow non-ASCII email addresses.  The extension would be
at Proposed Standard, and 5733 would be at Internet Standard as it is
now.

For (1), the best way would be to revise 5733 and change the
definition of email address syntax, republishing it at Proposed
Standard and "obsolete" 5733.  The protocol (the new RFC) would then
be back at Proposed Standard.  You could then do a status change later
to move the new RFC to Internet Standard (without publishing yet
another revision).

So... does the working group want it to appear that support for
non-ASCII email addresses is an optional extension, or part of the
base EPP?

Barry

---

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

I believe option 2 is the better route to go.  We went with option 2 to extend the password length in RFC 5730 with the Login Security Extension (RFC 8807).  The use of email addresses in EPP is not isolated to RFC 5733.  The Organization Mapping (RFC 8543) and some additional EPP mappings registered in the EPP Extension Registry (Email Forwarding Mapping and NameWatch Mapping) use email addresses.  A new EPP extension could be applied to more than one EPP mapping.  The other question is whether the Internationalized Email Address should be a replacement for or additive to the ASCII Email Address defined in the mappings, based on the email address usage and the support for Internationalized Email Addresses in the underlying protocols and implementations.  An extension could support both replacement and additive options.       

-- 
 
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 10/19/20, 5:48 AM, "regext on behalf of Barry Leiba" <[email-masked] on behalf of [email-masked]> wrote:

    Hi, Scott,

    Barry

    > There may be other possibilities. What are your thoughts on the best way to proceed? I personally think that the first option is the easiest and cleanest, and it's the way we've added additiona…

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1OMe-gZOMpSdaE_x-eNaMmuku-HiFkDXVCFGDWXBsOnAOQxOjGtERHNpHzKsnKz9ejchOyDdiIlaqfLOg9aQI39btY7z4bJi6U3a8dJUGHQsF3BaGH-zhHPMWB5udn9vylMEQUEcTMCaKu3cxLc6dqGVMeK9VtHspmbya4NZVkqGlGNbK57io7D4HMA6iGFWzfLehh2gyF31-9tcpP59WQRgeWumuRMWqa4wFIqnhKFrCE4R55DBiJjW2iKechIkbUV8fDC-ZkRuiCpXUKMpJgXKnxkmnm_GdnDtwSb4YIME/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 19 Oct 2020 19:50:34 +0300

Let me disagree...

Login Security Extension does much more than just increasing the password
length.
Going(2) means that EAI addresses are not first-class citizens, that seems
wrong for now.
Also, the current schema definition formally allows EAI addresses.

On Mon, Oct 19, 2020 at 7:23 PM Gould, James <jgould=
[email-masked]> wrote:

> I believe option 2 is the better route to go.  We went with option 2 to
> extend the password length in RFC 5730 with the Login Security Extension
> (RFC 8807).  The use of email addresses in EPP is not isolated to RFC
> 5733.  The Organization Mapping (RFC 8543) and some additional EPP mappings
> registered in the EPP Extension Registry (Email Forwarding Mapping and
> NameWatch Mapping) use email addresses.  A new EPP extension could be
> applied to more than one EPP mapping.  The other question is whether the
> Internationalized Email Address should be a replacement for or additive to
> the ASCII Email Address defined in the mappings, based on the email address
> usage and the support for Internationalized Email Addresses in the
> underlying protocols and implementations.  An extension could support both
> replacement and additive options.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> [email-masked]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> On 10/19/20, 5:48 AM, "regext on behalf of Barry Leiba" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi, Scott,
>
>     > We have a question about IETF process as it related to updating an
> Internet Standard document. RFC 5733 ("Extensible Provisioning Protocol
> (EPP) Contact Mapping", part of Standard 69) was published in August 2009.
> It includes a normative reference to RFC 5322 for the definition of email
> address syntax. RFC 6530 ("Overview and Framework for Internationalized
> Email") was published in 2012. The regext working group is discussing how
> we can best update the email address syntax specification in RFC 5733 to
> add support for the local part of internationalized email addresses to EPP.
> The EPP XML Schema already "works" as it should, so that doesn't need to
> change. It's just that pesky normative reference to RFC 5322 that isn't
> updated by RFC 6530. We think we have a couple of options:
>     >
>     > Create an EPP extension by writing an Internet-Draft that would
> explicitly add support for internationalized email address without touching
> anything associated with 5733.
>     >
>     > Write another document that updates 5733 to include the reference to
> 6530, if it's possible to update an Internet Standard that way.
>     >
>     > Submit an errata report to note the additional normative reference
> to 6530, though this isn't a technical or editorial error.
>     >
>     > There may be other possibilities. What are your thoughts on the best
> way to proceed? I personally think that the first option is the easiest and
> cleanest, and it's the way we've added additional functionality in the
> past. I'm wondering if there's an easier way, though.
>     >
>     > Scott
>     >
>
> https://www.ietf.org/mailman/listinfo/regext
>

-- 
SY, Dmitry Belyavsky

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 19 Oct 2020 19:31:10 +0200

+1 for (1).

Best

Mario

-- 
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: "Gould, James" <[email-masked]>
Date: Mon, 19 Oct 2020 17:35:12 +0000

Dmitry,

The primary driver around the Login Security Extension was to increase the password length, where the other features were additive.  Going (2) means that the EAI addresses are first-class citizens that can be applied more broadly than RFC 5733 and for a broader set of use cases and to take into account the support for Internationalized Email Addresses in the underlying protocols and implementations.  I agree that the XML schema of the EPP mappings support EAI addresses, but the issue is how to implement EAI addresses to satisfy the use cases of the various EPP mappings that exist (e.g., RDAP/WHOIS display, Registrar usage, or in support for a Registry Service).  I view (2) as being the best path to support EAI addresses in EPP.

--

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: Dmitry Belyavsky <[email-masked]>
Date: Monday, October 19, 2020 at 12:50 PM
To: James Gould <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Hollenbeck, Scott" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP

Let me disagree...

Login Security Extension does much more than just increasing the password length.
Going(2) means that EAI addresses are not first-class citizens, that seems wrong for now.
Also, the current schema definition formally allows EAI addresses.

On Mon, Oct 19, 2020 at 7:23 PM Gould, James <jgould=[email-masked]<mailto:[email-masked]>> wrote:
I believe option 2 is the better route to go.  We went with option 2 to extend the password length in RFC 5730 with the Login Security Extension (RFC 8807).  The use of email addresses in EPP is not isolated to RFC 5733.  The Organization Mapping (RFC 8543) and some additional EPP mappings registered in the EPP Extension Registry (Email Forwarding Mapping and NameWatch Mapping) use email addresses.  A new EPP extension could be applied to more than one EPP mapping.  The other question is whether the Internationalized Email Address should be a replacement for or additive to the ASCII Email Address defined in the mappings, based on the email address usage and the support for Internationalized Email Addresses in the underlying protocols and implementations.  An extension could support both replacement and additive options.

--

JG

James Gould
Fellow Engineer

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

Verisign.com <http://verisigninc.com/<http://secure-web.cisco.com/1Ud1wJ80ukU2WUjdeT9mc920m-pbZd7ApZNs33mwQdKmat1DTnYVfVh-So_9t6EtJVR8zQ7dihlsfADvb3HVdE5G0vgkULUd3nVkPEnQgsISwGzq-uSZiX6JNkDlcwjPjkqEDXBvHGfCSoURiOV4Io03WfIuko-AEjIOJ7Okdq1ZVmJvFiypdMnDQvhqXEOIEJvIq2trBqIRjSQ6CS2DGytnzzNYu9KV7Zg5ajmFpb9w1U2CFhxFAQRRHiKlyUfufbGVykhVuwtsNoKKS5BS2mg/http%3A%2F%2Fverisigninc.com%2F>>

On 10/19/20, 5:48 AM, "regext on behalf of Barry Leiba" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi, Scott,

    Barry

    _______________________________________________
    regext mailing list
    [email-masked]<mailto:[email-masked]>
    https://secure-web.cisco.com/1OMe-gZOMpSdaE_x-eNaMmuku-HiFkDXVCFGDWXBsOnAOQxOjGtERHNpHzKsnKz9ejchOyDdiIlaqfLOg9aQI39btY7z4bJi6U3a8dJUGHQsF3BaGH-zhHPMWB5udn9vylMEQUEcTMCaKu3cxLc6dqGVMeK9VtHspmbya4NZVkqGlGNbK57io7D4HMA6iGFWzfLehh2gyF31-9tcpP59WQRgeWumuRMWqa4wFIqnhKFrCE4R55DBiJjW2iKechIkbUV8fDC-ZkRuiCpXUKMpJgXKnxkmnm_GdnDtwSb4YIME/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/15T9if8SKwvvDI6CR7Th9shSxJSzrcWsx-TJui5tn1YVqUVPA8I2qlgst2vSpKSC8SrUjG_DZDwfSn_dFuvVkSGvuGKpLQWqyOFKWtIm1Yp502oyxb8lp7hzQZgiE4DpmJgGMQzESxMZhdTDbHWKcX-_NWZoiAhNYaCgUEU1ZHcYD2uHLUKSEGfyghzCiygr1OThWyyIJfrK6fKQN9TX91ajwOYaB5t097fVJrf02sqSzXVUOIcq63aqK4l10u1Xb-RXULE-aqrbzyILG2BBCfH5axr5sVgEUcO8DYmG657U/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>

--
SY, Dmitry Belyavsky

---

From: "John Levine" <[email-masked]>
Date: 19 Oct 2020 13:43:53 -0400

>> 1. Do you want the EPP standard to support non-ASCII email addresses?

Do we believe that every registry that supports EPP can handle UTF-8
addresses? If not, what happens when a regstrar sends a UTF-8 address
to a registry that can't handle it?

---

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

John,

The registry can support the receipt of UTF-8 addresses based on the EPP RFCs, but full support comes down to the validation of the email addresses, how the email addresses are stored, and what the email addresses are used for.  I would expect an EPP error (2004 "Parameter value range error" or 2306 "Parameter value policy error") if an internationalized email address is received when the registry does not support it.   

-- 
 
JG

James Gould
Fellow Engineer

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

On 10/19/20, 1:44 PM, "regext on behalf of John Levine" <[email-masked] on behalf of [email-masked]> wrote:

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1qcDCNLyDIN3HqWMcb7-LuVNC5Wot-5j-dVjUhYeJQGItCmz7UJwVSQqf70-qTisWhxVnKCyfZ9ptN7I_n4lTGpzlFMbPxSzgj5Nn_e3ElYqv432R1Nhw-XXY11GzUB0uEiVg99Urvgm25a591Fm2eIb5nl6EwXF4Gsz3gwykYuESAqBwN0J0V_0vTr4jv9EppVLjSHsBaZD5bf7wWWpfnxJakllfHlP0CfCvXDvlkrkdnmyX2hRgf3bU6-qkgBIz9wXxTYSABJTQzLUSwxkGMyuZMQojvjnBBCU2P1kcXJk/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "John Levine" <[email-masked]>
Date: 19 Oct 2020 14:28:54 -0400

In article <[email-masked]> you write:
>
>The registry can support the receipt of UTF-8 addresses based on the EPP RFCs, but full support comes down to the validation of the
>email addresses, how the email addresses are stored, and what the email addresses are used for.  I would expect an EPP error (2004
>"Parameter value range error" or 2306 "Parameter value policy error") if an internationalized email address is received when the
>registry does not support it.   

That makes sense, but it also seems needlessly cruel. I expect
registrars would build ad-hoc lists of who handles EAI and who
doesn't, to provide better reports to their users, which would
then inevitably get out of date.

If we do this it really would be nice if there were a signal for who
handles EAI and who doesn't.

---

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

John,

The signal would be handled via support for an EPP extension XML namespace in option 2, an operational practice XML namespace in what I would call 2b, or most likely a new contact XML namespace (contact-1.1) in option 1 for RFC 5733.  The XML namespace would be reflected in the EPP greeting services and login services.   

-- 
 
JG

James Gould
Fellow Engineer

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

On 10/19/20, 2:28 PM, "John Levine" <[email-masked]> wrote:

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 19 Oct 2020 19:03:04 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Gould, James
> Sent: Monday, October 19, 2020 2:50 PM
> To: [email-masked]; [email-masked]
> The signal would be handled via support for an EPP extension XML
> namespace in option 2, an operational practice XML namespace in what I
> would call 2b, or most likely a new contact XML namespace (contact-1.1) in
> option 1 for RFC 5733.  The XML namespace would be reflected in the EPP
> greeting services and login services.

I'm more a fan of using an extension with a new namespace than I am a fan of trying to update 5733. An extension would be more easily consumed by other extensions that use email addresses vs. having to also update all existing extensions that use email addresses.

Scott

---

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

On Mon, Oct 19, 2020 at 10:03 PM Hollenbeck, Scott <shollenbeck=
[email-masked]> wrote:

> I'm more a fan of using an extension with a new namespace than I am a fan
> of trying to update 5733. An extension would be more easily consumed by
> other extensions that use email addresses vs. having to also update all
> existing extensions that use email addresses.
>

Adding support of an extension is harder than just allowing EAI email
addresses, both for registries and registrars.
Also, we get some fuzziness on implementation level. E.g., can we set ASCII
email via this extension?

-- 
SY, Dmitry Belyavsky

---

From: Mario Loffredo <[email-masked]>
Date: Tue, 20 Oct 2020 11:22:24 +0200

Many things are usually allowed by the EPP Schemas but refused according 
to server policies so it seems to me that this case is similar to many 
others. For example, are registrars aware of the TLDs implementing 
DNSSEC or do they simply rely on finding the DNSSEC namespace in EPP 
greeting?

Besides, I agree with Dimitry that dealing with an ad-hoc EPP extension 
would be more complex than just allowing the EAI email addresses. In 
fact, clients/servers should send/receive an email address in the 
related EPP element.

Cheers,

Mario

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 20 Oct 2020 11:44:13 +0000

From: Dmitry Belyavsky <[email-masked]>
Sent: Monday, October 19, 2020 4:12 PM
To: Hollenbeck, Scott <[email-masked]>
Cc: Gould, James <[email-masked]>; [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP

On Mon, Oct 19, 2020 at 10:03 PM Hollenbeck, Scott <shollenbeck=[email-masked]<mailto:[email-masked]>> wrote:

   > From: regext <[email-masked]<mailto:[email-masked]>> On Behalf Of Gould, James
   > To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

   Adding support of an extension is harder than just allowing EAI email addresses, both for registries and registrars.

   Also, we get some fuzziness on implementation level. E.g., can we set ASCII email via this extension?

   [SAH] I disagree on both points. Extensions are, by definition, opt-in. Registries and registrars can add support for them as they see fit. By changing the core protocol we impose a mandate for implementation. I’d rather not do that until we know that all elements of the underlying mail system (SMTP servers, mail stores, etc) support EAI email addresses. Extensions are additive, so yes, it’ll be possible to support both the legacy email addresses and the extended addresses if the extension is done properly.

   Scott

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 26 Oct 2020 13:53:02 +0800

Hello all,

  Otion 1 is ideal and option 2 are reasonable.
  Since not many registries and registrars support EAI services and few registrants use EAI address in the near future, I think that option 2 might be the current direction.

Best Regards

Jiankang Yao

From: Barry Leiba
Date: 2020-10-19 17:48
To: Hollenbeck, Scott
CC: [email-masked]; [email-masked]
Subject: Re: [regext] Internationalized Email Addresses and EPP
Hi, Scott,

Barry

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 29 Oct 2020 14:18:10 +0000

> From: Barry Leiba <[email-masked]>
> Sent: Monday, October 19, 2020 5:48 AM
> Cc: [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: Internationalized Email Addresses and EPP
>
> Hi, Scott,
>
> 2. Do you want to *extend* EPP to support non-ASCII email addresses, as an
> option for those who implement the extension?
>
> definition to allow non-ASCII email addresses.  The extension would be at
> Proposed Standard, and 5733 would be at Internet Standard as it is now.
>
> For (1), the best way would be to revise 5733 and change the definition of
> email address syntax, republishing it at Proposed Standard and "obsolete"
> 5733.  The protocol (the new RFC) would then be back at Proposed Standard.
> You could then do a status change later to move the new RFC to Internet
> Standard (without publishing yet another revision).

After doing a bit more document-reading-based research, I think the normative 
reference situation is where it needs to be, though the document relationships 
are a bit unclear because they're not explicitly shown in the IETF 
Datatracker. RFC 5733 includes a normative reference to RFC 5322 ("Internet 
Message Format")  for the definition of email address syntax. Section 3.4.1 is 
where the local-part is specified. 5322 also includes an informative reference 
to 5321, "Simple Mail Transfer Protocol".

RFC 6531 describes an SMTP extension (as provided for in RFC 5321) for 
internationalized addresses. SMTP extensions are OPTIONAL. Section 5 of RFC 
6530 states that "The email message header document [RFC6532] essentially 
updates RFC 5322 to permit some information in email message headers to be 
expressed directly by Unicode characters encoded in UTF-8 when the SMTP 
extension described above is used." RFC 6532 includes "Syntax Extensions to 
RFC 5322" In Section 3.2. Put all this together and we have EAI documents that 
update the syntax specification found in 5322 *if* you choose to support the 
EAI SMTP extension.

So, I believe the reference in 5733 is still appropriate, and the right way to 
tackle this is to create an EPP extension to allow EPP clients and servers to 
support EAI. That extension would need to include normative references to the 
EAI RFCs, and it would need to allow internationalized email addresses in any 
EPP fields, including other extensions, that currently carry email addresses. 
The XML Schema in 5733 already supports internationalized email addresses, so 
that doesn't need to change, either.

I'm looking forward to the discussion at our next meeting, assuming that I can 
stay awake for it.

Scott