(to slightly minimize traffic and the number of "too many addressees" messages, response to Scott's suggestion below as well.) --On Tuesday, August 23, 2022 12:45 +0000 "Gould, James" <jgould=40verisign.com@xxxxxxxxxxxxxx> wrote: > The requirement of draft-ietf-regext-epp-eai is to add support > for SMTPUTF8 email addresses in EPP. Changing the cardinality > (one to two or one to many) for e-mail addresses in EPP > extensions, such as RFC 5733 and RFC 8543, is a different > requirement that can be addressed with a different EPP > extension, and the decision of whether to require an all-ASCII > e-mail address would be up to server policy and not the > protocol itself. James, I think you have just explained something I was not "getting". More on that below. At some level, the above is probably key to the disagreement we are having. One view of the situation, stated in somewhat more extreme form than anything you have said, is "this spec just adds support for the syntax of non-ASCII addresses. Anything else, such as whether those addresses are usable and by whom, whether sufficient information is provided to be consistent with the SMTPUTF8 specs, what additional extensions or policy work might be needed, etc., is Someone Else's Problem (or a future issue having nothing to do with this spec)." The other view is that, if this is going to be an IETF standards track protocol, it cannot introduce properties that are known to be problematic by saying "future problem, out of scope". If the problems and solutions are known, the spec should be required to address them. If only the problems are known, the spec should at least carefully explain those problems and the reasons why they cannot be addressed at present. Step away from EPP for a moment and think about what the IETF's reaction would be if someone proposed a TCP extension, was told that it would wreck deployed implementations, and responded with "damage is out of scope but can be addressed, if needed, by future specifications, so the IETF should approve this one". In line with that second view, I don't think you get to say "...addressed in a different extension" unless you are prepared to specify, and normatively reference, that extension now or better explain why the extension is not needed to make this one work in practice for all plausible applications. Now, separately, what I just learned is that the reason you are objecting to adding a mechanism for an alternate, all-ASCII, address, which is that a second field for such an address would change "the cardinality ... for e-mail addresses". From one point of view, that is a big deal. From another, if parts of the former EAI WG community and/or i18n expert community are telling you that non-ASCII addresses are impractical in the general case without it, that is a message that this is just not as simple as a small syntax modification and that a spec that treats it as the latter is, at best, incomplete. However, it seems to me (without doing a great deal of research) that you could provide the alternate address functionality with a single field even though it might be a tad ugly. If your other constraints permit (or could be extended by this document), one could have something like: "non-ASCII-local@non-ASCII-domain ; ASCII-local@ASCII-domain" Whatever that might be, it is almost certainly one address and not two (but it is not conformant _as one address_ with RFC 5322 so you would need to do some careful writing. Or, if you didn't like the aesthetics or other implications of that, consider: "SMPTUTF8withAlternateAddress: non-ASCII-local@non-ASCII-domain, ASCII-local@ASCII-domain;" an odd, but perfectly valid, use of group syntax from 5322. You could, I suppose, even recommend a specific group name in your spec. Finally to Scott's suggestion/ question: --On Tuesday, August 23, 2022 11:54 +0000 "Hollenbeck, Scott" <shollenbeck=40verisign.com@xxxxxxxxxxxxxx> wrote: > [SAH] A thought: the traditional command-response extension > would preserve the ability to provision an all-ASCII address > using the data structures defined in RFC 5733. A contact > <create> command (for example) could be extended to add > support for provisioning an additional SMTPUTF8 address. Would > that approach address your concern, John? >From a technical standpoint, yes. However, it raises a variation on a point both Dmitry and James have raised in different ways (and with which I mostly agree): if one wants to encourage the use of non-ASCII email addresses when they are available, then they should be the first-class forms if they are available and an all-ASCII alternative form should be seen only as a fallback. So I suppose one would want an extension like this one to get the non-ASCII address into the 5733 data structure and then to use contact <create> to specify the non-ASCII one. One could even make the additional contact information and non-ASCII form optional in that case -- I can live with almost anything that makes provision for supplying it through the protocol. That, too, would work for me but iff that mechanism were specified in the current document rather than being used as an excuse to say "out of scope, someone else's problem". best, john > From: Dmitry Belyavsky <beldmit@xxxxxxxxx> > Date: Tuesday, August 23, 2022 at 2:43 AM > To: John C Klensin <john-ietf@xxxxxxx> > Cc: James Gould <jgould@xxxxxxxxxxxx>, Patrik Fältström > <paf@xxxxxxxxxx>, "Gould, James" > <jgould=40verisign.com@xxxxxxxxxxxxxx>, "art@xxxxxxxx" > <art@xxxxxxxx>, "draft-ietf-regext-epp-eai.all@xxxxxxxx" > <draft-ietf-regext-epp-eai.all@xxxxxxxx>, "last-call@xxxxxxxx" > <last-call@xxxxxxxx>, regext <regext@xxxxxxxx>, > "i18ndir@xxxxxxxx" <i18ndir@xxxxxxxx>, "gen-art@xxxxxxxx" > <gen-art@xxxxxxxx> Subject: [EXTERNAL] Re: Re: Re: [Last-Call] > last call reviews of draft-ietf-regext-epp-eai-12 (and -15) > > Dear John > On Tue, 23 Aug 2022, 04:27 John C Klensin, > <john-ietf@xxxxxxx<mailto:john-ietf@xxxxxxx>> wrote: > > > --On Monday, August 22, 2022 16:01 +0000 "Gould, James" > <jgould@xxxxxxxxxxxx<mailto:jgould@xxxxxxxxxxxx>> wrote: > >> John, >> >> How about if we change the approach to use the well-understood >> command-response extension? > > If things were changed to create an extension type that is > defined in RFC 5730 rather than creating a new type, that would > certainly eliminate the need to update 5730 (or explain clearly > why that was not necessary). > > That, of course, leaves the more substantive SMTPUTF8 issues, > particularly the need for a slot for an alternate all-ASCII > address. > > No. SMTPUTF8 email address _is_ email address. Otherwise we > are stuck with email addresses of first-class and of > second-class forever. > > We don't need separate slot for all-ASCII addresses. a kludge that those who where sufficiently motivated could figure out such as: "(ASCII-local@ASCII-domain) non-ASCII-local@non-ASCII-domain" (I'd be opposed to the latter, but others might disagree.) All of these would be perfectly valid under the syntax you cite from RFC 5322 Section 3.4 (and its RFC 6531 variation) and with "eppcom:minTokenType" as defined in RFC 8543 [1] and RFC 5730 since the latter defines that term as "token" with no specified pattern and https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#token imposes restrictions only on CR, LF, and white space characters. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
