Greetings John, You have just revealed the extent of the complexity below, and perhaps set the stage for the discussions, I believe. Thank you for your time. I like your ...analogy that IDNs will not solve... or cure cancer. That was humerus. In any case, I read your analysis with interest and believe ICANN/GNSO would benefit and draw a lesson from many of the points you made; I certainly did, specifically from these main comments below: I am continuing my dialog with you as appropriate ... - I also believe that effort should have f*ocused on the establishment of "best practices" models, not mandates and requirements*, from the very beginning (and independent of where and how those models are approved and published) and that ICANN's PDP process is inappropriate for trying to draw that work together. ( I see that...) - The ICANN PDP approach, with its model of one SO developing a proposal and then throwing it over the wall for review by others is, in my opinion, very poorly suited for developing good policies, or even good recommendations, in an environment that is this complex. We also *run the risk that poor policies or poor guidelines could effectively make IDNs almost useless* --or too dangerous to use-- in actual practice. (this is where we have to evaluate the best approach, and it seems that we are perhaps applying a single standard for all... we have to think more in dept..uhmm) - We know from the original IDN testbed activities that it is easier to say "testbed" than it is to say *" wait until we figure this out".*Whether that is the right answer or not typically depends on what a testbed is intended to accomplish. If the idea is to give some registrants, registrars, or registries an advantage or if the testbed is designed in a way that has that effect even if it was not intended, then testbeds are generally a poor idea (as I think we learned from the original IDN testbed some years ago). They are, ultimately, nothing more than an attempt to turn such principles as *"make sure it is really a test, not a head-start or commitment to a particular strategy" and "be sure that you understand what you are trying to learn and how you intended to learn it "* into an outline of a testing procedure. ( my point, exactly John, I could not agree with you more on this. This was why I raised my question during the meeting, although I could not articulate it as well as you. The testbeds seem like bet and keep strategy..in light of this and in restating what I asked, ..please see below) ........ - I believe that, if we are going to do tests, we need to use them to examine each of the alternatives and its implications so that we can advise relevant parties as to what to do or not do and can advise ICANN on priorities and actions (is there a big challenge to another 'go-ahead' strategy other than testbeds?,otherwise, I agree with your point.) If we play devil's advocate, and say there is no real technical issue with the 'testbeds'that prevents us from going directly to the policy issue, then, some questions that I think I want to ask, which seem to be *brought to my attention as a concern * would be the following: 1. Why should we do the testbed? What are the EXACT technical objectives of the testbed? What do you expect to achieve from the technical aspect? Do we have a detailed proposal and framework to work from, like in any other experiment? 2. What do we think is going to work? Where do we expect is it going to fail (from a technical point of view – like overload, resolution, etc." – If we don't think anything is going to fail then its really and implementation and not a testbed issue? 3. Moreover –from the DNAME perspective, there seem to be an issue with going for the DNAME solution, which is not recommended (not a real Internationalized domain name, but kind of another name to an English name. You can't do email on a DNAME). In the IDN workshop at Vancouver Vint Serf said explicitly that DNAME is a bad solution. so "Why do they want to go that way? 4. Finally, *if there is a decision to really go for a testbed before resolving the policy issues,* are we considering the following few principals? - The testbed must be done for a virtual TLD –- like ".xyz" - a TLD with no meaning in the language it is done – so it should be something equivalent to ".xyz" in Chinese. This will prevent from this testbed to become an implementation. - ICANN should decide on a technical group, with different representatives (like the PAC) to run the tesbed, and do in the facilities of an objective party – like a university, etc. in any case it must not be done by an existing gTLD registry. - BEFORE deciding and running a testbed – ICANN must have an open discussion about conducting it (like in the next ICANN meeting). I hope I am going towards the right direction in my understanding of matters. Your guidance is always appreciated. Kind regards, Sophie On 27/01/06, John C Klensin <klensin@jck.com> wrote:
Sophia,
Thanks for the clarification and the kind words. A few comments below...
--On Thursday, 26 January, 2006 17:08 -0800 Sophia B <sophiabekele@gmail.com> wrote:
... was specific to the 'test beds' as you can see,and comes directly from the question I asked you during our Jan 17 meeting, on the 'test beds' while discussing the IETF Draft doc on the IDN issues.
Your response to me* interalia,* you did *not recommend personally the test beds, was not personally involved in the development of the guidelines except peripherally etc...* I suppose that threw me off and I was trying to confirm your involvement from this specific subject and not necessarily your involvement within the 'internationalization' issues, to which again, we are grateful for your input.
I hope that shades some light of where I was coming from, and provide clarification to my question.
Yes, thank you.
Your question actually opens up the entirety of my complex relationship with IDNs. That is hard to summarize in a note of reasonable length, but let me try to do so. References that expand on some of these issues are cited in the IAB draft (more in version 02 than in version 01; I now hope to have version 02 posted on Monday). I have always believed that IDNs are important and useful. At the same time, simply going from the use of around 63 characters to several tens of thousands increases complexity on many dimensions. Those dimensions are not just technical ones. Indeed, for IDNs, implementation of the protocols to make them work is the easiest of the various issues. If one is going to have IDNs, one must accept, understand, and deal with those complexities or there is danger of reducing the use of the DNS as an effective tool. Unless one likes keeping track of and typing IP addresses --very long IP addresses and many of them as we move to IPv6-- we have no alternative to the job the DNS must do, so I don't consider reducing DNS effectiveness to be an option.
More important, there are a series of problems that IDNs cannot solve. It is important to know the difference between those and the ones for which IDNs are really useful and to make business, policy, and technical decisions accordingly. IDNs will not solve Internet deployment problems, connect countries that are not now connected, or cure cancer. They may contribute to the motivation to do those things, but our expectations should remain closely tied to reality, not wild claims and desires. The most common example of an unsolved problem is the "users should be able to work entirely in their own script" statement of the IDN requirement. The difficulty is that, in general, users don't use domain names. Instead, they use URIs, email addresses, and other types of references. That is important because, in something like
http://www.example.com/search?q=abc+def&ie=utf-8&rls=def.ghi:en-US:official
going to IDNs and substituting an internationalized version of the URL (an "IRI"), we can get the domain name (but not the "." characters) into a local script and we can change the "abc" abd "def", into local scripts too. By changing the server, we might be able to convert the keywords ("search", "q", "ie" and perhaps "utf-8" or "en-US" into the local script. But we are stuck with "http://", "/", and "?" and "&" although possibly not with "=", "+", and ":". Getting rid of those things --getting them into the local script or otherwise fixing it so the end user doesn't see them-- requires an entirely different approach than IDNs and IRIs. And, interestingly, as soon as on adopts one of those approaches, IDNs, for those contexts, may recede in importance.
That situation takes us back to the guideline and testbed questions. I don't intend to cast blame here --it would accomplish little and the reasons why things happened or didn't happen are complex -- but I believe that a serious effort to revise the guidelines should have been initiated very shortly after problems with version 1.0 were noticed, i.e., right after the Montreal meeting. I also believe that effort should have focused on the establishment of "best practices" models, not mandates and requirements, from the very beginning (and independent of where and how those models are approved and published) and that ICANN's PDP process is inappropriate for trying to draw that work together. Each part of that is important: because of the complexities of the general IDN situation, solutions, rules, or guidelines that are devised by and for the gTLDs without active consideration of the needs of the ccTLDs are ultimately going to fail, probably by causing problems for the end user. Similarly, even if the ccTLDs and gTLDs were to work together, we would run significant risk of problems with implementations or subtle technical interactions for end users or with any number of international cultural or linguistic authorities. The ICANN PDP approach, with its model of one SO developing a proposal and then throwing it over the wall for review by others is, in my opinion, very poorly suited for developing good policies, or even good recommendations, in an environment that is this complex. We also run the risk that poor policies or poor guidelines could effectively make IDNs almost useless --or too dangerous to use-- in actual practice.
So I have been unhappy with the 2.0 Guideline process. The people involved in developing those Guidelines did, I believe, an outstanding job given a too-short time schedule (from when they actually got started in what turned out to be a hasty job after years of procrastination) and the wrong objective (patching the 1.0 Guidelines rather than starting with a clean slate and an analysis of the problems to be solved). But they could not, in my opinion, overcome either obstacle.
When Patrik and I came on the call, we really were not expecting to discuss the IDN TLD issue at all (and the IAB report does not address it in any significant way) so our comments were personal on-the-spot reflections rather than carefully considered positions. For me, my issues with the testbed ideas have been similar to those with the Guidelines. We know from the original IDN testbed activities that it is easier to say "testbed" than it is to say "wait until we figure this out". Whether that is the right answer or not typically depends on what a testbed is intended to accomplish. If the idea is to give some registrants, registrars, or registries an advantage or if the testbed is designed in a way that has that effect even if it was not intended, then testbeds are generally a poor idea (as I think we learned from the original IDN testbed some years ago). I started writing the notes Cary circulated while listening to the audiocast of the IDN, public forum, and Board sessions in Vancouver. They are, ultimately, nothing more than an attempt to turn such principles as "make sure it is really a test, not a head-start or commitment to a particular strategy" and "be sure that you understand what you are trying to learn and how you intended to learn it" into an outline of a testing procedure.
Finally, as I and others have said before, we have three possible ways to implement what the user will see as IDNs at the top level:
(i) Name aliases in applications software
(ii) DNAME-type aliases in the root, with no separate domain zone files.
(iii) Actual new TLDs with IDN-style names.
No one of these is "best" in any absolute way. Instead, each one has its own advantages, disadvantages, and risks. Those are not just technical, although the technical issues are different with each one, but are different in terms of approvals, allocation models and their implications, IPR and cultural appropriateness in naming, questions of who stands to profit, and so on. I believe that, if we are going to do tests, we need to use them to examine each of the alternatives and its implications so that we can advise relevant parties as to what to do or not do and can advise ICANN on priorities and actions.
regards, john
-- Sophia Bekele Voice/Fax: 925-935-1598 Mob:925-818-0948 sophiabekele@gmail.com SKYPE: skypesoph www.cbsintl.com