[jig] JIG final report on universal acceptance of IDN TLDs. Recommendation B (budget)

["Dillon, Chris" <c.dillon@xxxxxxxxx>]

Dear Colleagues,



Here is a first attempt at breaking down and prioritising part 1.B of the 'JIG 
final report on universal acceptance of IDN TLDs', as I promised during the JIG 
call on 22 January.



1.B

"Allocate specific budget for the advocacy of Universal Acceptance beyond the 
passive development of informational materials and toolkits."



I have taken the recommendations for ICANN from the VIP Project 6's report on 
'Examining the user experience implications of active variant TLDs', the latest 
draft of which was posted on Jan. 18, 2013 and added some notes.



What are our aims in this? (What do we want to prevent?)

*         We want IDNs to work technically. For example, we want IDN URLs to 
resolve as expected by the user and IDN e-mails to be sent and received without 
(bouncing or getting lost).

*         We want IDNs to be perceived as safe to use. (We do not want them to 
be perceived as prone to scams. We do not want unnecessary delay.)

*         We want up-to-date authoritative versions of toolkits to be available 
centrally. (We do not want multiple versions of toolkits doing the same thing 
scattered all over the Internet.)

*         We want high quality information materials.



Any recommended prioritisation(s) the JIG may make, may be submitted to the 
Supporting Organizations, which may decide to recommend one or more of them to 
the Board. Please note that all of the report's recommendations to ICANN are 
listed for the sake of completeness. In decreasing order of priority:



6.1.6. ICANN must require IDN TLD registries with variants to apply the 
relevant (script) subset of the root zone LGR and state life cycle for variants 
across second-level

domain labels. Deviations should be justified

The second and lower levels are not covered by the Project 2.1 work. Work needs 
to be done to highlight any differences between the second and lower levels, 
and the root zone, which tends to be more conservative.



6.1.8. ICANN must require accredited registrar [sic] who supports IDNs with TLD 
and/or SLD variants to support variants across its registration platform

To what extent have registrars started this work? Can ICANN provide advice on 
how best to set up registration platforms for variant management?



6.1.4. ICANN must develop, to the [sic] extent possible, a minimal, simple and 
consistent life cycle for the variant TLD sets (across languages and scripts)

Note that more TLD statuses are suggested in the P.6 report than in the P2.1 
report (which now recognizes only Allocatable and Blocked). Domain name life 
cycle is mentioned in the P2.1 report, but that aspect of the report does need 
to be developed.



6.1.10. ICANN must convene relevant experts involved in domain name disputes to 
determine any new issues introduced by variants and update existing dispute 
resolution

processes accordingly

ICANN has a dispute fund. It is likely that there will always be litigation by 
applicants who do not get their TLDs and other parties who believe that some 
successful applicant should not have got their name. Only once the results of 
the String Similarity Evaluation panel are posted will it be clear to what 
extent this is an issue with variants.



Development of information materials and toolkits

6.1.7. ICANN must create educational materials on the use and impact of 
variants for different user communities

This implies work in many languages for various types of user. It is likely to 
be expensive.



6.1.2. ICANN must maintain a repository for LGRs for the root zone and IDN TLDs 
and make it available to users and programmatically processable

Funding will need to be available for this. The alternative is a chaotic 
situation with organisations providing a miscellany of solutions.



6.1.5. ICANN must define guidelines to evaluate the competence and readiness of 
the registry to manage variants, to ensure a stable and secure end user 
experience

Much of this will have been done by applicants for new gTLDs. Similar criteria 
could be recycled for such guidelines in the light of experience gained from 
the current round.



6.1.9. ICANN must develop consistent registration data requirements for 
variants at root and other levels

These data will enter the system created by P1 which will run according to the 
rules set down in the documentation written by P2.1. Is this already part of P1 
- does anything actually need to be done?



Registries

The P.6 report recommends that registries create educational materials. They 
should be encouraged to cooperate as they do so. Perhaps ICANN could have a 
webpage with links to such materials.



The following are covered by existing projects, but may require on-going 
funding:

6.1.1. ICANN must implement a well defined and conservative variant TLD 
allocation process

P1 and P2.1 are already funded and working on this. Work on specific scripts 
occurring after P2.1 will need to be funded.



6.1.11. ICANN must define technical requirements and engage with standards 
organizations, such as the IETF, to determine how the IDN variants should be 
consistently implemented

This falls within the remit of projects P1 and P2.1.



6.1.3. ICANN must develop, to the extent possible, minimal, simple and 
consistent LGR [sic] for the root zone

P2.1 is doing this; the work will be continued by panels implementing the work 
described in the P2.1 report.



Do we think that the above misses out anything important?

Is this actually all covered in the ICANN strategic plan? The relevant sections 
are:

*         Increase TLD options in more languages

*         Rollout new gTLDs including IDNs



As with so much work ICANN is currently doing, it has never been done before; 
one of the main implications of this being great difficulty in financial 
planning. As usual I am open to corrections and additions.



Regards,



Chris.

--

Research Associate in Linguistic Computing, Dept of Information Studies, UCL, 
Gower St, London WC1E 6BT Tel +44 20 7679 1599 (int 31599) 
ucl.ac.uk/dis/people/chrisdillon