It seems to me that the
function of UA day is inherently NOT
directed at end users. It is directed at
getting vendors, those who provide software
interfaces for end users, to make provision
for IDNs.
Is it really
directed at apps developers?
Consider that
some of the apps in play are open source. ICANN
could simply contribute code to Mozilla,
Thunderbird, Wordpress, Signal and other
projects to make their IDN support seamless. If
that support is an in-demand feature it will
make those applications more desirable in a
competitive environment.
End users are, of course,
wildly unlikely to be writing their own
browsers, email systems, etc., so they don't
really need to be involved.
People aren't
writing browsers, email systems, etc. to satisfy
the needs of ICANN, they're trying to meet the
needs of end-users. So if end users don't care
about IDNs, neither will apps developers, since
they have other priorities such as speed,
security, and end-user focused
features such as VPNs, form auto-completion,
spell-checkers, incognito modes and so on.
(Except to the extend that it
would be useful to show some user demand
when trying to convince vendors to become
IDN compatible.)
End-user
demand for IDNs isn't "useful", it's a mandatory
prerequisite. Without such bottom-up demand, app
developers have no incentive to divert
resources. In the service of i18n developers
place far more emphasis on Unicode support,
multilingual UI and multilingual integrated
search engines. If these features satisfy
end-user needs then there is no reason for them
to spend extra effort on IDNs. Developers may
well see IDNs as just a way for ICANN and its
contractors to peddle more domains, and without
end-user interest they have no incentive to
facilitate that.
One must again
remind that ICANN is not a treaty-backed
organization. It has no means to impose, let alone
enforce, its decisions on the world. Its solutions
must be superior and desired. Thus, so
long as end-user demand is not seen as a necessary
component in advancing IDNs, they will remain a
non-priority to developers and an avoidable risk
to would-be IDN registrants.
(Aside: I truly
find it amazing that this argument even needs to
be made within the community tasked with advancing
end-user interests within ICANN.)
Making end users aware of the
option to use non-ASCII characters for these
is, to my mind, an entirely separate
discussion.
If so, that
"separate discussion" is the only one worth
having within ICANN At-Large. Other
constituencies (civil society, governments, the
technical community, etc) all have their own
places to define and assert their own needs.
Both whether it is a worthwhile
effort and how to go about it if so. It is
also something that would really need to be
deferred until something like Universal
Acceptance is available on at least the most
widespread browsers and email systems.
Chicken and
egg.
If end-users
don't care about IDNs, browsers and apps won't
support them.
If browsers
and apps don't support IDNs, end-users won't
care about them.
BTW, the
objective is not for browsers to implement "UA".
Support for
IDNs is the solution being pitched, UA is just
the name of the marketing campaign.
Pitching to end users, when
the software they use does not yet support
IDNs, would be counterproductive.
And THAT is
why, 20 years from now, ICANN will still be
wondering why IDNs never caught on.