Re: [regext] Internationalized Email Addresses and EPP

"Gould, James" <jgould@verisign.com> Mon, 19 October 2020 16:21 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF22E3A0BC0; Mon, 19 Oct 2020 09:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xuCEG1PYrvB; Mon, 19 Oct 2020 09:21:07 -0700 (PDT)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0E33A0BD7; Mon, 19 Oct 2020 09:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=6340; q=dns/txt; s=VRSN; t=1603124468; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=HRGGHYYou2LBRUBpqptSZ8WEtswF7CmcnbIf4Y2mkFo=; b=XKh2iGgp/gJFBJH6p7I6MCAJ3mCkjRCQDEHDW/0GjHKpiZTi0vaEa8lZ jxneALncIlb7BwEYo6DV9jgbfxWTh5s8b1Zp94A0Q/n+Z5LEXPM1JJ5T0 4savEMqIKw8jgWa5F+HGQ0cQlNfpUtG1t0phw7p0JY3qmmyINZnSFB417 /G+Kg8k54IdKs/62HEHFnPrlYaBW4fKimI2zthgdsMALqAqSSBCTtq1Tz TcF8zoOVrub6goFuYQP3987W8fjuckTUhOcBW1kjT47ERr6veUhJe8NjM yOkyFHLld4R+OubKjvifnmAFlISut2HItUA3Dm89Bhu/xowUjFWBdqeDs g==;
IronPort-SDR: X+NVreu/Np0JppRmsAu+zDTFNLvrcBPLfJrL5zG2dKHSnnLD4APGQE+MOyrbb+rlU1k0il1mwW 7dDHkTT/ebV1Vi365q+YzMZHeD5RokQMU+JxRQxNPUXQcLbDHFWmbw47c0SA3iZq9MDY0Gt2jj QIFPij3OBSby6lHzMSjDYVCcjFTwf2D9DNWL9EwQH6QWvnLKLO4Rsz0MqqvJd4hBhIEH6OrWmr gRi6exZXWnITZg2qRZDWjM0yJvMLms7vttksK174YAn0ejMHFtEAcjwXr+/sSqUx/cJWexeZ86 LA4=
X-IronPort-AV: E=Sophos;i="5.77,394,1596513600"; d="scan'208";a="3236067"
IronPort-PHdr: 9a23:9CIFFhEvSo6MJbBW5OsHYp1GYnF86YWxBRYc798ds5kLTJ76psq8bnLW6fgltlLVR4KTs6sC17OJ9f+5Ejddqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba5wIRmsrwjdq8YajIViJ60s1hbHv3xEdvhMy2h1P1yThRH85smx/J5n7Stdvu8q+tBDX6vnYak2VKRUAzs6PW874s3rrgTDQhCU5nQASGUWkwFHDBbD4RrnQ5r+qCr6tu562CmHIc37SK0/VDq+46t3ThLjlTwKPCAl/m7JlsNwjbpboBO/qBx5347Ue5yeOP5ncq/AYd8WWW9NU8BMXCJDH4y8dZMCAeofM+hFs4nzqVgArRW8CgaiBePg1jBGiXDt0K0myOshFB3K0BA6Et8MtnnfsdX7NL0VUeCw1KTEwzTNb/RL2Tf59YfEag0qr/WWUrJ1b8XR0kcjHB7Cg1WSpozlOC6V1uAQvGWA8epvS/ivi288qwFwrTivwN0ghZXOhoIQ013J8zhyz4kpK9OiUkF7fcKkH4VKtyGcL4Z7QMwvTnx2tCsmxbMLuJ62cSsOxZoo2hLRZfOKfoiU7h/tSeqfLjh1iW9qdb6hiBu/71atx/D8W8e60FhGsjRJn9/RvX4D0BzT79KISvp7/kq5xzaAyRrT6uBfIUA1mqrbLZ8hwrgsmZYJrUvDGSr2lF3qg6+XbUUr5u+o5/77bbXho5+QL450hR/iMqQggMC/Bv44MgcIUmOG+uq8zKXu8VDlTLlQk/E7kKfUvIrHKckbqKO1GQBY34I75xqiEzuqyskUkHsbIF5fZR6KgIvkN0vTLP37C/q0nk6iny1xx//cO73sGpDNLn/en7j/Zbt98EtcyBYrzdBY+pJUFqkNIPLtVU/1s9zVFgI0PRCszer6CNpzzowQVmOTDqOHKq/Sr0OH5uU1I+mUfoMaoivyJ+I75/70ln85n0URcrWu3ZsScHy4H/JmLFuFYXf0n9sNDX0Gshc8QeHkklGOTD5eanioU68z4jw3EIemAp3CRoCpjryBxiC7HphOa2BEBVCMFmrod4GZVPoXdiKdPNVhkj0fVbigRI8h0wuiuxP9y7piNubU4DEXtYr/1Nhp4O3ejQo9+iZuD8SH02CNS397nmITSDAsx61wvUt9ylKb0ahln/xXC8ZT6+lOUgcgOp7W1/Z6BMzqWgLdYteJT06rTc+8ATEtV94+2cIBY11mFtWjkB/DwySqD6USl7yRC5w+6rjc0GTpJ8Zh13bG07Esj0M4TctAK2KnibJ/+hPSB4HXj0WZmbymdaMG3C7Cpy+/yj/EtkhCSh90XKTPVFgUYU7OsMj0/AXFVbDkQeAtOxFb2MqPK6FDQtbuiE1bWPr5ftPEbDT10y2QAhKMy7WGYYHpPy0m1yLBFAJMxxsT+nKCOA40Cyyii3zTFj11FF3pJUjr9L8thmm8Sxp+4AaXa0Eln5i8/xMOz7TISfwUw7YIkDkssTRvHVm7mdnRDozT9EJaYKxAbIZlsx983mXDulk4Z8T4Ig==
X-IPAS-Result: A2HxAwAMvI1f/zGZrQpdAx4BAQsSDECDRIElgTQKhDORGIN5kH+FRIEsPQsBAQEBAQEBAQEIAR8QBAEBAoRIAheBeCY4EwIDAQELAQEBBQEBAQEBBgMBAQEChkoMgjcpAXM9CT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHTQdHAR8BBSMROgsQAgEIGAICEgEBEgICAjAVEAEBBA4FgyYBsj+BMopXgQ4qhmCCRIQtgUI+gTgcgU9+PoN0FAESAS0LCiYBAgWCSDOCLASTTqQsAweCaokEi1iGGB+DFoEqnRCTKwaBe4cDEoFjlToCBAIEBQIVgWuBC3BwFTsqAYI+CUcXAg2SEIpWdA4nAwIGAQkBAQMJjAQPFYEPgREBAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Mon, 19 Oct 2020 12:21:05 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2106.002; Mon, 19 Oct 2020 12:21:05 -0400
From: "Gould, James" <jgould@verisign.com>
To: "barryleiba@computer.org" <barryleiba@computer.org>, "Hollenbeck, Scott" <shollenbeck@verisign.com>
CC: "art-ads@ietf.org" <art-ads@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
Thread-Index: AdaiHfrcb7oe0mfaSgq6+fYkWR5jogEAIIeAAAVWlgA=
Date: Mon, 19 Oct 2020 16:21:05 +0000
Message-ID: <954514C4-E1ED-4B6D-A97D-49680F50A7C4@verisign.com>
References: <a1d3bd0c2dce4b1c9c7a0355be22e9b5@verisign.com> <CALaySJJ3FUC61q8zuOMs2JRya5OwfihDNpizOScFn2fHUyAmdw@mail.gmail.com>
In-Reply-To: <CALaySJJ3FUC61q8zuOMs2JRya5OwfihDNpizOScFn2fHUyAmdw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D9EA970CEE570349B6507A1C141A1BD8@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/f00fIfFnye9oMd8KXY-dNqvvxH0>
Subject: Re: [regext] Internationalized Email Addresses and EPP
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2020 16:21:10 -0000

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