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

Wed Jun 22 01:51:58 UTC 2011

FYI

On 6/22/11 1:26 AM, "Patrik Fältström" <patrik at frobbit.se> wrote:

>Dear Manal,
>
>I had not seen this, as I am on the vip@ list, but not any of the
>specific lists.
>
>Happy I managed to start some discussion :-)
>
>   Patrik
>
>On 22 jun 2011, at 01.07, Manal Ismail wrote:
>
>> 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
>> 	
>> 	
>> 	
>> 
>> 
>> 
>
>