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. + 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). - 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. Besides that usage of extension for the non-ASCII email addresses impugn the Universal Acceptance (UA) principle as it is described on the ICANN site. ------ Universal Acceptance (UA) is a fundamental requirement for a truly multilingual and digitally inclusive Internet. UA ensures that all domain names, including long new TLDs and IDNs, and email addresses are treated equally and can be used by all Internet-enabled applications, devices, and systems. Technically, they must accept, validate, store, process, and display all domain names equally, consistently, and correctly. ----- That is I see no reason to drive out the non-ASCII addresses into a separate extension while there are not any hurdles to use existing XML for such addresses (all the more so I heard there are registries that already do this way). > On 19 Nov 2020, at 15:47, Hollenbeck, Scott > <shollenbeck=40verisign....@dmarc.ietf.org> wrote: > > From: regext <regext-boun...@ietf.org> On Behalf Of Dmitry Belyavsky > Sent: Thursday, November 19, 2020 4:03 AM > To: regext@ietf.org > Subject: [EXTERNAL] [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, > > I think it's worth providing some thoughts about the EAI support in EPP from > a registrar's perspective. > > From a registrar's perspective, when the registry provides some feature, the > registrar has to support it in most cases. When a registry supports EAI, the > registrar should be ready to at least get an EAI address in the <info> > command on transfer. > > Registrars usually got accreditation for working with more than one registry, > and have to write some registry-specific code. In the case of EAI, the > changes should require at least accepting EAI addresses from the clients not > having the ASCII ones and some mechanism providing the valid ASCII email > address in the case when such client wants to register a domain in a registry > that does not support EAI. > > [SAH] This is why an optional extension is our best option. The server > (registry) advertises support for the extension. The capability is requested > when a client (registrar) performs a login with a server, and there’s reduced > risk of the client sending something the server won’t understand and > vice-versa. In the case (1) this is solved just by the "encoding" field in the XML header. > > 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
