Re: [regext] Internationalized Email Addresses and EPP

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

jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@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-bounces@ietf.org on behalf of Klaus.Malorny@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