Re: New Version Notification for draft-obispo-epp-idn-00.txt
Eric Brunner-Williams <[email protected]>
| Newsgroups | gmane.ietf.provreg |
|---|---|
| Organization | wampumpeag |
| Message-ID | <[email protected]> |
> Because of all of the above, I'd like to step back a bit from the
> language-vs-script and table-based way of framing this discussion and
> focus more on how one selects which set of code points one wants to
> use and, if there are rules governing the behaviour of those code
> points, how one expresses one's options under those rules. This will
> make for a more complicated EPP extension, but it will also make for
> one that actually matches the different registry policies already in
> place today. By creating an extension that can accommodate the many
> different policies in place, we might be able to reduce the number of
> extensions that actually get deployed.
Concur. An ASCII (hex) code point repertoire of {(41,61), (45,65),
(49,69), (4f,6f), (55,75), (59,79)} (English vowels) is just as
reasonable a repertoire {30 ... 39} (digits) and just as reasonable a
repertoire as {30, 32, ... (5a,7a)} (even valued points within LDH) as
the ASCII LDH set of code points. None are sufficiently characterized
as "language" or "script", but are sufficiently characterized as
enumerations or rules for the construction of repertoires of code points.
For a less mathematician-centric or
bottom-half-of-the-tty-driver-centric example, consider the "proper
word" requirement of the circa-2006 Arabic Script group. A "is in a
dictionary and is not on a reserved list" rule is neither "Arabic"
(the language") nor "Arabic Script" (the Unicadette created thingie an
earlier instance of the IDN WG, steered by non-contributors, elected
to commit _some_ DNS text resource records to). The dictionaries of
two "Arabic Language" supporting and "Arabic Script" using registries
may differ, as may their reserved lists.
Verisign's take on Arabic makes me grin. I hope they'll be just as
creative when it comes to Chinese.
My two beads worth,
Eric
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg