Re: [regext] [Last-Call] 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]>]

James,

A few comments on yours below (with a lot of text elided).  Then
I'm going to step back from this until/unless others are heard
from.

--On Friday, May 27, 2022 12:03 +0000 "Gould, James"
<jgould=[e-mail]> wrote:

> John,
> 
> Thank you for your review and feedback.  My responses are
> embedded below.  
>...

>> On 5/26/22, 2:11 PM, "John C Klensin" <[e-mail]>
>> wrote:

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

I note that you did not respond to the above.  Probably that is
ok -- it could reasonably be interpreted as calling for a
response from WG Chairs and AD, not authors.

>>     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.
 
> JG - Support for EAI across a set of existing and future EPP
> extensions did represent a new extensibility use case was
> discussed in the working group, along with other options.
> The intent of the draft is to support EAI with the definition
> of a functional extension being as a building block to satisfy
> the requirement.  If the use of a functional extension is
> needed beyond EAI then I agree that a functional extension
> draft can be created.  I don't foresee that need at this
> point.  

I think that at least partially misses the point, so let me try
this differently.  "Extension types" are presumably important to
EPP.  They seem to be important enough that you feel called upon
to say "there were three and now we are adding another one".
Perhaps more to the point, while I had not reviewed the base EPP
document, RFC 5730/STD 69, before sending my earlier note, I
have now.  Its section 2.7 of the lists those types and says
"allows features to be added at the protocol, object, and
command-response levels".  That is a very strong implication
that those are the _only_ kinds ("levels") of features that can
be added.  

Internet Standards are not chiseled into stone and nothing
prevents modifying them.  But, at least IMO, adding another
level of features is certainly enough of a big deal to require
explicitly updating RFC 5730 (which the I-D does not identify in
its header).   And the WG should be providing (I'm inclined to
say "owes") the community an explanation of why a fourth type is
needed as well as a clear description of that type that
parallels 2.7.1 - 2.7.3 rather than [just] the language of
Section 4 of the I-D.   The latter appears to very nearly imply
that the extension model of 5730 is inadequate because it does
not provide for overlays on other extensions and properties.  If
that is the case (I might be misreading it, but then your
Section 4 is not clear enough), then that is an even stronger
reason why a clear update to Section 2.7 of RFC 5730 is needed.

Finally, perhaps you have been lucky enough to be spared the
pain, but we've repeatedly discovered (see the IAB's efforts to
understand protocol extensibility) that putting features into a
protocol that are defined on the basis that no one foresees
reasons to use them in different ways leads to complications in
both technical specifications and the ways we construct
documentation.

In any event, the fact that this new type changes, indeed
violates, a provision of RFC 5730, very strongly suggests that a
separate document that updates it and provides adequate
explanation is a necessity.  Even if there were consensus that
it was not needed, this I-D would still be updating 5730 and
should be identified as such.

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

> JG - The migrating to new versions section has become common
> in the EPP extensions (e.g., Section 2 of RFC 9167, Section 2
> of RFC 8807, Section 2 of RFC 8748).  The draft is solely
> focused on supporting EAI in EPP that used pointed version
> numbers (e.g., urn:ietf:params:xml.ns:epp:eai-0.1,
> urn:ietf:params:xml.ns:epp:eai-0.2,
> urn:ietf:params:xml.ns:epp:eai-0.3) for draft implementation
> signaling until after WGLC when the version was changed to
> urn:ietf:params:xml.ns:epp:eai-1.0.  This section is needed to
> provide guidance as implementations upgrade to version
> urn:ietf:params:xml.ns:epp:eai-1.0.  The standards track is
> appropriate for the draft.  The work is complete and there is
> no mechanism serving the same purpose under development.  

Ok.  On this I have to defer to those who have been involved in,
or studied, EPP more deeply than I have (or have time to do).  I
can only say that it gives me a bad feeling and that the object
would be much more serious were this document or any of those
three be proposed for advancement to Internet Standard.

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

AFAICT, you did not respond to that point.
 
>>     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.

> JG - The challenge in the draft is how to apply the non-ASCII
> email address syntax defined in RFC 6530 to the EPP protocol,
> which is highlighted in section 3 of the draft.  The focus is
> on the EPP protocol and not non-protocol policy elements.  The
> security considerations section highlights risks that need to
> be considered. 

I can only give you my opinion.  That opinion, while informed by
my involvement as co-chair of the EAI WG and co-author of RFC
6530, may not represent informed community consensus today.
The collection of specifications in RFC 6530-6532 are more than
about syntax -- the documents (at least try to) rather carefully
explain the potential disruptions and dangers to
interoperability of essentially creating an incompatible overlay
to the Internet's email systems.  The security considerations
discussions in RFCs 6530 and 6531 that you incorporate by
reference are only part of that story.

If an application is going to refer to that set of
specifications as the authority for what it is doing, then it
has some obligation to consider the discussions in them, not
just pick up a piece of syntax out of context, use it, and cite
the SMTPUTF8 family of specifications as the authority.

I don't think mentioning some risks in a Security Considerations
section sufficiently addresses those issues, with the potential
need for either a fallback address or a different negotiation
design being the most important.  

	ASIDE:  I know this is complicated.  I would apologize
	on behalf of the EAI WG, but fault lies with whatever
	entity or process to which one attributes the vast
	differences in human languages and writing systems.
	Many of our efforts, not just within the IETF, but in
	the Unicode Consortium and elsewhere, are ultimately
	about trying to overlay universal common principles on
	systems that do not inherently have them.  If one wants
	to use non-ASCII strings in protocols or as protocol
	elements (as distinct from putting some Unicode-encoded
	free text somewhere; even that often has issues
	especially if the text is going to be displayed).  You
	want strings like non-ASCII email addresses, you accept
	the complexity.   There was even clear awareness within
	the EAI WG that non-ASCII email addresses might be a bad
	idea, i.e., that email addresses should be treated as
	protocol elements.  For several of the participants, the
	main reason for even defining such addresses was that
	people were going to do it anyway and it was more
	important to have clear and interoperable specifications
	than to try to stop the oncoming train (fwiw, the same
	thing was said about non-ASCII domain name labels and,
	due to the IDNA innovation, they were, and are, far more
	safe).

The second paragraph in that section of the I-D adds confusion
rather than clarity.  If readers interpret it as a summary, they
are discouraged from believing they actually need to open and
study the sections of RFCs 6530 and 6531.  If they did study
those documents, they would discover that the paragraph is fully
covered by, and a small subset of, them.  The paragraph's focus
on issues related to domain names ignores the risk, at least as
serious, as attacks on local-parts. For example, in a world with
email service providers (some of whom support non-ASCII local
parts or will do so soon) that support millions of mailboxes at
the same domain, a "homograph" attack on local-parts is far
easier (and likely to be effective sooner) than registering a
similar but malicious domain name and waiting for a mistake to
be made.  Not only is the set of local-parts a bigger target
(opportunity) space, but, as 6350 points out (but the paragraph
in the I-D does not), IDNA imposes some constraints that prevent
a subset of possible attacks that SMTPUTF8 does not.

If, instead, readers interpret that paragraph providing material
in addition to what is in the cited RFCs... well, it doesn't.

At a minimum, more clarity is needed in that section.  If your
comment was meant to imply that is covers enough of the
considerations to eliminate the need to careful attention to the
provisions of the SMTPUTF8 collection of RFCs in you design, it
is, at best, inadequate.

best,
   john