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

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 7 Oct 2020 16:28:00 +0300

Dear colleagues,

This is an initial version of the IETF draft allowing usage of
Internationalized Email Addresses in the EPP protocol.

---------- Forwarded message ---------
From: <[email-masked]>
Date: Wed, Oct 7, 2020 at 4:25 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
To: Dmitry Belyavskiy <[email-masked]>

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

Name:           draft-belyavskiy-epp-eai
Revision:       00
Title:          Use of Internationalized Email Addresses in EPP protocol
Document date:  2020-10-07
Group:          Individual Submission
Pages:          4
URL:            https://www.ietf.org/id/draft-belyavskiy-epp-eai-00.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-00

Abstract:
   This document permits usage of Internationalized Email Addresses 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: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 8 Oct 2020 14:13:14 +0000

Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t think we can update Standard 69 (the set of EPP RFCs) this way. I’m not aware of any RFCs that expressly prohibit such things, but it’s a topic that the IESG has debated multiple times over the years and there might not be support for doing it his way now. A safer path would be to develop an extension using one of the techniques described in RFC 3735, “Guidelines for Extending the Extensible Provisioning Protocol”.

Scott

From: regext <[email-masked]> On Behalf Of Dmitry Belyavsky
Sent: Wednesday, October 7, 2020 9:28 AM
To: [email-masked]
Cc: marabox <[email-masked]>
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

Dear colleagues,

This is an initial version of the IETF draft allowing usage of Internationalized Email Addresses in the EPP protocol.

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Oct 7, 2020 at 4:25 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
To: Dmitry Belyavskiy <[email-masked]<mailto:[email-masked]>>

Name:           draft-belyavskiy-epp-eai
Revision:       00
Title:          Use of Internationalized Email Addresses in EPP protocol
Document date:  2020-10-07
Group:          Individual Submission
Pages:          4
URL:            https://www.ietf.org/id/draft-belyavskiy-epp-eai-00.txt<https://secure-web.cisco.com/1LkyicX_gPmVOFcqhopUmVBWNTNu8kNZjDBEJQvuOubNy547f4jeqX_rzGbyYv6ETENBk4XhC6Pf1HYfuQdaDUGDzadgReCVZHuAE3qDlDJ-ztd4b8LLqBg3K_QCXVYdim6g241oyclQbCWdzjcjdB0qsqZhAj7W3T-uShNPnveo9pis0PgzAehHj4M_Pa1E2SJthPbd5fydZFjMvT1MZ7uJOuf11g-OM7uxR0y4HKXBBcQmHQeYPly9f0fMNpUmxbzdghKVzx472b1k082jKppl8gS440Z2FgZc1DYcPwzw/https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-belyavskiy-epp-eai-00.txt>
Status:         https://datatracker.ietf.org/doc/draft-belyavskiy-epp-eai/<https://secure-web.cisco.com/1iH-jWELClftnGP8aH6xLx2NYPu3jsbvha_VBM_4gIYI_a8gCvX2XYik-58d-Us1TIPSkJ-7MhuKX4fkdG4KZTg6OnUZ-zO05p4r4nD5I65TQfgse3foF4wNxX8RmIRAC7QJJZfmvtRF40KsstlpsRnvYB6kI9UZHGMck8TJxG4ie2i_kJkLDrxEG4bX4IwyU_uaYJ6NcQKwea85dIKFVXK7crG9xK8yBLnaj7wswNB70e2H_7SYNN1Iye6vp1u3iq54v8LaLW08h06WUNV5rxQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-belyavskiy-epp-eai%2F>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-belyavskiy-epp-eai<https://secure-web.cisco.com/1R1veyqLSTSFJHBa1BOcXLht2lZlaD_b-6Bcn_diis5-1NVr8a1BzS7TR8Hx0DncgMGnCAxrF7tXkKyNq8gqWnEUxjk2pAF9gfoOnpD39Aa3C81DT4CHwuBnuZx9GisUlHkmqsxp2MkhJKm-1oyTZGF9pTmhivYFGZdBjn9pRiTMFYfCDrvh6aE1Q1_ZBmI3o6O5Y68lqVSGq23CffeKWDO6wXDh-43gZ9Uri_2xEmQbOzBdfrrvfdLy7dRo0XEaaG_Ixs6XMLnC9OQSoppMSbw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-belyavskiy-epp-eai>
Htmlized:       https://tools.ietf.org/html/draft-belyavskiy-epp-eai-00<https://secure-web.cisco.com/1aPLpPIJlvKOGrv9LEQTzgEaIIt-akmzF6wRR_zggj-AfW5Y1tzou50A5DCNMH-Fdh2GPXgvVE2JvtV-6esKg-9tT0f-1iQykAZFrmwEYBLzRgmzI7XbCUcbjoMuV7BsJlwNBzH4j50M5pdZJa0HXNlXozZxgd9oeWyq-yPwoq-mg4mGEDYXJ_aS8sTyd0VPYw1_jJV0RlvffC9RLZ1t6WSpFIlP1IW3dEqhkFF0Lj3CEhPPJAYe47DoLsUCcnbcz-Gc-1tv63IN6ljQrXIXITIYo_HnS9RwKFZQ8lcQ9XDc/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-belyavskiy-epp-eai-00>

Abstract:

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<http://secure-web.cisco.com/1Uf4zmBFe46PVm16LpIWeYo6zFDeCMc2krmNCh3enAUGvptve1fyz-b7Ajy5sgY3pxCRTvrr8PSkB8TxBU26-mOuzr751etNgYOdmrmv7bGGtkDxLWyYJufulJaqZILFmfGSMMkAWh07W_JGwcxgQ-FwE5tyXQ_H3Ka6VoeG8BUjpzT77mFSpvxlgcu4il6bYriCZWRrgvLZTH87sUfS2zQ2qIuM-6BHE6xtTxk0J7nbjI8KZUUu9vTJAvq6YnoTNsdf8qPm9KHQ3I-MktA3ikpnptxlzHINmJAIJJPD5L2E/http%3A%2F%2Ftools.ietf.org>.

The IETF Secretariat

--

SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 8 Oct 2020 17:21:12 +0300

Dear Scott,

Many thanks for your response!

I'm sorry, I don't feel the difference between this case and a similar
update of X.509 profile by RFC 8399.

And, as the email field is mandatory on creating the contact, I don't think
that the extension is the best way.

On Thu, Oct 8, 2020 at 5:13 PM Hollenbeck, Scott <[email-masked]>
wrote:

> Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t
> think we can update Standard 69 (the set of EPP RFCs) this way. I’m not
> aware of any RFCs that expressly prohibit such things, but it’s a topic
> that the IESG has debated multiple times over the years and there might not
> be support for doing it his way now. A safer path would be to develop an
> extension using one of the techniques described in RFC 3735, “Guidelines
> for Extending the Extensible Provisioning Protocol”.
>
>
>
> Scott
>
>
>
> *From:* regext <[email-masked]> *On Behalf Of *Dmitry Belyavsky
> *Sent:* Wednesday, October 7, 2020 9:28 AM
> *To:* [email-masked]
> *Cc:* marabox <[email-masked]>
> *Subject:* [EXTERNAL] [regext] Fwd: New Version Notification for
> draft-belyavskiy-epp-eai-00.txt
>
>
>
> Dear colleagues,
>
> <https://secure-web.cisco.com/1LkyicX_gPmVOFcqhopUmVBWNTNu8kNZjDBEJQvuOubNy547f4jeqX_rzGbyYv6ETENBk4XhC6Pf1HYfuQdaDUGDzadgReCVZHuAE3qDlDJ-ztd4b8LLqBg3K_QCXVYdim6g241oyclQbCWdzjcjdB0qsqZhAj7W3T-uShNPnveo9pis0PgzAehHj4M_Pa1E2SJthPbd5fydZFjMvT1MZ7uJOuf11g-OM7uxR0y4HKXBBcQmHQeYPly9f0fMNpUmxbzdghKVzx472b1k082jKppl8gS440Z2FgZc1DYcPwzw/https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-belyavskiy-epp-eai-00.txt>
> <https://secure-web.cisco.com/1iH-jWELClftnGP8aH6xLx2NYPu3jsbvha_VBM_4gIYI_a8gCvX2XYik-58d-Us1TIPSkJ-7MhuKX4fkdG4KZTg6OnUZ-zO05p4r4nD5I65TQfgse3foF4wNxX8RmIRAC7QJJZfmvtRF40KsstlpsRnvYB6kI9UZHGMck8TJxG4ie2i_kJkLDrxEG4bX4IwyU_uaYJ6NcQKwea85dIKFVXK7crG9xK8yBLnaj7wswNB70e2H_7SYNN1Iye6vp1u3iq54v8LaLW08h06WUNV5rxQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-belyavskiy-epp-eai%2F>
> Htmlized:
> <https://secure-web.cisco.com/1R1veyqLSTSFJHBa1BOcXLht2lZlaD_b-6Bcn_diis5-1NVr8a1BzS7TR8Hx0DncgMGnCAxrF7tXkKyNq8gqWnEUxjk2pAF9gfoOnpD39Aa3C81DT4CHwuBnuZx9GisUlHkmqsxp2MkhJKm-1oyTZGF9pTmhivYFGZdBjn9pRiTMFYfCDrvh6aE1Q1_ZBmI3o6O5Y68lqVSGq23CffeKWDO6wXDh-43gZ9Uri_2xEmQbOzBdfrrvfdLy7dRo0XEaaG_Ixs6XMLnC9OQSoppMSbw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-belyavskiy-epp-eai>
> <https://secure-web.cisco.com/1aPLpPIJlvKOGrv9LEQTzgEaIIt-akmzF6wRR_zggj-AfW5Y1tzou50A5DCNMH-Fdh2GPXgvVE2JvtV-6esKg-9tT0f-1iQykAZFrmwEYBLzRgmzI7XbCUcbjoMuV7BsJlwNBzH4j50M5pdZJa0HXNlXozZxgd9oeWyq-yPwoq-mg4mGEDYXJ_aS8sTyd0VPYw1_jJV0RlvffC9RLZ1t6WSpFIlP1IW3dEqhkFF0Lj3CEhPPJAYe47DoLsUCcnbcz-Gc-1tv63IN6ljQrXIXITIYo_HnS9RwKFZQ8lcQ9XDc/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-belyavskiy-epp-eai-00>
>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org
> <http://secure-web.cisco.com/1Uf4zmBFe46PVm16LpIWeYo6zFDeCMc2krmNCh3enAUGvptve1fyz-b7Ajy5sgY3pxCRTvrr8PSkB8TxBU26-mOuzr751etNgYOdmrmv7bGGtkDxLWyYJufulJaqZILFmfGSMMkAWh07W_JGwcxgQ-FwE5tyXQ_H3Ka6VoeG8BUjpzT77mFSpvxlgcu4il6bYriCZWRrgvLZTH87sUfS2zQ2qIuM-6BHE6xtTxk0J7nbjI8KZUUu9vTJAvq6YnoTNsdf8qPm9KHQ3I-MktA3ikpnptxlzHINmJAIJJPD5L2E/http%3A%2F%2Ftools.ietf.org>
> .
>
> The IETF Secretariat
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>

