Subject: Re: [regext] EAI in EPP from a registrar point of view

From: "Gould, James" <[email-masked]>
Date: Fri, 20 Nov 2020 05:36:02 +0000

I agree with Scott's responses, but I need to add some to it, which I embed below.  

-- 
 
JG

James Gould
Fellow Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 11/20/20, 12:04 AM, "regext on behalf of Hollenbeck, Scott" <[email-masked] on behalf of shollenbeck=[email-masked]> wrote:

    > -----Original Message-----
    > From: regext <[email-masked]> On Behalf Of Taras Heichenko
    > Sent: Thursday, November 19, 2020 1:47 PM
    > To: [email-masked]
    > Subject: [EXTERNAL] Re: [regext] EAI in EPP from a registrar point of view
    >
    > Caution: This email originated from outside the organization. Do not click links
    > or open attachments unless you recognize the sender and know the content
    > is safe.
    >
    > Hello!
    >
    > For a long enough period, I worked as a CTO in one of the ccTLD registries. I'd
    > like to say my position about the proposed variants. Briefly:
    > (1) write new RFC and make RFC5733 obsoleted
    > (2) write RFC that defines an extension for non-ASCII email addresses
    >
    > Let's compare the pros and contras of both
    > (1)
    > + allows implementation by minimum changes in the software. It is enough
    > to change the rule which checks email addresses.

    I disagree with this completely. A new version of 5733 means a new XML namespace, which means that every single implementation of 5733 is affected.

JG - The issue with EAI is not isolated to 5733, where 8543 and other registered EPP extensions registered in https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml that use email addresses need to be addressed.  Obsoleting 5733 at a minimum would require a new XML namespace in a similar manner that was done when obsoleting 4310 with 5910, which is highly impactful.  An EPP extension has the capability to getting applied to any EPP object, so all of the applicable EPP extensions can be addressed and support is optional that minimizes the impact.    

    > + the XML structure does not depend on the support or no support non-
    > ASCII email addresses by the registry. There is no need to add code that
    > implements extension and parse this extension from the other side.
    > + new RFC could be written the way that uses the MUST word for ASCII email
    > addresses in the <email> field and MAY word for non-ASCII addresses in the
    > same field. So the usage of non-ASCII addresses would not be mandatory for
    > all registries.
    > - there is a need to go through the new RFC acceptance and making RFC5733
    > obsolete (there is more work than just accept the new RFC with extension,
    > AFAIU).
    >
    > (2)
    > + wittingly it is not mandatory by design causes less bureaucratic work
    > + with RFC documents (there is no need to obsolete any RFC, just accept
    > + new one with the extension)
    > - causes much more software modification. Even if a registrar does not work
    > with this extension it must make modifications to its code to parse responses
    > to <check> or <info> commands with the possible extension. In case (1)
    > there would be just symbols in the wrong encoding (if even).

    A registrar/client that does not negotiate use of the extension should not receive internationalized email addresses in any response. If that happens, the server is doing something wrong.

JG - I believe handling the EAI element either in the object mapping or in the extension when support is not negotiated would need to be determined.  Does the element not get returned?  Does the element get returned with a specific placeholder value?  Is the unhandled namespaces practice used to provide a signal to the client that data exists?  The preferred extension option impacts the best method for handling this case.

    > - can cause (and if it can then it would) muddle with the usage of email
    > addresses. In this case, we have a potential field for the second email
    > address in the Contact object. I can define an address in the main <email>
    > field or in the extension. What would be if I define the ASCII address by the
    > first call to the registry and define the non-ASCII address by the second call to
    > the same registry? If the second call rewrites the main address it is strange
    > that the extension rewrites the main field. If the extension does not rewrite
    > the main field it can cause the DB structure modification to allow ASCII and
    > non-ASCII addresses simultaneously. And it brings us to multiply email
    > addresses in the Contact object.
    >
    > I think that (1) has a more positive balance than (2). I disagree with the
    > proposed document and the design suggested by it. I think that non-ASCII
    > email addresses should use the same <email> field as ASCII addresses and
    > whether registry allows or denies such addresses must be defined in the
    > registry documentation.

    "non-ASCII email addresses should use the same <email> field as ASCII addresses" sounds reasonable to me, assuming that this is negotiated at login time. I believe this is the approach taken by SMTP when use of the OPTIONAL EAI extension is negotiated.

