--On Tuesday, September 13, 2022 22:17 +0200 Dmitry Belyavsky <beldmit@xxxxxxxxx> 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\u1F438@xxxxxxxxxxx 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
