Dear Scott, On Mon, Nov 23, 2020 at 4:59 PM Hollenbeck, Scott <shollenbeck= 40verisign....@dmarc.ietf.org> wrote:
> > -----Original Message----- > > From: Alexander Mayrhofer <alex.mayrhofer.i...@gmail.com> > > Sent: Monday, November 23, 2020 1:04 AM > > To: Gould, James <jgo...@verisign.com> > > Cc: klaus.malo...@knipp.de; Hollenbeck, Scott > > <shollenb...@verisign.com>; 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> 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. > > > For example, what would an "old" client do that doesn't understand a > > potential EAI extension? Would they be deprived of email addresses > > completely, and receive non-sensical placeholders which they'd > unwittingly > > hand over to their email system (even if that email system would > perfectly > > understand EAIs?). Does sound like a failed opportunity to me! > > See question above. > > Scott > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext > -- SY, Dmitry Belyavsky
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
