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

["Gould, James" <[e-mail]>]

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

-- 
 
JG



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

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" <[e-mail] on behalf of shollenbeck=[e-mail]> wrote:


    > -----Original Message-----
    > From: regext <[e-mail]> On Behalf Of Taras Heichenko
    > Sent: Thursday, November 19, 2020 1:47 PM
    > To: [e-mail]
    > 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
    [e-mail]
    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