[UA-discuss] GNSO requested deferral of IDN Guidelines 4.0 Vote - CPH / Registrants impact
Asmus Freytag
asmusf at ix.netcom.com
Mon May 13 22:49:28 UTC 2019
On 5/13/2019 10:08 AM, John Levine wrote:
> On Mon, 13 May 2019, Ram Mohan wrote:
>> While it's a straightforward argument to say no variants should be
>> allowed
>> on the DNS, the reality in many linguistic locales is that variants
>> are a
>> part of everyday life. Not just in the Han script, but in Indic and
>> Arabic
>> scripts, among others. We can't wish them away, nor do we have the
>> luxury
>> of saying the DNS wasn't designed for it, so it shall never support it.
>
> I think there's a large gap between "many writing systems can write
> the same thing in different ways" and "those different ways should be
> in the DNS."
>
> It's easy to see why you'd block variants, but particularly given the
> utter lack of tools to provision them, and no interest in creating
> those tools, hard to see why you'd delegate them.
John, sorry, I'm with Ram on this one. Where I agree with you is on the
beneficial nature of blocked variants. They are a cheap and underused
tool to limit the attack surface for deceptive registrations.
However, once you block a variant, you take away the option for
applicants to apply for the variant even if they have registered the
original label. Where variants are unrelated, that's not an issue. But
in many scripts you have situations where different keyboards, for
example, may have one of the variants, but not the other. And where both
variants are used for the same letter.
By blocking such variants, you exclude one community from "reaching" any
label registered for another one.
We don't really have that situation in the Latin script, not even with
European languages. The closest you can get is that Danish uses "ø" for
the letter for which Swedish uses "ö". However, the same word, like the
name of the Danish capital, is often spelled differently elsewhere in
the word, e.g. Köpenhamm instead of København. (Therefore, Copenhagen
can simply apply for all three spellings, and additional ones as well -
such as the German spelling; even if the two code points were variants,
the labels are not).
That reduces the case for making these two letters variants of each
other. However, between Arabic and Persian, you'll have cases where
geographic names differ ONLY by such local variant use. You could target
only one community.
Not allowing someone to register both variants in this situation causes
just as many problems as ignoring the variant relation altogether and
letting an unrelated party register the variant.
There are many similar examples, and the best way to handle them is to
support allocatable variants. They still block the access to
registration of the variant label by unrelated parties, but allow one
applicant to register both. With the new LGR format, you can express
some further constraints so that only a limited number of variant
*labels* can be allocated.
For example, if you have a pair of code points that are variants, and a
pair of labels that contain 2 copies of each (in matching positions) you
would normally get a set of 4 variant labels. An easy way to constrain
that is to limit all variants to be from the same subset (e.g. either
all Persian, or all Arabic).
Allocatable variants still leave it to the discretion of the applicant
as to whether to apply for more than one variant. Some people prefer
automatic activation, where all applicant would receive all variants.
There may be some cases where that would match the overall users'
expectations. For example, there are three sets of digits used with the
Arabic script, each being in "native" use in a different region. Two of
these sets even share many digit forms. Since any numbers these digits
represent are obviously the same, and in some cases, users cannot tell
which set of digits is used, forcing activation may be justified.
No matter how you come down on that last example, there's no escaping
the need to deal with scripts that do have such variants.
The LGR format in RFC 7940 is making a start in letting you express more
of your registry policies in a machine-readable format that was possible
before (even with the earlier IDN table format extensions for Chinese
and Arabic).
Time to put some of the other tools into place.
A./
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20190513/918abf10/attachment.html>
More information about the UA-discuss
mailing list