JG - This comes down to the EPP extensions options (1 - Placeholder Text and a New Email Element, 2 - Implicit Replacement Based on Login Services, 3 - Replacement Marker Element).  Both option 2 & 3 leverage the same <email> field in the EPP object mapping.  I prefer the explicit method of option 3 over the implicit method of option 2 to support the signaling at the object-level.  Option 1 supports signaling at the element-level, since it enables defining which of the <email> fields is replaced.  I'm aware of one EPP extension that has more than one email element, but it's somewhat obvious which one does apply.  Option 2 supports signaling at the object-level, where the client and server can indicate EAI support at the object-level, which also supports differentiating support at the TLD-level and at the EPP object mapping level.  Option 3 supports signaling at the session-level, which implicitly indicates support for all EPP object mappings and TLDs supported by the client and server.   Option 3 - Replacement Marker Element may be the happy medium for signaling that enables reuse of the existing <email> field.  

    Scott
    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1aXHMjQTsb6-KAe0cyuuoXs9ho87CZQ0XuOHsHhNudZH46iSG3qVnKBb2c-zW3aD5XebvHVUHzj2fjOw4Aj3vXLvPiwl_VZ4GwdCFq5g1jMAY4rtLL_oMRjs9iJl87R0S0_pFJKqKJCEpb409722KiUJ0XeAQYzojB1DOJl2TNOp13m9vVIA8_ihRyLbHAV9qUPvb7SM5VGKfOUSc2UnY2vtpWpY4aOoRWkG6sFkBCuH-En-_Ams19vblgIh3nF_7eDHl_022ixdzonxS5YSqQ0oOpuKQYO3yWxuu0hLZZjw/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: "Gould, James" <[email-masked]>
Date: Mon, 23 Nov 2020 14:37:55 +0000

Klaus,

The EAI address issue applies to more than RFC 5733 (RFC 8543 and Email Forwarding Mapping at a minimum) , where even if creating a new version of RFC 5733 made sense, it would not solve the broader issue.  The EPP extension option would be straight forward and can be applied across multiple EPP objects with no need to directly revise the EPP object specifications.   

There are three EPP extension options that have been discussed with different scopes (session-level, object-level, and element-level).  The current EPP extension draft (draft-belyavskiy-epp-eai-02) defines the element-level scope, since you specify the element using the placeholder text along with the extension that contains the value for the element.  The object-level scope would be handled via a marker extension, where the application of EAI is applied to any e-mail element in the object.  The session-level scope would be handled via the greeting and login services, where all objects accessed in the session has EAI applied.

-- 
 
JG

James Gould
Fellow Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

On 11/20/20, 12:32 PM, "regext on behalf of Klaus Malorny" <[email-masked] on behalf of [email-masked]> wrote:

    On 20.11.20 14:37, Taras Heichenko wrote:
    > 
    >> Right - it's a lot MORE work.
    > 
    > Let's ask Klaus what takes more developer's work, changing namespace, or adding the extension generation and parsing.
    > (In the neighbor thread Klaus wrote that his company is developing EPP software.)
    > 

    Hi,

    well, for the first case our EPP toolkit already allows the use of the 
    domain, host and contact objects with different XML namespaces. The 
    changes would mostly comprise creating subclasses for the respective 
    commands and responses that simply override the previous (RFC 5733) 
    namespace, since the schema would not change. This is less work than 
    creating a brand new extension.

    For the registrar system, I would have to introduce a configuration 
    parameter to select EAI support in any case. For the login process, the 
    work would also be more or less the same. For the code actually issuing 
    the contact commands only changes for the creation of the toolkit 
    objects would be required in the first case, whereas the extension 
    version would require additional logic to create the extension resp. 
    check for the presence of the extension and fiddle around with it. This 
    is some more work and an additional source of bugs.

    For the namespace solution, when some time in the future all supported 
    registries have phased out the RFC 5733 contact object, I could clean up 
    my code. In contrast, the code for the extension would stay forever and 
    clutter up my code.

    Klaus

    _______________________________________________
    regext mailing list
    [email-masked]
    https://secure-web.cisco.com/1tkGH6yshJslX1H5rVyXef-gmOiwGQeI0_cj3OyHX2bcGTjTg8If_ia4I63uvt3fg1dKwJA0lhLt2KjU5BCLariU_4ie_g1e23LXAWTBGr6Ze2MvlYNEKKCFJH4CMisS6_E0yvIieNlzR_-I7dmV4p09aVqy_kUK3BWH5XPM73nVJvvRMv9UpseKXuI6osj4DifG7m6Czmysg08IivFORmQPOW1ZS8FJt9sLcO9gS-RkXsi6YYcbdCxD3BYea2YCoHY5BKgKU1l64GLASpPgfq4eMYuGjsL6YiIBp_kbduRM/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext