John, Thanks for your detailed feedback.
-17 does support an all-ASCII email address if a non-ASCII email is provided, but during a transition period that is up to server policy. There is no way for the extension to forecast the support for SMTPUTF8 globally. The complexity and the need for the extra e-mail only applies during the transition period (e.g., prior to SMTPUTF8 global support). If the <eai:email> element only contains an ASCII e-mail address and the primary e-mail address contains either an ASCII or SMTPUTF8 address, then the need for the extra (alternative) e-mail would only apply during a transition period. SMTPUTF8 full support may take decades as you state, but the extension needs to support removing the need for the extra ASCII e-mail. The extra e-mail address in the <eai:email> element does represent an alternative e-mail address and it really should only be provided when the primary e-mail address is SMTPUTF8 and the server is running in the transition period. I believe the concept of the alternative e-mail needs to remain, along with the concept of a transition period to drive when the alternative e-mail is needed, and when the alternative e-mail can be removed. I do like the concept of having the alternative e-mail only be used for the ASCII value, which puts SMTPUTF8 on equal footing with ASCII for the primary e-mail value. On the use of eai XML namespace and XML prefix, we discussed it but didn't feel it was necessary. I'm not opposed to making the change from "eai". Is your proposal to use "smtputf8" in place of "eai" for the draft name (draft-ietf-regext-epp-smtputf8), the XML namespace (urn:ietf:params:xml:ns:epp:smtputf8-1.0), and the XML prefix and XML elements (<smtputf8:smtputf8> and <smtputf8:email>)? Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/27/23, 1:17 PM, "John C Klensin" <john-i...@jck.com <mailto:john-i...@jck.com>> wrote: James, I believe I've said most of what I'm about to say in early November or even earlier, but it looks like that several of those notes didn't go to the WG list much less the Last Call one. So, since you asked, let me try once more. In the process, let me try a slightly different perspective in the hope of explaining better. I also think this will be useful as a review for those who have not been following the evolution of the discussion carefully and from the beginning. Anyone who is firmly convinced that they understand the entire context and history can safely skip to the paragraph starting "Bottom line" below and read from there. It seems to me that, with a significant fraction of the work covered by REGEXT, and with optional extensions to EPP in particular, there are two separate (for lack of a better term) decision points or clusters. One is basically policy: determination of what fields are required and which are optional and, to some degree, how information is represented within a given field if it is used. The other is technical: whether or not a field is present/ allowed in the protocol or database element/ data dictionary specification. We have REGEXT and its work on the technical side; part of it may affect EPP because information that is captured/obtained from the registrant by the registrar but not transmitted to the registry cannot end up in a registry database. Keeping information out of the registry databases may constrain policy decisions about that information and be considered inappropriate or even obstructive. On the more clearly policy side, there are all sorts of current and potential actors. The most obvious (and the one we discussed in the context of much earlier versions of the draft) is what a registry decides it will allow and/or require, things that might reasonably be written into contracts or instructions from registry to registrar. However, there are other possibilities with the most obvious being the possibility of ICANN making a decision that such-and-such information must be available in a registry database (and writing the requirement into contracts) or a national regulator or court with authority over the registry saying the same thing (or, in theory, prohibiting capture of some data elements). I don't think it is relevant to this discussion but regulations and decisions about who can actually access what information and under what circumstances (with GDPR and GDPR-like rules as a prominent example) are almost completely orthogonal to the above. Now, with that as backdrop, let's come back to non-ASCII email addresses and review the situation. The EAI WG did not impose any significant restrictions on the local-part of an email address other than it be valid UTF-8 (see the discussion in Section 3.3 of RFC 6531). From some perspectives, that may have been a mistake, but it is where we are today. Many email providers have imposed, e.g., rules about specific scripts or use of only a single script in a local-part, but that is, again, policy: EPP cannot depend on there being global rules or even conventions. If a registrant, for whatever reason, wants to obscure an email address, it is not hard to construct a string that will not even copy and paste correctly using most libraries. Given the range of the world's writing systems and languages and the observation that "valid UTF-8" does not prohibit mixtures of them that we would consider odd (if not inherently malicious), it would not even be hard to end up with such an address out of an excess of cleverness (the most obvious example would involve a local-part with one or more clever embedded emoji combining sequences). Glancing back to the policy side, there is, AFAIK, no global (and enforced) rule requiring that a registrar use the supplied email address (or any email address at all) to communicate with registrants or that they otherwise ensure that even they, much less anyone else, can use the address to communicate. If someone does something sufficiently strange where communication is important, and does so using a script with which the registry (and anything entitled to access and use the data) are not thoroughly familiar, there is no alternative other than an all-ASCII alternate (or "fallback", which might have been a better term from the start) email address. That is not to imply that non-ASCII, SMPTUTF8-conforming, addresses do not work well within a language environment in which everyone is familiar with the writing systems being used and either regulation or good business sense causes mail service providers to restrict the addresses that can be allocated and used to ones that are locally sensible: they do work quite well and there are millions of such addresses and users of them. But the DNS is global and, as we have observed, many registries have decided that it is not in their interest (or their interpretation of the interest of the international Internet) to follow the requirement of the IDNA2008 specifications for deep understanding of the scripts they are permitting for registration of domain names [1]... a far easier requirement than ensuring that an non-ASCII email address will be globally useful. There is another aspect to the above, which is that the issues are fundamental to the SMTPUTF8 protocol requirements and, more important, to Unicode and its mechanisms (including UTF-8). They are not going away, at least until we all speak and write the same language and use the same writing systems (something I hope no one is advocating). With all of that as background, having provision in EPP for an alternative, all-ASCII, email address when a non-ASCII one is provided is important, especially if one is trying to promote the use of non-ASCII addresses (promotion, i.e., "mak[ing] them more widely accepted") is arguably a policy matter with which IETF standards track specs should not be involved). Whether to allow non-ASCII addresses is a policy matter (and the draft quite properly provides a way to negotiate that between registrar and registry). Whether to allow or require an all-ASCII alternative when a non-ASCII email address is provided is, equally, a policy matter, although, again, not providing for such an address blocks reasonable policies, so I'm glad we have gotten past that. Bottom line on -17: As long as there is provision for an all-ASCII email address if a non-ASCII one is provided, I can live with the spec. However, the spec as it appears in -17 is, IMO, far more complicated than it needs to be and some of the additional complexity could easily introduce confusion and interoperability problems. Specifically: (i) What is needed is provision for an all-ASCII address if the extension is used to allow a non-ASCII one. Using the extension to allow two non-ASCII addresses, two all-ASCII ones, or an all-ASCII primary one and a non-ASCII alternative makes no sense (at least AFAICT), risks being confusing, and puts additional burden on the policy makers to make rules that prevent its misuse. So, unless there is a rationale I don't understand, the <eai:email> element should have content restricted to an RFC 5322-conforming address. (ii) While, again, appropriate policy decisions could "fix" (or, if you prefer, subvert) it, the discussion of, and requirement for, a transition period is a work of fiction. For the reasons having to do with the complexity of human (so far) writing systems implied above, "transition period long enough for authorized users to effectively communicate using only an SMTPUTF8 address" is going to be in centuries at least. This is not a matter of putting out a new EPP release with an extra block of code. (iii) Nit: I still wish you would get "EAI" out of this. Regardless of how it may or may not be used outside IETF specs, it is NOT RECOMMENDED usage in IETF specs and will cause confusion if and when a WG is created to review and upgrade the SMTPUTF8 specification collection. While the corrections to the document title and running text are appreciated, it would be an improvement to name elements something other than, e.g., <eai:eai> and <eai:email>. Summary and Recommendations: (1) Clear all of the "transition" material and comments out of the document. It adds confusion and complexity, gets tangled up with policy matters, and will have no practical value in addressing the underlying issues. (2) Clear out the "alternate SMTPUTF8 address" stuff. If the extension is successfully negotiated, there should be only two cases. In one, the main address is SMTPUTF8-conforming and hence potentially non-ASCII. In the second case, the main address is SMTPTUTF8-conforming and there is an alternative one that is all-ASCII. I would prefer that you put a SHOULD NOT on the second case if the main, SMTPUTF8, address is entirely conformant to RFC 5322 for the local-part and does not use IDNs (in either form) for the domain-part, but I don't feel very strongly about it. If you do not make that provision, and maybe if you do, there should be no prohibition on the alternate address being identical to the main one. Whether the second case is required, or, indeed, permitted, in practice is a policy matter. (3) (Less important than the above) Finish the process of clearing "eai" out of the document, especially wrt element names. thanks, john [1] See https://secure-web.cisco.com/1Rwn55zElMR6DcPDJ2wK_VtOP2F2WzHFbafAOxv8XEAWuD-Dofddr3I6AXkNBuAtXk2D6d_Zw_4LXzY1OxvQGooeMOuPh_opniKAuRBKEdzRNxooZbmHeL1llBex6fRU7BCtGKK_ZVkbMkc-x1EsyANc9NYocExYKEzBvgr-W0GlFVYlUZPYVjCOcxkHapOCcregc4M6tslzWzRsBUMv6mRT7I80tU3smrkr5jngZ2zeM8SwpVIG_w2TRgPFjV4l25gquO41Vf5IeNDkXWmo-3jCOOZWEC5z-M5gXBDgpH5U/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-klensin-idna-rfc5891bis%2F <https://secure-web.cisco.com/1Rwn55zElMR6DcPDJ2wK_VtOP2F2WzHFbafAOxv8XEAWuD-Dofddr3I6AXkNBuAtXk2D6d_Zw_4LXzY1OxvQGooeMOuPh_opniKAuRBKEdzRNxooZbmHeL1llBex6fRU7BCtGKK_ZVkbMkc-x1EsyANc9NYocExYKEzBvgr-W0GlFVYlUZPYVjCOcxkHapOCcregc4M6tslzWzRsBUMv6mRT7I80tU3smrkr5jngZ2zeM8SwpVIG_w2TRgPFjV4l25gquO41Vf5IeNDkXWmo-3jCOOZWEC5z-M5gXBDgpH5U/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-klensin-idna-rfc5891bis%2F> for a longer discussion on that matter. [2] As suggested in Section 8, bullet 1 of the draft. --On Thursday, January 26, 2023 13:17 +0000 "Gould, James" <jgo...@verisign.com <mailto:jgo...@verisign.com>> wrote: > Andy, > > Sorry for the late response to your message. The updates in > -17 were made to address the feedback from John Klensin during > the IETF Last Call, which included changing the cardinality to > the One or Two (ASCII or SMTPUTF8) Option defined in the > IETF-115 presented deck > (https://secure-web.cisco.com/1Pt8HuW_yyhw3td0mbz8F31vTGSSHRZsxXf8KRA26x7Yyqo1qVlNNKLuBRnPo3fQyPev-hcvdUwHKiyTp93_mEyKe8r_LvhVJzcTM7Za63lsYO85mf2nXElMJ4HWZpfp0NOOPk0uJehohGmIL9fPiIlIVL2Nub0fAN3RY4vIZwjMYfqPe_6D7RZg8VJCE_GV1KHXWD_Y7WhijhLhmZ1fvGyf8o8Q-MGF65N2sG18Zr9vjE3MQhnepB8u7ogOkXFXqFfqMGrjEuIOExCKEfJwn5JVQr0hGhFuG1QMTH0jzOSo/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F115%2Fmaterials%2Fslides-115 > > <https://secure-web.cisco.com/1Pt8HuW_yyhw3td0mbz8F31vTGSSHRZsxXf8KRA26x7Yyqo1qVlNNKLuBRnPo3fQyPev-hcvdUwHKiyTp93_mEyKe8r_LvhVJzcTM7Za63lsYO85mf2nXElMJ4HWZpfp0NOOPk0uJehohGmIL9fPiIlIVL2Nub0fAN3RY4vIZwjMYfqPe_6D7RZg8VJCE_GV1KHXWD_Y7WhijhLhmZ1fvGyf8o8Q-MGF65N2sG18Zr9vjE3MQhnepB8u7ogOkXFXqFfqMGrjEuIOExCKEfJwn5JVQr0hGhFuG1QMTH0jzOSo/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F115%2Fmaterials%2Fslides-115> > -regext-draft-ietf-regext-epp-eai-cardinality-00). One of the > elements of the One or Two (ASCII or SMTPUTF8) Option was to > "Provide guidance in draft for the transition period", which > is covered in Section 8 "SMTPUTF8 Transition Considerations" > (https://secure-web.cisco.com/11Sv8McB5e2xMytYNg0UJwGnI6nDZqmvQOATJXLHUD7wdEemk_pn3fbHPy1Sv1fZZz7bWFV3SjjEY_kK_EFLntjOWsQPebE17y2XelFcr81PEzahzYGGHDDCSd7WuomjFC351M64fI1YCvEnga64zYJtkVOk66-oonr0GM0yrfVmcfDF-jGfV5WB6iJFVUKdhEg6K49V2SpEHQTsDfXDhkfiCyy_1LCvYddicknDDZSCbduOHaoEZC229c_D6kgAZ6jFimYyL54i3VYgGqvybnET74JalFvv_hOi_r9RIrZ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-e > > <https://secure-web.cisco.com/11Sv8McB5e2xMytYNg0UJwGnI6nDZqmvQOATJXLHUD7wdEemk_pn3fbHPy1Sv1fZZz7bWFV3SjjEY_kK_EFLntjOWsQPebE17y2XelFcr81PEzahzYGGHDDCSd7WuomjFC351M64fI1YCvEnga64zYJtkVOk66-oonr0GM0yrfVmcfDF-jGfV5WB6iJFVUKdhEg6K49V2SpEHQTsDfXDhkfiCyy_1LCvYddicknDDZSCbduOHaoEZC229c_D6kgAZ6jFimYyL54i3VYgGqvybnET74JalFvv_hOi_r9RIrZ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-e> > ai#section-8 ) with normative language. Below are the options > to consider for the working group: > > 1. Keep Normative Language - Keep the Section 8 "SMTPUTF8 > Transition Considerations" > (https://secure-web.cisco.com/11Sv8McB5e2xMytYNg0UJwGnI6nDZqmvQOATJXLHUD7wdEemk_pn3fbHPy1Sv1fZZz7bWFV3SjjEY_kK_EFLntjOWsQPebE17y2XelFcr81PEzahzYGGHDDCSd7WuomjFC351M64fI1YCvEnga64zYJtkVOk66-oonr0GM0yrfVmcfDF-jGfV5WB6iJFVUKdhEg6K49V2SpEHQTsDfXDhkfiCyy_1LCvYddicknDDZSCbduOHaoEZC229c_D6kgAZ6jFimYyL54i3VYgGqvybnET74JalFvv_hOi_r9RIrZ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-e > > <https://secure-web.cisco.com/11Sv8McB5e2xMytYNg0UJwGnI6nDZqmvQOATJXLHUD7wdEemk_pn3fbHPy1Sv1fZZz7bWFV3SjjEY_kK_EFLntjOWsQPebE17y2XelFcr81PEzahzYGGHDDCSd7WuomjFC351M64fI1YCvEnga64zYJtkVOk66-oonr0GM0yrfVmcfDF-jGfV5WB6iJFVUKdhEg6K49V2SpEHQTsDfXDhkfiCyy_1LCvYddicknDDZSCbduOHaoEZC229c_D6kgAZ6jFimYyL54i3VYgGqvybnET74JalFvv_hOi_r9RIrZ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-e> > ai#section-8 ) normative language 2. Change to Non-Normative > Language - Change Section 8 "SMTPUTF8 Transition > Considerations" > (https://secure-web.cisco.com/11Sv8McB5e2xMytYNg0UJwGnI6nDZqmvQOATJXLHUD7wdEemk_pn3fbHPy1Sv1fZZz7bWFV3SjjEY_kK_EFLntjOWsQPebE17y2XelFcr81PEzahzYGGHDDCSd7WuomjFC351M64fI1YCvEnga64zYJtkVOk66-oonr0GM0yrfVmcfDF-jGfV5WB6iJFVUKdhEg6K49V2SpEHQTsDfXDhkfiCyy_1LCvYddicknDDZSCbduOHaoEZC229c_D6kgAZ6jFimYyL54i3VYgGqvybnET74JalFvv_hOi_r9RIrZ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-e > > <https://secure-web.cisco.com/11Sv8McB5e2xMytYNg0UJwGnI6nDZqmvQOATJXLHUD7wdEemk_pn3fbHPy1Sv1fZZz7bWFV3SjjEY_kK_EFLntjOWsQPebE17y2XelFcr81PEzahzYGGHDDCSd7WuomjFC351M64fI1YCvEnga64zYJtkVOk66-oonr0GM0yrfVmcfDF-jGfV5WB6iJFVUKdhEg6K49V2SpEHQTsDfXDhkfiCyy_1LCvYddicknDDZSCbduOHaoEZC229c_D6kgAZ6jFimYyL54i3VYgGqvybnET74JalFvv_hOi_r9RIrZ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-e> > ai#section-8 ) to be non-normative, similar to Section 6 > "Transition Considerations" of RFC 9154 > (https://secure-web.cisco.com/1KHKcW1v64v4YtXoGrGuiJDcetsbO8JtpXpXr2xec0zs7RkCkWwNZ4XY9qtAGjnuFkzc2J0AV0e9AAW001zvMnwjPG3kyQHKHiUS7cYmE50G0jSFSsyUEoBvG1Ve6AUB2wkFG5z21uc0gIU3nqspIhswHvAqNqbhDzA7TakwA9zGWM7CcpibXmJhhSEq1hdVrMVrzFahhUL6hJrPXRQCrRTZ6JcGnVWZxu982OjbAIRtTYZ6Le_I9Mi7It3zJToaQNhKuO2XlxKAtCU1SaVVouvuOlCVP_vZa3a2O4eKXo30/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9154%23section-6 > > <https://secure-web.cisco.com/1KHKcW1v64v4YtXoGrGuiJDcetsbO8JtpXpXr2xec0zs7RkCkWwNZ4XY9qtAGjnuFkzc2J0AV0e9AAW001zvMnwjPG3kyQHKHiUS7cYmE50G0jSFSsyUEoBvG1Ve6AUB2wkFG5z21uc0gIU3nqspIhswHvAqNqbhDzA7TakwA9zGWM7CcpibXmJhhSEq1hdVrMVrzFahhUL6hJrPXRQCrRTZ6JcGnVWZxu982OjbAIRtTYZ6Le_I9Mi7It3zJToaQNhKuO2XlxKAtCU1SaVVouvuOlCVP_vZa3a2O4eKXo30/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9154%23section-6>). > 3. > Use Hybrid Language - Use a hybrid of normative and > non-normative language in Section 8 "SMTPUTF8 Transition > Considerations" > (https://secure-web.cisco.com/11Sv8McB5e2xMytYNg0UJwGnI6nDZqmvQOATJXLHUD7wdEemk_pn3fbHPy1Sv1fZZz7bWFV3SjjEY_kK_EFLntjOWsQPebE17y2XelFcr81PEzahzYGGHDDCSd7WuomjFC351M64fI1YCvEnga64zYJtkVOk66-oonr0GM0yrfVmcfDF-jGfV5WB6iJFVUKdhEg6K49V2SpEHQTsDfXDhkfiCyy_1LCvYddicknDDZSCbduOHaoEZC229c_D6kgAZ6jFimYyL54i3VYgGqvybnET74JalFvv_hOi_r9RIrZ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-e > > <https://secure-web.cisco.com/11Sv8McB5e2xMytYNg0UJwGnI6nDZqmvQOATJXLHUD7wdEemk_pn3fbHPy1Sv1fZZz7bWFV3SjjEY_kK_EFLntjOWsQPebE17y2XelFcr81PEzahzYGGHDDCSd7WuomjFC351M64fI1YCvEnga64zYJtkVOk66-oonr0GM0yrfVmcfDF-jGfV5WB6iJFVUKdhEg6K49V2SpEHQTsDfXDhkfiCyy_1LCvYddicknDDZSCbduOHaoEZC229c_D6kgAZ6jFimYyL54i3VYgGqvybnET74JalFvv_hOi_r9RIrZ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-regext-epp-e> > ai#section-8 ). The normative elements would be based on > working group feedback. > > In reviewing a similar case of Section 6 "Transition > Considerations" of RFC 9154 > (https://secure-web.cisco.com/1KHKcW1v64v4YtXoGrGuiJDcetsbO8JtpXpXr2xec0zs7RkCkWwNZ4XY9qtAGjnuFkzc2J0AV0e9AAW001zvMnwjPG3kyQHKHiUS7cYmE50G0jSFSsyUEoBvG1Ve6AUB2wkFG5z21uc0gIU3nqspIhswHvAqNqbhDzA7TakwA9zGWM7CcpibXmJhhSEq1hdVrMVrzFahhUL6hJrPXRQCrRTZ6JcGnVWZxu982OjbAIRtTYZ6Le_I9Mi7It3zJToaQNhKuO2XlxKAtCU1SaVVouvuOlCVP_vZa3a2O4eKXo30/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9154%23section-6 > > <https://secure-web.cisco.com/1KHKcW1v64v4YtXoGrGuiJDcetsbO8JtpXpXr2xec0zs7RkCkWwNZ4XY9qtAGjnuFkzc2J0AV0e9AAW001zvMnwjPG3kyQHKHiUS7cYmE50G0jSFSsyUEoBvG1Ve6AUB2wkFG5z21uc0gIU3nqspIhswHvAqNqbhDzA7TakwA9zGWM7CcpibXmJhhSEq1hdVrMVrzFahhUL6hJrPXRQCrRTZ6JcGnVWZxu982OjbAIRtTYZ6Le_I9Mi7It3zJToaQNhKuO2XlxKAtCU1SaVVouvuOlCVP_vZa3a2O4eKXo30/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc9154%23section-6>), > I > would choose option 2 "Change to Non-Normative Language ". > > I would like to hear from others in the working group, > including John Klensin. > > Thanks, _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