-- 
SY, Dmitry Belyavsky

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 8 Oct 2020 14:36:42 +0000

RFC 8399 is a Proposed Standard RFC that updates RFC 5280, another Proposed 
Standard. RFCs 5730 – 5733 are Internet Standards (RFC 2026 describes the 
difference in maturity levels), and as such the barrier for updates tends to 
be higher. The EPP RFCs are aging, and yes, we’re finding things that need to 
be updated. However, this is precisely why we can extend the protocol without 
having to modify the core XML schemas. You may disagree, but I think you’ll 
find that an extension will be an easier path forward from both implementation 
interest and process perspectives.

Scott

From: Dmitry Belyavsky <[email-masked]>
Sent: Thursday, October 8, 2020 10:21 AM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-00.txt

Dear Scott,

I'm sorry, I don't feel the difference between this case and a similar update 
of X.509 profile by RFC 8399.

On Thu, Oct 8, 2020 at 5:13 PM Hollenbeck, Scott <[email-masked] 
<mailto:[email-masked]> > wrote:

Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t think 
we can update Standard 69 (the set of EPP RFCs) this way. I’m not aware of any 
RFCs that expressly prohibit such things, but it’s a topic that the IESG has 
debated multiple times over the years and there might not be support for doing 
it his way now. A safer path would be to develop an extension using one of the 
techniques described in RFC 3735, “Guidelines for Extending the Extensible 
Provisioning Protocol”.

Scott

From: regext <[email-masked] <mailto:[email-masked]> > On 
Behalf Of Dmitry Belyavsky
Sent: Wednesday, October 7, 2020 9:28 AM
To: [email-masked] <mailto:[email-masked]>
Cc: marabox <[email-masked] <mailto:[email-masked]> >
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for 
draft-belyavskiy-epp-eai-00.txt

Dear colleagues,

---------- Forwarded message ---------
From: <[email-masked] <mailto:[email-masked]> >
Date: Wed, Oct 7, 2020 at 4:25 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
To: Dmitry Belyavskiy <[email-masked] <mailto:[email-masked]> >

Htmlized:       https://datatracker.ietf.org/doc/html/draft-belyavskiy-epp-eai 

Abstract:

The IETF Secretariat

-- 

SY, Dmitry Belyavsky

-- 

SY, Dmitry Belyavsky

---

