From: Dmitry Belyavsky <beld...@gmail.com> Sent: Monday, November 23, 2020 10:00 AM To: Hollenbeck, Scott <shollenb...@verisign.com> Cc: alex.mayrhofer.i...@gmail.com; Gould, James <jgo...@verisign.com>; regext@ietf.org; klaus.malo...@knipp.de Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP
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. Dear Scott, On Mon, Nov 23, 2020 at 4:59 PM Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>> wrote: > -----Original Message----- > From: Alexander Mayrhofer <alex.mayrhofer.i...@gmail.com<mailto:alex.mayrhofer.i...@gmail.com>> > Sent: Monday, November 23, 2020 1:04 AM > To: Gould, James <jgo...@verisign.com<mailto:jgo...@verisign.com>> > Cc: klaus.malo...@knipp.de<mailto:klaus.malo...@knipp.de>; Hollenbeck, Scott > <shollenb...@verisign.com<mailto:shollenb...@verisign.com>>; regext@ietf.org<mailto:regext@ietf.org> > Subject: [EXTERNAL] Re: [regext] Internationalized Email Addresses and EPP > > 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. > > Jumping into this discussion quite late, but... > > On Thu, Nov 19, 2020 at 4:39 PM Gould, James > <jgould=40verisign....@dmarc.ietf.org<mailto:40verisign....@dmarc.ietf.org>> wrote: > > > The 3 options presented and discussed at the REGEXT meeting included > three extension options, which all include an namespace URI in the greeting > and logic services: > > I'd really like to understand why there's not option (4), which, as i > mentioned, would be: > > - Accept EAI addresses like any other email address in the standard EPP field > (if the registry supports this). I don't see why the current RFC 5730 ff schema > would not support this. > - If a registry doesn't want to accept EAI addresses, return a 2306. > This is inline with many other elements of registry policies - eg. > when a registry validates the pc element of contacts against local policy, it > would also 2306 - and nobody has yet discussed an extension for the purpose > of announcing that the registry only supports a certain set of pc values > (nooooo, no i've planted ideas in all of our > brains!) > - I don't see an issue with RDAP. RDAP can perfectly display non-ASCII > characters > - Creating an extension like this will never make EAI's "first class citizens". > Accepting EAIs in standard "<email>" elements will. > > Maybe I'm failing to see the point. And, as Klaus said, we're making EPP > based registries a super complicated beast, implemented by a very small > community. Introducing "yet another switch" into the protocol won't make it > easier. This may be the path of least resistance. I'm still trying to think through hat would happen if a registry returns an internationalized email address to a registrar that doesn't expect one. This could happen after a domain transfer, for example. Is this a problem? If not, maybe we could just get by without any other protocol changes or extensions. From my point of view, if the registry has implemented EAI support, all the registrars will have to do it. They should deal with the clients with such emails _somehow_. E.g., they hardly can reject the transfer relying on this reason. [SAH] I’m not talking about rejecting a transfer. I’m talking about what a registrar that does not support EAI would/should do if it is the receiving registrar of a domain that includes contacts using internationalized email addresses and those addresses aren’t supported by the registrar. How should this work? Scott
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
