> On 20 Nov 2020, at 07:04, Hollenbeck, Scott <shollenb...@verisign.com> 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 <check> or <info> 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 <email> 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 <email> 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
