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

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

Scott,

Thanks.  I will look at it as soon as I can but am, unfortunately,
reading very slowly these days.  Watch for a note, I hope fairly
soon, that tries to summarize my thinking about i18n issues in the
IETF and the risk that having too many standards to choose from might
have almost the same effect as no standard at all.  

Two quick thoughts, with the understanding that I have not looked at
this draft yet:

(1) As you know, I personally favor the idea that, if non-ASCII email
addresses are to be used in a global context, all-ASCII alternatives
should be available.  Consequently, I'm happy to hear that the I-D is
headed in that direction.  I was, however, told quite emphatically a
year or more ago that the WG would never stand for such a requirement
and that it would need to be a matter of choice worked out between
registry and registrar.   Also, while I would advise them against it
if asked, I can easily imagine some ccTLD registries in countries
with one official language (and writing system) deciding that the
only non-ASCII addresses to be allowed reflect that writing system
and that an ASCII alternative is unnecessary clutter.  So I hope the
ducks are lined up. 

(2) You may have already dealt with this but, if not... While I don't
think there is a direct interaction, some potential non-ASCII local
parts are much more likely to interoperate smoothly and work well
than others and registries and/or registrars might want to establish
rules about what they will accept that are narrower than what the
SMTPUTF8 specs allow.  The first category is, I think, more or less
what Arnt has been trying to capture as "nice" addresses.  Some
lightweight crossreferences, even, if necessary, an indication that
work is in progress without specific document references, might be
helpful to your readers and implementers.

best,
   john


--On Wednesday, August 21, 2024 19:19 +0000 "Hollenbeck, Scott"
<[e-mail]> wrote:

>> -----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-ea
>> i-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
> 
> 



--On Wednesday, August 21, 2024 19:19 +0000 "Hollenbeck, Scott"
<[e-mail]> wrote:

>> -----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-ea
>> i-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
> 
>