<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>