Re: [regext] Internationalized Email Addresses and EPP

Patrick Mevzek <pm@dotandco.com> Mon, 23 November 2020 21:40 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 9EAF23A1368 for <regext@ietfa.amsl.com>; Mon, 23 Nov 2020 13:40:03 -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=aXrFjhO2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SWjkehx4
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 6ONb-jdmHNfv for <regext@ietfa.amsl.com>; Mon, 23 Nov 2020 13:40:02 -0800 (PST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9713A135A for <regext@ietf.org>; Mon, 23 Nov 2020 13:40:01 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9BB005C018D for <regext@ietf.org>; Mon, 23 Nov 2020 16:40:00 -0500 (EST)
Received: from imap22 ([10.202.2.72]) by compute3.internal (MEProxy); Mon, 23 Nov 2020 16:40:00 -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:content-transfer-encoding; s=fm1; bh=qK1b5 skBgInnWiD3HivKWFQLpC4V//oqpVcKVZQCWF8=; b=aXrFjhO2ayGzILGhYIoZD XrHlM/R261mQwZ9/jPOU5+ucr3vle0aHl74yQjbqL9cBNq7x3DR6pmcat5RylgeZ 2ELyl28e3stKVYauRAr+Z1aMyPInlhJX99o/jroC9DCogOcVH1U2fSETCkSgzIiL mGEGhpVIUUPiSkXXaD6FSxPrrxC8IafLsn4jTv38nF28IdHVmFj7uq7ItClllu3/ 57veOPE3Vuv7KFD2kgNpqxYOHNkd7cZkxG2VHOhR/F8MpJuDBInJa+gnNE3kaqsF 03z4Id82oe2psaFV7rami3dlgSeUBs+b1aHcZLttW6ztyI9YKCMxmV/Y1flvT7E2 w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding: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=qK1b5skBgInnWiD3HivKWFQLpC4V//oqpVcKVZQCW F8=; b=SWjkehx4oK1lCE1i/ccyR27Emq4cNhubN/xWmqaM9jFGP46WRONmgzJ0E QNlEANe1PPEd0c3ct9lpLp9MiXJhD5mJgSoxXKNJxMmYeb8JT5vPL7QR5OUTAf6e wbVkPIWjE7+erhU4z2ghXgPyzYXKT3hpCuxr6/cPnxyK4fY7sz7wJsm6XGeMIWdR KoTPIDKOjnPVc9UFGhVbP8oeulDEMRcbqz5fTYcELHdtE7BzSGRUjOAZqGDM/rNv gHg4QElC9n/esD/XTyVJVgrdm9rvxGsrluiR3UTaVhWuVdrNueMTSctxhmde5p2C pP0GHxMPn3lsIjKXNiz/oUUayLpSA==
X-ME-Sender: <xms:MCy8XxZK9JYWeD-EHFF4dGeWEA3KxyfPHiNfK4ieZpSF-Y052OYyHEN-2us> <xme:MCy8X4Zr0WjJa_gMu63iEhCMhviRT6xaIGmpNGSS_gKgl_dwRcpoJLf7bq460Tclm JwTDseO85oo_TKR_g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegjedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmsegu ohhtrghnuggtohdrtghomheqnecuggftrfgrthhtvghrnhepffegleevhfelkedugfeiie ejffduudfhgefhleejvdetfedugedufefhffdtfeevnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrghnuggtohdrtghomh
X-ME-Proxy: <xmx:MCy8Xz-ErRIKzEmOOAHP4Sv7IgCkqqhioya46El3SToUyMZTzWBsqA> <xmx:MCy8X_pUqamuU1S7-wjV8dt1pz1lyhAHWW2QYXFyGzBNXVli9VOrJw> <xmx:MCy8X8qOLb7InUpmG8R-X-7srlWO53WGblL2uT954r44KdOsMKpNhw> <xmx:MCy8X52h_xopcl2nRXySMCD-SBPcrYK0qKc5-Jj4GC5C-4xiOr39MA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 440406680078; Mon, 23 Nov 2020 16:40:00 -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: <a23d4ff1-9fd9-4a28-90fd-5a91585d846b@www.fastmail.com>
In-Reply-To: <20201123205504.4A58627C7661@ary.qy>
References: <20201123205504.4A58627C7661@ary.qy>
Date: Mon, 23 Nov 2020 16:39:38 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/bLedh7wYYPzZkxfqt1sfFMjJRU0>
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 21:40:10 -0000


On Mon, Nov 23, 2020, at 15:55, John Levine wrote:
> In article <f57ec7e59aed47ce96f747f10c7468f1@verisign.com> you write:
> >   [SAH] I’m not talking about rejecting a transfer. I’m talking about what a registrar that does not support EAI would/should do if
> >it is the receiving registrar of a domain that includes contacts using internationalized email addresses and those addresses aren’t
> >supported by the registrar. How should this work?
> 
> Reject the transfer -- you get what you pay for.
> 
> Transfers only happen when a registrant asks for them. If registrars
> find that they're losing customers due to inability to handle EAI
> addresses, they can decide that it's an acceptable cost or they can
> upgrade their software, either to handle EAI, or to ask the registrant
> to change her e-mail address to an ASCII one and try again.

A bit harsh/unrealistic: the new registrar may have 0 way to know, before
the transfer succeeds that it has this problem to handle.

Because:
- contact:info commands can be refused by registry on contacts not owned
(so new registrar can not see email addresses of current contacts owned by current
registrar), or the result be filtered
- data may not show at all in whois/RDAP

Hence what will happen:
- the registrar starts the transfer
- it succeeds after some time
- NOW and only NOW can he by surprise discover he has a problem if
he tries to synchronize the contact data from registry to its own systems.
(he won't have problems if he just creates new contacts and update the domain,
as many/some/the majority of registrar do).

That defeats the "do not surprise" law and creates harm for no reason.

Either the registry has to mandate outside of protocol (ex: technical accreditation
test) that every registrar knows how to handle any possible email address, including
EAI case, OR there should be a way for a registrar to dynamically signal the registry
it wants/do not want to handle this case, OR the registry has to provide something
that is forward compatible (hence: 1) not breaking current software but 2) allows
updated software to enjoy more features)

-- 
  Patrick Mevzek
  pm@dotandco.com