Re: [regext] Internationalized Email Addresses and EPP

[Mario Loffredo <[e-mail]>]

Hi all,

I prefer option 2.

Similarly to option 3, it doesn't involve a change to EPP core but it is 
less complex to be implemented for both registrars and registries.

After all, the placeholder value "[EAI-ADDRESS]" is itself uncompliant 
with the current contact:email definition.


Best,

Mario

Il 20/11/2020 12:34, Dmitry Belyavsky ha scritto:
>
>
> On Fri, Nov 20, 2020 at 2:17 PM Hollenbeck, Scott 
> <shollenbeck=[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     > -----Original Message-----
>     > From: Taras Heichenko <[e-mail]
>     <mailto:[e-mail]>>
>     > Sent: Friday, November 20, 2020 6:13 AM
>     > To: Hollenbeck, Scott <[e-mail]
>     <mailto:[e-mail]>>
>     > Cc: [e-mail] <mailto:[e-mail]>;
>     [e-mail] <mailto:[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]
>     <mailto:[e-mail]>> wrote:
>     > >
>     > >> -----Original Message-----
>     > >> From: regext <[e-mail]
>     <mailto:[e-mail]>> On Behalf Of Klaus Malorny
>     > >> Sent: Friday, November 20, 2020 3:47 AM
>     > >> To: [e-mail] <mailto:[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
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web: http://www.iit.cnr.it/mario.loffredo