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....@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 > 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/> > > On 10/19/20, 5:48 AM, "regext on behalf of Barry Leiba" < > regext-boun...@ietf.org on behalf of barryle...@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 > <shollenb...@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
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
