Dear All,
I posted this to Arabic-vip list, but as the discussion is getting language
specific on the general list, this may also be useful here. Apologies for
cross-posting for those who have already received it.
regards,
Sarmad
---------- Forwarded message ----------
From: Dr.Sarmad Hussain <sarmad(a)cantab.net>
Date: Tue, Jun 21, 2011 at 10:01 AM
Subject: Re: [vip] Suggested meta-questions to think about
To: arabic-vip(a)icann.org
Taking Patrik's enumeration forward, here is a tentative list for Arabic,
for further discussion:
A1.1.1 Unicode code points having same shape in at least one of the four
forms (beginning, middle, final and isolated)
A1.1.2 composed and decomposed forms not covered through Unicode which are
exactly same
A1.2.1 Unicode code points have shape similar enough that user will get
confused and accept them equal (causing security threat, e.g. phishing)
A1.2.1.1 similar shapes
A1.2.1.2 similar marks
A1.2.2 composed and decomposed forms same enough to cause user confusion
(causing security threat, e.g. phishing)
A1.3.1 conflating level 2 marks (less significance, higher optionality)
(e.g. fatha)
A1.3.2 conflating level 1 marks (higher significance, lower optionality)
(e.g. hamza above/below)
A1.3.3 conflating level 0(?) marks (highest significance, no optionality)
(e.g. double-fatha) (could this be A 2.1?)
Interestingly, it can be argued that A1.3.x is a label level variance
instead of character level variance, which is an interesting concept, but is
not quite similar to A.2 suggested below but somewhere in between A.1 and
A.2, as Arabic writing system (Abjad) works differently in some ways that
Alphabetical systems like Latin.
AX 1.1 There is also label level variance in a few cases, where technically
ZWNJ is licensed by protocol (and should be licensed in spirit) but the
changed shape is so slightly different that it is not perceptible and may
cause security threats (e.g. phishing).
I would draw the line before A.2 for variants.
regards,
Sarmad
2011/6/19 Patrik Fältström <patrik(a)frobbit.se>
> Hi, I am sending this as an interested individual, and not as SSAC Chair...
>
> I have a few times this weekend already tried to explain my view on
> "variants", and after doing that in a chat, I felt it start to (for me) make
> sense, so I wanted to share with you.
>
> We have, I think, a problem divided in two different questions. And
> unfortunately many people think of the solution only the form of "answers to
> the second question". Let me try to explain.
>
> First, whether something is a variant or not (note: word is undefined), is
> actually a grayscale from "yes" to "no". There are various shades of gray
> there. For example:
>
> A.1. Two characters in Unicode really are to be treated as being
> equivalent. I presume one could say that the Hangul SC/TC issues fall in
> that category.
> A.2. Two different spellings of the same word in the same script and same
> language, like color/colour.
> A.3. Same word in the same language in two different scripts (bulgarian)
> A.4. Same word in two different languages
>
> And then there are many A.1.1, A.1.2, A.2.1 etc, and I did even hear today
> people say "two variants are two different accepted spellings of the same
> word that _sound_ the same". I do not even know where to put that.
>
> But one thing I because of that think should be done, and could be done, by
> people is to list all different "variants" they can come up with...
>
> The one draw the line, what is and what is not? Is the line drawn at
> A.1.1232 or A.2.56?
>
> Ok, given we have some agreement on what is a variant and not, we have to
> discuss what implications it has. I here also see a number of different
> questions to be answered. For example:
>
> B.1. Should an application with more TLDs than one be counted as one
> application if the TLDs in the application are variants of each other? And
> if so, should there be only one fee per application?
> B.2. Should two different variants be able to be managed by two different
> registries or not, and if not, what should happen with the variants? One
> primary and others like the bundling tactics in some TLDs (i.e. choice
> between "yes delegation" or "just block for other to register")?
>
> And then there might be a technical question in there...
> C.1. Given two domain names are variants of each other, is there something
> that can be done in the DNS from a technical point of view to express that,
> or can we only do delegations?
>
> The really tricky question is of course to really draw the line between
> variants and not variants. I think the line from a technical point of view,
> AND the implications on the second questions, should be for the new TLD
> approval process be as conservative as possible.
>
> Default answer: If someone want two domain names, just send in two
> applications.
>
> Exception: As you desperately need both and not only one of the domain
> names, you will get both treated as one application.
>
> Then ICANN ask IETF formally "can you please let us know if it is possible
> to have some kind of solution for _technically_ link two TLDs with each
> other, in a safe and stable way". Via a letter to IAB.
>
> Until and if IETF give such a solution, ICANN only have the following two
> alternatives for the ones that do get two variants approved:
>
> 1. Get both delegated
>
> 2. Get one delegated and the other blocked
>
> Then MAYBE there will be a third option:
>
> 3. Get both with some alias solution
>
> But these are things which are implications given a definition on what
> "variants" are, and that discussion is in the future -- although I am pretty
> sure some parties really would like to have certain solutions to the
> problem...
>
> Patrik
>
>
>
