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

[Manal Ismail]

Thank you Sarmad ..
I'll go through the list and let you know my feedback ..
I'm cc'ing Patrik on your response as I'm not sure whether he's on the arabic-vip mailing list or not ..
 
Patrik, apologies if you have already received the below ..
 
Kind regards
 
--Manal

________________________________

من: arabic-vip-bounces at icann.org بالنيابة عن Dr.Sarmad Hussain
تاريخ الإرسال: الثلاثاء 21/06/2011 07:01 م
إلى: arabic-vip at icann.org
الموضوع: Re: [arabic-vip] [vip] Suggested meta-questions to think about


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