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

Sun Jun 26 07:24:00 UTC 2011

Thank you Sarmad ..

In fact my first thinking was categorizing issues along the following lines:

- issues of relevance to ICANN/IANA

- issues of relevance to registries/registrars

- issues of relevance to registrants

- issues of relevance of end-users

but I was not sure yet if this is the best way to go about it .. so I'm fine with the categorization too .. I believe things will become more clear as we insert the different issues under the relevant categories ..

In another self-brainstorming I came up with the attached slide .. not sure how useful it may be or if colleagues would agree to this breakdown at the first place but thought to share with you and I'm surely willing to discuss if needed ..

Kind Regards

--Manal  

From: arabic-vip-bounces at icann.org [mailto:arabic-vip-bounces at icann.org] On Behalf Of Dr.Sarmad Hussain
Sent: Saturday, June 25, 2011 8:23 AM
To: arabic-vip at icann.org
Subject: Re: [arabic-vip] [vip] Suggested meta-questions to think about

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/20110626/dd6f826e/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: A Diagram on Arabic Variants Issues.ppt
Type: application/vnd.ms-powerpoint
Size: 148992 bytes
Desc: A Diagram on Arabic Variants Issues.ppt
Url : http://mm.icann.org/pipermail/arabic-vip/attachments/20110626/dd6f826e/ADiagramonArabicVariantsIssues-0001.ppt 