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

From: Dmitry Belyavsky <[email-masked]>
Date: Thu, 19 Nov 2020 12:03:11 +0300

Hello,

I think it's worth providing some thoughts about the EAI support in EPP
from a registrar's perspective.

>From a registrar's perspective, when the registry provides some feature,
the registrar has to support it in most cases. When a registry supports
EAI, the registrar should be ready to at least get an EAI address in the
<info> command on transfer.

Registrars usually got accreditation for working with more than one
registry, and have to write some registry-specific code. In the case of
EAI, the changes should require at least accepting EAI addresses from the
clients not having the ASCII ones and some mechanism providing the valid
ASCII email address in the case when such client wants to register a domain
in a registry that does not support EAI.

-- 
SY, Dmitry Belyavsky

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 19 Nov 2020 13:47:39 +0000

From: regext <[email-masked]> On Behalf Of Dmitry Belyavsky
Sent: Thursday, November 19, 2020 4:03 AM
To: [email-masked]
Subject: [EXTERNAL] [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,

I think it's worth providing some thoughts about the EAI support in EPP from a registrar's perspective.

From a registrar's perspective, when the registry provides some feature, the registrar has to support it in most cases. When a registry supports EAI, the registrar should be ready to at least get an EAI address in the <info> command on transfer.

Registrars usually got accreditation for working with more than one registry, and have to write some registry-specific code. In the case of EAI, the changes should require at least accepting EAI addresses from the clients not having the ASCII ones and some mechanism providing the valid ASCII email address in the case when such client wants to register a domain in a registry that does not support EAI.

[SAH] This is why an optional extension is our best option. The server (registry) advertises support for the extension. The capability is requested when a client (registrar) performs a login with a server, and there’s reduced risk of the client sending something the server won’t understand and vice-versa.

Scott

---

From: Taras Heichenko <[email-masked]>
Date: Thu, 19 Nov 2020 20:46:35 +0200

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

Besides that usage of extension for the non-ASCII email addresses impugn the Universal Acceptance (UA) principle as it is described on the ICANN site.
------
Universal Acceptance (UA) is a fundamental requirement for a truly multilingual and digitally inclusive Internet. UA ensures that all domain names, including long new TLDs and IDNs, and email addresses are treated equally and can be used by all Internet-enabled applications, devices, and systems. Technically, they must accept, validate, store, process, and display all domain names equally, consistently, and correctly.
-----
That is I see no reason to drive out the non-ASCII addresses into a separate extension while there are not any hurdles to use existing XML for such addresses (all the more so I heard there are registries that already do this way).

> On 19 Nov 2020, at 15:47, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> 

In the case (1) this is solved just by the "encoding" field in the XML header.

>  
> Scott
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

--
Taras Heichenko
[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Nov 2020 05:04:03 +0000

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

---

From: Taras Heichenko <[email-masked]>
Date: Fri, 20 Nov 2020 12:49:06 +0200

> On 20 Nov 2020, at 07:04, Hollenbeck, Scott <[email-masked]> wrote:
> 

[skip]

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

I did not say that it is possible to avoid software modification. But changing namespace
and adding a chank of code to process new extension differ a lot by the amount of work.

[skip again]

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

Ok. Let's imagine the case. There is a contact in a registry with a non-ASCII email address.
A registrar connects to the registry by EPP. Registrar does not support the EAI extension and
it asks the registry info about the Contact object with a non-ASCII address. What is going next?

[and skip again]

> "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 SMT…

May I ask you to explain in a few words why the negotiation at login time is so important? I try
to explain my point of view. Every registry has a predefined set of registrars that connect to it by
EPP. Every registrar has a predefined set of registries to connect with. There are many different
registries in the world with nuances in the EPP implementation. It does not mean that registries
should have different EPP implementation for each registry but at least they must have a set of
rules for the EPP with every registry. And this set of rules is not built on-the-fly. It is not an SMTP
protocol when there is no predefined set of peers and protocol must be very simple and clear to
be supported by all the participants. The EPP protocol is already far beyond the SMTP by complexity.
And registrars do not connect to the registries without appropriately preparing the software. So any
negotiation at login time has a very formal meaning for this protocol. Maybe I am wrong I just explain
my point of view from almost nine years in one of the ccTLD.

--
Taras Heichenko
[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Nov 2020 11:18:12 +0000

> From: Taras Heichenko <[email-masked]>
> Sent: Friday, November 20, 2020 5:49 AM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]
> >> + allows implementation by minimum changes in the software. It is
> >> + enough
> > 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.
>
> I did not say that it is possible to avoid software modification. But 
> changing
> namespace and adding a chank of code to process new extension differ a lot
> by the amount of work.

Right - it's a lot MORE work.

> [skip again]
>
> >>
> >> (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.
>
> Ok. Let's imagine the case. There is a contact in a registry with a 
> non-ASCII
> email address.
> A registrar connects to the registry by EPP. Registrar does not support the 
> EAI
> extension and it asks the registry info about the Contact object with a non-
> ASCII address. What is going next?

How did that contact object get populated if the registrar doesn't support the 
capability? It might be possible in the case of a domain transfer. That's 
something we need to think about.

> [and skip again]
>
> >>
> >> 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.
>
> May I ask you to explain in a few words why the negotiation at login time is
> so important? I try to explain my point of view. Every registry has a
> predefined set of registrars that connect to it by EPP. Every registrar has 
> a
> predefined set of registries to connect with. There are many different
> registries in the world with nuances in the EPP implementation. It does not
> mean that registries should have different EPP implementation for each
> registry but at least they must have a set of rules for the EPP with every
> registry. And this set of rules is not built on-the-fly. It is not an SMTP 
> protocol
> when there is no predefined set of peers and protocol must be very simple
> and clear to be supported by all the participants. The EPP protocol is 
> already
> far beyond the SMTP by complexity.
> And registrars do not connect to the registries without appropriately
> preparing the software. So any negotiation at login time has a very formal
> meaning for this protocol. Maybe I am wrong I just explain my point of view
> from almost nine years in one of the ccTLD.

Login negotiation is CRITICAL because that's where the client and the server 
agree on the set of services and capabilities that will be used during the 
session. Registrars cannot assume that every registry supports the same 
services, and registries cannot assume that every registrar supports all the 
services they offer. DNSSEC (DS record provisioning) is a tangible example. 
It's not supported by all registrars.

For what it's worth, I'm not new to this, either. I respect your point of 
view, and I can appreciate that we might have different operational 
experiences. Let's figure out how we can add this capability in a way that 
minimizes the impact on all involved. That's what I designed the EPP extension 
mechanism for - to provide a lightweight, opt-in way to add new features 
without having to change the core protocol.

Scott

---

From: Taras Heichenko <[email-masked]>
Date: Fri, 20 Nov 2020 15:37:14 +0200

> On 20 Nov 2020, at 13:18, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> 

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

> something we need to think about.

For example, this registry has open contacts and on registrar check a contact of
another one, or this contact was opened to the other registrar to check it before a
domain transfer. There may be a lot of cases.

> It's not supported by all registrars.

I think would be interesting to make a poll through registrars of different TLDs
(country, generic, new) about these questions. Does their software choose
syntax dynamically or the syntax is predefined for every registry they are work with?

> without having to change the core protocol.

I fully agree and support you in this point. Can we make questioning through the
EPP software developers, registries and registrars what is more appropriate from
their point of view?

--
Taras Heichenko
[email-masked]

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 20 Nov 2020 18:32:15 +0100

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

---

From: Taras Heichenko <[email-masked]>
Date: Fri, 20 Nov 2020 22:21:52 +0200

> On 20 Nov 2020, at 19:32, Klaus Malorny <[email-masked]> wrote:
> 
> 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.

Thank you for your answers. You entirely confirmed my thoughts about these issues.

--
Taras Heichenko
[email-masked]