Re: [regext] Internationalized Email Addresses and EPP

[Dmitry Belyavsky <[e-mail]>]

On Fri, Nov 20, 2020 at 2:17 PM Hollenbeck, Scott <shollenbeck=
[e-mail]> wrote:

> > -----Original Message-----
> > From: Taras Heichenko <[e-mail]>
> > Sent: Friday, November 20, 2020 6:13 AM
> > To: Hollenbeck, Scott <[e-mail]>
> > Cc: [e-mail]; [e-mail]
> > 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 20 Nov 2020, at 11:06, Hollenbeck, Scott
> > <shollenbeck=[e-mail]> wrote:
> > >
> > >> -----Original Message-----
> > >> From: regext <[e-mail]> On Behalf Of Klaus Malorny
> > >> Sent: Friday, November 20, 2020 3:47 AM
> > >> To: [e-mail]
> > >> 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.
>
> Sorry, but an extension is a whole lot less complex than changing the core
> protocol.
>

>From my *implementation* experience, the extension (as a body, not just as
a marker) is more complex than relaxing the email syntax.
And we anyway have a much larger volume of work when the registrar starts
tuning his mail system to work with EAI...

-- 
SY, Dmitry Belyavsky