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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
