Re: [regext] Internationalized Email Addresses and EPP

[Klaus Malorny]

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

Re: [regext] Internationalized Email Addresses and EPP

[Hollenbeck, Scott]

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

Scott

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EAI in EPP from a registrar point of view

[Taras Heichenko]

> On 20 Nov 2020, at 07:04, Hollenbeck, Scott  wrote:
> 

[skip]

>> Let's compare the pros and contras of both
>> (1)
>> + allows implementation by minimum changes in the software. It is enough
>> to change the rule which checks email addresses.
> 
> I disagree with this completely. A new version of 5733 means a new XML 
> namespace, which means that every single implementation of 5733 is affected.

I did not say that it is possible to avoid software modification. But changing 
namespace
and adding a chank of code to process new extension differ a lot by the amount 
of work.

[skip again]

>> 
>> (2)
>> + wittingly it is not mandatory by design causes less bureaucratic work
>> + with RFC documents (there is no need to obsolete any RFC, just accept
>> + new one with the extension)
>> - causes much more software modification. Even if a registrar does not work
>> with this extension it must make modifications to its code to parse responses
>> to  or  commands with the possible extension. In case (1)
>> there would be just symbols in the wrong encoding (if even).
> 
> A registrar/client that does not negotiate use of the extension should not 
> receive internationalized email addresses in any response. If that happens, 
> the server is doing something wrong.

Ok. Let's imagine the case. There is a contact in a registry with a non-ASCII 
email address.
A registrar connects to the registry by EPP. Registrar does not support the EAI 
extension and
it asks the registry info about the Contact object with a non-ASCII address. 
What is going next?

[and skip again]

>> 
>> I think that (1) has a more positive balance than (2). I disagree with the
>> proposed document and the design suggested by it. I think that non-ASCII
>> email addresses should use the same  field as ASCII addresses and
>> whether registry allows or denies such addresses must be defined in the
>> registry documentation.
> 
> "non-ASCII email addresses should use the same  field as ASCII 
> addresses" sounds reasonable to me, assuming that this is negotiated at login 
> time. I believe this is the approach taken by SMTP when use of the OPTIONAL 
> EAI extension is negotiated.

May I ask you to explain in a few words why the negotiation at login time is so 
important? I try
to explain my point of view. Every registry has a predefined set of registrars 
that connect to it by
EPP. Every registrar has a predefined set of registries to connect with. There 
are many different
registries in the world with nuances in the EPP implementation. It does not 
mean that registries
should have different EPP implementation for each registry but at least they 
must have a set of
rules for the EPP with every registry. And this set of rules is not built 
on-the-fly. It is not an SMTP
protocol when there is no predefined set of peers and protocol must be very 
simple and clear to
be supported by all the participants. The EPP protocol is already far beyond 
the SMTP by complexity.
And registrars do not connect to the registries without appropriately preparing 
the software. So any
negotiation at login time has a very formal meaning for this protocol. Maybe I 
am wrong I just explain
my point of view from almost nine years in one of the ccTLD.


> 
> Scott

--
Taras Heichenko
ta...@academ.kiev.ua





___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[Taras Heichenko]

> On 20 Nov 2020, at 11:06, Hollenbeck, Scott 
>  wrote:
> 
>> -Original Message-
>> From: regext  On Behalf Of Klaus Malorny
>> Sent: Friday, November 20, 2020 3:47 AM
>> To: regext@ietf.org
>> 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.

> 
> Scott
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Taras Heichenko
ta...@academ.kiev.ua





___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[Hollenbeck, Scott]

> -Original Message-
> From: Taras Heichenko 
> Sent: Friday, November 20, 2020 6:13 AM
> To: Hollenbeck, Scott 
> Cc: klaus.malo...@knipp.de; regext@ietf.org
> 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
>  wrote:
> >
> >> -Original Message-
> >> From: regext  On Behalf Of Klaus Malorny
> >> Sent: Friday, November 20, 2020 3:47 AM
> >> To: regext@ietf.org
> >> 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.

Scott

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EAI in EPP from a registrar point of view

[Hollenbeck, Scott]

