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

["Hollenbeck, Scott" <[e-mail]>]

> -----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.

> + 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.

> - 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.

Scott