On 2/26/2018 11:10 AM, Mark Svancarek via UA-discuss wrote:
I misunderstood Andre's original post, sorry, my mind was thinking about the characters in the TLD, not the characters in the other labels. Oops.
It still seems weird to me to have a superset table (Japanese) as well as subset tables (Hiragana, Katakana) for the same TLD. What's the utility? None that I can see.
There is some use for different tables that overlap in more complicated ways. Such as allowing both Chinese labels (from a large subset of Han ideographs) and Japanese labels (from a smaller/different subset) but together with Hiragana and Katakana. That's at least the plan for the Root Zone and a scheme like that would be a reasonable solution for the second-level for zones that have a more global audience. Having two tables limits the combinations based on whether you are registering a "Japanese" vs. a "Chinese" label, even though the namespaces overlap. If, in addition, you align the definition of variants so some existing Japanese labels can block a new Chinese label that would look like a variant to a Chinese user, then you've incrementally reduced the attack surface for spoofing - arguably always a good thing. A./
-----Original Message----- From: UA-discuss <ua-discuss-bounces@icann.org> On Behalf Of Andrew Sullivan Sent: Monday, February 26, 2018 10:44 AM To: ua-discuss@icann.org Subject: Re: [UA-discuss] IANA IDN Tables
On Mon, Feb 26, 2018 at 05:30:38PM +0000, Mark Svancarek via UA-discuss wrote:
コ andム are katakana characters, so only examples 1 and 3 are valid from a language perspective. Those characters do not exist within hiragana and I do not believe they exist as standalone Chinese characters, either. That doesn't matter, because the characters _below_ the Katakana _could_ be Han or whatever. Japanese is written in multiple scripts, so knowing that one label is only written with Katakana does not tell you whether another label might have Han characters in it. It doesn't, indeed, even tell you that there might not be a Chinese name lower in the tree, much as com today permits characters outside the ASCII range.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com