[At-Large] UA Days

Mon Apr 8 10:03:22 UTC 2024

Dear Evan,

How about something like this? (which was pointed out to me)
https://www.punycoder.com/

Kindest regards,

Olivier

On 04/04/2024 05:45, Bill Jouris via At-Large wrote:
> Hi Evan,
>
> 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.
>
> And I've been arguing, without apparent success, for ICANN to do 
> exactly that.
>
> Bill
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>
>     On Wed, Apr 3, 2024 at 11:27 AM, Evan Leibovitch
>     <evanleibovitch at gmail.com> wrote:
>     Hi Bill,
>
>     On Wed, Apr 3, 2024 at 12:18 PM Bill Jouris <b_jouris at yahoo.com>
>     wrote:
>
>         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.
>
>     - Evan
>
>
>
> _______________________________________________
> At-Large mailing list
> At-Large at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/at-large
>
> At-Large Official Site:http://atlarge.icann.org
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/at-large/attachments/20240408/7ffb90c9/attachment.html>