Re: [regext] Internationalized Email Addresses and EPP

[Klaus Malorny <[e-mail]>]

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.

Just my two cents.

Klaus