<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 4/22/14 1:10 AM, Cary Karp wrote:<br>
</div>
<blockquote cite="mid:535623D8.2080107@karp.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite" style="color: #000000;">
<pre wrap=""><span class="moz-txt-citetags">> </span>... in Abenaki we use several ASCII character sequences
<span class="moz-txt-citetags">> </span>inter-changeably ("ou", "w" and "8") as well as an "u atop o" character
<span class="moz-txt-citetags">> </span>defined in one or more extensions to ASCII, which typewritters with
<span class="moz-txt-citetags">> </span>half-height settings, and the character "8" have accommodated over the
<span class="moz-txt-citetags">> </span>past century, in support of a local (to a zone) semantic, e.g.,
<span class="moz-txt-citetags">> </span>equivalency of two labels, e.g., "ou.example" and "8.example" (or
<span class="moz-txt-citetags">> </span>"wabanaki.example" and "8abanaki.example" and "ouabanaki.example"),
</pre>
</blockquote>
<pre wrap="">Are there similar non-ASCII examples?
</pre>
</blockquote>
<br>
Values assigned outside the ASCII range for the "u-above-o" combined
character in the UTC repertoire areĀ U+0222 and U+0223, reflecting
the casing of Latin Script.<br>
<br>
<blockquote type="cite">
<blockquote type="cite" style="color: #000000;">
<pre wrap="">Obviously, what ICANN gTLD registry operators do is governed by contacts
between they and ICANN, and what ccTLD registry operators is also
governed, in part, by desires for consistency, but below (or outside) of
these namespaces with <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>local<span class="moz-txt-tag">_</span></span> (not pervasive to all levels of the tree)
restrictions on labels, what resolves is a local question -- local in
the sense of both the FQDN, the RRSet associated, and the resolvers to
which query(s) are made.
</pre>
</blockquote>
<pre wrap="">Does this suggest that there are language communities with need to have
such intricacy accommodated on lower levels of the gTLD/ccTLD namespace,
who are willing to forgo the possibility of manifesting their languages
directly in TLD labels?
</pre>
</blockquote>
<br>
Hmm. The cost of access to the IANA root zone for language
communities not associated with an ISO-3166-1 assigned code point is
bounded below by the cost of access to an ICANN new gTLD sales
event, nominally a one-time fee to ICANN on the order of 200,000 USD
with annual recurring fees on the order of a 50,000 USD, in addition
to operational costs serving the language community (zone file
generation and publication), and the transactional cost of providing
policied create and modify access to the underlying database,
associating labels and resources. <br>
<br>
Locating the language community namespace subordinate to any but the
terminal label separator removes the precondition of access, with or
without an ISO-3166-1 assigned code point, and the attendant
one-time and recurring annual fees. Owing to the feature (or defect)
of the algorithm in current use, language communities requiring
scripts which do not have a left-to-right directionality have fewer
existing superior label association choices than language
communities using scripts which have a left-to-right directionality.<br>
<br>
There is in general no one-time fee to access subordinate zones, and
in general the recurring cost of access is four orders of magnitude
less than the recurring ICANN fee, leaving only the operational
costs mentioned above.<br>
<br>
I can't speak for the cost-benefit analysis of others, but for
Modern Chinook, a language I've been working in since September,
with a caseless Latin-based script containing combining characters
(ch, c'h, kw, k'w, qw, q'w, tL, t'L, ts, t's, xw, Xw) (where "L"
indicates a "barred-ell" and "X" indicates "x-with-dot-under"), each
of which functions as a single lexical unit, as well as the rarer
combining characters (dj, dz, zh) which also function as a single
lexical unit, the subject of this thread, with a user community in
the North-Eastern Pacific coastal area, as with the Wabanaki
languages I cited originally (user community in the North-Western
Atlantic coastal area), I can't identify a benefit I think likely to
motivate significant de-allocation of resources from in-community
language programs to an external consumer offering only a label and
significant recurring annual fees and elevated operational cost and
a loss of some aspects of sovereignty.<br>
<br>
In sum, for the two instances of scripts with combining characters
I've recited above, and the difference in cost of access to lower
levels of the namespaces, Cary's suggestion appears to me to be
likely to be shown correct.<br>
<br>
I have to confess I'd no idea ICANN has a VIP program, or that the
[b,c,d,...]name problem space was being addressed by this program.<br>
<br>
ENOCLUE,<br>
Eric<br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</body>
</html>