Subject: Re: [regext] Use of Internationalized Email Addresses in EPP protocol: placeholder value

From: "Gould, James" <[email-masked]>
Date: Mon, 2 Aug 2021 13:50:54 +0000

Marco,

The issue is associated with a transition state when one side of the connection (registrar or registry) supports EAI while the other does not, the email element is required by the protocol, and the only value available is an EAI address.  The EAI-supporting side can’t pass the EAI value since is known that the other side doesn’t support it based on the EPP greeting or login services.  The proposal in the draft is to pass a predefined placeholder value ([email-masked]<mailto:[email-masked]>) to signal the existence of an EAI value to a non-EAI supporting party, which is temporary until both parties support EAI.  This is a corner case that needs to be considered until both sides support EAI.  Let's consider some specific examples:

  1.  EPP Contact <create> Command (https://datatracker.ietf.org/doc/html/rfc5733#section-3.2.1) – The <contact:email> element is required, which poses an issue when the registrar supports EAI and the registry does not support EAI.  What should the registrar pass to the non-EAI supporting registry?  Collecting an ASCII and EAI email address for this case may be logical, but it’s counter to the goal of supporting EAI, since the registries that the registrar interfaces with can have a mix of EAI support.
  2.  EPP Contact <info> Response (https://datatracker.ietf.org/doc/html/rfc5733#section-3.1.2) - The <contact:email> element is required, which poses an issue when the registry supports EAI and the querying registrar does not support EAI.  The querying registrar could be any registrar and not just the sponsoring registrar, where there is only a single email value in the registry that is an EAI address for this use case.  What should the registry return to the non-EAI supporting registrar?  This case is even more challenging then case #1 since registry has a single value and there can be a mix of EAI supporting querying registrars.  One alternative is to return an error response (e.g., 2308 “data management policy violation”) instead of a successful response with a predefined placeholder value,  but that seems harsh to me.

I believe the use of a predefined placeholder value is the best approach to handle this transition corner case in the protocol, but I would like to hear viable alternates from the working group to incorporate into the draft.

Thanks,

--

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 8/2/21, 9:12 AM, "regext on behalf of InterNetX - Marco Schrieck" <[email-masked] on behalf of [email-masked]> wrote:

    Hi All,

    I am completely with Ulrich.

    >From policy side and also from aspect of clean data. Using dummy values

    in objects was always a bad idea.

    And even in GTLD space, the registrar usually have requirements to

    verify the contacts. So not only registry must support the EAI also the

    registrar have to do it.

    Regards

    Marco

    Am 02.08.21 um 14:47 schrieb Dmitry Belyavsky:

    > Hello Regext,

    > First, many thanks to James for his presentation of the draft update.

    > As it was suggested, let's move the discussion to the ML.

    > As usual with EAI, we have a chicken-and-egg problem. I agree with

    > Ulrich, that using a placeholder instead of a regular address doesn't

    > leave a Registry any option to communicate with a domain administrator

    > via email. But enforcing the domain administrator using a valid ASCII

    > address effectively stops it from moving to EAI. So placeholder is

    > implied to be a temporary measure until EAI is not widely supported. I

    > understand that the support of EAI will be different in different CC

    > TLDs, but I think it's worth supporting such addresses in the GTLDs.

    > I agree that the question is about the intersection of the technical

    > aspects (where it's reasonable to provide the placeholder to make the

    > object created), legal stuff (where the valid address may be required)

    > and policy stuff (that imply the EAI addresses should be treated as just

    > email addresses).

    > --

    > SY, Dmitry Belyavsky

    > _______________________________________________

    > regext mailing list

    > [email-masked]

    > https://secure-web.cisco.com/1knrAJeJSAijatcnZRFL2-q2sa9iAqop6c6aXEBkL5u98WhGqbukYOUR__gp59Q-GPk2aFY1BoKzb6RlNpmY12zqTx4AeARpNRf5ZNCoFRN9Nedd7nMTqIDLZrfj5EITKSKGL_pUoITxWiuxLvHGVhT7Hp_XNuKkpIe9HRifjofrBMrGzk3MoG1Fd6Of8Iw4VRUlKNTt5fmkSfKcfkwApqjGCFzFx86_1QIEGwora_SXwhwOpVIZb1Ter2ZZdWvy0N-TnIZceYeRBalZr7K1nnA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

    _______________________________________________

    regext mailing list

    [email-masked]

    https://secure-web.cisco.com/1knrAJeJSAijatcnZRFL2-q2sa9iAqop6c6aXEBkL5u98WhGqbukYOUR__gp59Q-GPk2aFY1BoKzb6RlNpmY12zqTx4AeARpNRf5ZNCoFRN9Nedd7nMTqIDLZrfj5EITKSKGL_pUoITxWiuxLvHGVhT7Hp_XNuKkpIe9HRifjofrBMrGzk3MoG1Fd6Of8Iw4VRUlKNTt5fmkSfKcfkwApqjGCFzFx86_1QIEGwora_SXwhwOpVIZb1Ter2ZZdWvy0N-TnIZceYeRBalZr7K1nnA/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext

---

From: InterNetX - Marco Schrieck <[email-masked]>
Date: Mon, 2 Aug 2021 16:49:53 +0200

Hi James,

I have an example how such information is used.

For example a system that parse this information before transfer so that
 have a domain with complete contact data.

That system do not get any error and would automatically receive an
valid email. After that the system try to validate the email adress if
email adresse cant get validated maybe the domain get deactivated.

Maybe there are also such process, at registry side.

That remind me a little on the "REDACTED FOR PRIVACY" in whois as email. :)
But here the client parsing was broken, so you can see the errors.

So from my perspective its better to have an no existient value than a
wrong one. And I think clients should be aware of it because we have
also a disclose feature.

So if you have a EAI on registry and client do support it, it should be
empty and maybe add an extension where the real value is.

For the other side, client support EAI and Server not it can only be
prohibited.

Regards
Marco

Am 02.08.21 um 15:50 schrieb Gould, James:
> Marco,
> 
>  
> 
> The issue is associated with a transition state when one side of the
> connection (registrar or registry) supports EAI while the other does
> not, the email element is required by the protocol, and the only value
> available is an EAI address.  The EAI-supporting side can’t pass the EAI
> value since is known that the other side doesn’t support it based on the
> EPP greeting or login services.  The proposal in the draft is to pass a
> predefined placeholder value ([email-masked]
> <mailto:[email-masked]>) to signal the existence of an EAI value
> to a non-EAI supporting party, which is temporary until both parties
> support EAI.  This is a corner case that needs to be considered until
> both sides support EAI.  Let's consider some specific examples:
> 
>  
> 
>  1. EPP Contact <create> Command
>     (https://datatracker.ietf.org/doc/html/rfc5733#section-3.2.1
>     <https://datatracker.ietf.org/doc/html/rfc5733#section-3.2.1>) – The
>     <contact:email> element is required, which poses an issue when the
>     registrar supports EAI and the registry does not support EAI.  What
>     should the registrar pass to the non-EAI supporting registry? 
>     Collecting an ASCII and EAI email address for this case may be
>     logical, but it’s counter to the goal of supporting EAI, since the
>     registries that the registrar interfaces with can have a mix of EAI
>     support.      
>  2. EPP Contact <info> Response
>     (https://datatracker.ietf.org/doc/html/rfc5733#section-3.1.2
>     <https://datatracker.ietf.org/doc/html/rfc5733#section-3.1.2>) - The
>     <contact:email> element is required, which poses an issue when the
>     registry supports EAI and the querying registrar does not support
>     EAI.  The querying registrar could be any registrar and not just the
>     sponsoring registrar, where there is only a single email value in
>     the registry that is an EAI address for this use case.  What should
>     the registry return to the non-EAI supporting registrar?  This case
>     is even more challenging then case #1 since registry has a single
>     value and there can be a mix of EAI supporting querying registrars. 
>     One alternative is to return an error response (e.g., 2308 “data
>     management policy violation”) instead of a successful response with
>     a predefined placeholder value,  but that seems harsh to me.
> 
>  
> 
> I believe the use of a predefined placeholder value is the best approach
> to handle this transition corner case in the protocol, but I would like
> to hear viable alternates from the working group to incorporate into the
> draft.
> 
>  
> 
> Thanks,
> 
>  
> 
> -- 
> 
>  
> 
> JG
> 
>  
> 
>  
> 
>  
> 
> James Gould
> 
> Fellow Engineer
> 
> [email-masked]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>
> 
>  
> 
> 703-948-3271
> 
> 12061 Bluemont Way
> 
> Reston, VA 20190
> 
>  
> 
> On 8/2/21, 9:12 AM, "regext on behalf of InterNetX - Marco Schrieck"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
>  
> 
>     Hi All,
> 
>  
> 
>     >From policy side and also from aspect of clean data. Using dummy values
> 
>     > Hello Regext,
>     >
>     > First, many thanks to James for his presentation of the draft update.
> 
>     > As it was suggested, let's move the discussion to the ML.
> 
>     >
> 
>     > As usual with EAI, we have a chicken-and-egg problem. I agree with
> 
>     > Ulrich, that using a placeholder instead of a regular address doesn't
> 
>     > leave a Registry any option to communicate with a domain administrator
> 
>     > via email. But enforcing the domain administrator using a valid ASCII
> 
>     > address effectively stops it from moving to EAI. So placeholder is
> 
>     > implied to be a temporary measure until EAI is not widely supported. I
> 
>     > understand that the support of EAI will be different in different CC
> 
>     > TLDs, but I think it's worth supporting such addresses in the GTLDs.
> 
>     >
> 
>     > I agree that the question is about the intersection of the technical
> 
>     > aspects (where it's reasonable to provide the placeholder to make the
> 
>     > object created), legal stuff (where the valid address may be required)
> 
>     > and policy stuff (that imply the EAI addresses should be treated
> as just
> 
>     > email addresses).
> 
>     >
> 
>     > --
> 
>     > SY, Dmitry Belyavsky
> 
>     >
> 
>     > _______________________________________________
> 
>     > regext mailing list
> 
>     > [email-masked]
> 
>     >
>     >

Marco Schrieck
Bereichsleiter Entwicklung

-- 
InterNetX GmbH
Johanna-Dachs-Str. 55
93055 Regensburg
Germany

Tel. +49 941 59559-0
Fax  +49 941 59579-050

www.internetx.com
www.facebook.com/InterNetX
www.twitter.com/InterNetX

Geschäftsführer:
Thomas Mörz (CEO), Hakan Ali
Amtsgericht Regensburg, HRB 7142

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Mon, 2 Aug 2021 17:42:23 +0200

Hello,

On 8/2/21 15:50, Gould, James wrote:

>     sponsoring registrar, where there is only a single email value in the
>     registry that is an EAI address for this use case.  What should the
>     registry return to the non-EAI supporting registrar?  This case is
>     even more challenging then case #1 since registry has a single value
>     and there can be a mix of EAI supporting querying registrars.  One
>     alternative is to return an error response (e.g., 2308 “data
>     management policy violation”) instead of a successful response with a
>     predefined placeholder value,  but that seems harsh to me.

It does seem harsh, but it's (in my opinion) the better option than to
return a syntactically valid placeholder value for the e-mail, as that
placeholder value will - for registrars not supporting EAI - most likely
end up being used as the "real" e-mail address for the contact, causing
problems down the line, for example when the registrar tries to send
verification e-mails to the contact for ICANN WAP compliance. These mails
will bounce, which very often goes unnoticed, and domains may be
suspended as a result. In this scenario, it's better to "fail fast", i.e.
let the inquiry of the contact's data fail with the 2308 error, which
will immediately point the registrar to a systemic problem that needs to
be addressed.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: [email-masked]
Germany

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 02 Aug 2021 11:04:25 -0500

On Mon, Aug 2, 2021, at 08:50, Gould, James wrote:
> I believe the use of a predefined placeholder value is the best 
> approach to handle this transition corner case in the protocol, but I 
> would like to hear viable alternates from the working group to 
> incorporate into the draft.

I think I agree with Marco and Ulrich, I was already not happy by us allowing
to use a placeholder value in login-security extension, and for the exact same reason
I am not in favor of using another placeholder like that, no matter what it is or where it is.

Why and what seems better to me?

We use XML, we use XML namespaces and we version them even. What gain do we
have with that if we don't leverage it?
Placeholders are just a symptom of the fact that the current schema are not aligned
with our current needs. This is "normal", EPP is old now, it has to change to adapt
to current real life. Being blocked in old schemas is just technical debt, that we
try to "encapsulate" by now putting "dummy" (another term for placeholder) values
in places where the schema does not fit our needs. This lowers the value of using
a schema in the first place.

Yes, introducing contact-2.0 will be a huge task, but it is to me far better and
fool-proof than using placeholders. We postpone that more and more but we just
delay the inevitable (which could happen to be as well someone deciding to just
redo EPP basically under some current in fashion technologies, aka JSON,
which goal or side effect is exactly to get rid of all schemas and specifications)
or just continue to fuel the fragmentation with many extensions
working around deficiencies or missing pieces that should be in "core" schemas.

Yes, a change like that won't be easy or immediate. Yet, at the same time,
we currently allow to have, to my count, *18* XML namespace versions of the
fee EPP extension (including the final 1.0 one which is far from being the most
used one currently), and again to my count necessarily not exhaustive at least
7 of them are actively used by registries.
Major pains for registrars obviously, yet it shows things work when leveraging
the XML schema versioning, and if we don't then we just enshrine a situation
with as many EPP as they are registries, each one using their own specific extensions,
which makes "core" EPP basically unusable anywhere as is.

Like in all other cases, I think it could help guide the discussion, if registries
and registrars would come forward telling they are interested to implement this
discussed extension or if they do not, why? That would allow to make sure the
extension is designed to cover as many similar cases as possible, to lower
risks of fragmentation.

Also all of this is obviously related to Universal Acceptance, and at least in gTLD
world, ICANN has a specific team/workgroup on that subject.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 2 Aug 2021 19:17:26 +0200

Dear Patrick,

> world, ICANN has a specific team/workgroup on that subject.
Thanks for your letter!
Let me remind you that the 1st version of the draft proposed an update to
basic schemas to indicate that EAI addresses are valid.

I like your proposal about redesigning the client schema, but I'd also
remind that Contact is not the only object having an email attribute.
The proposed solution, with all of its downsides, covers all such objects.
You suggest the solution that will require explicit updating of all the
objects.

I wish that ICANN/Universal Acceptance people would participate in this
discussion.

-- 
SY, Dmitry Belyavsky

---

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 02 Aug 2021 13:40:10 -0500

On Mon, Aug 2, 2021, at 12:17, Dmitry Belyavsky wrote:
> Let me remind you that the 1st version of the draft proposed an update 
> to basic schemas to indicate that EAI addresses are valid.

Yes, but as James stated, the flow went towards the direction of placeholders...

> remind that Contact is not the only object having an email attribute. 

Where do you see one, among RFC 5730, 5731, 5732, 5733?

> The proposed solution, with all of its downsides, covers all such 
> objects. You suggest the solution that will require explicit updating 
> of all the objects.

Yes, as said, not an easy task. Exactly like each time you have technical debt:
you decide to just add more to it, or you decide to repay it.
Adding more placeholder values is just more technical debt and creating more
problems down the line.

> I wish that ICANN/Universal Acceptance people would participate in this 

+1, but also noting of course the issue may be more "pressing"/urgent in case
of some IDN ccTLDs than gTLDs.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Dmitry Belyavsky <[email-masked]>
Date: Mon, 2 Aug 2021 21:10:31 +0200

Dear Patrick,

> Where do you see one, among RFC 5730, 5731, 5732, 5733?

RFC 8543 is not in this list but defines an Organization mapping with email
attribute.

> Adding more placeholder values is just more technical debt and creating

I understand your reasons, but not sure it's exactly the case.

> of some IDN ccTLDs than gTLDs.

The ccTLDs are less limited in their practice and can provide their own
schemas and even protocols.

-- 
SY, Dmitry Belyavsky

---

From: InterNetX - Marco Schrieck <[email-masked]>
Date: Tue, 3 Aug 2021 08:44:13 +0200

Hi Patrick, Dmitry, and all,

I think a new Contact Schema maybe even a new Org Schema are the best
solution.
Maybe not 2.0 only contact-1.1 that indicate only small changes.

It will also goes the normal way in Registry Registrar relation.
Registry announce a change of schemas and Registrar have time to
implement and test it.

Even with placeholders there must be changes in systems when you don't
like to accept any wrong data.

Ciao
Marco

Am 02.08.21 um 21:10 schrieb Dmitry Belyavsky:
> Dear Patrick,
> 
> On Mon, Aug 2, 2021 at 8:40 PM Patrick Mevzek <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> RFC 8543 is not in this list but defines an Organization mapping with
> email attribute.
> 
> https://www.ietf.org/mailman/listinfo/regext
> 

Marco Schrieck

-- 
InterNetX GmbH
Johanna-Dachs-Str. 55
93055 Regensburg
Germany

Tel. +49 941 59559-0
Fax  +49 941 59579-050

www.internetx.com

Geschäftsführer: