[arabic-vip] Initial list of issues and questions

[Baher Esmat]

Here is the answer I received:

"This is in section 2.2.1.3.2 on string requirements.  See Part II, 2.1.3:
The general category of all codepoints, as defined by IDNA, must be one of
(Ll, Lo, Lm, Mn).  That is, Lowercase letter, Other letter, Modifier letter,
or Non-spacing mark.
 
In the case of ASCII, digits are disallowed per Part I of 2.2.1.3.2."


baher

On 6/20/11 11:59 AM, "Siavash Shahshahani" <shahshah at irnic.ir> wrote:

> Many thanks, Baher. And could you provide the definitive reference in the
> Guidebook, in case there exist other than the ones I found.
> Siavash
> 
> On Mon, 20 Jun 2011 02:52:38 -0700, Baher Esmat <baher.esmat at icann.org>
> wrote:
>> On 6/20/11 9:28 AM, "Siavash Shahshahani" <shahshah at irnic.ir> wrote:
>> 
>>> Regarding the presence of digits in TLD I got conflicting results:
>>> 1. I asked a couple of registry operators, both said that the only
>>> restriction (for ASCII) is that the TLD not start with a digit. But
> this
>>> may be from the older version guidebook because:
>>> 2. In the new Guidebook(redlined version), Module 2, p.2-11, article
>>> 1.2.1, it says that ASCII label must consist entirely of letters. Also
> on
>>> page 2-12, article 2.1.5, it says that all characters within the label
>>> must
>>> have the same directional property (thus eliminating Hindi-Arabic
> digits
>>> which are L-to-R within the R-to-L script).
>>> Maybe Baher could ask Kurt Pritz for an authoritative clarification.
>> 
>> I double checked and as per the guidebook digits in TLDs are not
> allowed.
>> 
>> Baher
>> 
>>> Siavash 
>>> 
>>> 
>>> 
>>> On Sun, 19 Jun 2011 09:50:46 -0700, "Dr.Sarmad Hussain"
>>> <sarmad at cantab.net>
>>> wrote:
>>>> Dear All,
>>>> 
>>>> As per the discussion in the meeting on 18th June, we met again on
> 19th
>>>> June
>>>> to discuss the issues.  Here is a summary of our initial discussion
> for
>>>> further feedback:
>>>> 
>>>> 1.  Extra normalization - composed and decomposed forms not considered
>>>> equivalent by Unicode
>>>> 2. Optional combining marks - aerab (e.g. fatha, damma, kasra, shadda,
>>>> etc.)
>>>> 3. Conflated combining marks - alif, vao, yeh, hah with and without
>>> hamza;
>>>> alif with and without madda, etc.
>>>> 4. Two characters/unicodes with same shape in a particular position
>>>> (initial, medial, final or isolated), e.g. arabic and persian kaf;
> yay;
>>>> etc.
>>>> 5. Two characters/unicodes with similar shape; e.g. swash and other
> kaf;
>>>> tay
>>>> marbuta and hay, etc.
>>>> 6. ZWNJ with characters which do not change shape perceptibly
>>>> 7. mechanisms for documenting these cases for eventual comparisons to
>>>> determine variant TLDs
>>>> 
>>>> Following issues were pended for consideration until the associated
>>>> questions are responded by ICANN staff and consultants:
>>>> 
>>>> 1. Confusion caused by digits - Question: Though digits are relevant
> for
>>>> labels, are they relevant issue for TLDs?
>>>> 2. Specification of "language" table - Question: The way the table is
>>>> defined in the documents circulated by ICANN in the context of IDN
>>> Variants
>>>> project may not be relevant for Arabic, but should the team consider
>>>> defining the proper table format an issue? How is the concept of table
>>>> relevant for TLDs (as it is normally not used for catering to labels
> at
>>> the
>>>> top level).
>>>> 3. Blocking, reserving, etc. are strategies being discussed in the
>>>> documents
>>>> circulated by ICANN. Question: How are they related to the variant
>>> issues?
>>>>  Are these strategies part of the problem or part of the solution for
>>>> variants?  If latter, should they be discussed at this stage of the
>>> project
>>>> where only issues are being considered?
>>>> 
>>>> The following sources of variations would not be considered:
>>>> 
>>>> 1. Homophones
>>>> 2. Bidirectional issues (as they are not relevant for a TLD, but to
> the
>>>> complete domain name)
>>>> 3. writing style - as this is largely a font issue
>>>> 
>>>> 
>>>> We look forward to the feedback on all the items.  We request feedback
>>> on
>>>> the second set of questions by ICANN staff and consultants.
>>>> 
>>>> regards,
>>>> Sarmad