> -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of Taras Heichenko > Sent: Thursday, November 19, 2020 1:47 PM > To: 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. > > Hello! > > For a long enough period, I worked as a CTO in one of the ccTLD registries. > I'd > like to say my position about the proposed variants. Briefly: > (1) write new RFC and make RFC5733 obsoleted > (2) write RFC that defines an extension for non-ASCII email addresses > > 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. > + the XML structure does not depend on the support or no support non- > ASCII email addresses by the registry. There is no need to add code that > implements extension and parse this extension from the other side. > + new RFC could be written the way that uses the MUST word for ASCII email > addresses in the <email> field and MAY word for non-ASCII addresses in the > same field. So the usage of non-ASCII addresses would not be mandatory for > all registries. > - there is a need to go through the new RFC acceptance and making RFC5733 > obsolete (there is more work than just accept the new RFC with extension, > AFAIU). > > (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. > - can cause (and if it can then it would) muddle with the usage of email > addresses. In this case, we have a potential field for the second email > address in the Contact object. I can define an address in the main <email> > field or in the extension. What would be if I define the ASCII address by the > first call to the registry and define the non-ASCII address by the second > call to > the same registry? If the second call rewrites the main address it is strange > that the extension rewrites the main field. If the extension does not rewrite > the main field it can cause the DB structure modification to allow ASCII and > non-ASCII addresses simultaneously. And it brings us to multiply email > addresses in the Contact object. > > 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. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
