Subject: [regext] I-D Action: draft-ietf-regext-epp-eai-02.txt

From: [email-masked]
Date: Sun, 08 Aug 2021 04:40:23 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions WG of the IETF.

        Title           : Use of Internationalized Email Addresses in EPP protocol
        Authors         : Dmitry Belyavskiy
                          James Gould
	Filename        : draft-ietf-regext-epp-eai-02.txt
	Pages           : 11
	Date            : 2021-08-08

Abstract:
   This document describes an EPP extension that permits usage of
   Internationalized Email Addresses in the EPP protocol and specifies
   the terms when it can be used by EPP clients and servers.  The
   Extensible Provisioning Protocol (EPP), being developed before
   appearing the standards for Internationalized Email Addresses (EAI),
   does not support such email addresses.

   TO BE REMOVED on turning to RFC: The document is edited in the
   dedicated github repo (https://github.com/beldmit/eppeai).  Please
   send your submissions via GitHub.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-epp-eai-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-02

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dmitry Belyavsky <[email-masked]>
Date: Sun, 8 Aug 2021 13:51:12 +0200

Dear colleagues,

Many thanks for your proposals and the fruitful discussion!

The draft authors were convinced that the concept of the placeholder is
irrelevant.
We have changed it to an explicit error returning by server or an explicit
requirement of the valid address from the client.
We believe that explicit error will enforce the registrars to adopt the EAI
support more effectively.

We understand and highly appraise the idea of redesigning the EPP client
schema to permit EAI and also fix some more historical aspects.
However, we believe that this approach causes the explicit amendments into
the other EPP objects' information.

We believe that the support of EAI should be present either on a protocol
level (that was proposed in the very first version of the draft)
or at least on the session level (as we've specified in the current draft).

Many thanks!

On Sun, Aug 8, 2021 at 1:41 PM <[email-masked]> wrote:

> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

-- 
SY, Dmitry Belyavsky

---

From: Gustavo Lozano <[email-masked]>
Date: Tue, 10 Aug 2021 00:34:09 +0000

Thank you, Dmitry, Jim,

I read version 02 of the I-D, and I think the draft is going in the right direction.

I have a comment regarding the following scenario:

The EAI supporting server MUST satisfy the following obligations when the client does not support the EAI extension:

[...]

When the email property is optional in the EPP response, the server MUST validate whether the email property is an EAI address and if so don't return the email property in the response and otherwise return the email property that has been set based on server policy.

I think that omitting the email property for this case is overloading the meaning of an optional field. How does a client know if the email property was omitted because there is no data or an EAI?. A client may implement different actions for each semantic (i.e., no data or EAI). 

I think that the action for this case (EAI persisted for an optional field) should be as in the case where the email property is required, in other words, to return the error code 2308.

Thoughts?

Regards,

Gustavo

From: regext <[email-masked]> on behalf of Dmitry Belyavsky <[email-masked]>
Date: Sunday, August 8, 2021 at 4:52 AM
To: regext <[email-masked]>
Subject: [Ext] Re: [regext] I-D Action: draft-ietf-regext-epp-eai-02.txt

Dear colleagues, 

The draft authors were convinced that the concept of the placeholder is irrelevant.

We have changed it to an explicit error returning by server or an explicit requirement of the valid address from the client.

We believe that explicit error will enforce the registrars to adopt the EAI support more effectively.

We understand and highly appraise the idea of redesigning the EPP client schema to permit EAI and also fix some more historical aspects.

However, we believe that this approach causes the explicit amendments into the other EPP objects' information. 

We believe that the support of EAI should be present either on a protocol level (that was proposed in the very first version of the draft)

Many thanks!

Abstract:

   TO BE REMOVED on turning to RFC: The document is edited in the
   dedicated github repo (https://github.com/beldmit/eppeai [github.com]).  Please
   send your submissions via GitHub.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/ [datatracker.ietf.org]

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-epp-eai-02.html [ietf.org]

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-02 [ietf.org]

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/ [ftp.ietf.org]

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext [ietf.org]

-- 

SY, Dmitry Belyavsky

---

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

Hello,

On 8/10/21 02:34, Gustavo Lozano wrote:

> The EAI supporting server MUST satisfy the following obligations when the
> client does not support the EAI extension:
> 
> [...]
> 
> When the email property is optional in the EPP response, the server MUST
> validate whether the email property is an EAI address and if so don't
> return the email property in the response and otherwise return the email
> property that has been set based on server policy.
> 
> I think that omitting the email property for this case is overloading the
> meaning of an optional field. How does a client know if the email
> property was omitted because there is no data or an EAI?. A client may
> implement different actions for each semantic (i.e., no data or EAI).
> 
> I think that the action for this case (EAI persisted for an optional
> field) should be as in the case where the email property is required, in
> other words, to return the error code 2308.
> 
> Thoughts?

I agree, simply omitting an optional e-mail field if the client didn't
signal EAI support creates uncertainty that must be avoided, so the 2308
error we discussed for mandatory e-mail fields should be used here, too.

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: Dmitry Belyavsky <[email-masked]>
Date: Tue, 10 Aug 2021 14:54:16 +0200

Dear Gustavo,

Many thanks, fair point!

I plan to incorporate your recommendation into the next version together
with some offlist and list feedback.
I think I'll publish the updated version on the upcoming weekend

On Tue, Aug 10, 2021 at 2:34 AM Gustavo Lozano <[email-masked]>
wrote:

> meaning of an optional field. How does a client know if the email property
> was omitted because there is no data or an EAI?. A client may implement
> different actions for each semantic (i.e., no data or EAI).
>
>
>
> *From: *regext <[email-masked]> on behalf of Dmitry Belyavsky <
> [email-masked]>
> *Date: *Sunday, August 8, 2021 at 4:52 AM
> *To: *regext <[email-masked]>
> *Subject: *[Ext] Re: [regext] I-D Action: draft-ietf-regext-epp-eai-02.txt
>
>
>
> Dear colleagues,
>
>
>
>    dedicated github repo (https://github.com/beldmit/eppeai [github.com]
> <https://urldefense.com/v3/__https:/github.com/beldmit/eppeai__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kzEpNVw8$>).
> Please
> [datatracker.ietf.org]
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kRroGewY$>
>
> [ietf.org]
> <https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-regext-epp-eai-02.html__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kBBnWLzY$>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-02__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kjzrZcpI$>
>
>
> <https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kUrTjOAo$>
>
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kKP7gujo$>
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>

-- 
SY, Dmitry Belyavsky