Statement at IGF on Diversity

>>PATRIK FÄLSTRÖM:   Thank you very much. So I was on this panel last year as
 well.  And last year, I talked quite a lot about Internationalized Domain
 Names.  And I will talk a little bit about Internationalized Domain Names this
 year as well. To start with, I think that we have made big progress since last
 year, because the discussions that we had last year was very much on the
 difference between the localization of the identifier, which is the
 Internationalized Domain Name, and localization of the content and creation of
 software that is translated into local languages. Today, I don't feel that we
 need that discussion. So when looking at Internationalized Domain Names,
 though, I still feel that there are a lot of people who think Internationalized
 Domain Names solve all problems in the world.  But, in reality, the technical
 solution of Internationalized Domain Names only solve very small piece of the
 puzzle.  We already heard many of the various issues already mentioned by the
 previous speakers on this panel.  So I hope that this will be a pretty short
 introduction. For example, we had requirements when coming up with the
 standards that the technical solution itself should be completely
 backward-compatible.  It must be possible for one user that has software that
 implements Internationalized Domain Names to send e-mail to a person that has
 software that does not implement the Internationalized Domain Names. It must be
 possible to do things like reply to an e-mail message that uses a domain name
 that is internationalized, even though you have software that does not support
 the standard. It must also be possible for a person that has an electronic
 address book that does not support Internationalized Domain Names to store
 those in that address book and do copy and paste. But there are also other
 issues that the standard does not have as a goal to resolve.  For example, what
 strings to allocate for the country -- the ccTLDs that we just heard about and
 that I do know that there will be a workshop about tomorrow. We also know that
 the standards do not solve what we call the "side of the bus" problem, which is
 the look alike of two different strings that might be printed on paper.  So if
 a person is reading a string, it might be very, very difficult to know what
 characters is actually representing that string. The last example I gave showed
 that comparison of characters in a context that is unknown is extremely
 difficult.  And this, in turn, might lead to various kind of comparison
 problems that in turn might lead to dispute resolution issues, specifically,
 between different scripts, different languages, and different contexts in other
 ways. So because of this, I think it's really important that all of us,
 actually, start work on Internationalized Domain Names and try to use them and
 not only talk about it. The Internet architecture board has come up with a
 document that actually lists many of these issues.  And last year I think we
 talked a little bit about the existence of the document.  But it now exists as
 an RFC.  And I encourage all of you to try and have a look at that one. We also
 in the IETF community are coming up with a new version of the Internationalized
 Domain Names.  And although that might scare many of you, the standard,
 although it's not used yet, we're already coming up with a new version, I can
 rest you assured that the new version is backwards-compatible with the new
 version, takes care of new versions of Unicode, and because of that, many, many
 more languages. So I would like to finish here by talking about what I think
 you can do, what we all can do.  Because, as I said from the beginning, I think
 all of us can start working with Internationalized Domain Names, but what can
 we do? First of all, I think it's really important that we all continue to
 develop local content, because it's the localized content which is key to all
 communication, I think. Part of that, of course, require localized software,
 because it's really difficult to actually create localized content if the
 program you're using and the manuals you have to whatever device you're using
 is in a language that you do not understand. It's also important that the local
 communities in the various countries and various language groups work together
 on developing local policies for IDN.  Because we will need specific dispute
 resolution policies.  We will need specific registration policies for domain
 names in the various scripts that is not taken into account by the technical
 standard in Internationalized Domain Names is. Other things we can do is to
 start to participate in this trial that we just heard about from our colleague
 from Russia, the ICANN test on Internationalized Domain Names.  And I urge all
 of you to go to the Web site IDN.ICANN.org.  That is a Web site in English.
 But you will find links to all the 11 scripts that the test is about.  And you
 can go to the Web site, see how your browser reacts.  You can also edit text
 and report back how your Web client is actually acting when using that script.
 Really important.  So I urge all of you to participate.  I'm really happy to
 hear that our friends from Russia are working hard on this project. The last
 thing that I think we can do much, much more regarding creation of local
 content is to help in the Wikipedia project.  And one thing that I heard from
 my mother, which is a teacher in art history, is that the school that she is
 working with had been forced to start to reject thesises from students that
 copied too much information from the Web.  My mother got a little bit
 concerned.  She doesn't know much about computers, but asked me, because she
 thinks that I know something about computers, and asked me, "Is it correct by
 us to reject thesises where information is collected from the Web and not from
 books, from paper?"  And I, of course, thought that was a pretty bad idea.  But
 on the other hand, she also understood that when you are a teacher in art
 history, one of the more important things to do is to require that a student
 write correct references, where do the information come from.  And she rejected
 a student that said that -- that claimed that the information was coming from
 Google. And yes, I like Google, sure.  But the information that you find in
 Google, the search engine, is not really written by Google.  It's written by
 someone else that wrote the article. Those kind of things are things that I
 think are important that schools educate in, and I actually came up with a
 suggestion to her that unfortunately her school did not accept, but I hope that
 one of you that are connected to the schools might take up this idea. Instead
 of rejecting articles that students write and copy from the Web, I would like
 teachers to give students, as a task, to actually update and write an article
 in the Wikipedia. So instead of copying data from the Internet, have people add
 things to the Internet. And then as everyone can edit things in Wikipedia, it's
 actually possible to grade the student depending on how many based upon how
 many people disagreed with whatever the student was writing. Wikipedia now
 exists in 253 languages.  And as we heard it's a very small number compared to
 the number of languages in the world.  But we should also remember that there
 are only 15 languages that have more than 100,000 articles. So even though
 Wikipedia is one of the more successful projects regarding localized content,
 it is not even as good as it looks. So there is a lot of things to do, and I
 urge you all to help. Thank you. [ Applause ]