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 <gustavo.loz...@icann.org> wrote: > 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 <regext-boun...@ietf.org> on behalf of Dmitry Belyavsky < > beld...@gmail.com> > *Date: *Sunday, August 8, 2021 at 4:52 AM > *To: *regext <regext@ietf.org> > *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 <internet-dra...@ietf.org> 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 > regext@ietf.org > 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 > -- SY, Dmitry Belyavsky
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
