John, You claim that the registrant's e-mail address in the registry is critical to the transfer process and therefore an ASCII address must always be provided. The EPP credential used to authorize a transfer is not the e-mail address, but the Authorization Information. I'm aware of the Form of Authorization (FOA) that relies on the registrant's e-mail address, which is currently deferred for the gaining registrar (registrar ABC in your example). RFC 9154 "EPP Secure Authorization Information for Transfer" was created to enhance the security of the Authorization Information, which should result in reducing or removing the dependency on the FOA from the gaining registrar and the use case that you're concerned with. You also claim that if the draft does not change the cardinality of the e-mail address in EPP that it's not a proper candidate for processing as an IETF standards track document. Adding support for EAI addresses as a first-class alternative to ASCII addresses in EPP is an important change that warrants an IETF standards track document. For an EAI address to be stored in the registry database, it needs to pass through 3 levels of policy. The registry policy needs to support receiving either an ASCII address or an EAI address. The registrar policy needs to support collecting an EAI address as an alternative to or in additional to an ASCII address, and support passing the EAI address to an EAI-enabled registry. The registrant decides, according to their policy, to provide an EAI address to the registrar. The protocol should not override these policy decisions by mandating an ASCII address always be provided. In line with Universal Acceptance (UA), what draft-ietf-regext-epp-eai does is to enable the servers (registries) and clients (registrars) to pass EAI addresses as first-class citizens to ASCII addresses in EPP, with the appropriate signaling and behavior obligations. Based on your feedback, we agree to revise the draft to be a command-response extension and to refer to an SMTPUTF8 address instead of an EAI address. Changing the cardinality of the e-mail addresses in EPP to continue to support an ASCII address is required policy is not in line with the purpose this draft. 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/23/22, 3:34 PM, "John C Klensin" <john-ietf@xxxxxxx> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. (shortening the quoted text to focus on things about which I have more to say) --On Monday, August 22, 2022 08:40 +0200 Dmitry Belyavsky <beldmit@xxxxxxxxx> wrote: > Dear John, > Many thanks for your comprehensive response! > > > > On Sun, 21 Aug 2022, 18:24 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. >> >... >> (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. >... Aha! This may identify another area where we have been understanding terminology, and hence the problem, differently, leading to some failure to communicate. I hope Patrik, who has been closer to the issues in recent years than I have, will comment further but... There is a third case that I think is different from your first one. Back in the ancient times when I was advising ICANN and then on the ICANN Board it was considered at least as important as your second one. My understanding of your first case was not considered a significant issue, partially for the reason you identified. That third case is best illustrated with a made-up example that drifts rather far into policy issues but it probably helps explain why, if registries are going to allow non-ASCII addresses in the registry databases, they need to be able to specify that ASCII alternatives be there too... and that implies that a way to provide such addresses should be part of the protocol. Suppose, I am a registrant of foo.example., registered there through registrar XYZ. I am happy with the name, with the registry for the "example." TLD and so on, but, perhaps due to changes in their business policies, am completely fed up with having XYZ as a registrar. So what I want to do, perhaps only at renewal time, is to register/renew the domain via a different registrar, perhaps ABC. The transfer case now involves the very fundamental and long-debated question of who the domain, foo.example, actually belongs to. Policy decisions have been made repeatedly that the answer is not XYZ. Because of the original name acquisition, I am registered as a client of XYZ. I have supplied them with a non-ASCII email address as the administrative contact (at least) for foo.example (probably the other contact addresses as well). I go to make the switch and perhaps ABC, despite whatever else attracts me to them, does not yet handle non-ASCII addresses. The registry does not have a non-ASCII address so ABC cannot use information there to validate me. Even if XYZ has an all-ASCII backup address (one that was not made available to the registry) hidden away, they have no technical, and probably no external policy, reason to cooperate. All of myself, ABC, and the registry now have a problem on our hands, one which could be resolved by an ICANN policy requiring that XYZ release all of the information they have on me (whether they consider it part of their business relationship or not) and including any special authentication information, or a specific list of data that include alternate email addresses, to ABC and/or the registry. To the best of my knowledge, there is no such policy and I would not be optimistic about the ability to create one quickly. Another solution would be an ICANN policy, mandatory for all contracted parties at least, requiring that everyone support non-ASCII email addresses written in any script supported in Unicode (not just, e.g., characters derived from the root MSR because these are email addresses, not domain names). Not holding my breath about that either. Of course, if the registry is feeling cooperative, they could contact me on behalf of ABC, get themselves in the middle of the transaction, and sort this out even though they have business incentives to avoid getting into the middle of this if possible (there are several opportunities here and above that could provide full employment to many lawyers). But consider a related case. Suppose that, instead of "foo", I had registered an IDN string using a script that the registry had no staff who could read or type and no MUA that knew how to utilize. No problem so far because of how IDNA works, but assume that I supplied an email address whose local part (as well as the domain part) were in that script. The path to which that leads is the reason for the "don't register what you don't understand" language in the IDNA specs and its reinforcement and explanation in the ill-fated draft-klensin-idna-rfc5891bis. And the bypass for the problem is, of course, availability _in the registry database_ of an alternate, all-ASCII, address in addition to the non-ASCII one. >> (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 :( My point --see my earlier note to James-- is that, if this is out of scope for this document, then the document is probably not a proper candidate for processing as an IETF standards track document. >> (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. And that arguably makes some ICANN policy-making prerequisite to the IETF processing this document. Whatever the IETF does, it should not be standardizing things that will make the Internet work worse in the absence of real-world realities. All of the above really says is that, if there is a choice, any protocol standardization effort should encourage good behavior (whether it can successfully discourage bad behavior or not). Note particularly the "forcing different arrangements" part. >> (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. As shown in the longer analysis in my earlier note today, that is correct. But, if no change to the formal XML scheme for the email address is needed, then this document need specify only the command-response negotiation between registrar and registry about whether the "real" syntax for email addresses can contain non-ASCII characters. Everything else is just a source of confusion. Of course, that still does not address the need for a way to transmit an all-ASCII alternative if the primary email address requires SMTPUPT8 support. > Do you think it makes sense to add that our document updates > RFC 5730? If that is what you are doing (e.g., if it is adding an extension type), I think that not only makes sense but is necessary. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
