Re: [regext] Internationalized Email Addresses and EPP

Barry Leiba <barryleiba@computer.org> Mon, 19 October 2020 09:48 UTC

Return-Path: <barryleiba@gmail.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 D45BA3A098E; Mon, 19 Oct 2020 02:48:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.502
X-Spam-Level:
X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 4bw-KiPJfYfc; Mon, 19 Oct 2020 02:48:27 -0700 (PDT)
Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 246673A0990; Mon, 19 Oct 2020 02:48:26 -0700 (PDT)
Received: by mail-vk1-f176.google.com with SMTP id p5so2254107vkm.4; Mon, 19 Oct 2020 02:48:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=5aLLoHt1i4R3DG5pzXzE+E5julI1sqOty+xSe6NBv6M=; b=TK/y8Q0kbQDWLS3yplIFPQ2TspbhUoyHllvsKUvFUcN1f0iRxAL5lsyJG2fJu7rqzk oNDkmbOEfO0iUp+UyEHDbcTL2Z/XJhmjy0sqA5gXP4lOElWhfLFCivau9z10zGeWLlB/ JDJCFIUtUNSIlBe6HZT8jthTEzOBGJWYUEnTFdQFLRVAHuBAzxEBZ/rh72+Tc6KWbUIb 0w4IleyfTQK31Lu1ZGnNLEtgk9esrZVj+NIc3Sc7+yq9ctLP3fOa9B0L0Nzw1kSaI/AC bznAb/PoTKaz6hQR1BAwgADrAn3ENsK8s/uiFF8ifYmtFgIgPgyXFYvjdesAWeJWFTkv 73Tg==
X-Gm-Message-State: AOAM533ENRUgP5wT9TO65ywwpKPKHae//41sUJIFR4jmrEKkK7CFzR+Y fo5qyWbbCjGIT8bnGo4Fo+27SsXG32StFMGQXqaOkQn9Vdw=
X-Google-Smtp-Source: ABdhPJwUCVBP8FXtFDUNjoJQZWhNU+AN4+ykIYxXUboPcIyz0s3Wcqkz3hU4XJWgQFy9lNTX5YEp7iFOtbfyeYAdpC4=
X-Received: by 2002:a05:6122:78e:: with SMTP id k14mr7573812vkr.23.1603100905018; Mon, 19 Oct 2020 02:48:25 -0700 (PDT)
MIME-Version: 1.0
References: <a1d3bd0c2dce4b1c9c7a0355be22e9b5@verisign.com>
In-Reply-To: <a1d3bd0c2dce4b1c9c7a0355be22e9b5@verisign.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Mon, 19 Oct 2020 05:48:13 -0400
Message-ID: <CALaySJJ3FUC61q8zuOMs2JRya5OwfihDNpizOScFn2fHUyAmdw@mail.gmail.com>
To: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Cc: "art-ads@ietf.org" <art-ads@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/IKm_q97OdOKRrh0lIiMEcQmChaU>
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 09:48:29 -0000

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
>