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

From: "Gould, James" <[email-masked]>
Date: Tue, 10 Aug 2021 12:23:22 +0000

Gustavo,

Good point, I agree that returning the 2308 “Data management policy violation” error response is the best option for the use case when the client doesn’t support EAI per the login services and the optional e-email response value is an EAI.  To map this up to the EPP RFCs with an email property, this case applies to implementations of the Organization Mapping (RFC 8543).

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

From: regext <[email-masked]> on behalf of Gustavo Lozano <[email-masked]>
Date: Monday, August 9, 2021 at 8:34 PM
To: Dmitry Belyavsky <[email-masked]>, regext <[email-masked]>
Subject: [EXTERNAL] Re: [regext] [Ext] Re: I-D Action: draft-ietf-regext-epp-eai-02.txt

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,

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]<mailto:[email-masked]>> wrote:

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 [github.com]<https://urldefense.com/v3/__https:/github.com/beldmit/eppeai__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kzEpNVw8$>).  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]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kRroGewY$>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-epp-eai-02.html [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-regext-epp-eai-02.html__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kBBnWLzY$>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-02 [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-regext-epp-eai-02__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kjzrZcpI$>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/ [ftp.ietf.org]<https://urldefense.com/v3/__ftp:/ftp.ietf.org/internet-drafts/__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kUrTjOAo$>

_______________________________________________
regext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/regext [ietf.org]<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!tvl_8txKhDVWIS3Jfu6yhLPQWzUr-wPBKqffpX5He0w9R6ysER9SoOa9ZfoXCxoWnX4kKP7gujo$>

--
SY, Dmitry Belyavsky

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 10 Aug 2021 12:48:30 +0000

Minor comment on the document title: “Use of Internationalized Email Addresses in EPP protocol” can be expanded to “Use of Internationalized Email Addresses in Extensible Provisioning Protocol protocol”. We don’t need “protocol” twice. Something like “Use of Internationalized Email Addresses in EPP” or “Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)” would be better.

Scott