From: "Gould, James" <[email-masked]>
Date: Thu, 8 Oct 2020 14:37:02 +0000

An extension was used to override the type of the RFC 5730 password and new password element in the Login Security Extension (https://tools.ietf.org/html/rfc8807).  In the case of the Login Security Extension, a pre-defined placeholder value is used in the RFC 5730 password or new password elements to point to the use of the corresponding elements in the extension.

What is the issue with the eppcom:minTokenType for an internationalized email address, which defines a minimum length of one and uses the XML schema “token” type, and which extends from the XML schema “normalizedString”?  The only difference between the “token” and the proposed “normalizedString” is the collapsing of whitespace.  Is the collapsing of whitespace (#x20 (space), #x9 (tab), #xA (linefeed), or #xD(carriage return)) an issue for internationalized email addresses?

--

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: Thursday, October 8, 2020 at 10:21 AM
To: "Hollenbeck, Scott" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

Dear Scott,

I'm sorry, I don't feel the difference between this case and a similar update of X.509 profile by RFC 8399.

And, as the email field is mandatory on creating the contact, I don't think that the extension is the best way.

On Thu, Oct 8, 2020 at 5:13 PM Hollenbeck, Scott <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t think we can update Standard 69 (the set of EPP RFCs) this way. I’m not aware of any RFCs that expressly prohibit such things, but it’s a topic that the IESG has debated multiple times over the years and there might not be support for doing it his way now. A safer path would be to develop an extension using one of the techniques described in RFC 3735, “Guidelines for Extending the Extensible Provisioning Protocol”.

Scott

From: regext <[email-masked]<mailto:[email-masked]>> On Behalf Of Dmitry Belyavsky
Sent: Wednesday, October 7, 2020 9:28 AM
To: [email-masked]<mailto:[email-masked]>
Cc: marabox <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for draft-belyavskiy-epp-eai-00.txt

Dear colleagues,

---------- Forwarded message ---------
From: <[email-masked]<mailto:[email-masked]>>
Date: Wed, Oct 7, 2020 at 4:25 PM
Subject: New Version Notification for draft-belyavskiy-epp-eai-00.txt
To: Dmitry Belyavskiy <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

--
SY, Dmitry Belyavsky

--
SY, Dmitry Belyavsky

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 8 Oct 2020 17:45:08 +0300

Dear James and Scott,

Many thanks for your clarifications and example!
Will soon return with an updated draft!

On Thu, Oct 8, 2020 at 5:37 PM Gould, James <[email-masked]> wrote:

> An extension was used to override the type of the RFC 5730 password and
> new password element in the Login Security Extension (
> https://tools.ietf.org/html/rfc8807).  In the case of the Login Security
> Extension, a pre-defined placeholder value is used in the RFC 5730 password
> or new password elements to point to the use of the corresponding elements
> in the extension.
>
>
>
> What is the issue with the eppcom:minTokenType for an internationalized
> email address, which defines a minimum length of one and uses the XML
> schema “token” type, and which extends from the XML schema
> “normalizedString”?  The only difference between the “token” and the
> proposed “normalizedString” is the collapsing of whitespace.  Is the
> collapsing of whitespace (#x20 (space), #x9 (tab), #xA (linefeed),
> or #xD(carriage return)) an issue for internationalized email addresses?
>
>
>
> --
>
>
>
> 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: *Thursday, October 8, 2020 at 10:21 AM
> *To: *"Hollenbeck, Scott" <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *Subject: *[EXTERNAL] Re: [regext] Fwd: New Version Notification for
> And, as the email field is mandatory on creating the contact, I don't
> think that the extension is the best way.
>
>
>

-- 
SY, Dmitry Belyavsky

---

From: "John Levine" <[email-masked]>
Date: 8 Oct 2020 14:17:01 -0400

In article <[email-masked]> you write:
>-=-=-=-=-=-
>Thanks for the note, Dmitry. I get what you’re trying to do, but I don’t think we can update Standard 69 (the set of
>EPP RFCs) this way. ...

Regardless of the standards politics, I don't think it would be a good idea
to unilaterally change the meaning of the address field.  It will take a
while for registries to upgrade to handle EAI mail and they need some way
to signal to the registrars that EAI addresses will work.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 8 Oct 2020 21:57:42 +0300

Dear John,

fair point!

The suggested model with dummy value and extension seems to be a relevant
signal.

On Thu, Oct 8, 2020 at 9:17 PM John Levine <[email-masked]> wrote:

> think we can update Standard 69 (the set of
> >EPP RFCs) this way. ...
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

-- 
SY, Dmitry Belyavsky