Re: [regext] Internationalized Email Addresses and EPP

Let me disagree...

Login Security Extension does much more than just increasing the password
length.
Going(2) means that EAI addresses are not first-class citizens, that seems
wrong for now.
Also, the current schema definition formally allows EAI addresses.

On Mon, Oct 19, 2020 at 7:23 PM Gould, James <jgould=
40verisign.com@dmarc.ietf.org> wrote:

> I believe option 2 is the better route to go.  We went with option 2 to
> extend the password length in RFC 5730 with the Login Security Extension
> (RFC 8807).  The use of email addresses in EPP is not isolated to RFC
> 5733.  The Organization Mapping (RFC 8543) and some additional EPP mappings
> registered in the EPP Extension Registry (Email Forwarding Mapping and
> NameWatch Mapping) use email addresses.  A new EPP extension could be
> applied to more than one EPP mapping.  The other question is whether the
> Internationalized Email Address should be a replacement for or additive to
> the ASCII Email Address defined in the mappings, based on the email address
> usage and the support for Internationalized Email Addresses in the
> underlying protocols and implementations.  An extension could support both
> replacement and additive options.
>
> --
>
> JG
>
>
>
> James Gould
> Fellow Engineer
> jgould@Verisign.com
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 10/19/20, 5:48 AM, "regext on behalf of Barry Leiba" <
> regext-bounces@ietf.org on behalf of barryleiba@computer.org> wrote:
>
>     Hi, Scott,
>
>     An interesting question...
>
>     I think it depends upon how you want this to appear from an EPP point
> of view:
>
>     1. Do you want the EPP standard to support non-ASCII email addresses?
>
>     2. Do you want to *extend* EPP to support non-ASCII email addresses,
>     as an option for those who implement the extension?
>
>     For (2), then the EPP extension would be the easiest option, where the
>     extension would "update" 5733 and say that the extension changes the
>     definition to allow non-ASCII email addresses.  The extension would be
>     at Proposed Standard, and 5733 would be at Internet Standard as it is
>     now.
>
>     For (1), the best way would be to revise 5733 and change the
>     definition of email address syntax, republishing it at Proposed
>     Standard and "obsolete" 5733.  The protocol (the new RFC) would then
>     be back at Proposed Standard.  You could then do a status change later
>     to move the new RFC to Internet Standard (without publishing yet
>     another revision).
>
>     So... does the working group want it to appear that support for
>     non-ASCII email addresses is an optional extension, or part of the
>     base EPP?
>
>     Barry
>
>     On Wed, Oct 14, 2020 at 7:54 AM Hollenbeck, Scott
>     <shollenbeck@verisign.com> wrote:
>     >
>     > Barry, Murray:
>     >
>     > We have a question about IETF process as it related to updating an
> Internet Standard document. RFC 5733 ("Extensible Provisioning Protocol
> (EPP) Contact Mapping", part of Standard 69) was published in August 2009.
> It includes a normative reference to RFC 5322 for the definition of email
> address syntax. RFC 6530 ("Overview and Framework for Internationalized
> Email") was published in 2012. The regext working group is discussing how
> we can best update the email address syntax specification in RFC 5733 to
> add support for the local part of internationalized email addresses to EPP.
> The EPP XML Schema already "works" as it should, so that doesn't need to
> change. It's just that pesky normative reference to RFC 5322 that isn't
> updated by RFC 6530. We think we have a couple of options:
>     >
>     > Create an EPP extension by writing an Internet-Draft that would
> explicitly add support for internationalized email address without touching
> anything associated with 5733.
>     >
>     > Write another document that updates 5733 to include the reference to
> 6530, if it's possible to update an Internet Standard that way.
>     >
>     > Submit an errata report to note the additional normative reference
> to 6530, though this isn't a technical or editorial error.
>     >
>     > There may be other possibilities. What are your thoughts on the best
> way to proceed? I personally think that the first option is the easiest and
> cleanest, and it's the way we've added additional functionality in the
> past. I'm wondering if there's an easier way, though.
>     >
>     > Scott
>     >
>
>     _______________________________________________
>     regext mailing list
>     regext@ietf.org
>
> https://secure-web.cisco.com/1OMe-gZOMpSdaE_x-eNaMmuku-HiFkDXVCFGDWXBsOnAOQxOjGtERHNpHzKsnKz9ejchOyDdiIlaqfLOg9aQI39btY7z4bJi6U3a8dJUGHQsF3BaGH-zhHPMWB5udn9vylMEQUEcTMCaKu3cxLc6dqGVMeK9VtHspmbya4NZVkqGlGNbK57io7D4HMA6iGFWzfLehh2gyF31-9tcpP59WQRgeWumuRMWqa4wFIqnhKFrCE4R55DBiJjW2iKechIkbUV8fDC-ZkRuiCpXUKMpJgXKnxkmnm_GdnDtwSb4YIME/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>

-- 
SY, Dmitry Belyavsky