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

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

(shortening the quoted text to focus on things about which I
have more to say)

--On Monday, August 22, 2022 08:40 +0200 Dmitry Belyavsky
<[e-mail]> wrote:

> Dear John,
> Many thanks for your comprehensive response!
> 
> 
> 
> On Sun, 21 Aug 2022, 18:24 John C Klensin, <[e-mail]>
> wrote:
> 
>> Dmitry and James,
>> 
>> I think several different issues are getting intertwined here,
>> some of which rise to the level of principles.  It is clear
>> that we are making different assumptions about what is
>> relevant and important and almost as clear that we are not
>> going to convince each other.  As I said earlier, that is why
>> we pay the IESG the big bucks.
>> 
>...
>> (2) As Patrik pointed out, there is a community interest (both
>> general and in ICANN policy) in making it easy for registrants
>> to switch registrars (whether the earlier registrar remains in
>> business or not).  For a registrar to treat business
>> relationship data that do not affect users, various
>> authorities, or elements of the DNS itself, as confidential
>> is entirely reasonable. However, usable contact information
>> for registrants does not fall into that category but,
>> instead, is information registries have been required to have
>> in their possession since before there was an ICANN (a
>> principle reaffirmed many times since then).

> Probably this is the most important point. So let me explain
> how the business process looks like from my point of view.
> 
> I am aware of two transfer scenarios.
> 
> First implies a one domain transfer. In this case a registrant
> should be already registered as a client and provide some
> email address. If this address is SMTPUTF8, it means that the
> registrar-acceptor supports sych addresses. If not, then
> registrar-acceptor can update the contact associated with the
> transferring domain immediately after acceptance. So it is not
> a show stopper.
> 
> The second one is bulk transfer in case of emergency. In that
> case it is the registrar's interest to be able to get more
> clients.
>...

Aha!  This may identify another area where we have been
understanding terminology, and hence the problem, differently,
leading to some failure to communicate.    I hope Patrik, who
has been closer to the issues in recent years than I have, will
comment further but...

There is a third case that I think is different from your first
one.  Back in the ancient times when I was advising ICANN and
then on the ICANN Board it was considered at least as important
as your second one.  My understanding of your first case was not
considered a significant issue, partially for the reason you
identified.  

That third case is best illustrated with a made-up example that
drifts rather far into policy issues but it probably helps
explain why, if registries are going to allow non-ASCII
addresses in the registry databases, they need to be able to
specify that ASCII alternatives be there too... and that implies
that a way to provide such addresses should be part of the
protocol.  Suppose, I am a registrant of foo.example.,
registered there through registrar XYZ.   I am happy with the
name, with the registry for the "example." TLD and so on, but,
perhaps due to changes in their business policies, am completely
fed up with having XYZ as a registrar.  So what I want to do,
perhaps only at renewal time, is to register/renew the domain
via a different registrar, perhaps ABC.   The transfer case now
involves the very fundamental and long-debated question of who
the domain, foo.example, actually belongs to. Policy decisions
have been made repeatedly that the answer is not XYZ.  

Because of the original name acquisition, I am registered as a
client of XYZ.  I have supplied them with a non-ASCII email
address as the administrative contact (at least) for foo.example
(probably the other contact addresses as well).  I go to make
the switch and perhaps ABC, despite whatever else attracts me to
them, does not yet handle non-ASCII addresses.  The registry
does not have a non-ASCII address so ABC cannot use information
there to validate me.  Even if XYZ has an all-ASCII backup
address (one that was not made available to the registry) hidden
away, they have no technical, and probably no external policy,
reason to cooperate.  All of myself, ABC, and the registry now
have a problem on our hands, one which could be resolved by an
ICANN policy requiring that XYZ release all of the information
they have on me (whether they consider it part of their business
relationship or not) and including any special authentication
information, or a specific list of data that include alternate
email addresses, to ABC and/or the registry.   To  the best of
my knowledge, there is no such policy and I would not be
optimistic about the ability to create one quickly.  

Another solution would be an ICANN policy, mandatory for all
contracted parties at least, requiring that everyone support
non-ASCII email addresses written in any script supported in
Unicode (not just, e.g., characters derived from the root MSR
because these are email addresses, not domain names).  Not
holding my breath about that either.

Of course, if the registry is feeling cooperative, they could
contact me on behalf of ABC, get themselves in the middle of the
transaction, and sort this out even though they have business
incentives to avoid getting into the middle of this if possible
(there are several opportunities here and above that could
provide full employment to many lawyers).   But consider a
related case.  Suppose that, instead of "foo", I had registered
an IDN string using a script that the registry had no staff who
could read or type and no MUA that knew how to utilize.  No
problem so far because of how IDNA works, but assume that I
supplied an email address whose local part (as well as the
domain part) were in that script.  The path to which that leads
is the reason for the "don't register what you don't understand"
language in the IDNA specs and its reinforcement and explanation
in the ill-fated draft-klensin-idna-rfc5891bis.   And the bypass
for the problem is, of course, availability _in the registry
database_ of an alternate, all-ASCII, address in addition to the
non-ASCII one.


