Re: [I18ndir] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

[John C Klensin <[e-mail]>]

--On Tuesday, September 13, 2022 22:17 +0200 Dmitry Belyavsky
<[e-mail]> wrote:

> Dear John,
> Thank you for your clarification!
> 
> Let me explain my understanding.
 
> First, SMTPUTF8 MUAs already exist.

But are typically limited to a relative handful (compared to the
total) of scripts.  See below

> Second, if the registry provides this support, it implies that
> it can deal with such addresses.

To take an really extreme example, I think it would be seriously
dumb for a registrar to allow an email address with the local
part consisting of the Unicode code points, U+1F438 U+200D
U+1F445 U+1F438 [1].  It might be bad news for a registry to
access such an address.  I can't even guess how many of those
SMTPUTF8 MUAs would render that in a reasonable way, much less
allow users to type it without Unicode escapes.  Similar
comments might apply to one consisting of U+0460 U+030E U+1CF50
which I assume you will agree makes no sense (and I wonder how
your favorite MUA would render it or how you could input it from
anything resembling a "normal" keyboard).  But the SMPTUTF8
specs allow both of those things (see Section 3.1(9) and 3.2 of
RFC 6531 and Section 3.2 of RFC 6532) and, arguably, worse.

Now, that suggests that it is very important that registrars and
registries get some serious guidance, perhaps less about
accepting non-ASCII email address local parts but about what
restrictions they should impose.  You (and James) will probably
suggest that is not a job for REGEXT or the IETF and I agree
but, if the guidance does not come from somewhere, some
registry-registrar pair will come along who are expert in areas
other than Unicode and writing system issues, decide that they
_really_ want to be supportive of internationalization and
non-Latin writing systems and allow anything the SMTPUTF8 specs
allow.  Noting that, for example,
\u1F438\u200D\u1F445\[e-mail] is, syntactically, a
perfectly valid email address (but an all-ASCII one, not some
sort of Unicode escape), someone is likely to be looking for an
ASCII form in a hurry.  Or not, but that is where I think our
more fundamental disagreement lies (see below).

> Third, it shouldn't be a big deal for the Registrar to use
> such MUA. 

But you are effectively assuming that SMTPUTF8 MUAs, maybe all
of them, can handle, in a reasonable way, handle any email
address that is valid under SMTPUTF8 syntax.  That is just not
the case.  Again, see below.

> Fourth, the Registrant using SMTPUTF8 address also
> is capable of dealing with it.
> 
> Sorry, I don't see where the chain is broken and communication
> becomes impossible.

And here is where we are making very different assumptions. As I
understand it, you see this as EPP, and anything it might
affect, being entirely a private-use registrar-registry protocol
with, of course, registrant needs in there somewhere.  If one
completely accepts that model, then a reasonable answer to my
concerns is that they should be smart enough to not allow/accept
addresses that they cannot deal with, manage, etc.  If they
can't, they will find out soon enough, work it out somehow, and
adjust their rules and procedures as needed.

>From my perspective, the IETF is about the Internet and we have
no more business standardizing a protocol for private use
between a pair of commercial parties in the domain name sales
and management space than we would, for example, standardizing
peering agreements among ISPs.  Various protocols for
communication across that peering boundary -- protocols that we
expect will be used, or at least considered, by anyone involved
in those arrangements -- certainly, but the agreements
themselves and how commercial peers exchange, e.g., non-routing
information or information about their clients are things we
don't touch.

So, again from my point of view, but with the understanding that
I believe that the boundaries involved are a very big deal, I'm
concerned about the data involved, whether it could end up in
registry databases or be (legally) accessed by other parties who
need to contact registrants, interactions with registrants who
might want to change registrars, and so on.  From one
perspective, all of those are ICANN issues, not IETF ones.  But
the IETF should not be making protocols that constrain ICANN
discussions or decisions in those areas unless they are
absolutely, critically, necessary from a technical point of
view.  The "transmit a non-ASCII email address only because this
is a private protocol among about buddies and business partners"
idea just does not work with those considerations.  So, to
repeat what I said some time ago, I see your alternatives as
providing for all-ASCII alternate email addresses along with
allowing non-ASCII ones in a standards track specification that
is about the Internet or dropping the idea of IETF
standardization, treating the effort as a private extension for
use by any registrar-registry pair who choose to use it, and
moving the effort toward Informational registration by you,
Verisign, or some other combination.

We may need to agree to disagree about that, but I hope we are
getting closer to clarity about each other's positions and
concerns.

best,
   john




[1] That is frog face, ZWJ, tongue, frog face: something that
some systems would ignore and display as those three emoji
graphemes and that others would interpret as two graphemes, the
first as a frog with its tongue extended.

[2] Cyrillic Capital Omega, Combining Double Vertical Line
Above, U+1CF50.