Re: [regext] Internationalized Email Addresses and EPP

Hello

> > -----Original Message-----
> > From: Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>
> > Sent: Monday, November 23, 2020 1:04 AM
> > To: Gould, James <jgould@verisign.com>
> > Cc: Klaus.Malorny@knipp.de; Hollenbeck, Scott
> > <shollenbeck@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.com@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