Subject: Re: [regext] Internationalized Email Addresses and EPP

From: "Gould, James" <[email-masked]>
Date: Thu, 19 Nov 2020 18:14:30 +0000

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,

-- 
 
JG

James Gould
Fellow Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 11/19/20, 11:56 AM, "Klaus Malorny" <[email-masked]> wrote:

    On 19.11.20 16:37, Gould, James wrote:
    > Klaus,
    > [...]

    >  2. Implicit Replacement Based on Login Services – Inclusion of the
    >     namespace URI in the greeting and login services indicate support
    >     for EAI addresses implicitly.  This would be treated similar to an
    >     EPP extension with the namespace URI in the greeting and login services.
    > [...]

    > It sounds like you’re proposing the use of the second option.  I believe 
    > that inclusion in only the greeting and logic services is too course 
    > grain, since the registry systems can support many TLDs and many EPP 
    > objects, each with different levels of support for EAI addresses.  
    > Option 3 would be a lighter weight method that is an object-level 
    > indicator and option 1 would be the most explicit to indicate which 
    > email element is replaced by use of the placeholder text with the 
    > extension email element. The use of email addresses apply to multiple 
    > EPP RFCs (RFC 5733, RFC 8543) and to at least one non-RFC EPP extension 
    > registered in the EPP Extension Registry 
    > (https://secure-web.cisco.com/10F-1HgkEVNjFP0QgeBKhNA6sGTSD5RdZNJB4QHkoLDH8IHBYRs1ltUZiJPQNpihXZRKqZnlZfft8YypQmOjFdKnT6xD8VWe0qoyaI66wv8KLgW6NwVw9yKxur_9mPHqImn2NdED0DulgXSONcHFsSXPwjOjo3dhdmXS99AEu06iPQ5SdWh4mxRpqQezq22KmHdnz6i3MjgIFVSjk61bkmmkGv4OfN2faHghwaNVLCO1PszPa1O3Xv8qnay5A_HfRelkpzXwgtVWks1yBkwNPtw/https%3A%2F%2Fwww.iana.org%2Fassignments%2Fepp-extensions%2Fepp-extensions.xhtml).
    > 

    Hi James,

    you are right, my proposal matches option 2. I didn't know that this was 
    discussed already. In respect to option 3 I really think that if EAI 
    support shall be specific to object types then it would be better to 
    release updated specifications of these objects, maybe with new URIs if 
    necessary. This would be my general preference, as I noted in my 
    previous e-mail.

    Having extensions that influence the interpretation of certain elements 
    in objects or other extensions has the problem that it increases the 
    complexity over time, makes it less understandable and makes it more 
    difficult to get rid of old stuff. The DNSSEC extensions (1.0 and 1.1) 
    are a good counter example for how it should work. I guess that nowadays 
    no active EPP server or client is unable to use version 1.1, thus 1.0 
    support could be theoretically removed from the implementations.

    Maybe one could find additional improvements to the contact object to 
    justify an update. For example, fixing the disclosure settings. While 
    their use have become questionable in the context of data protection 
    regulations like the GDPR anyway, they have the slight design problem 
    that one cannot set and remove specific disclosure settings at the same 
    time. Or one could consider to add a language field, which could be 
    helpful when sending e-mails to registrants, e.g. WDRP e-mails, transfer 
    related e-mails. Maybe there are other aspects with which registrars, 
    resellers and end users are unhappy.

    Regards,

    Klaus

---

From: Klaus Malorny <[email-masked]>
Date: Fri, 20 Nov 2020 09:47:25 +0100

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Nov 2020 09:06:40 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Klaus Malorny
> Sent: Friday, November 20, 2020 3:47 AM
> To: [email-masked]
> 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.
>
> > 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,
>
> 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.

Scott

---

From: Taras Heichenko <[email-masked]>
Date: Fri, 20 Nov 2020 13:13:23 +0200

> On 20 Nov 2020, at 11:06, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> 

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.

> 
> Scott
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

--
Taras Heichenko
[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Nov 2020 11:17:40 +0000

> From: Taras Heichenko <[email-masked]>
> Sent: Friday, November 20, 2020 6:13 AM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]; [email-masked]
> > On 20 Nov 2020, at 11:06, Hollenbeck, Scott
> <shollenbeck=[email-masked]> wrote:
> >
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >> 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.

Scott

---

From: Dmitry Belyavsky <[email-masked]>
Date: Fri, 20 Nov 2020 14:34:20 +0300

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

> click links

>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

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 20 Nov 2020 15:54:01 +0100

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=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > From: Taras Heichenko <[email-masked]
>     <mailto:[email-masked]>>
>     > To: Hollenbeck, Scott <[email-masked]
>     <mailto:[email-masked]>>
>     > Cc: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     > <shollenbeck=[email-masked]
>     <mailto:[email-masked]>> wrote:
>     > >
>     > >> From: regext <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of Klaus Malorny
>     > >> To: [email-masked] <mailto:[email-masked]>
>     > >> Subject: [EXTERNAL] Re: [regext] Internationalized Email
>     Addresses
>     > >> and EPP
>     > >>
>     > >>> The EAI support goes beyond RFC 5733 and is a perfect
>     example of the
>     > >>> use
> 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
>

-- 
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