John, I will address your point (5), based on the prior thread that we had back in May (https://mailarchive.ietf.org/arch/msg/regext/G08akVkCjnXEPw8k7NiCHbeEamo/), where I stated: I don't agree that section 2.7 of RFC 5730 defines the only forms of extensibility that can ever be supported by EPP and by defining a new form of extensibility to solve a specific problem in EPP is disallowed or non-compliant with RFC 5730. In this case, the form of extensibility (Functional Extension) is formerly defined in draft-ietf-regext-epp-eai for clarity for use in solving the specific problem of EAI in EPP. The intent is not to define a new form of extensibility to EPP in RFC 5730 to solve other similar problems. I agree if a Functional Extension is meant to be a new formal form of extensibility for use in other yet to be defined EPP extensions, then it would make sense to define it in a draft by itself, but that is not the case with draft-ietf-regext-epp-eai. Thanks, -- JG James Gould Fellow Engineer jgould@xxxxxxxxxxxx <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@xxxxxxxxxxxx> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 8/21/22, 12:25 PM, "John C Klensin" <john-ietf@xxxxxxx> 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. (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). (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. (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. (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. thanks, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
