[regext] Re: I-D Action: draft-ietf-regext-epp-eai-21.txt

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: Wednesday, August 21, 2024 3:00 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: [EXTERNAL] I-D Action: draft-ietf-regext-epp-eai-21.txt
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe.
> 
> Internet-Draft draft-ietf-regext-epp-eai-21.txt is now available. It is a work
> item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
> 
>    Title:   Use of Internationalized Email Addresses in the Extensible Provisioning
> Protocol (EPP)
>    Authors: Dmitry Belyavskiy
>             James Gould
>             Scott Hollenbeck
>    Name:    draft-ietf-regext-epp-eai-21.txt
>    Pages:   24
>    Dates:   2024-08-21
> 
> Abstract:
> 
>    The Extensible Provisioning Protocol (EPP) does not natively support
>    internationalized email addresses because the specifications for
>    these addresses did not exist when EPP was developed.  This document
>    describes a command-response extension that adds support for
>    associating either an internationalized email address or a second
>    all-ASCII address with an EPP contact object and specifies how these
>    addresses can be used by EPP clients and servers.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-epp-eai/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-regext-epp-eai-21.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-eai-21

[SAH] I've cc'd John, Pete, and Arnt, all of whom shared significant feedback regarding recent versions of this draft. It's been extensively rewritten in an attempt to address their feedback.

Note that the draft no longer attempts to implicitly update RFC 5733 by allowing SMTPUTF8 addresses in the contact object. If an SMTPUTF8 address is wanted, it can be provisioned as part of an extension element. If an SMTPUTF8 address is provisioned, there MUST be an all-ASCII address available in the same contact object. It's also possible to provision an additional all-ASCII address, and the extension includes an attribute to identify which address has higher priority.

Please review the draft again. The extension is now much simpler, and hopefully we're close to being able to finish this work.

Scott