Re: [regext] Internationalized Email Addresses and EPP

Matthias Pfeifer <info@freshmail.de> Mon, 23 November 2020 14:33 UTC

Return-Path: <info@freshmail.de>
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 F0D463A0CC0; Mon, 23 Nov 2020 06:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 E7JEP_8k3Mm4; Mon, 23 Nov 2020 06:33:13 -0800 (PST)
Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.135]) (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 DFFB13A0CB8; Mon, 23 Nov 2020 06:33:12 -0800 (PST)
Received: from MatthiasPC ([87.170.153.219]) by mrelayeu.kundenserver.de (mreue012 [212.227.15.167]) with ESMTPSA (Nemesis) id 1N01hu-1kLZoq28aE-00x1i9; Mon, 23 Nov 2020 15:33:06 +0100
From: "Matthias Pfeifer" <info@freshmail.de>
To: "'Hollenbeck, Scott'" <shollenbeck=40verisign.com@dmarc.ietf.org>, <alex.mayrhofer.ietf@gmail.com>, "'Gould, James'" <jgould@verisign.com>
Cc: <regext@ietf.org>, <Klaus.Malorny@knipp.de>
References: <C9EBEF19-55C1-4C5E-87BC-894FBF7439FF@verisign.com> <CAHXf=0p5F1LsUYoeX_mRNvuKNpeOvWufY0tNL9zNn+6Zj0cR1A@mail.gmail.com> <3d6ce5fd7d1e482fb3df168e0d26c0a0@verisign.com>
In-Reply-To: <3d6ce5fd7d1e482fb3df168e0d26c0a0@verisign.com>
Date: Mon, 23 Nov 2020 15:31:18 +0100
Message-ID: <00bf01d6c1a5$4ff6fe80$efe4fb80$@freshmail.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJzyKcu2uVC6EXZ2ToVMDu9WO5tAgG4Jbd0AlPeJ1yoe1hn0A==
Content-Language: de
X-Provags-ID: V03:K1:ZkKmB38+ijlgvrMQK5eV8eeYpmIYbgVZYhqksHd1wwD9Yv21NnD KBTnkOMcWDO+yhPoBiQ4+jtfeNZPJcQvnbyla0F7F9aLbaq+TbrL8zVHB6cdqi00lefiHDd g3muqQ3L0QymwEB8E2zzQccrSRu2vrR2JPfdJOlzCOo6lEq45IKV87xG7844Hvy2cxNToWh Zg9KFUrQEgRzcfWk/93mg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:5V31cb++918=:y3BNuR8eINvBEayQc2nNP2 qaneeLDq5Di0kZtdHECTZ2fUiVMbsanpN+rtepqGViAkHrXsH8XE0O20cHJBJb8nASsfbYcUs fzisOPwAAgZtzOpwJpx8R/E1Q4ziR7nPy+DUhNN63W10dBgV89baDBPzihN6TurGzEm56Kr11 3gFkh0tp0xpIo1Dp/+38e+5yh3QkIcpZJBaNWSZqpZ5sKrBo5GupsdbFsAu4UJ69VVHQefDe9 wf61iKwDtEx2aDEkRuvMLen9AjqroWCKBmIPL4luHWFQboog3lARqPPwcZdDa4itU/EPa5yIt fwo9agHXbNpo7TJfpiZP0ObJemAmIMvoocSr0rU8ydQgEQPeZvrCemRewYhTY/FUZlHbxADzQ 8wm9Czb8hCJlWzV43IPjsxfjkZm0fBKITO7XdAqMxl8twIGaZWV0tMdtoHu40
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/NJMYz8sooA7hgUh47Jv0jOdRLTI>
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 14:33:15 -0000

Hello

> > -----Original Message-----
> > From: Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>
> > Sent: Monday, November 23, 2020 1:04 AM
> > To: Gould, James <jgould@verisign.com>
> > Cc: Klaus.Malorny@knipp.de; Hollenbeck, Scott
> > <shollenbeck@verisign.com>om>; regext@ietf.org
> > Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and
> > EPP
> >
> > Caution: This email originated from outside the organization. Do not
> > click links or open attachments unless you recognize the sender and
> > know the content is safe.
> >
> > Jumping into this discussion quite late, but...
> >
> > On Thu, Nov 19, 2020 at 4:39 PM Gould, James
> > <jgould=40verisign.com@dmarc.ietf.org> wrote:
> >
> > > The 3 options presented and discussed at the REGEXT meeting included
> > three extension options, which all include an namespace URI in the
> > greeting and logic services:
> >
> > I'd really like to understand why there's not option (4), which, as i
> > mentioned, would be:
> >
> > - Accept EAI addresses like any other email address in the standard
> > EPP field (if the registry supports this). I don't see why the current
> > RFC 5730 ff schema would not support this.
> > - If a registry doesn't want to accept EAI addresses, return a 2306.
> > This is inline with many other elements of registry policies - eg.
> > when a registry validates the pc element of contacts against local
> > policy, it would also 2306 - and nobody has yet discussed an extension
> > for the purpose of announcing that the registry only supports a
> > certain set of pc values (nooooo, no i've planted ideas in all of our
> > brains!)
> > - I don't see an issue with RDAP. RDAP can perfectly display non-ASCII
> > characters
> > - Creating an extension like this will never make EAI's "first class
citizens".
> > Accepting EAIs in standard "<email>" elements will.
> >
> > Maybe I'm failing to see the point.  And, as Klaus said, we're making
> > EPP based registries a super complicated beast, implemented by a very
> > small community. Introducing "yet another switch" into the protocol
> > won't make it easier.
> 
> 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.

Maybe a dump question but is this entry not - a least - "just ascii with an
at" so I would just a matter of view?


> > For example, what would an "old" client do that doesn't understand a
> > potential EAI extension? Would they be deprived of email addresses
> > completely, and receive non-sensical placeholders which they'd
> > unwittingly hand over to their email system (even if that email system
> > would perfectly understand EAIs?). Does sound like a failed opportunity
to
> me!
> 
> See question above.
> 

Best, Matthias

> Scott
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext