hi all, i took out of our recent phone call was to bring your attention to the IDN Variant "user experience" report that was issued in March and lightly discussed at a meeting in Beijing. so here's a little email to whet your appetite. this is posted to the public list because i kinda want this cry of alarm to be heard pretty widely. here's a link to the full report -- issued in March https://www.icann.org/en/resources/idn/variant-tlds/active-ux-21mar13-en.pdf i've chopped in just the table of contents from Chapter 5 of the report. i *STRONGLY* urge you all to read the detail of that chapter -- as an ISP who's likely to be getting calls about these things, my jaw drops. just one example. let's say that your username is an email address at a service provider. let's not pick on Facebook, let's think about somebody smaller like maybe Mikey's Pretty Good ISP where you go for your connectivity plus a few related services like email and maybe some hosting services. so your expectation is that your email address will work in both its ASCII form *and* any number of IDN variant forms?? that's what's being proposed. but but… they're separate strings, you say. validation on the different string will fail, but the expectation is that it shouldn't. there are many more similar issues described in this chapter. 5. Challenges Related to Active Variant TLDs........................................................................ 28 5.1. Challenges with the Use of Variants............................................................................. 28 • 5.1.1. Different Users cannot find the complete set of variants for a primary label....... 29 • 5.1.2. Variants not intuitive............................................................................................. 29 • 5.1.3. Variants delegated independently ......................................................................... 29 • 5.1.4. Variants defined inconsistently............................................................................. 30 • 5.1.5. Variants displayed inconsistently ......................................................................... 30 • 5.1.6. Variants cannot be input by the user..................................................................... 30 • 5.1.7. Unable to distinguish specific variants ................................................................. 30 • 5.1.8. Identifier not bound to all variants........................................................................ 31 • 5.1.9. Accessibility and privacy impacted ...................................................................... 31 • 5.1.10. Variants not searchable ......................................................................................... 31 • 5.1.11. Search rankings unpredictable .............................................................................. 32 • 5.1.12. Search optimization affected by variants .............................................................. 32 • 5.1.13. Variants not part of URL/URI/IRI ........................................................................ 32 • 5.1.14. Variants cause session re-establishment ............................................................... 32 5.2. Challenges in the Registration and Management of Variants....................................... 33 • 5.2.1. Management across IDN TLDs inconsistent ........................................................ 33 • 5.2.2. Registration for SLDs across TLDs inconsistent.................................................. 34 • 5.2.3. Inconsistent association of ASCII domain name and IDN TLDs......................... 34 • 5.2.4. Software support inadequate................................................................................. 34 • 5.2.5. Registration system not straightforward to localize.............................................. 35 • 5.2.6. Registration information inconsistent ................................................................... 35 • 5.2.7. Trademark protection tracking complex ............................................................... 35 • 5.2.8. Trademark protection dispute process complex ................................................... 36 5.3. Challenges in the Configuration and Diagnostics of Variants...................................... 36 • 5.3.1. Software configuration not supported................................................................... 36 • 5.3.2. Cannot associate variants for configuration.......................................................... 37 • 5.3.3. Compounded certificate management................................................................... 37 • 5.3.4. DNSSEC validation inconsistent .......................................................................... 37 • 5.3.5. Log and history searching does not match............................................................ 38 • 5.3.6. Network traffic statistics incomplete .................................................................... 38 • 5.3.7. Caching infrastructure inefficient ......................................................................... 39 • 5.3.8. Diagnostic and troubleshooting tools incompatible.............................................. 39 but what REALLY gets me going is Chapter Six where the recommendations are laid out. some of the problems described in Chapter 5 don't seem possible to solve at all, no matter who does the solving. and look at all the stuff that **ICANN** is supposed to do to make these things work. to use Dennis Jennings' analogy -- the problems described in Chapter 5 imply that these things just won't work -- sort of like an airplane constructed with the curved part of the wing on the bottom, which just won't fly. why/how is *ICANN* supposed to work this miracle? 6. Recommendations ............................................................................................................... 40 6.1. Recommendations to ICANN ....................................................................................... 41 6.1.1. ICANN must implement a well defined and conservative variant TLD allocation process .............................................................................................................................. 41 6.1.2. ICANN must maintain an LGR repository for the root zone and IDN TLDs and make it available to users and programmatically processable............................................... 41 6.1.3. ICANN must develop, to the extent possible, minimal, simple and consistent LGR for the root zone..................................................................................................................... 42 6.1.4. To help ensure that users have a more predictable and consistent experience registering and using primary and variant labels, ICANN must develop, to the extent possible, a minimal, simple and consistent life cycle for the variant TLD sets (across languages and scripts)............................................................................................................ 43 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 ................... 44 6.1.6. ICANN should 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 ....................................................................... 45 6.1.7. ICANN should create educational materials on the use and impact of variants for different user communities .................................................................................................... 45 6.1.8. ICANN must require any accredited registrar that supports IDNs with TLD and/or SLD variants to support variants across its registration platform ......................................... 46 6.1.9. ICANN should develop consistent registration data requirements for variants at root and other levels .............................................................................................................. 46 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 ............................................................................................................ 47 6.1.11. ICANN must define technical requirements and engage with standards organizations, such as the IETF, to determine how IDN variants should be consistently implemented .......................................................................................................................... 47 and here's all the stuff that registries are supposed to do... 6.2. Recommendations to a Registry that Offers IDNs for Scripts that have Variants........ 47 6.2.1. Registry should not register any second-level variant labels unless the label registration request has met all approval requirements ......................................................... 47 6.2.2. Registry that supports variants must make its updated LGR available to ICANN and the community ................................................................................................................ 48 6.2.3. Registry that supports variants should apply the LGR developed for the root across lower-level domains. Deviations from the LGR should be publicly documented and justified .............................................................................................................................. 48 6.2.4. Registry that supports variants should implement, to the extent possible, state life cycle for the second-level variants recommended by ICANN .............................................. 49 6.2.5. Registry should create educational materials on the use and impacts of variants for different user communities, such as end users, system administrators, etc........................... 49 6.2.6. Registry offering variants should require relevant registrars to support IDN variants across their registration platforms............................................................................ 49 and a list for registrars 6.3. Recommendations to a Registrar that Supports the Registration of Variants............... 50 6.3.1. Registrar must update its practice to address requirements specific to the registration of IDN variants ................................................................................................... 50 6.3.2. Registrar should extend linguistic and technical support of IDN variants for registrants .............................................................................................................................. 50 • 6.3.3. Registrar must support IDN variants across their registration platforms ............. 50 • 6.3.4. Registrar must support registry policies and associated services for collecting and managing registration data of IDN variants .......................................................................... 51 6.3.5. Registrar that supports the registration of variants may also update any related services that are impacted by variants ................................................................................... 51 and the "technical community" -- these recommendations largely fall in the "magical thinking" category for me. 6.4. Recommendations to the Technical Community.......................................................... 51 6.4.1. Developers of software tools for the technical community should consider, based on user requirements, enhancing their software to support the administration and management of variants......................................................................................................... 51 6.4.2. Software intended for Internet end users—such as web browsers, email clients, and operating systems—should support variants to the extent necessary to ensure a positive user experience ...................................................................................................................... 52 6.4.3. To provide end users with a consistent and predictable experience with variants across software applications, developers should, to the extent possible, publicly share best practices and emerging standards in terminology and functionality ..................................... 52 i really urge you to read these two chapters -- i can't figure out how the stuff they're proposing will solve the puzzles and are being described. the problem is, none of us have been paying attention and this pile of contradictions isn't getting challenged. i think we really need to step into this conversation from the ISPCP point of view and point out that if these things are really seriously broken, we're going to take the brunt of the calls and eventually start considering some really unpalatable and unpopular actions. enough for a starting-point rant. i'd love to hear your views/reactions. at a minimum, i think it would be great to have Dennis Jennings and somebody from the IDN team come and have a little debate during our meeting in Durban. mikey PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)