> On 20 Nov 2020, at 13:18, Hollenbeck, Scott
> <shollenbeck=40verisign....@dmarc.ietf.org> wrote:
>
>> -----Original Message-----
>> From: Taras Heichenko <ta...@academ.kiev.ua>
>> Sent: Friday, November 20, 2020 5:49 AM
>> To: Hollenbeck, Scott <shollenb...@verisign.com>
>> 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 <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.
>
> 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 <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?
>
> 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 <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.
>
> 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 would be interesting to make a poll through registrars of different TLDs
(country, generic, new) about these questions. Does their software choose
syntax dynamically or the syntax is predefined for every registry they are work
with?
>
> 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.
I fully agree and support you in this point. Can we make questioning through the
EPP software developers, registries and registrars what is more appropriate from
their point of view?
>
> 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
