1. IDN issues ITU-T SG16-Q7 26 July 2010

2. Objective Provide a set of examples why IDN study at ITU-T could be considered Demonstrate the need of ITU recommendation for at least one issue. Trigger the discussion between local expert communities about other issues which still need to be addressed.

3. Current status Standards issued by IETF : IDNA 2008 in their final phase, major revision of IDNA2003. Mainly focus on character conversion and registration protocol, no focus on applications. ICANN launched IDN ccTLD “fast track” on 2009. The “full fledged” IDN gTLD process will be launched at start of 2011. We believe there are still certain “holes” in the current standards which need to be covered. Mainly at the application level.

4. Variants and visual confusion Old problem : Paypal visual confusion attack (The “P” is cyrillic and not Latin). IDNA sol. : No mixing of characters between “scripts”. Notice: scripts and not “languages”. Prob.: Scripts could be shared by many language communities. Example: Arabic Script (Arabic, farsi, Urdu, jawi, etc). IDNA2008 relies on UNICODE, which also defines scripts and not languages. Result: Visual confusion still possible. Even worse: visually confusing characters within the same language.

5. Example for visual confusion

6. Variants and visual confusion Problem: What would happen to a registry if he opens door for IDN registration w/o considering visual confusion issues ? Problem currently existing with Arabic scrip, but not sharp (yet) because there are no IDN TLDs, but this will change soon (1 year, 2 years ?). Proposed solution: Apply a master key algorithm before domain allocation to generate all variants and block them. http://arabic-domains.org/adn_tools/mk/index.php Algorithm needs further development: acceleration, check with other languages/script communities if the approach is applicable or not.

7. Variants and visual confusion Action needed: Issue an ITU recommendation about variants in domain names and how to deal with them. In case a master key algorithm is found to be appropriate, a set of rules to designate the key should be included within the standard. Who needs this recommendation ? –Registry operators –Developpers of registration software for registries and registrars –Developpers of applications using IDN domains A liaison could be established with IETF to avoid redundancy.

8. URL structure A web address is composed of three parts: Scheme://Domain Name/Path IDN adresses only the domain name part. W3C/IETF standards would allow Path to be written in Unicode, but not Scheme. Even worse: if we do not write scheme, then it defaults to http. Result: We got the gTLDs in IDN, but it is difficult to use. Action: Issue a recommendation about Full Unicode web addresses. A liaison could be established with W3C

9. Conclusion Certain IDN issues need to be adressed, mainly for application support. Not adressed by current standards because out of scope. Some of them are clearly identified (such as visual confusion), some needs more study (such as URL structure, email structure, etc.). The outcome will definitly be needed by the community once large scale IDN registration starts (within 1-2 years). Propose to start working on clearly identified issues, while others are being prepared within local expert communities.