IDN Variant Issues Project
Arabic Case Study Team F2F Meeting
Singapore, 18/06/2011

Intensive discussion on definitions. Team didn’t follow the alphabetical order of listed definitions in the document and chose to follow more logical order and to go from character, label, to table level. 

In general, team found some definitions were coming directly from standard sources and were acceptable, some may require slight changes, and other definitions were irrelevant or rather confusing as far as Arabic script is concerned. Team also thought that as they move forward there would likely be a need for additional definitions to reflect more on the specifics of Arabic script variants. 

More specific observations on definitions:
The term ‘valid codepoint’ is confusing since IDNA uses similar terminology ‘PVALID’ but in a different way.
In Pakistan (66 spoken languages and 40+ written) the term ‘language table’ does not make much sense and the ‘script table’ is used instead. Also in gTLD context, the term ‘script table’ makes more sense. 
Another example from Pakistan: two different set of characters are needed, one for registration and one for resolution. This differentiation is not captured in the definition of ‘valid codepoint’.
The definition of ‘language variant table’ with the suggested three-column format does not make sense in the case of Arabic. 
There may be a need to use terms other than ‘fundamental label’ and ‘preferred variant’; perhaps something like ‘primary’ and ‘secondary’.  
As a general observation, the document seems to be using a pre-defined set of static definitions that do not address the dynamic nature of variants. 

There was an agreement that all team members should go through the definitions, share and collate their comments on the mailing list. 

On experiences of existing ccTLDs, both IRNIC (.ir) and ictQatar (.qa) briefed the team on how they handle variants on second-level. Main problem in Iran is that lots of computers come with Arabic keyboards so end-users use characters that look exactly like Persian characters but in reality they are Arabic characters (i.e. Yeh, Kaf). Therefore IRNIC allow registrations in Arabic characters and offer registrants bundles that they can activate and/or reserve. IctQatar on the other hand identify 4 groups of character sets (alef, ha’, yah, waw) as variants, and allow registration of bundled strings according to certain policies. 

Discussion on working plan addressed the question of whether definitions and issues are two separate things or they are dependant. Team was of the view that definitions and issues were related but they also agreed that they could not fit the Arabic script case to the suggested definitions, rather they would have to fit definitions to the Arabic case. Therefore, team decided to look into issues first. 

Team asked ICANN to provide some concrete direction on where they are taking these definitions to. A general answer was given reiterating the need to have an agreed upon terminology on the various aspects of variants which is one key objective of this project. 

Team identified 4 main tasks:
List all issues in relation to Arabic variants, then identify issues that are relevant to the project 
Document issues in detail and provide examples 
While discussion on issues is evolving, identify areas in the definition document that would require modifications and additions 
Finalize list of issues and definitions, and document all findings in the final report

Sarmad to lead on ‘issues’ and Manal to lead on ‘definitions’. Fahd to work with Manal on ‘definitions’. More volunteers to be solicited through the mailing list. 

Sarmad would circulate the full list of issues right away and discuss it with team members while in Singapore, as well as share it on the mailing list in order for the team to decide on the list of relevant issues. 

Team agreed on due dates for each of the tasks listed above. Timeline is circulated separately. 

Team agreed that while having work done over mailing lists and conference calls would be necessary in order to meet the deadlines, much work could be done during face-to-face meetings. Team discussed potential dates for the first face-to-face meeting. There was a suggestion to have the first meeting during the first week of July (3-7). IctQtar will have to check feasibility. Team members will have to provide their availability during the period of July, August and September. Sarmad said he will not be available between 10 and 31 July. Siavash will not be available between 4 and 31 August. If no face-to-face meeting in the first week of July, team will have a conference call on 5 July. 

Team agreed to have another meeting tomorrow Sunday at 7:30PM at the open space outside Olivia. A note to be sent to the mailing list so if remote members want to join, they can call on Skype.