Re: [regext] Internationalized Email Addresses and EPP

Taras Heichenko <tasic@academ.kiev.ua> Fri, 20 November 2020 11:13 UTC

Return-Path: <tasic@academ.kiev.ua>
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 1EFB53A07C4; Fri, 20 Nov 2020 03:13:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 cCjYVGHZTHq9; Fri, 20 Nov 2020 03:13:33 -0800 (PST)
Received: from academ.kiev.ua (academ.kiev.ua [194.143.145.237]) (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 A66F13A07A0; Fri, 20 Nov 2020 03:13:32 -0800 (PST)
Received: from [10.0.3.72] by academ.kiev.ua with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from <tasic@academ.kiev.ua>) id 1kg4M0-0002Rx-En; Fri, 20 Nov 2020 13:13:30 +0200
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
From: Taras Heichenko <tasic@academ.kiev.ua>
In-Reply-To: <08e72da8ecc745cb8a6c4338566ff0c6@verisign.com>
Date: Fri, 20 Nov 2020 13:13:23 +0200
Cc: "Klaus.Malorny@knipp.de" <Klaus.Malorny@knipp.de>, "regext@ietf.org" <regext@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6EBBAF72-6CFC-4295-A453-66BA1403919D@academ.kiev.ua>
References: <AB832A1D-083B-40E4-9F45-B03DB7452B70@verisign.com> <a5446f92-2250-d1e6-16f5-7fdffc48a9c8@knipp.de> <08e72da8ecc745cb8a6c4338566ff0c6@verisign.com>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
X-Spam-Score_int: [academ.kiev.ua] -28
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/eo_tebttijKeUKvD4a-wo0ud7Y8>
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 11:13:35 -0000


> On 20 Nov 2020, at 11:06, Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org> wrote:
> 
>> -----Original Message-----
>> From: regext <regext-bounces@ietf.org> On Behalf Of Klaus Malorny
>> Sent: Friday, November 20, 2020 3:47 AM
>> To: 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.

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

--
Taras Heichenko
tasic@academ.kiev.ua