Klaus,
The 3 options presented and discussed at the REGEXT meeting included three extension options, which all include an namespace URI in the greeting and logic services: 1. Placeholder Text and a New Email Element – This matches https://tools.ietf.org/html/draft-belyavskiy-epp-eai-01 that includes the use of placeholder text and an extra email element in an extension. This would include the namespace URI in the greeting and login services like any other EPP extension. 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. 3. Replacement Marker Element – Use of an empty marker extension as an implicit indication of support for EAI addresses on a per object-level (e.g., contact, organization, or other EPP objects). This would include the namespace URI in the greeting and login services like any other EPP extension. 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://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml). -- 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, 10:20 AM, "regext on behalf of Klaus Malorny" <regext-boun...@ietf.org on behalf of klaus.malo...@knipp.de> wrote: Hi Scott et al., sorry for proposing the following so late in the discussion. Due to other duties, my visits to the list were less frequent in the recent time. Looking at the two options - update of RFC 5733 or an extension -, I probably would tend to the first option, but I understand the problems with it. What I regard as suboptimal in respect to the proposed EPP extension [1] is the big effort for the little issue (RFC-wise and implementation-wise), and also using this dummy placeholder [EAI-DUMMY] in the original <email> XML element (while I know that this has been done before). For a non-supporting registrar the latter is probably similarly confusing as an updated RFC 5733. Well, you could argue that the registry can distinguish supporting and non-supporting clients upon extensions specified at the login and behave differently. And here comes my proposal: As the original email XML element could transport the internationalized e-mail address XML schema-wise, as mentioned before, why not reduce the whole extension to a single extension URI without any real EPP extension in the <extension> section? No schema, no extra data. The presence in the login would simply indicate: "yes, I can deal with internationalized e-mail addresses in the <email> element in the contact object", like a flag. Well, I know that would be a novel way of using extensions, but it would reduce the implementation effort a lot on the other hand. Regards, Klaus [1] https://secure-web.cisco.com/1eSK9wecykl6SY5-nP9QWJmD_sBwN8xHmPwuhDy8P3qDoWGHFh3iYxpmxiQD_0tS1Q-mhyLJrye0W5StyBEhY2CZvkE2rz4hhNpzrfPQxdzkBb1z_M20VSrzr7izEilx_FsSNF6TuH1KfLrS1gQTy7UxsWP1xigU9dFe0uNekRDUvf0t3LA7gJRJSpMxwY7Q9HtwoKUh7fjcU7kWcGDFwn7BwOoEUQx-TvJrPD19EgQ0UVHcR7B9uv08-yXwrkoJWIdKhq2Y-8egnR0IeB80JDdiJPpcFpoo-QxrbEbU08NM/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-belyavskiy-epp-eai-01 _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1-niXPoyAQkNoqJO8euNQWKTc_FepY-88-sGPEYrl-ABochx3Hcq8aIDVMq3yh3qLEXtK4ajzPX_fUs8dvbs4A0g10dcHmvMhRAl2ecqw5ABa4zveZ4GvM0ApXz0sQ_rjCSnE0CD4dbEQB8hDm-rjnCw4QbkocFxym1WTF8tMXrx6DqaS4lfO078yBWxAXcILxZQh0xj7MYFbWYeBodcIe6J3VpzTtOTGWVci2OW96aAxL3aiQP-Lx1EWkAstSEonN0QoW9rGTWmDs2UPyB-TVHx70HQY-ARUvTXaUHG6bvo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
