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

From: "Gould, James" <[email-masked]>
Date: Thu, 19 Nov 2020 15:37:12 +0000

Klaus,

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:

  1.  Placeholder Text and a New Email Element – This matches https://tools.ietf.org/html/draft-belyavskiy-epp-eai-01 that includes the use of placeholder text and an extra email element in an extension.  This would include the namespace URI in the greeting and login services like any other EPP extension.
  2.  Implicit Replacement Based on Login Services – Inclusion of the namespace URI in the greeting and login services indicate support for EAI addresses implicitly.  This would be treated similar to an EPP extension with the namespace URI in the greeting and login services.
  3.  Replacement Marker Element – Use of an empty marker extension as an implicit indication of support for EAI addresses on a per object-level (e.g., contact, organization, or other EPP objects). This would include the namespace URI in the greeting and login services like any other EPP extension.

It sounds like you’re proposing the use of the second option.  I believe that inclusion in only the greeting and logic services is too course grain, since the registry systems can support many TLDs and many EPP objects, each with different levels of support for EAI addresses.  Option 3 would be a lighter weight method that is an object-level indicator and option 1 would be the most explicit to indicate which email element is replaced by use of the placeholder text with the extension email element.  The use of email addresses apply to multiple EPP RFCs (RFC 5733, RFC 8543) and to at least one non-RFC EPP extension registered in the EPP Extension Registry (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml).

--

JG

James Gould

Fellow Engineer