> -Original Message-
> From: Taras Heichenko 
> Sent: Friday, November 20, 2020 5:49 AM
> To: Hollenbeck, Scott 
> Cc: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] EAI in EPP from a registrar point of view
>
> 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 07:04, Hollenbeck, Scott 
> wrote:
> >
>
> [skip]
>
> >> Let's compare the pros and contras of both
> >> (1)
> >> + allows implementation by minimum changes in the software. It is
> >> + enough
> >> to change the rule which checks email addresses.
> >
> > I disagree with this completely. A new version of 5733 means a new XML
> namespace, which means that every single implementation of 5733 is
> affected.
>
> I did not say that it is possible to avoid software modification. But 
> changing
> namespace and adding a chank of code to process new extension differ a lot
> by the amount of work.

Right - it's a lot MORE work.

> [skip again]
>
> >>
> >> (2)
> >> + wittingly it is not mandatory by design causes less bureaucratic
> >> + work with RFC documents (there is no need to obsolete any RFC, just
> >> + accept new one with the extension)
> >> - causes much more software modification. Even if a registrar does
> >> not work with this extension it must make modifications to its code
> >> to parse responses to  or  commands with the possible
> >> extension. In case (1) there would be just symbols in the wrong encoding
> (if even).
> >
> > A registrar/client that does not negotiate use of the extension should not
> receive internationalized email addresses in any response. If that happens,
> the server is doing something wrong.
>
> Ok. Let's imagine the case. There is a contact in a registry with a 
> non-ASCII
> email address.
> A registrar connects to the registry by EPP. Registrar does not support the 
> EAI
> extension and it asks the registry info about the Contact object with a non-
> ASCII address. What is going next?

How did that contact object get populated if the registrar doesn't support the 
capability? It might be possible in the case of a domain transfer. That's 
something we need to think about.

> [and skip again]
>
> >>
> >> I think that (1) has a more positive balance than (2). I disagree
> >> with the proposed document and the design suggested by it. I think
> >> that non-ASCII email addresses should use the same  field as
> >> ASCII addresses and whether registry allows or denies such addresses
> >> must be defined in the registry documentation.
> >
> > "non-ASCII email addresses should use the same  field as ASCII
> addresses" sounds reasonable to me, assuming that this is negotiated at
> login time. I believe this is the approach taken by SMTP when use of the
> OPTIONAL EAI extension is negotiated.
>
> May I ask you to explain in a few words why the negotiation at login time is
> so important? I try to explain my point of view. Every registry has a
> predefined set of registrars that connect to it by EPP. Every registrar has 
> a
> predefined set of registries to connect with. There are many different
> registries in the world with nuances in the EPP implementation. It does not
> mean that registries should have different EPP implementation for each
> registry but at least they must have a set of rules for the EPP with every
> registry. And this set of rules is not built on-the-fly. It is not an SMTP 
> protocol
> when there is no predefined set of peers and protocol must be very simple
> and clear to be supported by all the participants. The EPP protocol is 
> already
> far beyond the SMTP by complexity.
> And registrars do not connect to the registries without appropriately
> preparing the software. So any negotiation at login time has a very formal
> meaning for this protocol. Maybe I am wrong I just explain my point of view
> from almost nine years in one of the ccTLD.

Login negotiation is CRITICAL because that's where the client and the server 
agree on the set of services and capabilities that will be used during the 
session. Registrars cannot assume that every registry supports the same 
services, and registries cannot assume that every registrar supports all the 
services they offer. DNSSEC (DS record provisioning) is a tangible example. 
It's not supported by all registrars.

For what it's worth, I'm not new to this, either. I respect your point of 
view, and I can appreciate that we might have different operational 
experiences. Let's figure out how we can add this capability in a way that 
minimizes the impact on all involved. That's what I designed the EPP extension 
mechanism for - to provide a lightweight, opt-in way to add new features 
without having to change the core protocol.

Scott

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Internationalized Email Addresses and EPP

[Dmitry Belyavsky]

On Fri, Nov 20, 2020 at 2:17 PM Hollenbeck, Scott  wrote:

