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
<[email protected]
<mailto:[email protected]>> wrote:
> -----Original Message-----
> From: Taras Heichenko <[email protected]
<mailto:[email protected]>>
> Sent: Friday, November 20, 2020 6:13 AM
> To: Hollenbeck, Scott <[email protected]
<mailto:[email protected]>>
> Cc: [email protected] <mailto:[email protected]>;
[email protected] <mailto:[email protected]>
> 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
> <[email protected]
<mailto:[email protected]>> wrote:
> >
> >> -----Original Message-----
> >> From: regext <[email protected]
<mailto:[email protected]>> On Behalf Of Klaus Malorny
> >> Sent: Friday, November 20, 2020 3:47 AM
> >> To: [email protected] <mailto:[email protected]>
> >> 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
[email protected]
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: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
