Re: [regext] Internationalized Email Addresses and EPP

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Klaus Malorny <[e-mail]>
> Sent: Thursday, November 19, 2020 10:21 AM
> To: Hollenbeck, Scott <[e-mail]>
> Cc: [e-mail]
> 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.
>
> Hi Scott et al.,
>
> sorry for proposing the following so late in the discussion. Due to other
> duties, my visits to the list were less frequent in the recent time. Looking at
> the two options - update of RFC 5733 or an extension -, I probably would
> tend to the first option, but I understand the problems with it.
>
> What I regard as suboptimal in respect to the proposed EPP extension [1] is
> the big effort for the little issue (RFC-wise and implementation-wise), and
> also using this dummy placeholder [EAI-DUMMY] in the original <email> XML
> element (while I know that this has been done before). For a non-supporting
> registrar the latter is probably similarly confusing as an updated RFC 5733.
> Well, you could argue that the registry can distinguish supporting and non-
> supporting clients upon extensions specified at the login and behave
> differently. And here comes my proposal:
>
> As the original email XML element could transport the internationalized e-
> mail address XML schema-wise, as mentioned before, why not reduce the
> whole extension to a single extension URI without any real EPP extension in
> the <extension> section? No schema, no extra data. The presence in the
> login would simply indicate: "yes, I can deal with internationalized e-mail
> addresses in the <email> element in the contact object", like a flag. Well, I
> know that would be a novel way of using extensions, but it would reduce the
> implementation effort a lot on the other hand.

It could certainly be done that way, Klaus. An extension doesn’t have to require a lot of overhead if there's a simpler way to make it work.

Scott