> > -Original Message-
> > From: Taras Heichenko 
> > Sent: Friday, November 20, 2020 6:13 AM
> > To: Hollenbeck, Scott 
> > Cc: klaus.malo...@knipp.de; regext@ietf.org
> > 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
> >  wrote:
> > >
> > >> -Original Message-
> > >> From: regext  On Behalf Of Klaus Malorny
> > >> Sent: Friday, November 20, 2020 3:47 AM
> > >> To: regext@ietf.org
> > >> 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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EAI in EPP from a registrar point of view

[Taras Heichenko]

> On 20 Nov 2020, at 13:18, Hollenbeck, Scott 
>  wrote:
> 
>> -Original Message-
>> From: Taras Heichenko 
>> Sent: Friday, November 20, 2020 5:49 AM
>> To: Hollenbeck, Scott 
>> Cc: regext@ietf.org
>> Subject: [EXTERNAL] Re: [regext] EAI in EPP from a registrar point of view
>> 
>> 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 07:04, Hollenbeck, Scott 
>> wrote:
>>> 
>> 
>> [skip]
>> 
 Let's compare the pros and contras of both
 (1)
 + allows implementation by minimum changes in the software. It is
 + enough
 to change the rule which checks email addresses.
>>> 
>>> I disagree with this completely. A new version of 5733 means a new XML
>> namespace, which means that every single implementation of 5733 is
>> affected.
>> 
>> I did not say that it is possible to avoid software modification. But 
>> changing
>> namespace and adding a chank of code to process new extension differ a lot
>> by the amount of work.
> 
> Right - it's a lot MORE work.

Let's ask Klaus what takes more developer's work, changing namespace, or adding 
the extension generation and parsing.
(In the neighbor thread Klaus wrote that his company is developing EPP 
software.)

> 
>> [skip again]
>> 
 
 (2)
 + wittingly it is not mandatory by design causes less bureaucratic
 + work with RFC documents (there is no need to obsolete any RFC, just
 + accept new one with the extension)
 - causes much more software modification. Even if a registrar does
 not work with this extension it must make modifications to its code
 to parse responses to  or  commands with the possible
 extension. In case (1) there would be just symbols in the wrong encoding
>> (if even).
>>> 
>>> A registrar/client that does not negotiate use of the extension should not
>> receive internationalized email addresses in any response. If that happens,
>> the server is doing something wrong.
>> 
>> Ok. Let's imagine the case. There is a contact in a registry with a 
>> non-ASCII
>> email address.
>> A registrar connects to the registry by EPP. Registrar does not support the 
>> EAI
>> extension and it asks the registry info about the Contact object with a non-
>> ASCII address. What is going next?
> 
> How did that contact object get populated if the registrar doesn't support 
> the 
> capability? It might be possible in the case of a domain transfer. That's 
> something we need to think about.

For example, this registry has open contacts and on registrar check a contact of
another one, or this contact was opened to the other registrar to check it 
before a
domain transfer. There may be a lot of cases.

> 
>> [and skip again]
>> 
 
 I think that (1) has a more positive balance than (2). I disagree
 with the proposed document and the design suggested by it. I think
 that non-ASCII email addresses should use the same  field as
 ASCII addresses and whether registry allows or denies such addresses
 must be defined in the registry documentation.
>>> 
>>> "non-ASCII email addresses should use the same  field as ASCII
>> addresses" sounds reasonable to me, assuming that this is negotiated at
>> login time. I believe this is the approach taken by SMTP when use of the
>> OPTIONAL EAI extension is negotiated.
>> 
>> May I ask you to explain in a few words why the negotiation at login time is
>> so important? I try to explain my point of view. Every registry has a
>> predefined set of registrars that connect to it by EPP. Every registrar has 
>> a
>> predefined set of registries to connect with. There are many different
>> registries in the world with nuances in the EPP implementation. It does not
>> mean that registries should have different EPP implementation for each
>> registry but at least they must have a set of rules for the EPP with every
>> registry. And this set of rules is not built on-the-fly. It is not an SMTP 
>> protocol
>> when there is no predefined set of peers and protocol must be very simple
>> and clear to be supported by all the participants. The EPP protocol is 
>> already
>> far beyond the SMTP by complexity.
>> And registrars do not connect to the registries without appropriately
>> preparing the software. So any negotiation at login time has a very formal
>> meaning for this protocol. Maybe I am wrong I just explain my point of view
>> from almost nine years in one of the ccTLD.
> 
> Login negotiation is CRITICAL because that's where the client and the server 
> agree on the set of services and capabilities that will be used during the 
> session. Registrars cannot assume that every registry supports the same 
> services, and registries cannot assume that every registrar supports all the 
> services they offer. DNSSEC (DS record provisioning) is a tangible example. 
> It's not supported by all registrars.

