Subject: Re: [regext] Internationalized Email Addresses and EPP

From: Klaus Malorny <[email-masked]>
Date: Thu, 19 Nov 2020 16:20:40 +0100

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.

Regards,

Klaus

[1] https://tools.ietf.org/html/draft-belyavskiy-epp-eai-01

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 19 Nov 2020 16:00:27 +0000

> -----Original Message-----
> From: Klaus Malorny <[email-masked]>
> Sent: Thursday, November 19, 2020 10:21 AM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]
> 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

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 23 Nov 2020 12:10:38 -0500

> implementation-wise), and also using this dummy placeholder [EAI-DUMMY] 

Using such kind of placeholder, like it was done for login-security
seems to me just a poor way to try doing basically whatever XML namespaces
are trying to do without doing it properly.

I sincerely do not hope this is the way things are going
(speaking as an implementer of multiple EPP servers and clients).

-- 
  Patrick Mevzek
  [email-masked]