IETF Logo Mail Archive

[I18ndir] EAI: RFC 6531 Updates 5321?

"Hollenbeck, Scott" <shollenbeck@verisign.com> Wed, 28 October 2020 14:17 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: i18ndir@ietfa.amsl.com
Delivered-To: i18ndir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8846A3A099F for <i18ndir@ietfa.amsl.com>; Wed, 28 Oct 2020 07:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5CMTzDTP8TmV for <i18ndir@ietfa.amsl.com>; Wed, 28 Oct 2020 07:17:05 -0700 (PDT)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (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 251EF3A09BE for <i18ndir@ietf.org>; Wed, 28 Oct 2020 07:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1086; q=dns/txt; s=VRSN; t=1603894624; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=+0EVka5VnP8/tBJGqPk9SgepS/VUnG88bZvjKuVHet0=; b=GGkpwh0OTy9t5fyD+AQelLcRfESbNLJfujFXKOfcDb+dIkWPkdy/fgHC CaFAjBiSqog5+4bSmeHet7eMNLC5fRoNojaHlA7s9rt0BFLClK7BDvsWC X3CVlQoohuN2yJxOqmqLazLYh7jOhlm3TxnXr9AmEF93G377Lj+tDtDo3 wmiL1lDI4LHrOgP8BNk+e1hHmO8GpibhdgudHj+jh+x24QC0Zi+Hkfmaw bEkvUvQXXIcPMd4+oOKclv8xmDb2auvLz+qhzJy2qsnxLAklWVNE9UL0s bpNeywlM7V3KYGhHapozrpjZAkZ9C9IANrRNcUrfMeFy+Xjam4mW+vKUG w==;
IronPort-SDR: /VryaiR+lq8Y8eGzzAIjFZwGjhiZ5THSvKbeBilx3XdERbDTFJzG7CBF4JtSqogm+7LdP2G5te j2yblfZHxxrAouMtXPjjs2gdUw8qvWyvkkyliifrLNQO/tRJGK2JWRBoP34qnQGeV4lCLGLcYy WMSrHkLQR9JrderOsGSkSKgUsVn98S1Nwv3vGN6sf9Qs1XsjIVfUbxKKmcSKnP9woJCpNZoxTU eTkwemZFOUIr4oEBdKECeLiLlOEsseAKGpX1TC6NXahDBeRO27t0nqI8DqYQ6QVSkGPsBsG4jb XsU=
X-IronPort-AV: E=Sophos;i="5.77,426,1596513600"; d="scan'208";a="3406037"
IronPort-PHdr: 9a23:j0FXiBDOH56AZKkLbDSrUyQJP3N1i/DPJgcQr6AfoPdwSPX7pMbcNUDSrc9gkEXOFd2Cra4d1KyH6uu6CCQp2tWoiDg6aptCVhsI2409vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6nK94iQPFRrhKAF7Ovr6GpLIj8Swyuu+54Dfbx9HiTagY75+NhG7oRjeusUIhYZpN7o8xAbOrnZUYepd2HlmJUiUnxby58ew+IBs/iFNsP8/9MBOTLv3cb0gQbNXEDopPWY15Nb2tRbYVguA+mEcUmQNnRVWBQXO8Qz3UY3wsiv+sep9xTWaMMjrRr06RTiu86FmQwLuhSwaNTA27XvXh9RwgqxFvRyhuxJxzY3VYI6JO/RxcbjQfc8DRWpDQspdSzBNDp26YoASD+QBJ+FYr4zlqlcArxW+Ag2sBOfxxT9OnXD5w7E10+c5HQrbwQIvA9UOsGjIrNn7KawfVvu1zKnPzTXHa/NZxzH955PWfR89ovGBRqxwftTLyUkuDAPFj1qQqYr/MzyJ0eQNtnGW4ux9Xu2gl2ApsRt+oiSzxsgykInJgJoYx0zZ+Sh6zog7K9K1RVJlbdO6EpZdsy6UOo9qT84+QWxlpik0xLMIt5OnYCQHyJAqyh3BZvKJcYWE/w7vWeiRLzp+mXlre6q/ig6v/US80OHwS8u53VhQoiZYktTBuGoB2hPX58SfV/dx4l2t1SuN2gzP8O1IPE85mKnBJ5I8wbM9kIcYv17ZES/sgkr2ibebdkAj+ue19evqeq7mppqAN49sjQH+L7gultS/AesmNggOWHCW9Pmg2rP74EH2QK1EgPI3naXFrpzWP9obqbK+Aw9PyoYv8QywACq83NQGh3kHN1RFdAibgIjuPlHCOPH4DfGhjFSwiDpn2uzKMqf8DpjPIHXPiqrtcLZz5kJGxwc+ychT55dOBbEAJPLzVFXxtNvdDhIhKAy0w+HnCNF51owAX2KAGbGWP7/RsVKT+OIgPfOMZI4OuDb8JPgl4eTigmM+mV8YZaWpx4cYaGikHvR6JEWUeXvsjsoCHGcMowU+TfbqhUaDUTFNe3ayUbgw5jYhCIKpXs//QdXngeXR2iu6BLVXa3xITFeWHj2gI4TdC/EAaTi6I8J9nHoDT7f3GKE70hT7/i/9z75qKODZ8S5c/ano08RpraWHjhE18Th5Cc6Q2GKlUWxun3gJSDlw16d69x8ugmyf2LR11qQLXedY4OlEB183
X-IPAS-Result: A2EFBQDOfJlf/zGZrQo3BQEBIoEJhiiwAYFpCwEBAQEBAQEBAQgBExwEAQGGUyY4EwIDAQELAQEBBQEBAQEBBgMBAQEChksLgjcihDc4GQE+QiYBBBuzRIE0hVeFBIE4jVSBQj6EX4EEgwQBEAIBhhcEtwGBDAMHgmuadyuDF55IAZNBgX6ePQIEAgQFAhWBa4ELcHBQgmpPFwINjjeOMYEsAgYKAQEDCYwTgSSBEQEB
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) 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; Wed, 28 Oct 2020 10:17:02 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.2106.002; Wed, 28 Oct 2020 10:17:02 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "i18ndir@ietf.org" <i18ndir@ietf.org>
Thread-Topic: EAI: RFC 6531 Updates 5321?
Thread-Index: AdatNF2TJhwtvLnsQ3W//izlTdLEAQ==
Date: Wed, 28 Oct 2020 14:17:02 +0000
Message-ID: <6353e26525fa4249960a1bc1468c796d@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/i18ndir/ZhqCtvlxyjb20SvFwg0CZDa87fE>
Subject: [I18ndir] EAI: RFC 6531 Updates 5321?
X-BeenThere: i18ndir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Internationalization Directorate <i18ndir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i18ndir/>
List-Post: <mailto:i18ndir@ietf.org>
List-Help: <mailto:i18ndir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i18ndir>, <mailto:i18ndir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Oct 2020 14:17:07 -0000

Folks, I have a question about i18n-related RFC updates that I hope you can shed some light on.

We recently had a suggestion from an IETF participant to add support for internationalized email addresses to EPP, which has a normative reference to RFC 5322 for email address syntax. It predates EAI, so there's nothing there to support internationalized local-parts. We're thinking about defining an EPP extension to add support, but the discussion on the regext WG list got me looking at the EAI RFCs and it made me wonder why they don't formally (in the Datatracker sense) update their predecessors. For example, Section 3.3 of RFC 6531 says that "RFC 5321, Section 4.1.2, defines the syntax of a <Mailbox> entirely in terms of ASCII characters.  This document extends <Mailbox> to add support of non-ASCII characters", but there's nothing I can find in the Datatracker to note that 6531 updates 5321. 6531 *is* described as obsoleting 5336. Am I missing something? Shouldn't the Datatracker note the update relationships explicitly?

Scott

v2.23.0 | Report a Bug | By Email