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

[Dmitry Belyavsky <[e-mail]>]

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.
>
> In no particular order:
>
> (1) I believe that, if you are trying to create an IETF
> standards track protocol that draws on another IETF standards
> track protocol for its motivation, you are obligated to follow
> the specifications of that protocol and associated experience,
> not just pick up its syntax.  In the case of non-ASCII email
> addresses, that includes making all-ASCII addresses available as
> an alternative unless there is great confidence that they will
> not be needed (e.g., for communications within a country using
> that country's major script (and where relevant, language) and a
> restricted set of email providers.  Such a restriction might
> actually be reasonable within a constrained business
> transaction, especially when registrant, registry, registry, and
> the domain itself primarily serve a particular country or
> cluster of countries (see below).
>
> The IETF and its predecessors have carefully avoided specifying
> MUA, especially MUA-UI, behavior for well over 40 years.  In
> that context, the key difficulty with non-ASCII addresses may
> not be easily discerned from our specifications.  However, as
> the EAI WG understood from the beginning, transporting non-ASCII
> addresses across the Internet,in message header formats, even
> delivery status notification (DSN) messages, is fairly easy.  It
> is especially easy by comparison to actually designing and
> building software that interacts with users across a very broad
> range of languages and writing systems.  The usual solutions are
> to either give up on that quality of MUA/UI-UX design and
> instead design for a particular language community or small
> cluster of them, but that leaves messages that use, or embed
> addresses in, other languages and scripts in need of all-ASCII
> (or some other common/agreed form) in greater or lesser trouble.
>
> As a different, extreme, and nit-picky, example of where this
> specification has failed to appreciate what the
> Internationalized Email specifications say, thse specifications
> for non-ASCII email addresses and headers make it quite clear
> that there are no such things as an "EAI Address" or an "EAI
> extension" and that the correct term is "SMTPUTF8".  That would
> not be important except that IETF specs should not be creating
> confusion by using incorrect terminology (no matter how
> prevalent elsewhere) and because it reinforces the concern that
> the WG may not have paid careful attention to the relevant
> specifications (beyond a citation of syntax) in creating this
> one.
>

Yes, using the "SMTPUTF8-compliant" term seems reasonable.

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


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


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


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

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


>
> thanks,
>     john
>
>
>