Re: [regext] Internationalized Email Addresses and EPP

Mario Loffredo <mario.loffredo@iit.cnr.it> Fri, 20 November 2020 14:57 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
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 BF8343A0C06 for <regext@ietfa.amsl.com>; Fri, 20 Nov 2020 06:57:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 5PkcaIz2HO4w for <regext@ietfa.amsl.com>; Fri, 20 Nov 2020 06:57:41 -0800 (PST)
Received: from smtp.iit.cnr.it (mx5.iit.cnr.it [146.48.98.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8230E3A0BF2 for <regext@ietf.org>; Fri, 20 Nov 2020 06:57:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 24CA0C03CB; Fri, 20 Nov 2020 15:57:38 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at mx5.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx5.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxP4Csd6P6Bf; Fri, 20 Nov 2020 15:57:34 +0100 (CET)
Received: from [192.12.193.108] (pc-loffredo.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id 98C5CC0388; Fri, 20 Nov 2020 15:57:34 +0100 (CET)
To: Dmitry Belyavsky <beldmit@gmail.com>, "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
Cc: "tasic@academ.kiev.ua" <tasic@academ.kiev.ua>, "regext@ietf.org" <regext@ietf.org>, "Klaus.Malorny@knipp.de" <Klaus.Malorny@knipp.de>
References: <AB832A1D-083B-40E4-9F45-B03DB7452B70@verisign.com> <a5446f92-2250-d1e6-16f5-7fdffc48a9c8@knipp.de> <08e72da8ecc745cb8a6c4338566ff0c6@verisign.com> <6EBBAF72-6CFC-4295-A453-66BA1403919D@academ.kiev.ua> <cf4727d834a340ca98226b3785ce7b19@verisign.com> <CADqLbz+kU9Usf-uH8DhiYpr6JHgkdRb-ickEuLe+4021K6DNLQ@mail.gmail.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
Message-ID: <6dff8083-8a0a-0f2e-f19d-674e77fd936e@iit.cnr.it>
Date: Fri, 20 Nov 2020 15:54:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <CADqLbz+kU9Usf-uH8DhiYpr6JHgkdRb-ickEuLe+4021K6DNLQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------5A99F29BF34DFDDCEBC51E78"
Content-Language: it
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/cwu5qexk6FJbc6drzMJYCbzL2GQ>
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: Fri, 20 Nov 2020 14:57:45 -0000

Hi all,

I prefer option 2.

Similarly to option 3, it doesn't involve a change to EPP core but it is 
less complex to be implemented for both registrars and registries.

After all, the placeholder value "[EAI-ADDRESS]" is itself uncompliant 
with the current contact:email definition.


Best,

Mario

Il 20/11/2020 12:34, Dmitry Belyavsky ha scritto:
>
>
> On Fri, Nov 20, 2020 at 2:17 PM Hollenbeck, Scott 
> <shollenbeck=40verisign.com@dmarc.ietf.org 
> <mailto:40verisign.com@dmarc.ietf.org>> wrote:
>
>     > -----Original Message-----
>     > From: Taras Heichenko <tasic@academ.kiev.ua
>     <mailto:tasic@academ.kiev.ua>>
>     > Sent: Friday, November 20, 2020 6:13 AM
>     > To: Hollenbeck, Scott <shollenbeck@verisign.com
>     <mailto:shollenbeck@verisign.com>>
>     > Cc: Klaus.Malorny@knipp.de <mailto:Klaus.Malorny@knipp.de>;
>     regext@ietf.org <mailto: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.
>     >
>     >
>     > > On 20 Nov 2020, at 11:06, Hollenbeck, Scott
>     > <shollenbeck=40verisign.com@dmarc.ietf.org
>     <mailto:40verisign.com@dmarc.ietf.org>> wrote:
>     > >
>     > >> -----Original Message-----
>     > >> From: regext <regext-bounces@ietf.org
>     <mailto:regext-bounces@ietf.org>> On Behalf Of Klaus Malorny
>     > >> Sent: Friday, November 20, 2020 3:47 AM
>     > >> To: regext@ietf.org <mailto: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.
>     > >>
>     > >> On 19.11.20 19:14, Gould, James wrote:
>     > >>> Klaus,
>     > >>>
>     > >>> The EAI support goes beyond RFC 5733 and is a perfect
>     example of the
>     > >>> use
>     > >> of the extensibility built into EPP.  Revising the RFCs and EPP
>     > >> extensions that use email addresses for EAI with new XML
>     namespaces
>     > >> and potentially other changes is much more impactful than
>     creating an
>     > >> EPP extension that specifically addresses the issue with
>     > >> applicability across any EPP object.  I was involved with
>     revising
>     > >> RFC 4310 to RFC 5910, which was needed to address significant
>     > >> implementation issues with RFC 4310, so I see it as a
>     different use
>     > >> case.  The intent is to make the EPP extension as lightweight as
>     > >> possible, to apply across multiple EPP objects, and to include an
>     > >> appropriate level of signaling (e.g., session-level,
>     object-level, element-
>     > level).  Any feedback is welcome.
>     > >>>
>     > >>> Thanks,
>     > >>>
>     > >>
>     > >> Hi James,
>     > >>
>     > >> I chose DNSSEC as an example as I know that you took the
>     major part
>     > >> in writing the update. At the very end, it is a matter of
>     taste, and
>     > >> one cannot argue about. So I respect your position.
>     > >>
>     > >> As you might know, my company is developing software both for the
>     > >> registry side (our TANGO software) and for the registrar side
>     (for
>     > >> customers and our own purpose). And for the latter, dealing
>     with all
>     > >> the slightly different implementations of the EPP, within the
>     limits
>     > >> of the specifications and beyond, and dealing with the flood of
>     > >> extensions, including different versions of them, is really
>     anything but
>     > fun.
>     > >>
>     > >> As I understand it, the original idea of EPP was to have a common
>     > >> protocol for all registries, and it "failed by the wayside"
>     > >> (hopefully the right idiom). It is not about blaming anyone
>     for this,
>     > >> maybe the idea was just too ambitious. So IMHO with every
>     proposed
>     > >> change to the EPP ecosystem one should ask oneself whether it
>     > >> increases or decreases the overall complexity and the need
>     for case
>     > >> differentiation, specifically in the long run. I do not
>     remember who
>     > >> said this, but there is a proverb which goes like the
>     following: If
>     > >> you design a protocol, don't ask what you can add to it, but
>     what you can
>     > remove from it. While this is likely idealistic, I'll try to
>     keep this in my mind.
>     > >>
>     > >> Coming back to the issue, I see internationalized e-mail
>     addresses
>     > >> coming to stay, like IPv6 did and IDN. So make it an integral
>     part of
>     > >> the protocol, not an optional one, in the long run. But hey,
>     that's only my
>     > taste.
>     > >
>     > > Please keep in mind that they're currently an OPTIONAL SMTP
>     extension. I
>     > think that would need to change before they become a MUST for EPP.
>     >
>     > I fully agree with Klaus, the proposed extension increases the
>     protocol
>     > complexity, adds a lot of job to the EPP software developers,
>     and what it
>     > gives back? Less work with the RFCs? Do you really think it is a
>     valuable
>     > exchange? And in a new RFC, support of non-ASCII email addresses
>     may be
>     > optional.
>
>     Sorry, but an extension is a whole lot less complex than changing
>     the core protocol.
>
>
> From my *implementation* experience, the extension (as a body, not 
> just as a marker) is more complex than relaxing the email syntax.
> And we anyway have a much larger volume of work when the registrar 
> starts tuning his mail system to work with EAI...
>
> -- 
> SY, Dmitry Belyavsky
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo