From: Gould, James <jgo...@verisign.com> Sent: Wednesday, June 12, 2024 8:41 AM To: orie@transmute.industries; Hollenbeck, Scott <shollenb...@verisign.com> Cc: regext@ietf.org; regext-cha...@ietf.org Subject: Re: [EXTERNAL] [regext] Re: draft-ietf-regext-epp-eai update
Orie, The draft has implemented multiple approaches to address the feedback from John Klensin, related to the desire to have an all-ASCII email address. I include the approaches below for summary. I believe the protocol should support either an ASCII email address or an SMTPUTF9 email address, which was the original purpose of creating draft-ietf-regext-epp-eai. RFC 5733 and RFC 8543 supports SMTPUTF8 email addresses on the wire, but not based on the reference to RFC 5322 in the specification. What is supported can be left to server policy and not restricted by the protocol itself. The latest version -20 provides the base set of features that a server can use to implement their policy (one ASCII, two ASCII, one ASCII or SMTPUTF8, one or two ASCII or SMTPUTF8). 1. -10 (IETF LC) a. Supported one ASCII or SMTPUTF8 email address 2. -17 a. Supported one or two ASCII or SMTPUTF8 email addresses with a transition period 3. -19 a. Supported one or two ASCII or SMTPUTF8 email addresses without a transition period Scott has proposed another approach with one ASCII email address with an optional ASCII or SMPTUTF8 alternate email address, and a primary email address marker. I still prefer the simplicity of the -10 approach, but if there is the need for an alternative email address to address the feedback, then my recommendation is -19 (-20 is the same approach). [SAH] Jim, here’s my thought process with respect to my email from yesterday. It starts with what I perceive to be given information: The XML schemas for EPP and its object mappings support UTF8. The EPP contact object mapping (RFC 5733) supports a single all-ASCII email address per contact object. Mail system support for SMTPUTF8 addresses isn't ubiquitous. WHOIS is an ASCII-only registration data directory service (RDDS) protocol. RDAP is a UTF8-capable RDDS protocol. Now let’s describe our use cases: Use case 1: The EPP server operator needs email addresses for the purpose of contacting people directly. Given that mail system support for SMTPUTF8 addresses isn't ubiquitous, this use case suggests that at least one all-ASCII address is required for every contact. We have that covered with RFC 5733. An extension can be used to add support for an additional, optional address that is either an SMTPUTF8 address or an additional all-ASCII address. Use case 2: The EPP server operator needs email addresses for registration data directory service publication using protocols like WHOIS and RDAP. WHOIS doesn't support UTF8. Again, that suggests a requirement for at least one all-ASCII address, and again, we have that covered with 5733. An extension can be used to add support for an additional, optional address that is either an SMTPUTF8 address or an additional all-ASCII address. If an SMTPUTF8 address is provisioned with EPP, text needs to be written somewhere to explain the implications for WHOIS. RDAP supports UTF8. Since this is a "display only" situation, the RDAP use case does not explicitly require at least one all-ASCII address. The purpose of displaying email addresses in RDAP is to facilitate contact, though, so there's an implicit need for an all-ASCII address and an EPP extension for SMTPUTF8 support as described in use case 1. If "mail system support for SMTPUTF8 addresses isn't ubiquitous" isn't a given, then both use cases can be approached differently. If it is a given, we have a requirement to continue to support exchange of all-ASCII email addresses. An extension can be defined to add support for the exchange of an optional SMTPUTF8 address, but we can’t eliminate the need for an all-ASCII address. Scott
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
