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