Hello > > -----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.
Maybe a dump question but is this entry not - a least - "just ascii with an at" so I would just a matter of view? > > 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. > Best, Matthias > Scott > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
