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

["Gould, James" <[e-mail]>]

John,

Again, thank you for your detailed layout of the issue.  The current state of the draft-ietf-regext-epp-eai is to allow for either an ASCII or a SMTPUTF8 address for a set of EPP extensions that currently support a single required or optional ASCII e-mail address.  Supporting an all-ASCII fallback address, means that the single e-mail address would need to shift from a one to two or even a one-to-many relationship across the EPP extensions along with the appropriate implicit or explicit signaling of the e-mail type, which is why it comes down to a protocol cardinality issue.  This is a material change that needs further discussion in the REGEXT WG.  I hope that you can participate in the discussion.

Thanks,

-- 
 
JG



James Gould
Fellow Engineer
[e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 9/13/22, 3:04 PM, "John C Klensin" <[e-mail]> wrote:

    James,

    My apologies for not having responded to your note sooner.
    I've been preoccupied with several unrelated things.

    I greatly appreciate the changes to use an existing EPP
    extension framework and to correct the terminology error of EAI
    -> SMTPUTF8.   I agree that the more substantive SMTPUTF8
    technical issues should go back to the WG.

    However, in order that the discussion you suggest for IETF 115
    be useful and not just lead to another round of heated Last Call
    discussions, I think that, for the benefit of those who have
    been following the discussion closely and those who should have
    been, it is important to be clear about what the disagreement is
    about.  When you characterize the issue as "e-mail cardinality",
    it makes it sound, at least to me (maybe everyone in the WG has
    a better understanding) like this is some subtle technical
    matter.

    It really isn't.  The EAI WG was very clear during the
    development of the SMTPUTF8 standards that the biggest problems
    with non-ASCII email addresses were going to be with user agents
    (MUAs) (and, to some degree, with IMAP and POP servers that are
    often modeled as part of MUAs) and not with SMTP transport over
    the Internet.  Making an MUA tailored to one particular language
    and script (in addition to ASCII), or even a handful of them, is
    fairly easy.  Making one that can deal well with all possible
    SMTPUTF8 addresses is very difficult (some would claim
    impossible, at least without per-language, or
    per-language-group, plugins or equivalent).  

    The implication of that problem is that, except with rather
    specific constraints, fallback all-ASCII addresses are
    important.  I'd be delighted to have a discussion about the
    types of constraints the would be needed, but every possibility
    involves a policy decision about DNS registration management and
    is hence out of IETF scope.  I claim didn't take the EAI WG to
    figure the need for fallback addresses out: it gets fairly easy
    as soon as someone thinks about, e.g., how their favorite MUA
    would manage addresses, and potentially error messages, that use
    a relatively complex writing system that has not been in active,
    non-scholarly, use for millennia. 

    This is why, unless non-ASCII email addresses are used strictly
    within a particular writing system environment (and restricted
    to those writing systems), it is strongly recommended that an
    all-ASCII email address be available as a fallback.  

    As we have discussed, I am not suggesting such an address be
    required in any particular transaction any more than you are
    suggesting that registries be required to accept non-ASCII email
    addresses at all.  Subject to whatever regulatory, contractual,
    or other constraints might apply, decisions about whether to
    allow (or encourage) such addresses, what constraints to impose
    on the scripts or domains that might be used in the addresses if
    any, and whether a all-ASCII address (or an all-ASCII local
    part) should be allowed or required in a particular transaction,
    is not a matter for the IETF.  

    However, providing for the optional transmission of a non-ASCII
    address without providing for the optional transmission of an
    all-ASCII alternative is as much of a policy decision as trying
    to build rules about when non-ASCII addresses should be
    permitted would be.  If the IETF (or at least REGEXT) believe
    that it is a good idea to provide for non-ASCII addresses, let's
    do that right.  And "right" requires either provision for a an
    all-ASCII alternative or a globally agreed profile of what sorts
    of non-ASCII addresses are valid.  It is not the sort of thing
    that can reasonably be ignored or postponed for future work, at
    least without creating back-door policy decisions and/or
    interoperability problems, or the IETF is willing to standardize
    a protocol with known serious deficiencies on the assumption
    that those "details" can be worked out later.

    thanks,
       john


    --On Wednesday, August 31, 2022 17:26 +0000 "Gould, James"
    <jgould=[e-mail]> wrote:

    > John, 
    > 
    > draft-ietf-regext-epp-eai-16 was posted that addresses two of
    > the issues that you raised, by changing to use a
    > command-response extension, and to replace the EAI references
    > with SMTPUTF8.  I believe the remaining issue of the e-mail
    > cardinality needs to be brought back to the REGEXT working
    > group for discussion.  I've requested an agenda item at
    > IETF-115 for it and I encourage you to participate in the
    > meeting to discuss it first-hand if the agenda item is
    > accepted.
    > 
    > Thank you for all your detailed feedback and discussion!