Re: [regext] Internationalized Email Addresses and EPP

[Klaus Malorny <[e-mail]>]

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