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 [cid:image001.png@01D78DC0.FC199050] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Gustavo Lozano <gustavo.loz...@icann.org> Date: Monday, August 9, 2021 at 8:34 PM To: Dmitry Belyavsky <beld...@gmail.com>, regext <regext@ietf.org> 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 <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<mailto: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<mailto: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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
