Re: [regext] Last Call: <draft-ietf-regext-epp-eai-10.txt> (Use of Internationalized Email Addresses in the Extensible Provisioning Protocol (EPP)) to Proposed Standard

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

--On Thursday, May 26, 2022 08:59 -0700 The IESG
<[e-mail]> wrote:

> 
> The IESG has received a request from the Registration
> Protocols Extensions WG (regext) to consider the following
> document: - 'Use of Internationalized Email Addresses in the
> Extensible
>    Provisioning Protocol (EPP)'
>   <draft-ietf-regext-epp-eai-10.txt> as Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the [e-mail] mailing lists
> by 2022-06-09. Exceptionally, comments may be sent to
> [e-mail] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
> 
> Abstract
> 
> 
>    This document describes an EPP extension that permits usage
> of    Internationalized Email Addresses in the EPP protocol
> and specifies    the terms when it can be used by EPP clients
> and servers.  The    Extensible Provisioning Protocol (EPP),
> being developed before    appearing the standards for
> Internationalized Email Addresses (EAI),    does not support
> such email addresses.

Hi.

Several comments after a first and quick look through this
document.

First, it appears that it is making a more fundamental change to
EPP than just allowing for SMTPUTF8 (aka "non-ASCII" or "EAI")
addresses local parts.  The second paragraph of the Introduction
says
	 "A new form of EPP extension, referred to as a
	Functional Extension, is defined and used..."
and Section 4 defines that mechanism.   Because there are people
who might look at an announcement of Last Call for an
internationalization-related extension and say either "someone
else will look at those complexities" or "oh, sure, non-ASCII
addresses are good", and move on, introduction of that new type
of extension should be highlighted in the Abstract and should
have been included in the Last Call so as to draw attention from
those who are, e.g., concerned about the tradeoffs associated
with adding complexity to EPP.

It would be helpful to have assurances that the WG carefully
considered the idea and definition of a new extension type and
any associated tradeoffs independent of the particular
requirements of this document.  While it might be necessary,
complexity and added options do not promote interoperability.
It would also be helpful to know whether developing a separate,
short, document defining the new extension type so it could
conveniently be referenced from this document and other
specifications had been considered.  Especially if an update or
replacement for this document is anticipated, referencing it
from other extensions that use the new type invites the tangled
problems of whether such a reference to an obsolete or updated
document is still appropriate.

Second, Section 2, titled "Migrating to Newer Versions of This
Extension" strongly implies that a different form of this
extension, or a different extension mechanism serving the same
purpose is under development (or even further along) and
expected to succeed this one.  If that is the case, should this
specification not be published as Experimental rather than
Standards Track (or even, noting Section 7, as "Verisign's
Preliminary Mechanism for Use of Internationalized Email
Addresses in..." and Informational)?  Or, if there is a
substantive reason to publish as Standards Track, I believe the
document should explain the reasons for doing this now when an
update/replacement using a different mechanism is anticipated?
Version numbers or not, the way of doing things that seems to be
proposed in the document also does not appear to be a good way
to promote interoperability.


Third, with regard to the i18n parts of this:

Nit: The last sentence of Section 3, 
	"By applying the syntax rules of [RFC5322], the EPP
	extensions will change from supporting only ASCII
	characters to supporting Internationalized characters
	both in the email address local-part and domain-part."
Does not appear to make sense since, as pointed out earlier in
that section, the syntax rules of RFC 5322 only allow (a subset
of) ASCII characters.  Was "[RFC6531]" intended?

While the SMTPUTF8 extension is now supported in most popular
sender-SMTP ("client") and receiver-SMTP ("server")
implementations, comprehensive support in MUAs and other
relevant, user-facing, programs and user interface arrangements
(including support by humans) is less common (where
"comprehensive" includes all scripts and all languages).  This
document shows no evidence that the WG has considered whether it
would be appropriate and should be possible to negotiate script
or language-specific use.  While that probably has nothing to do
with the technical use of the EPP protocol (i.e., computers
talking with computers), it could be very important to practical
operational use.  If nothing else, the document should probably
containing appropriate warnings to registrars and/or registries
who, for whatever reason, would like to claim better support for
those working in languages other than English about possible
pitfalls.

Similarly, at least because the server-end downgrade mechanisms
described in RFC 6857 do not appear to be widely supported and
those described in RFC 6858 lose information, it would appear to
be useful for this extension to include provisions for an
all-ASCII, RFC 5321/5322-conforming, fallback or alternate
contact address.  I see no way to provide such an address in
this spec.

There might be other issues as well, but I would strongly
encourage the WG to think about the entire system surrounding
this protocol extension, including not only EPP clients and
servers but registrants and those third parties who legally and
appropriately access registry (and, if separate, registrant)
databases to access, understand, and use information.  For
example, nothing in RFC 6530 and the related documents prohibits
the use of obscure and archaic scripts as local-part strings
but, especially when there are bidi rendering issues involved,
such strings can be very difficult to understand, use, or even
copy into other contexts.

Disclaimer: These comments are those of the author only and
should not be confused with an i18ndir review.  Neither they nor
the document have been discussed on that list.

    john