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