I think wou

Re: [regext] Internationalized Email Addresses and EPP

[Mario Loffredo]

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


> -Original Message-
> From: Taras Heichenko mailto:ta...@academ.kiev.ua>>
> Sent: Friday, November 20, 2020 6:13 AM
> To: Hollenbeck, Scott mailto:shollenb...@verisign.com>>
> Cc: klaus.malo...@knipp.de ;
regext@ietf.org 
> 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
> mailto:40verisign@dmarc.ietf.org>> wrote:
> >
> >> -Original Message-
> >> From: regext mailto:regext-boun...@ietf.org>> On Behalf Of Klaus Malorny
> >> Sent: Friday, November 20, 2020 3:47 AM
> >> To: regext@ietf.org 
> >> 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

Re: [regext] EAI in EPP from a registrar point of view

[Klaus Malorny]

On 20.11.20 14:37, Taras Heichenko wrote:



Right - it's a lot MORE work.


Let's ask Klaus what takes more developer's work, changing namespace, or adding 
the extension generation and parsing.
(In the neighbor thread Klaus wrote that his company is developing EPP 
software.)



Hi,

well, for the first case our EPP toolkit already allows the use of the 
domain, host and contact objects with different XML namespaces. The 
changes would mostly comprise creating subclasses for the respective 
commands and responses that simply override the previous (RFC 5733) 
namespace, since the schema would not change. This is less work than 
creating a brand new extension.


For the registrar system, I would have to introduce a configuration 
parameter to select EAI support in any case. For the login process, the 
work would also be more or less the same. For the code actually issuing 
the contact commands only changes for the creation of the toolkit 
objects would be required in the first case, whereas the extension 
version would require additional logic to create the extension resp. 
check for the presence of the extension and fiddle around with it. This 
is some more work and an additional source of bugs.


For the namespace solution, when some time in the future all supported 
registries have phased out the RFC 5733 contact object, I could clean up 
my code. In contrast, the code for the extension would stay forever and 
clutter up my code.


Klaus

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EAI in EPP from a registrar point of view

[Taras Heichenko]

> On 20 Nov 2020, at 19:32, Klaus Malorny  wrote:
> 
> On 20.11.20 14:37, Taras Heichenko wrote:
>>> Right - it's a lot MORE work.
>> Let's ask Klaus what takes more developer's work, changing namespace, or 
>> adding the extension generation and parsing.
>> (In the neighbor thread Klaus wrote that his company is developing EPP 
>> software.)
> 
> Hi,
> 
> well, for the first case our EPP toolkit already allows the use of the 
> domain, host and contact objects with different XML namespaces. The changes 
> would mostly comprise creating subclasses for the respective commands and 
> responses that simply override the previous (RFC 5733) namespace, since the 
> schema would not change. This is less work than creating a brand new 
> extension.
> 
> For the registrar system, I would have to introduce a configuration parameter 
> to select EAI support in any case. For the login process, the work would also 
> be more or less the same. For the code actually issuing the contact commands 
> only changes for the creation of the toolkit objects would be required in the 
> first case, whereas the extension version would require additional logic to 
> create the extension resp. check for the presence of the extension and fiddle 
> around with it. This is some more work and an additional source of bugs.
> 
> For the namespace solution, when some time in the future all supported 
> registries have phased out the RFC 5733 contact object, I could clean up my 
> code. In contrast, the code for the extension would stay forever and clutter 
> up my code.

Thank you for your answers. You entirely confirmed my thoughts about these 
issues.

> 
> Klaus
> 
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

--
Taras Heichenko
ta...@academ.kiev.ua





___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext