Klaus, The EAI support goes beyond RFC 5733 and is a perfect example of the use of the extensibility built into EPP. Revising the RFCs and EPP extensions that use email addresses for EAI with new XML namespaces and potentially other changes is much more impactful than creating an EPP extension that specifically addresses the issue with applicability across any EPP object. I was involved with revising RFC 4310 to RFC 5910, which was needed to address significant implementation issues with RFC 4310, so I see it as a different use case. The intent is to make the EPP extension as lightweight as possible, to apply across multiple EPP objects, and to include an appropriate level of signaling (e.g., session-level, object-level, element-level). Any feedback is welcome.
Thanks, -- JG 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/> On 11/19/20, 11:56 AM, "Klaus Malorny" <klaus.malo...@knipp.de> wrote: On 19.11.20 16:37, Gould, James wrote: > Klaus, > > [...] > 2. Implicit Replacement Based on Login Services – Inclusion of the > namespace URI in the greeting and login services indicate support > for EAI addresses implicitly. This would be treated similar to an > EPP extension with the namespace URI in the greeting and login services. > [...] > It sounds like you’re proposing the use of the second option. I believe > that inclusion in only the greeting and logic services is too course > grain, since the registry systems can support many TLDs and many EPP > objects, each with different levels of support for EAI addresses. > Option 3 would be a lighter weight method that is an object-level > indicator and option 1 would be the most explicit to indicate which > email element is replaced by use of the placeholder text with the > extension email element. The use of email addresses apply to multiple > EPP RFCs (RFC 5733, RFC 8543) and to at least one non-RFC EPP extension > registered in the EPP Extension Registry > (https://secure-web.cisco.com/10F-1HgkEVNjFP0QgeBKhNA6sGTSD5RdZNJB4QHkoLDH8IHBYRs1ltUZiJPQNpihXZRKqZnlZfft8YypQmOjFdKnT6xD8VWe0qoyaI66wv8KLgW6NwVw9yKxur_9mPHqImn2NdED0DulgXSONcHFsSXPwjOjo3dhdmXS99AEu06iPQ5SdWh4mxRpqQezq22KmHdnz6i3MjgIFVSjk61bkmmkGv4OfN2faHghwaNVLCO1PszPa1O3Xv8qnay5A_HfRelkpzXwgtVWks1yBkwNPtw/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fepp-extensions%2Fepp-extensions.xhtml). > Hi James, you are right, my proposal matches option 2. I didn't know that this was discussed already. In respect to option 3 I really think that if EAI support shall be specific to object types then it would be better to release updated specifications of these objects, maybe with new URIs if necessary. This would be my general preference, as I noted in my previous e-mail. Having extensions that influence the interpretation of certain elements in objects or other extensions has the problem that it increases the complexity over time, makes it less understandable and makes it more difficult to get rid of old stuff. The DNSSEC extensions (1.0 and 1.1) are a good counter example for how it should work. I guess that nowadays no active EPP server or client is unable to use version 1.1, thus 1.0 support could be theoretically removed from the implementations. Maybe one could find additional improvements to the contact object to justify an update. For example, fixing the disclosure settings. While their use have become questionable in the context of data protection regulations like the GDPR anyway, they have the slight design problem that one cannot set and remove specific disclosure settings at the same time. Or one could consider to add a language field, which could be helpful when sending e-mails to registrants, e.g. WDRP e-mails, transfer related e-mails. Maybe there are other aspects with which registrars, resellers and end users are unhappy. Regards, Klaus _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
