Dear John, Many thanks for your comprehensive response!
On Sun, 21 Aug 2022, 18:24 John C Klensin, <john-i...@jck.com> 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 > > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
