[arabic-vip] agenda for conference call today (on Version 0.8)

[Alireza Saleh]

Regarding the solution to the ZWNJ, I get confused about the terms "with ZWNJ" and "without ZWNJ" , what happen if a name contains more than one ZWNJ, then how we should group the variant names.
For example :

"A<ZWNJ>B<ZWNJ>CD" is variant of "ABC<ZWNJ>D" or not?


-
Alireza




On Oct 4, 2011, at 10:36 AM, Sarmad Hussain wrote:

> Dear all,
>  
> Thank you for your feedback. 
>  
>  
> Here is a tentative agenda, which is based on Version 0.8 of the report and points which still need discussion and finalization (please feel free to suggest if you would like to add something to it):
>  
>  
> 1.       We have not discussed in greater detail whether we are recommending character level or position level variants.  This is an important point as it has a great impact on the possible variants which are generated (and also the variety of TLDs which are available).  (I am thinking of adding a note on the appendices saying that the current tables are only valid for character level variants and need to be revisited for positional variance)
>  
> 2.       Should we move the normalization table in the “optional” section?
>  
> 3.       We have the following points in the ZWNJ discussion.  We need to discuss whether to include them in the final version.
>  
> a.  ZWNJ is allowed, however the string with it is considered a variant of the string without it.  This addresses KB, confusability and security issues (but gives the users the choice and flexibility based on their language)
>  
> b.  ZWNJ is allowed, however, if ZWNJ is allocated, then the variant without it must also be allocated
>  
> c.  ZWNJ is allowed, however, if ZWNJ is allocated, then the variant without it must also be allocated.  Additionally, the label with ZWNJ cannot be a fundamental label, but can only be a variant
>  
> d.  ZWNJ is allowed only if the applicant can demonstrate convincingly that the string will not cause security risks, with additional restrictions as discussed above
>  
> e.  ZWNJ is not allowed at this time
>  
> 4.       The team has spent considerable time on the section on dispute resolution.  There is a suggestion to delete this section as it is not relevant.  The team (with feedback from the IDN VIP team) needs to discuss and decide on this.
>  
> 5.       Discuss the following:
>  
> “The current registration tools need to be extended to incorporate the entire process automatically, with no (or minimal) manual interaction.[AZ1] [AZ2] “
>  
> 6.       Discussion on Fees Section
>  
> 7.       Additional entries in tables:
>  
> U+06D2 (ے)
> -
> -
> ـے
> ے[AZ3] [AZ4] 
>  
> And
>  
> U+0622 (آ)
> -
> -
> ـآ
> أ
> U+0671 (ٱ)
> -
> -
> ـٱ
> ٱ[SH5] 
>  
>  
> 8.       General note on language use.  I have been using “may” instead of “will” or “should” in the document as a polite but still definite assertion.  Reading the feedback, this may be confusing.  We need to clarify how we use this terminology. 
>  
> 9.       Update from Mohammed on formatting process and progress
>  
> 10.   Timelines and further steps towards finalization of the report for submission
>  
>  
> Regards,
> Sarmad
>  [AZ1]This is not applicable to TLD
> 
>  
> 
>  [AZ2]It is applicable because when an Arabic script label is applied for, ICANN should have a mechanism to generate all variants for the TLD to evaluate the application and reserve/block the label variants not applied for
> 
>  [AZ3] This is needed as the this version of Yeh is considered the same letter Yeh, with just stylistic variation. (This is similar to our treatment of the Kaf  U+06AA (ڪ)
> 
>  [AZ4]Need to discuss this as this is may be specific to Arabic language
> 
>  [SH5]Need to discuss these
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1654 bytes
Desc: not available
Url : http://mm.icann.org/pipermail/arabic-vip/attachments/20111004/986e7241/smime-0001.p7s