<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>I tend to agree with Evan that many, perhaps most, of the new
TLDs are not much better than toys to inflate various corporate
egos or speculative dreams.<br>
</p>
<p>However, it is not ICANN's job to dictate what on the Internet is
useful and what is not.</p>
<p>But ICANN can be helpful even when it is not authoritative.</p>
<p>Reading a root zone file published by IANA (operated by ICANN) is
way to tire one's eyeballs.</p>
<p>ICANN could publish a nice Linux/*BSD shell script for makers of
phones, systems, and apps that did the following:</p>
<p> 1. Pulled a copy of the latest IANA root zone file. (Eg a
simple "wget" command)</p>
<p> 2. Parsed the records of that file into a sequence of
<name>:<ipv4-address> or <name>:<ipv6-address
pairs></p>
<p> 3. Iterated through those pairs to perform a set of "dig"
queries using the <name> against the <ipv4-address> or
<ipv6-address> (as appropriate) to evaluate whether there is
indeed an operating name server at the given address that knows
about the purported name. (This could be extended to dig through
the NS records and check whether those servers are also
operational and valid.)</p>
<p>ICANN could then make this script available to makers with a
cover not that asks "Is your list of top level domains complete?
Here's a tool to help you check."</p>
<p>(If I were writing this, I'd do it as a two-level hierarchy of
scripts, the bottom-most would do the dig based name checks given
a sequence of name-address pairs. That would be a tool used by a
higher level script that fetched and parsed a root zone file to
produce the name-address pairs.)</p>
<p>There's additional things that could be evaluated, such as
whether the vendor is properly handling things like DNSSEC, DoH or
DoT, whether connectivity to the name servers works over both IPv4
and IPv6 (this is different than whether the servers and the
vendor's code properly handle IPv4 and IPv6 address queries.)</p>
<p>ICANN could even put this kind of tool into Apps for things like
iPhones and Android phones (and for other platforms) to make it
easier for vendors to run these checks (and for users to check
whether their vendors are testing or being lazy.)<br>
</p>
<p> --karl--<br>
</p>
<div class="moz-cite-prefix">On 9/13/23 7:55 AM, Roberto Gaetano via
At-Large wrote:<br>
</div>
<blockquote type="cite"
cite="mid:F89178E8-ED85-454D-A062-723F0386D78E@gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Folks,
<div class=""><br class="">
</div>
<div class="">While I agree with Evan that most Internet users
don’t know and don’t care about some less used TLDs - in the
same way as most drivers and car buyers don’t know and don’t
care about some less used car brands - I am missing something
about the “problem" that started this thread, i.e.:</div>
<div class=""><br class="">
</div>
<blockquote
style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class=""><b class=""><i class="">Developers of major pieces
of internet software, including the world’s most-popular
messaging app, may be relying on seriously outdated lists
of top-level domains.</i></b></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">There is one single authoritative source of
information, maintained by IANA, that is the root zone file. Why
on earth should ICANN maintain a second one? This fancy tendency
by developers (I can say that, as I have been in that business
for decades) to rely on alternate sources of information and/or
make incorrect assumptions (like assuming that TLDs are max 3
chars long, except for ARPA) is the root cause of most of the
problems.</div>
<div class=""><br class="">
</div>
<div class="">By the way, when we say “One world, one Internet” we
implicitly condemn having alternate or secondary sources of
information about the Internet components.</div>
<div class=""><br class="">
</div>
<div class="">Cheers,</div>
<div class="">Roberto</div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 13.09.2023, at 15:50, Evan Leibovitch via
At-Large <<a
href="mailto:at-large@atlarge-lists.icann.org"
class="moz-txt-link-freetext" moz-do-not-send="true">at-large@atlarge-lists.icann.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394">Can't
say that I'm surprised. Welcome to the totally
predictable consequences of ICANN's:</div>
<ul class="">
<li class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394">Insisting
that it's not a regulator</li>
<li class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394">Making
"global" decisions without weight of international
treaty</li>
<li class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394">Expanding
the gTLD space *well* beyond that which benefits
Internet users.</li>
</ul>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394">At-Large's
most useful activity is to document and publicize the
list of gTLDs unrecognized by the Android library, and
to encourage ICANN to engage with Android developers
to update the library.<br class="">
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394"><br
class="">
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394">It
should be telling that nobody has noticed this problem
that has existed since 2015, and that the news
appeared in an industry news site rather than in the
IT mainstream. That tells me that most Internet
end-users don't know and don't care about these other
domains.</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394"><br
class="">
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394">There's
a lesson here to be learned.<br class="">
</div>
<div class="gmail_default"
style="font-family:tahoma,sans-serif;color:#0b5394"><br
class="" clear="all">
</div>
<div class="">
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr" class="">
<div class="">
<div dir="ltr" class="">
<div dir="ltr" class="">
<div style="text-align:center" class="">
<div style="text-align:left" class="">Evan
Leibovitch, <span
style="font-size:12.8px" class="">Toronto
Canada</span></div>
<div style="text-align:left" class=""><span
style="font-size:12.8px" class="">@evanleibovitch
/ </span><span
style="font-size:12.8px" class="">@el56</span></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br class="">
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Sep 12, 2023
at 10:43 AM Dev Anand Teelucksingh via At-Large <<a
href="mailto:at-large@atlarge-lists.icann.org"
class="moz-txt-link-freetext" moz-do-not-send="true">at-large@atlarge-lists.icann.org</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr" class="">"<b class="">Developers of
major pieces of internet software, including the
world’s most-popular messaging app, may be relying
on seriously outdated lists of top-level domains.</b>
<p class="">That’s the picture that seems to be
emerging from one new gTLD operator’s quest to
discover why WhatsApp doesn’t recognize its TLD,
and many others including major dot-brands, as
valid."</p>
....When most social media apps detect the user has
inputted a URL or domain name, they automatically
“linkify” it so it can be easily clicked or tapped
without the need for copy/paste.<br class="">
<br class="">
But when Rami Schwartz of new gTLD .tube discovered
that .tube URLs sent via WhatsApp, said to have two
billion users, were not being linkified, despite the
TLD being delegated by ICANN almost eight years ago,
he set out to find out why.<br class="">
<br class="">
Schwartz compiled a spreadsheet (.xlsx) listing
which gTLDs are recognized by WhatsApp and which are
not and discovered a rough cut-off point in November
2015. TLDs delegated before then are linkified,
those delegated after were not......This means that,
for example, .microsoft domains linkify but .amazon
and .apple domains do not; .asia domains linkify but
.africa and .arab domains do not; .london works but
.abudhabi doesn’t. Even .verisign missed the
cut-off.<br class="">
<br class="">
If WhatsApp users include a “www.” or “<a class="moz-txt-link-freetext" href="http://”">http://”</a> then
the app will linkify the domain, even if the
specified TLD does not exist.<br class="">
<br class="">
.....During the course of <a
href="https://github.com/publicsuffix/list/issues/1807" rel="noopener"
target="_blank" class="" moz-do-not-send="true">a
discussion</a> on the web site of the Public
Suffix List — which maintains an open-source list of
all TLDs and the levels at which names may be
registered — it was discovered that the problem may
be deeper rooted than the WhatsApp app.
<p class="">It turns out <a
href="https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/core/java/android/util/Patterns.java;l=114"
rel="noopener" target="_blank" class=""
moz-do-not-send="true">a library in the Android
operating system</a> contains a hard-coded list
of valid TLDs which hasn’t been updated since
November 24, 2015" </p>
Read full article : <br class="">
<div class=""><a
href="https://domainincite.com/29054-is-this-why-whatsapp-hates-some-tlds-but-not-others"
target="_blank" class="moz-txt-link-freetext"
moz-do-not-send="true">https://domainincite.com/29054-is-this-why-whatsapp-hates-some-tlds-but-not-others</a></div>
<div class=""><br class="">
<br class="">
</div>
<div class="">Regards,<br class="">
<br class="">
</div>
<div class="">Dev Anand Teelucksingh<br class="">
</div>
</div>
_______________________________________________<br
class="">
At-Large mailing list<br class="">
<a href="mailto:At-Large@atlarge-lists.icann.org"
target="_blank" class="moz-txt-link-freetext"
moz-do-not-send="true">At-Large@atlarge-lists.icann.org</a><br
class="">
<a
href="https://atlarge-lists.icann.org/mailman/listinfo/at-large"
rel="noreferrer" target="_blank"
class="moz-txt-link-freetext" moz-do-not-send="true">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br
class="">
<br class="">
At-Large Official Site: <a
href="http://atlarge.icann.org/" rel="noreferrer"
target="_blank" class="moz-txt-link-freetext"
moz-do-not-send="true">http://atlarge.icann.org</a><br
class="">
_______________________________________________<br
class="">
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 (<a
href="https://www.icann.org/privacy/policy"
rel="noreferrer" target="_blank"
class="moz-txt-link-freetext" moz-do-not-send="true">https://www.icann.org/privacy/policy</a>)
and the website Terms of Service (<a
href="https://www.icann.org/privacy/tos"
rel="noreferrer" target="_blank"
class="moz-txt-link-freetext" moz-do-not-send="true">https://www.icann.org/privacy/tos</a>).
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.</blockquote>
</div>
_______________________________________________<br
class="">
At-Large mailing list<br class="">
<a href="mailto:At-Large@atlarge-lists.icann.org"
class="moz-txt-link-freetext" moz-do-not-send="true">At-Large@atlarge-lists.icann.org</a><br
class="">
<a class="moz-txt-link-freetext" href="https://atlarge-lists.icann.org/mailman/listinfo/at-large">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a><br
class="">
<br class="">
At-Large Official Site: <a class="moz-txt-link-freetext" href="http://atlarge.icann.org">http://atlarge.icann.org</a><br
class="">
_______________________________________________<br
class="">
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 (<a class="moz-txt-link-freetext" href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and
the website Terms of Service
(<a class="moz-txt-link-freetext" href="https://www.icann.org/privacy/tos">https://www.icann.org/privacy/tos</a>). 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.</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
At-Large mailing list
<a class="moz-txt-link-abbreviated" href="mailto:At-Large@atlarge-lists.icann.org">At-Large@atlarge-lists.icann.org</a>
<a class="moz-txt-link-freetext" href="https://atlarge-lists.icann.org/mailman/listinfo/at-large">https://atlarge-lists.icann.org/mailman/listinfo/at-large</a>
At-Large Official Site: <a class="moz-txt-link-freetext" href="http://atlarge.icann.org">http://atlarge.icann.org</a>
_______________________________________________
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 (<a class="moz-txt-link-freetext" href="https://www.icann.org/privacy/policy">https://www.icann.org/privacy/policy</a>) and the website Terms of Service (<a class="moz-txt-link-freetext" href="https://www.icann.org/privacy/tos">https://www.icann.org/privacy/tos</a>). 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.</pre>
</blockquote>
</body>
</html>