Thanks for the reference to DBOUND. I was unaware of that group. I can understand that this group being evangelists is not the right team to solve these problems. However, noting this is an issue seems also to be less than adequate. As we advocate for EAI and IDNA we need to point out the cons as well as the pros. If the cons are substantial obstacles, we should be advocating for solutions or workarounds, not just noting them. When we promote an IDN and note that by the way this opens the door to multiple malicious IDNs that your users cannot determine belong to you nor whether your IDN is legitimate, any arguments as to the benefits falls away. We should advocate for lowering barriers, not just promoting usage. We should also be advocating safe utilization, not just utilization. In addition to identifying systems that lack support and advocating remediation, we should perhaps have a document identifying other limitations and be seeking their remediation as well. Tex -----Original Message----- From: John Levine [mailto:john.levine@standcore.com] Sent: Wednesday, December 26, 2018 3:03 PM To: Tex Cc: ua-discuss@icann.org Subject: RE: [UA-discuss] More from Ram Mohan on ICANN's further commitment to Universal Acceptance On Tue, 25 Dec 2018, Tex wrote:
Although this thread addresses the structural difficulties of multiple domains serving one organization, the other issue is the difficulty of users verifying that these domains belong to the same owner.
This is another very hard problem, one that the IETF tried and failed to address in the DBOUND working group.
So is this thread really about: Having IDNs make sense as singular domains, but when does it make sense or not make sense to have multiple domains (IDN or otherwise)?
Chanelling Asmus to some degree, identifying the same owner is the same problem regardless of what scripts the domain names might be in. The best one can do now is green bar TLS certificates. Again, this is something that we might note as an issue, not something we should or can try to fix. Regards, John Levine, john.levine@standcore.com Standcore LLC