Re: [regext] Internationalized Email Addresses and EPP

Klaus Malorny <Klaus.Malorny@knipp.de> Thu, 19 November 2020 16:56 UTC

Return-Path: <Klaus.Malorny@knipp.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 62CB63A0CE2 for <regext@ietfa.amsl.com>; Thu, 19 Nov 2020 08:56:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 FjQxmdgvCI07 for <regext@ietfa.amsl.com>; Thu, 19 Nov 2020 08:56:02 -0800 (PST)
Received: from kmx5a.knipp.de (kmx5a.knipp.de [195.253.6.99]) (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 BAFED3A0CD7 for <regext@ietf.org>; Thu, 19 Nov 2020 08:56:02 -0800 (PST)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx5a.knipp.de (Postfix) with ESMTP id 4CcQmc5T7kz4v6y; Thu, 19 Nov 2020 17:56:00 +0100 (CET)
Received: from [IPv6:2a01:5b0:0:25::1b] (unknown [IPv6:2a01:5b0:0:25::1b]) by hp9000.do.knipp.de (Postfix) with ESMTP id 7F2C571002; Thu, 19 Nov 2020 17:56:00 +0100 (MEZ)
Message-ID: <ef10e03a-d7e1-7bf4-3fb6-a738aab9b954@knipp.de>
Date: Thu, 19 Nov 2020 17:55:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:85.0) Gecko/20100101 Thunderbird/85.0a1
Content-Language: en-US
To: "Gould, James" <jgould@verisign.com>, "shollenbeck=40verisign.com@dmarc.ietf.org" <shollenbeck=40verisign.com@dmarc.ietf.org>
Cc: "regext@ietf.org" <regext@ietf.org>
References: <C9EBEF19-55C1-4C5E-87BC-894FBF7439FF@verisign.com>
From: Klaus Malorny <Klaus.Malorny@knipp.de>
In-Reply-To: <C9EBEF19-55C1-4C5E-87BC-894FBF7439FF@verisign.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spamd-Bar: /
X-Rspamd-Server: v1117
X-Rspamd-Queue-Id: 4CcQmc5T7kz4v6y
Authentication-Results: kmx5a.knipp.de; none
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:195.253.0.0/16, country:DE]; LOCAL_WL_IP(0.00)[195.253.2.54]
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/Xy6qkEll3qH4_ERrbzy__2RDM-E>
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: Thu, 19 Nov 2020 16:56:08 -0000

On 19.11.20 16:37, Gould, James wrote:
> Klaus,
> 
> [...]

>  2. Implicit Replacement Based on Login Services – Inclusion of the
>     namespace URI in the greeting and login services indicate support
>     for EAI addresses implicitly.  This would be treated similar to an
>     EPP extension with the namespace URI in the greeting and login services.
> [...]

> It sounds like you’re proposing the use of the second option.  I believe 
> that inclusion in only the greeting and logic services is too course 
> grain, since the registry systems can support many TLDs and many EPP 
> objects, each with different levels of support for EAI addresses.  
> Option 3 would be a lighter weight method that is an object-level 
> indicator and option 1 would be the most explicit to indicate which 
> email element is replaced by use of the placeholder text with the 
> extension email element. The use of email addresses apply to multiple 
> EPP RFCs (RFC 5733, RFC 8543) and to at least one non-RFC EPP extension 
> registered in the EPP Extension Registry 
> (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml).
> 

Hi James,

you are right, my proposal matches option 2. I didn't know that this was 
discussed already. In respect to option 3 I really think that if EAI 
support shall be specific to object types then it would be better to 
release updated specifications of these objects, maybe with new URIs if 
necessary. This would be my general preference, as I noted in my 
previous e-mail.

Having extensions that influence the interpretation of certain elements 
in objects or other extensions has the problem that it increases the 
complexity over time, makes it less understandable and makes it more 
difficult to get rid of old stuff. The DNSSEC extensions (1.0 and 1.1) 
are a good counter example for how it should work. I guess that nowadays 
no active EPP server or client is unable to use version 1.1, thus 1.0 
support could be theoretically removed from the implementations.

Maybe one could find additional improvements to the contact object to 
justify an update. For example, fixing the disclosure settings. While 
their use have become questionable in the context of data protection 
regulations like the GDPR anyway, they have the slight design problem 
that one cannot set and remove specific disclosure settings at the same 
time. Or one could consider to add a language field, which could be 
helpful when sending e-mails to registrants, e.g. WDRP e-mails, transfer 
related e-mails. Maybe there are other aspects with which registrars, 
resellers and end users are unhappy.

Regards,

Klaus