[At-Large] UA Days

Andrei Kolesnikov andrei at rol.ru
Mon Apr 1 14:01:53 UTC 2024


Evan, IDNs are good for outdoor, TV and radio ads. Also search engines
handle IDN pretty well. It means good business for domain sellers, brands
and SMEs.
End users, especially in developing countries, carry their smartphones with
helpful apps (multiple reports available). They might not know what the
domain name is. Should they? )

--andrei

On Mon, Apr 1, 2024 at 1:11 PM Evan Leibovitch via At-Large <
at-large at atlarge-lists.icann.org> wrote:

> I have long maintained that UA is little more than a poorly executed
> marketing campaign, created to address ICANN's impotence at enforcing its
> decisions outside its bubble. Nothing in this discussion challenges that
> view.
>
> The ALAC take on this issue is rather focused, or at least it ought to be.
> We need to take the point of view of the Internet consumer whose point of
> entry (for the purposes of explicitly typing domain memorable names in any
> language) is almost always browsers or mobile apps.
>
> IDNs may indeed provide value to people who wish to use them to reach
> Internet destinations in their own language. But I'm still wary of any
> great effort to push them out to an Internet world that may neither want
> nor need them anymore. At most they are an add-on rather than necessity,
> since existing global Internet destinations (and the people who seek them)
> have had to figure out other ways so far (like the use of all-numeric
> domain names or QR codes). IDNs could have been world-changing a decade or
> more ago, now they're just late to the game and most of the world has moved
> on. Since it has no treaty or other enforcement mechanism, ICANN now has to
> rely on promotion. And UA days, nights, weeks and months of talking to
> ourselves are not going to do it.
>
> Social coercion? Really? That's just an unfunny joke. Is the plan to SHAME
> people into using IDNs? Good luck with that.
>
> That any within the ICANN community consider outreach to browser makers to
> be out of scope is just astounding; they are EXACTLY the entities most
> needed onboard if there are to be IDN buyers as well as sellers. In the
> absence of such outreach, browser makers aren't moving because browser
> USERS aren't asking for it; many other demands such as speed and security,
> ease-of-use and now AI assistants take priority. That's the problem with
> ICANN's IDN development process, which has been top-down -- driven by
> domain sellers -- rather than bottom-up, driven by domain users
> (registrants and Internet consumers). It's no surprise that the UASG does
> not consider end-users a pillar. As a result I really don't know if the
> idea has now gone past its expiration date, becoming a solution looking for
> a problem that no longer exists. As AI and NLP and voice recognition find
> their way ever deeper into apps and browsers, IDNs become less necessary to
> end-users by the day. I'm not convinced that the developed world really
> cares about (let alone knows) what the non-developed world really NEEDS,
> but we have this scheme that involves revenue from domain selling so OK!
>
> Having said all this, ALAC's mandate remains to present the PoV of
> end-users -- not domain sellers -- and we can assume that there are at
> least some that might still want IDNs. IMO, in their support, ALAC should
> be calling on ICANN to eliminate the useless and self-serving UA program
> and allocate those resources towards:
>
>    1. Appropriate market research so that we can all honestly determine
>    whether IDNs have enough *end-user* and *registrant* demand to justify
>    additional resources and indeed new IDN registries.
>    2. Explicit outreach and resource support to the developers of app
>    makers and browsers (and any other end-user-facing Internet interfaces)
>    because without them onboard most of the rest is pointless
>    3. IF the market research confirms demand, create a browser/app IDN
>    certification program and promote that to the public, to drive bottom-up
>    demand.
>
> Cheers,
> - Evan
>
> PS: @Alfredo ... given that embedded devices don't need to use
> "memorable" or even human-parsable domain names, I'm not sure how IDNs
> serve IoT at all, indeed their support adds needless complexity when code
> space is minimal. Besides, in its current state ICANN is in no position to
> force anyone (outside of contracted parties) to do anything.
>
> @Roberto, I want to actually hear from those farmers in Bangladesh, not
> anyone pretending to guess their needs. Do they really need IDNs or are we
> just projecting? Are there better solutions? I might suggest that many are
> doing just fine on the Internet of today without IDNs, thanks to search
> engines and other innovations. I had some very eye-opening experiences when
> working a few years at UNHCR, that taught me how how resourceful and
> innovative people can be in the tightest of circumstances. I would not
> presume to know anyone's actual needs without asking them. And tweaked
> Internet domain names are not the only, or even the best, answer to remote
> accessibility challenges.
> _______________________________________________
> 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.



-- 
Andrey Kolesnikov
IOTAS.RU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://atlarge-lists.icann.org/pipermail/at-large/attachments/20240401/4ad80a5a/attachment.html>


More information about the At-Large mailing list