[arabic-vip] [vip] Suggested meta-questions to think about

Sat Jun 25 06:22:57 UTC 2011

Dear All,

Kindly review the questions document circulated and let us start listing
issue-categories.
Here are some suggestions:

1. What is a variant in Arabic script (see the email below)
2. How to represent variants formally (table related issues)
3. TLD vs. other level variants in Arabic - what is applicable level wise
4. Variant TLD delegation
5. Variant TLD registration
6. Variant TLD resolution
7. Variants and user experience

Others?

This list could essentially translate into our document structure. Does this
seem the right way to proceed or is there alternate ways to structure the
work?

regards,
Sarmad

On Wed, Jun 22, 2011 at 1:01 AM, Dr.Sarmad Hussain <sarmad at cantab.net>wrote:

> 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 at 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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/arabic-vip/attachments/20110625/86cf6a0b/attachment-0001.html 