>> (3) Whether a registrant is allowed to supply a non-ASCII
>> email address at all and, if they are allowed to do that,
>> whether an ASCII alternative should (or must) be supplied is,
>> we are agreed, a matter for registry-registrar agreements --
>> at least until national governments, other authorities, or
>> ICANN itself step in.  I don't think anyone has suggested
>> that supplying an alternative all-ASCII address through the
>> protocol should be a requirement imposed by the IETF
>> (certainly I have not).  I imagine that the REGEXT WG making
>> a strong recommendation on the subject would even be viewed
>> by some as an intrusion on ICANN's scope of authority.
>> However, it is important that the protocol be able to
>> accommodate the inclusion and transfer of that alternate
>> address information lest someone --perhaps even someone
>> acting on behalf of a registrar who believes its interests
>> would be served by making transfers difficult-- claim in an
>> ICANN forum that such information is unnecessary and
>> difficult to provide --and hence should be excluded from
>> discussions-- because the IETF decided it was not allowed in
>> the protocol.

> Well... Providing an opportunity to provide multiple email
> addresses within object (no matter if they are ASCII or
> SMTPUTF8) is probably worth doing but out of scope of this
> document. Otherwise I don't understand your point here :(

My point --see my earlier note to James-- is that, if this is
out of scope for this document, then the document is probably
not a proper candidate for processing as an IETF standards track
document. 

>> (4) To say almost the same thing from a different perspective,
>> if the purpose of this specification is to reduce the number
>> of incompatible ways in which registry-registrar pairs do
>> things, then please recognize that there is a strong
>> possibility (as predicted by the SMTPUTF8 specification
>> family), either immediately or after experience starts to
>> accumulate, that alternate all-ASCII addresses will be
>> required for some combinations of actors (before you removed
>> the text, it strongly implied just that).  If you allow them
>> in the protocol and data structure, then people who need to
>> transmit them will have a guide as to how to do so.  If they
>> are not allowed in the protocol, they you would be actively
>> encouraging different ways of doing things by forcing
>> different arrangements for transferring that information.
>> Given what everyone who has studied database theory knows
>> about the dangers of transmitting closely linked data in
>> separate pieces it is even more likely that they will invent
>> alternatives to this protocol as soon as the requirement (or
>> even an option) for transmitting an all-ASCII alternative
>> address to the registry arises.

> It is a fair point - but I'm not sure if it is in the scope of
> IETF. Registrars have a lot of such quirks and any registry
> adds more and more.

And that arguably makes some ICANN policy-making prerequisite to
the IETF processing this document.    Whatever the IETF does, it
should not be standardizing things that will make the Internet
work worse in the absence of real-world realities.   All of the
above really says is that, if there is a choice, any protocol
standardization effort should encourage good behavior (whether
it can successfully discourage bad behavior or not).   Note
particularly the "forcing different arrangements" part.

>> (5) Finally, there is a procedural issue that seems to have
>> gotten lost in the other (particularly i18n) discussions.  The
>> base EPP spec [RFC5730] says that there are three ways to
>> extend the protocol -- protocol, object, and command-response
>> levels. It does not say there can never be additional ways or
>> that other ways are not possible but it does say "three
>> ways".   This document defines and adds a fourth, a
>> "functional extension". No matter how harmless that addition
>> is and even if the WG is certain it would never be used for
>> anything other than this particular spec (in which case the
>> reasoning should probably appear in the spec), that
>> constitutes an update to 5730 that should be appropriately
>> reflected in the RFC header and other document metadata.  If
>> it really were a change to allow changes to the function of
>> EPP (I don't think it is and believe the term may be badly
>> chosen), then the community is owed an explanation of why the
>> function and/or scope of an Internet Standard is being
>> changed as part of what ought to be a fairly minor extension.

> I believe that the change in this document is quite similar to
> the protocol extension - but definitely doesn't fit to it
> perfectly. From the other point of view we technically don't
> change the formal XML scheme for the email address - as I
> wrote in the very first version of the document.

As shown in the longer analysis in my earlier note today, that
is correct.  But, if no change to the formal XML scheme for the
email address is needed, then this document need specify only
the command-response negotiation between registrar and registry
about whether the "real" syntax for email addresses can contain
non-ASCII characters.  Everything else is just a source of
confusion.  Of course, that still does not address the need for
a way to transmit an all-ASCII alternative if the primary email
address requires SMTPUPT8 support.

 
> Do you think it makes sense to add that our document updates
> RFC 5730?

If that is what you are doing (e.g., if it is adding an
extension type), I think that not only makes sense but is
necessary.

best,
   john