Re: [I18ndir] [Last-Call] last call reviews of draft-ietf-regext-epp-eai-12 (and -15)

[John C Klensin <[e-mail]>]

(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=[e-mail]> 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=[e-mail]> 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 <[e-mail]>
> Date: Tuesday, August 23, 2022 at 2:43 AM
> To: John C Klensin <[e-mail]>
> Cc: James Gould <[e-mail]>, Patrik Fältström
> <[e-mail]>, "Gould, James"
> <jgould=[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, "[e-mail]"
> <[e-mail]>, regext <[e-mail]>,
> "[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]> 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,
> <[e-mail]<mailto:[e-mail]>> wrote:
> 
> 
> --On Monday, August 22, 2022 16:01 +0000 "Gould, James"
> <[e-mail]<mailto:[e-mail]>> 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.