John, To clarify the "we" in the statement "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." are the co-editors (me and Dmitry). We (co-editors) are attempting to address your feedback based on the scope of the draft that was discussed in the WG. Changing of the cardinality (one to many) to support an SMTPUFT8 address in addition to an ASCII address was first brought up by you during the IETF last call. It sounds like you agree that an ASCII address is not required, which is good. Where we (co-editors) and you disagree is your proposal of changing the cardinality of the e-mail addresses in EPP, which is a material change that we (co-editors) don't believe is warranted. If there is the need to change the cardinality of e-mail addresses in EPP, then a new EPP extension can be created for that purpose. That is not intended to do handwaving, but to state how things are handled in EPP. My point around the FOA and RFC 9154 was meant to show that the concern you raised is not a current issue and should not be an issue in the future. We can agree to disagree on the cardinality proposal. I would like to hear from others on this topic. 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/30/22, 3:44 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. (TL;DR summary at end) --On Tuesday, August 30, 2022 12:18 +0000 "Gould, James" <jgould@xxxxxxxxxxxx> wrote: > 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. That is not what I said and I have explained, several times now, that I have not said or claimed it. What I have said is that, if a non-ASCII email address is to be supported, there should be provision --as part of this change, not some handwaving about future possible extensions-- for an all-ASCII alternative to 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. This is all wonderful. But unless you are prepared to show that RFC 9154 has been universally adopted, all the above does is to strengthen the case for allowing for (again, I did not say "requiring in practice") an all-ASCII alternative address when a non-ASCII one is supplied. And, even if you could show that level of adoption, it would have nothing to do with all of the other uses of information that might reasonably be expected to be in registry databases. > 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. I didn't say that either. I'm not even convinced that "cardinality of the e-mail address" is relevant. I believe it was you who claimed that, since that cardinality was not changed, there was no need to show this document as updating 5730. What I have tried to say on that subject, several times, is that draft-ietf-regext-epp-eai is either making a substantive change to 5730 or it is purely supplemental to it. If it is making a substantive change, then it must be identified as updating 5730. It is fairly clear to me that, if a document said "there are three ways" and one adds a fourth, that it is a change ("update"). Contrary to an earlier claim from you about what I said, I never claimed that the document said "there can be only three". Of course, if you are dropping the "functional extension" idea and moving to one of the extension types specified in 5730, that issue is, of course, moot. > 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. Ok. Really interesting. And almost completely irrelevant to this particular specification and protocol, as you have indicated in the past. You have left several actors whom I consider important out of your explanation, but that is almost completely irrelevant as well. I even agree about the last sentence but, while I will again point out that the experience with SMTPUTF8 addresses (outside narrowly defined contexts) would recommend providing such addresses, neither I (nor, as far as I can remember), anyone else has recommended "mandating" them, much less overriding any policy decisions. Instead, the recommendation has, consistently, been that the protocol for passing along non-ASCII addresses (I note that you continue to use "EAI address" above) if the relevant actors decide to do that also make provision for passing along all-ASCII ones should those actors make that decision. If I try to rephrase that into the language of your paragraph above, if any of the relevant actors, including those I believe you have omitted, decide that a non-ASCII email address is not acceptable unless an ASCII alternative is supplied, the protocol should not override that policy decision by making it impossible to provide such an address, at least without going back to the IETF and trying to initiate additional work that, because it was not designed when the protocol specification was approved, might turn out to be more kludge-like than desirable. > 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. I was not aware that the IETF had accepted the efforts of the UA effort as binding technical judgments rather than, e.g., promotional efforts from another community. References to that work and its conclusions are notably missing from the document. I recommend that we not go there. > 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. Could you, or the WG Chairs, please explain "we" as used in the paragraph above? I just took a quick look at the REGEXT mailing list archive and there is no evidence of any discussion in the WG -- the only relevant messages are those copied from this list discussion. I also note that the minutes of the REGEXT meeting from IETF 114 say, in part, "This document has quite some discussion in the IETF-wide last call, and issues reported from: i18ndir, secdir and artart LC. "No in-meeting comments beyond the above." So, whomever "we" is, it presumably is not the WG who forwarded this document to the IESG for publication approval and that has tracked it closely since, approving of each change. I also note that, despite the changes you outline above, the Shepherd's report has not been updated since April. TL;DR summary, as promised... I appreciate the changes you have outlined above. I should perhaps wait for a new draft, and perhaps a new Shepherd report, before commenting further, but, assuming those changes will be as I am assuming, there is only one remaining technical/substantive issue and that is whether, if you are going to provide for transmitting a non-ASCII email address in the protocol, you should also make provision for supplying a non-ASCII alternative in the protocol as well. Such provision would be consistent with the recommendations and experience of the EAI WG as well as several of the examples I have tried to supply; not providing it is inconsistent with both. You will please note that the previous sentence does not say "required to use" -- that is clearly a policy matter -- only that the provision should be there. At this point, there is a separate issue, which is whether, given almost no evidence of WG discussion of this document after it was adopted (converted from draft-belyavskiy-epp-eai) and certainly not after external reviews started to be requested, this is properly processed as a WG document with the strong assumption of consensus within the WG rather than as an individual submission by the authors, perhaps one that the WG decided was a good idea in principle. thanks, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
