I’ve discussed the path forward for draft-ietf-regext-epp-eai with some working
group participates and I have concern of the current path that the draft is
taking with the support for an alternate e-mail address, whether it be either
ASCII, SMTPUTF8, or either. There are system and policy impacts associated
with the requirement to collect and transmit an additional e-mail address
across EPP RFCs (e.g., RFC 5733, RFC 7848, RFC 8543), where the end goal of
draft-ietf-regext-epp-eai was to support the use of SMTPUTF8 e-mail values with
the appropriate signaling by the server and client. I realize that the term
“cardinality” was not popular with some, but the inclusion of an alternative
e-mail across all EPP extensions that include an e-mail address does make a
crosscutting cardinality change from one to two. The registry needs to support
either ASCII or SMTPUTF8 addresses to enable the registrars, which have the
relationship with the registrant, to make the decision what form of e-mail to
accept. In hindsight, I believe the “Change of Cardinality to One or Two
(ASCII or SMTPUTF8)” recommendation from the IETF-115 REGEXT meeting that was
incorporated into draft-ietf-regext-epp-eai-17 is the wrong option. We should
keep the cardinality of one to provide the needed support for SMTPUTF8 in the
registry for the registrars to make the decision what to collect and pass to
the registry. I provide the options below for consideration by the working
group:
1. Cardinality of One – The approach taken in draft-ietf-regext-epp-eai-16,
where the server (registry) supports either SMTPUTF8 or ASCII addresses for a
decision by the client (registrar).
2. Cardinality of Two – The approach taken in draft-ietf-regext-epp-eai-17,
where the server (registry) supports an alternative email element during a
transition period that requires one email element to be ASCII. There are two
sub-options based on the recent discussion:
* Alternative Email can be ASCII or SMTPUTF8
* Alternative Email is only ASCII
My preference is Cardinality of One that would roll back to
draft-ietf-regext-epp-eai-16. Please respond to the mailing list with your
preference or any other options that should be considered.
Thanks,
--
JG
[cid:image001.png@01D94CDB.A5428850]
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/>
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