[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271

12061 Bluemont Way

Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 11/19/20, 10:20 AM, "regext on behalf of Klaus Malorny" <[email-masked] on behalf of [email-masked]> wrote:

    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://secure-web.cisco.com/1eSK9wecykl6SY5-nP9QWJmD_sBwN8xHmPwuhDy8P3qDoWGHFh3iYxpmxiQD_0tS1Q-mhyLJrye0W5StyBEhY2CZvkE2rz4hhNpzrfPQxdzkBb1z_M20VSrzr7izEilx_FsSNF6TuH1KfLrS1gQTy7UxsWP1xigU9dFe0uNekRDUvf0t3LA7gJRJSpMxwY7Q9HtwoKUh7fjcU7kWcGDFwn7BwOoEUQx-TvJrPD19EgQ0UVHcR7B9uv08-yXwrkoJWIdKhq2Y-8egnR0IeB80JDdiJPpcFpoo-QxrbEbU08NM/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-belyavskiy-epp-eai-01

    _______________________________________________

    regext mailing list

    [email-masked]

    https://secure-web.cisco.com/1-niXPoyAQkNoqJO8euNQWKTc_FepY-88-sGPEYrl-ABochx3Hcq8aIDVMq3yh3qLEXtK4ajzPX_fUs8dvbs4A0g10dcHmvMhRAl2ecqw5ABa4zveZ4GvM0ApXz0sQ_rjCSnE0CD4dbEQB8hDm-rjnCw4QbkocFxym1WTF8tMXrx6DqaS4lfO078yBWxAXcILxZQh0xj7MYFbWYeBodcIe6J3VpzTtOTGWVci2OW96aAxL3aiQP-Lx1EWkAstSEonN0QoW9rGTWmDs2UPyB-TVHx70HQY-ARUvTXaUHG6bvo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: Klaus Malorny <[email-masked]>
Date: Thu, 19 Nov 2020 17:55:57 +0100

On 19.11.20 16:37, Gould, James wrote:
> [...]

>  2. Implicit Replacement Based on Login Services – Inclusion of the
>     namespace URI in the greeting and login services indicate support
>     for EAI addresses implicitly.  This would be treated similar to an
>     EPP extension with the namespace URI in the greeting and login services.
> [...]

> It sounds like you’re proposing the use of the second option.  I believe 
> that inclusion in only the greeting and logic services is too course 
> grain, since the registry systems can support many TLDs and many EPP 
> objects, each with different levels of support for EAI addresses.  
> Option 3 would be a lighter weight method that is an object-level 
> indicator and option 1 would be the most explicit to indicate which 
> email element is replaced by use of the placeholder text with the 
> extension email element. The use of email addresses apply to multiple 
> EPP RFCs (RFC 5733, RFC 8543) and to at least one non-RFC EPP extension 
> registered in the EPP Extension Registry 
> (https://www.iana.org/assignments/epp-extensions/epp-extensions.xhtml).
> 

Hi James,

you are right, my proposal matches option 2. I didn't know that this was 
discussed already. In respect to option 3 I really think that if EAI 
support shall be specific to object types then it would be better to 
release updated specifications of these objects, maybe with new URIs if 
necessary. This would be my general preference, as I noted in my 
previous e-mail.

Having extensions that influence the interpretation of certain elements 
in objects or other extensions has the problem that it increases the 
complexity over time, makes it less understandable and makes it more 
difficult to get rid of old stuff. The DNSSEC extensions (1.0 and 1.1) 
are a good counter example for how it should work. I guess that nowadays 
no active EPP server or client is unable to use version 1.1, thus 1.0 
support could be theoretically removed from the implementations.

Maybe one could find additional improvements to the contact object to 
justify an update. For example, fixing the disclosure settings. While 
their use have become questionable in the context of data protection 
regulations like the GDPR anyway, they have the slight design problem 
that one cannot set and remove specific disclosure settings at the same 
time. Or one could consider to add a language field, which could be 
helpful when sending e-mails to registrants, e.g. WDRP e-mails, transfer 
related e-mails. Maybe there are other aspects with which registrars, 
resellers and end users are unhappy.

Regards,

Klaus

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 23 Nov 2020 07:04:01 +0100

Jumping into this discussion quite late, but...

> 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.

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!

best,
Alex

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 23 Nov 2020 13:59:24 +0000

> -----Original Message-----
> From: Alexander Mayrhofer <[email-masked]>
> Sent: Monday, November 23, 2020 1:04 AM
> To: Gould, James <[email-masked]>
> Cc: [email-masked]; Hollenbeck, Scott
> <[email-masked]>; [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.
>
> > 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:
>
> - 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.
> 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!)
> - 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.

> 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

---

From: "Matthias Pfeifer" <[email-masked]>
Date: Mon, 23 Nov 2020 15:31:18 +0100

Hello

> > 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.
> >
> > three extension options, which all include an namespace URI in the
> > greeting and logic services:
> >
citizens".
> 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?

> > would perfectly understand EAIs?). Does sound like a failed opportunity
to
> me!

Best, Matthias

> https://www.ietf.org/mailman/listinfo/regext

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 23 Nov 2020 18:00:14 +0300

Dear Scott,

On Mon, Nov 23, 2020 at 4:59 PM Hollenbeck, Scott <shollenbeck=
[email-masked]> wrote:

> click links
> policy, it
> 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.

> unwittingly

-- 
SY, Dmitry Belyavsky

---

From: Taras Heichenko <[email-masked]>
Date: Mon, 23 Nov 2020 20:46:19 +0200

Hi!

> On 23 Nov 2020, at 17:00, Dmitry Belyavsky <[email-masked]> wrote:
> 
> Dear Scott,
> 

[skip]

> 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_. 

There are cases when registry cannot enforce registrars to implement some features. But I see no problem in the registry response with EAI. EPP works with UTF-8
encoding so EAI should not cause the EPP interface crash. Such email can cause strange symbols in the web interface but as for me it should not bring serious problems.

--
Taras Heichenko
[email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 23 Nov 2020 20:07:45 +0000

> From: Taras Heichenko <[email-masked]>
> Sent: Monday, November 23, 2020 1:46 PM
> To: Dmitry Belyavsky <[email-masked]>
> Cc: Hollenbeck, Scott <[email-masked]>;
> [email-masked]; [email-masked]; Gould, James
> <[email-masked]>; [email-masked]
> > This may be the path of least resistance. I'm still trying to think through hat
> registrar that doesn't expect one. This could happen after a domain transfer,
> registrars will have to do it. They should deal with the clients with such emails
> _somehow_.
> There are cases when registry cannot enforce registrars to implement some
> features. But I see no problem in the registry response with EAI. EPP works
> with UTF-8 encoding so EAI should not cause the EPP interface crash. Such
> email can cause strange symbols in the web interface but as for me it should
> not bring serious problems.

That's only true if you're not also doing syntax checking of the local part outside of what your XML parser is doing with the schema. A regular expression to match an ascii-only local part would NOT match an internationalized email address.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 23 Nov 2020 20:10:26 +0000

From: Dmitry Belyavsky <[email-masked]>
Sent: Monday, November 23, 2020 10:00 AM
To: Hollenbeck, Scott <[email-masked]>
Cc: [email-masked]; Gould, James <[email-masked]>; [email-masked]; [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.

Dear Scott,

On Mon, Nov 23, 2020 at 4:59 PM Hollenbeck, Scott <shollenbeck=[email-masked]<mailto:[email-masked]>> wrote:

   > From: Alexander Mayrhofer <[email-masked]<mailto:[email-masked]>>
   > To: Gould, James <[email-masked]<mailto:[email-masked]>>
   > Cc: [email-masked]<mailto:[email-masked]>; Hollenbeck, Scott
   > <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
   > <jgould=[email-masked]<mailto:[email-masked]>> wrote:
   >

   [SAH] I’m not talking about rejecting a transfer. I’m talking about what a registrar that does not support EAI would/should do if it is the receiving registrar of a domain that includes contacts using internationalized email addresses and those addresses aren’t supported by the registrar. How should this work?

   Scott

---

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

On Mon, Nov 23, 2020, at 10:00, Dmitry Belyavsky wrote:
> 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_. 

Why do we want to design protocols that have the unfortunate consequence
of forcing things like that (that are fine on the paper, but just do not fly
at all in real life) while at the same time believing there is a need
to address the case of "unhandled namespaces" which problem could also be
solved by just saying "registry forces namespaces X, Y, Z and registrars 
have to deal with them somehow"?

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 23 Nov 2020 15:17:02 -0500

On Mon, Nov 23, 2020, at 08:59, Hollenbeck, Scott wrote:
> 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.

It may not be a problem in real life, but probably difficult to completely
exclude it if we want to make sure the protocol is adapted to all registries' cases
out there.

There may be a majority (I can't give numbers of course so treat it as an
assumption) of cases where registrars do the following:
- do the transfer
- upon success, create new contacts
- update domain with new contacts

Whatever case the previous contacts were is then irrelevant for that registrar.

The above case solves multiple problems for registrars (retrieving data out of current contacts can be a problem), and creates a new one
for registry (explosion of unused contacts, as to solve privacy and association
issues registries typically copy contacts upon transfer, so that contacts with
the same data can now be in new registrar's portfolio of objects).

Note that some registries do solve it differently:
the registrar HAS TO provide the new contact IDs at transfer time,
ie a transfer can not start before the registrar created its own contacts and
associate them with the domain at transfer time.

Due to laws like GDPR, maybe this case makes more sense, but part of
this space is also more policy than protocol.
I would have been happy (but I do not hold my breadth) if there would have
been a singular extension or design that would permit any policy such as:
- transfer with copy of contacts
- transfer except if contacts can not be transfered at the same time (if they
are used by multiple domains; it won't be something new, host objects are
automatically transferred already)
- transfer and set new contacts (either full set provided or only the one to change,
I don't know).

-- 
  Patrick Mevzek
  [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 23 Nov 2020 15:55:03 -0500

In article <[email-masked]> you write:
>   [SAH] I’m not talking about rejecting a transfer. I’m talking about what a registrar that does not support EAI would/should do if
>it is the receiving registrar of a domain that includes contacts using internationalized email addresses and those addresses aren’t
>supported by the registrar. How should this work?

Reject the transfer -- you get what you pay for.

Transfers only happen when a registrant asks for them. If registrars
find that they're losing customers due to inability to handle EAI
addresses, they can decide that it's an acceptable cost or they can
upgrade their software, either to handle EAI, or to ask the registrant
to change her e-mail address to an ASCII one and try again.

R's,
John

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 23 Nov 2020 22:05:22 +0100

On Mon, 23 Nov 2020, 21:55 John Levine, <[email-masked]> wrote:

> >   [SAH] I’m not talking about rejecting a transfer. I’m talking about
> what a registrar that does not support EAI would/should do if
> >it is the receiving registrar of a domain that includes contacts using
> internationalized email addresses and those addresses aren’t

If I remember correctly, there is a closed list of reasons to reject the
transfer for the gTLDs. CCTLDs may establish any rules they want.

---

From: Taras Heichenko <[email-masked]>
Date: Mon, 23 Nov 2020 23:33:36 +0200

> On 23 Nov 2020, at 22:07, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> 

Usually, software developers use libraries (libxml2 usually) to parse XML. If the XML
contains encoding=utf-8 in its header it would be instruction for the parser to use utf-8
encoding. Of course, further checking will give an error if we try to parse data returned
from a registry. But I see no reason to parse this data – we should show what we got 
from the registry. (Of course, it does not mean that this is impossible.)

--
Taras Heichenko
[email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 23 Nov 2020 16:34:34 -0500

On Mon, Nov 23, 2020, at 16:05, Dmitry Belyavsky wrote:

> If I remember correctly, there is a closed list of reasons to reject 
> the transfer for the gTLDs.

Correct but that is for the outgoing (current) registrar not for the prospective
(new) one. Current one has no reason to reject things if only because the new
one can not handle something.

-- 
  Patrick Mevzek
  [email-masked]

---

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

> to change her e-mail address to an ASCII one and try again.

A bit harsh/unrealistic: the new registrar may have 0 way to know, before
the transfer succeeds that it has this problem to handle.

Because:
- contact:info commands can be refused by registry on contacts not owned
(so new registrar can not see email addresses of current contacts owned by current
registrar), or the result be filtered
- data may not show at all in whois/RDAP

Hence what will happen:
- the registrar starts the transfer
- it succeeds after some time
- NOW and only NOW can he by surprise discover he has a problem if
he tries to synchronize the contact data from registry to its own systems.
(he won't have problems if he just creates new contacts and update the domain,
as many/some/the majority of registrar do).

That defeats the "do not surprise" law and creates harm for no reason.

Either the registry has to mandate outside of protocol (ex: technical accreditation
test) that every registrar knows how to handle any possible email address, including
EAI case, OR there should be a way for a registrar to dynamically signal the registry
it wants/do not want to handle this case, OR the registry has to provide something
that is forward compatible (hence: 1) not breaking current software but 2) allows
updated software to enjoy more features)

-- 
  Patrick Mevzek
  [email-masked]

---

From: Taras Heichenko <[email-masked]>
Date: Mon, 23 Nov 2020 23:45:18 +0200

> On 23 Nov 2020, at 22:55, John Levine <[email-masked]> wrote:
> 

As for me, this is the right point of view. The registrant has a non-ASCII address.
What will he/she/it do with a registrar that does not support such addresses? Will the
registrant make a new ASCII email just to be with the new registrar?

--
Taras Heichenko
[email-masked]

---

From: Taras Heichenko <[email-masked]>
Date: Mon, 23 Nov 2020 23:50:43 +0200

> On 23 Nov 2020, at 23:39, Patrick Mevzek <[email-masked]> wrote:
> 
> 
> 

Just a question: How can a registrar accept the transfer of a domain by a user if it does
not check that this domain is owned by this user?
This is a direct way to the fraud.

--
Taras Heichenko
[email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 23 Nov 2020 16:55:33 -0500

> not check that this domain is owned by this user?

You may want to look at <domain:authInfo> ...

This is completely orthogonal to anything related to email addresses.
Long gone are the days when only an email sent was enough to trigger a transfer,
and for good reasons.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Taras Heichenko <[email-masked]>
Date: Tue, 24 Nov 2020 01:12:33 +0200

> On 23 Nov 2020, at 23:55, Patrick Mevzek <[email-masked]> wrote:
> 
> 
> 

I said nothing about only an email address but complete contact information. Most
of our registrars were checking an entire Contact object to identify the user requesting
a transfer to avoid court. From their point of view, the only password for a domain does
not provide enough protection to a domain transfer. I know that there are other ways of
transfer. You may want to look at different registrar's agreements...

--
Taras Heichenko
[email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 23 Nov 2020 18:26:03 -0500

On Mon, Nov 23, 2020, at 18:12, Taras Heichenko wrote:
> a transfer to avoid court. 

I fail to see how this authenticates anything
(and to be able to do this any registrar needs to be allowed to do contact:info
on any contact, with a transfer in the future or not, which is surely a privacy
problem at least, or the data must be public in whois/RDAP which is another privacy
issue also, besides the fact that in this case anyone can just impersonate anyone
else by reading the output in this model), but in all cases this is completely
irrelevant to the discussion in this thread so no real point discussing one specific
registry policy around transfers, yes they are many out there, none to my knowledge
relying only on email value being known/available to reply.

If registrars want to compare contact data before even staging a transfer request,
and can per registry procedures/policies in which they operate,
then there is no problem regarding EAI: if the customer gives an "internationalized" email
to the registrar, and the registrar does not handle it, the problem will not be solved
by anything done at the EPP level, so is completely out of scope here.
The registrar will have to fix its systems first, and we are back to Mr. Levine point.
Which is fine if registries want to do that, understanding that in that case some
registrars may decide not to sell their TLDs, which can be fine or not, but a problem
for the registry to decide and for which this protocol called EPP can not do anything.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Taras Heichenko <[email-masked]>
Date: Tue, 24 Nov 2020 09:19:03 +0200

> On 24 Nov 2020, at 01:26, Patrick Mevzek <[email-masked]> wrote:
> 
> 
> 

Two notes:
- the authinfo field in a Contact object allows opening personal data to only one registrar
- it is not registry policy, it is the registrar's agreement

> for the registry to decide and for which this protocol called EPP can not do anything.

I just wanted to say that if a registrar cannot handle the internationalised email of new
customer it will lose new customers and this situation force it to fix its EPP.

--
Taras Heichenko
[email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 24 Nov 2020 09:38:50 -0500

> - the authinfo field in a Contact object allows opening personal data 

So... domain:authInfo is not good enough to authenticate the owner to do the transfer...
but contact:authInfo is good enough to retrieve contact data and then authenticate the owner
to do the transfer.

"Interesting". 2 authInfo but seemingly one has more "power" than the other.

Also:
"to only one registrar": no, to any registrar having this token. Exactly like
domain:authInfo allowing transfer to any registrar having it.

> - it is not registry policy, it is the registrar's agreement

[..]

> customer it will lose new customers and this situation force it to fix 

So then why should a registry force anything? We are back at the fact
that registrars wanting to support that scenario will indeed need to put
resources for it, and hence if there is an EPP extension to support that
they will implement it.
The question is how to do it in a smart way to not disrupt all other
registrars NOT wanting to support this scenario.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 24 Nov 2020 15:27:57 +0000

> From: regext <[email-masked]> On Behalf Of Patrick Mevzek
> Sent: Tuesday, November 24, 2020 9:39 AM
> To: [email-masked]

[snip]

> > I just wanted to say that if a registrar cannot handle the
> > internationalised email of new customer it will lose new customers and
> > this situation force it to fix its EPP.
>
> So then why should a registry force anything? We are back at the fact that
> registrars wanting to support that scenario will indeed need to put 
> resources
> for it, and hence if there is an EPP extension to support that they will
> implement it.

This is a very important point. It's not just about how much work it takes the 
registry operator to do something, we also have to think about client impact. 
A change to the core protocol affects all clients and servers, whereas an 
extension affects only those clients and servers that choose to implement and 
support it.

Scott

---

From: Taras Heichenko <[email-masked]>
Date: Tue, 24 Nov 2020 19:35:04 +0200

> On 24 Nov 2020, at 16:38, Patrick Mevzek <[email-masked]> wrote:
> 
> 
> 

If you steal a domain password you get control over the domain. If you steal the contact
password it does not give you the ability to change contact but just to see it. And registrant
must approve that he/she/it is in the Contact object. Just if you wonder how it works.

> "Interesting". 2 authInfo but seemingly one has more "power" than the other.

Yes. They also have different power by influence.

> domain:authInfo allowing transfer to any registrar having it.

Domain owner if it wants to transfer the domain, requests token from current registrar
then goes with this token to a future registrar, approves that it is in the Contact object of
the domain and then new registrar requests transfer. Do you think it too complicated? Or
protection by a domain password that may be sent by email is equal to this one? And I must
say this schema was made by the registrar's request. And this way is not mandatory the
responsibility for the transfer is entirely on the registrars.

Looks like we are now far away from the start topic of the thread.

>> internationalised email of new

First of all, registry does not force anything. It gives the possibility that registrars
can use. But if there are users that want to use non-ASCII email then registrars
and registries should give the ability to use such addresses to the users. (At least
if we say about universal acceptance). So whether EAI would be implemented by
extension or in the main <email> field it will bring all registrars to the EAI implementation.

--
Taras Heichenko
[email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 24 Nov 2020 12:56:39 -0500

On Tue, Nov 24, 2020, at 12:35, Taras Heichenko wrote:
> can use. 

... which then forces all other registrars to have to support that possibility,
except if the registry offers a way for registrars not wanting it to be able
to opt-out from it.
A registry is a shared data storage, in one simplified view. If registrar X
has the "possibility" to enter data there that registrar Y has no way to handle,
this means pretty much everyone is forced to upgrade in order to handle the new data.
Or just stop using that shared datastore.

Again, I think the purpose is to find a solution that could work
for any registry (so trying not to just create things for the benefit
of a sole actor, even if that happens too often to my taste), and any registrar,
including those that do not want to support that new feature, even if you personally
believe that all registrars should support it.

We can talk endlessly about a specific registry and a specific problem.
But I guess that if ones wants to have something akin to an RFC at least some
work is needed to include other actors in the play even if finally the specification
won't be used by more than one actor. Otherwise it can just be published as an I-D
or Informational RFC I guess, for just notification, and there is a little for the
working group to discuss (if the initial specification is not open to changes).

> But if there are users that want to use non-ASCII email then 
> registrars

That "either" might need only a couple of electrons in an email, but both options need
a non trivial amount of work: either designing a proper extension (without plays
on placeholders or things like that), or just doing "EPP v2" if you want to change
the "email" definition, and then good luck to make everyone switch to that.
(and if there is anytime a work towards EPP v2 there are other problems far
more pressing to fix there than just email).

> "it will bring all registrars to the EAI implementation."

I will let you believe that then, but 1) the IETF is not the protocol or policy police
even if the perfect solution is designed there is no guarantee anyone will use it
and 2) a non technical problem can not be solved by a technical solution, no matter what
you will do here, each registrar has its own business case and can decide, from its
own point of view, if he wants to do that or not (and hence go up to not carrying the
TLD at all if there is no other solution). Which means that the registry has
to force by non technical means (aka: contracts) if it wants that behavior
(exactly like ICANN contracts mandates implementation of specific RFCs by registries
and registrars) or offer proper solutions for registrars not wanting to do it.
We can discuss here only the second part, if there is a change in current specifications
that allows nicely registrars wanting the feature and registrars not wanting the feature
to continue to work.

(also, you might be slightly forgetting the "transition" period. Even if registry X
says "ok in 6 months all email is EAI compatible, go fix your systems dear registrars",
and no matter what delay you give, it will be too short for some)

Look at DNSSEC and IPv6 for similar cases of "but everyone should be doing that,
it is even mandated by contracts" vs the sore reality of "yeah it kinda works at
some places but certainly not everywhere".

I think it is better to stick to proposal and see how they work.
Another options is to first document the problem and constraints space, and then
in a separate document offer a solution.
Making everyone first agreeing exactly on what problems need to be solved
can frame discussions efficiently.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Taras Heichenko <[email-masked]>
Date: Tue, 24 Nov 2020 20:57:15 +0200

> On 24 Nov 2020, at 19:56, Patrick Mevzek <[email-masked]> wrote:
> 

You ask strange questions. There are DB with data that my interface does not support.
How can I work with the DB under such circumstances? Really I do not have an answer
to this question. It looks like "I wand use email but I do not want my software to correspond
RFC 5322. What should I do?"

> and

I know what is IETF. But I dislike the approach: we made some standard from our
heads and now you can do with it whatever you want. And I saw here thoughts that
differ from yours from the people that are working in this area. What are we going to do?

Maybe it is too early to adopt such a standard and we should wait until usage of non-ASCII
email on the Internet would be more defined.

From my point of view, the extension does not give any advantages. It makes the protocol
more complicated and gives nothing back.

> 2) a non technical problem can not be solved by a technical solution, no matter what

--
Taras Heichenko
[email-masked]