Re: [regext] Internationalized Email Addresses and EPP

Patrick Mevzek <pm@dotandco.com> Mon, 23 November 2020 20:17 UTC

Return-Path: <pm@dotandco.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 822AC3A0BB3 for <regext@ietfa.amsl.com>; Mon, 23 Nov 2020 12:17:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.22
X-Spam-Level:
X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=dotandco.com header.b=J4qdzUhQ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eozW77lQ
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 pWeZnMuqUIEg for <regext@ietfa.amsl.com>; Mon, 23 Nov 2020 12:17:26 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81723A0B8E for <regext@ietf.org>; Mon, 23 Nov 2020 12:17:26 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 062355C0174 for <regext@ietf.org>; Mon, 23 Nov 2020 15:17:26 -0500 (EST)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Mon, 23 Nov 2020 15:17:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=cRMBpCxeVCSvdWOXQqzeTNcxeNlUKtd CVtIvKTbwVqw=; b=J4qdzUhQqja5iC/Jb4gcO94PBaif/JG7VVKQKzaINlMecTa ncl072l4151Z1HdJSIM75w7c+DY5MYN2A37b6Hl3eXcD3ympL3jRyN5Vug0QZK8B GdcPpQbA4hMuj38JllI7kqeq+2Xop06UTgw1WJdPJC/wDUwFBP8/allROC7NXN5S kvWcPGJF7wahv2YLtAZqsNZP93hu+Ffe4XpCtGc9m7eYDZENQGedMGgF9b+qUpvF ODPHWo5bR6CWeXkNnx2LnM7CuDh0mdFyolI/pueS4NY9r4HZ1iZOsGSoY8/1Ecsl wL7bChqrgoKwNqm8LXsxMOAsKtKTdhc+SZzHWbw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=cRMBpC xeVCSvdWOXQqzeTNcxeNlUKtdCVtIvKTbwVqw=; b=eozW77lQX0FAxOkJ5OE5w6 vLAw6QFuKggbCW4U0syulRQZOV8xWFYy6hVuofFE5M13/tw6kxMgtQoyWsaQKjrg FVwNTI/J6NDGHRQH7jfeVAuSRa9hWvQon6gTbZzQd6A2z4lKeUCf3TPvh+4uof+B Q/DtlDMyQp0WnkElCIEsxLtlZboFokuqhoQmpSmQd8rHve9dGK0TdrXgUBKOT8bV r8yECAsVS55dE4NLEsbLf1yX1BJn4bFvaZlzRJUtOsxvqVlWFI8Vh9pxhkv5929P 5fMAPO/6zWButz3RhiKvB1eWcnKjMzhlglUTu1Skzrt61KgHbLmr9vT8HMJIh52w ==
X-ME-Sender: <xms:1Ri8X4RVvpSZYATvZrrdr_WYet8Kefy3H1guQAr3SDXJ7QJfsmdCcwsiHHY> <xme:1Ri8X1wdhevOpG_moNLMH6kD76YtisRkCCff6zwQ4W8P71O398AaQ5KOXad3zt8dl OoQp2DttBGZdC5nAA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegjedgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpedugfffieehffejkeduhfdvke evffdufeeuieekheeuffejfeejieetieehudfgkeenucevlhhushhtvghrufhiiigvpedt necurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghordgtohhm
X-ME-Proxy: <xmx:1Ri8X12APrAjsk8m5yQfpJ_hKGh0drO_CJ6b4hoMblnN5-EcqYQC0g> <xmx:1Ri8X8Chj3KY2OErUbYmMsDIx0JFDhKjPeuxsyzwLZ_LZd_It9a4tQ> <xmx:1Ri8Xxgjvqu9DedVIQcFGWeY1SoNuURtENfcEvA6zVSa-TvdRe7y4w> <xmx:1hi8X8tsCkh0u-n2CvcWQlbhj54d-fu2iywapLkaVrYHRJlLn3Mp6w>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A8B646680078; Mon, 23 Nov 2020 15:17:25 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3
Mime-Version: 1.0
Message-Id: <d343c337-3aea-4d5f-ae4e-95afa77c4446@www.fastmail.com>
In-Reply-To: <3d6ce5fd7d1e482fb3df168e0d26c0a0@verisign.com>
References: <C9EBEF19-55C1-4C5E-87BC-894FBF7439FF@verisign.com> <CAHXf=0p5F1LsUYoeX_mRNvuKNpeOvWufY0tNL9zNn+6Zj0cR1A@mail.gmail.com> <3d6ce5fd7d1e482fb3df168e0d26c0a0@verisign.com>
Date: Mon, 23 Nov 2020 15:17:02 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/92SmppQfZlXBq2QjAigBpxRZS34>
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, 23 Nov 2020 20:17:29 -0000

On Mon, Nov 23, 2020, at 08:59, Hollenbeck, Scott wrote:
> This may be the path of least resistance. I'm still trying to think 
> through hat would happen if a registry returns an internationalized 
> email address to a registrar that doesn't expect one. This could happen 
> after a domain transfer, for example. Is this a problem? If not, maybe 
> we could just get by without any other protocol changes or extensions.

It may not be a problem in real life, but probably difficult to completely
exclude it if we want to make sure the protocol is adapted to all registries' cases
out there.

There may be a majority (I can't give numbers of course so treat it as an
assumption) of cases where registrars do the following:
- do the transfer
- upon success, create new contacts
- update domain with new contacts

Whatever case the previous contacts were is then irrelevant for that registrar.

The above case solves multiple problems for registrars (retrieving data out of current contacts can be a problem), and creates a new one
for registry (explosion of unused contacts, as to solve privacy and association
issues registries typically copy contacts upon transfer, so that contacts with
the same data can now be in new registrar's portfolio of objects).

Note that some registries do solve it differently:
the registrar HAS TO provide the new contact IDs at transfer time,
ie a transfer can not start before the registrar created its own contacts and
associate them with the domain at transfer time.

Due to laws like GDPR, maybe this case makes more sense, but part of
this space is also more policy than protocol.
I would have been happy (but I do not hold my breadth) if there would have
been a singular extension or design that would permit any policy such as:
- transfer with copy of contacts
- transfer except if contacts can not be transfered at the same time (if they
are used by multiple domains; it won't be something new, host objects are
automatically transferred already)
- transfer and set new contacts (either full set provided or only the one to change,
I don't know).

-- 
  Patrick Mevzek
  pm@dotandco.com