The following is the output of the real-time captioning taken during the Eigth Meeting of the IGF, in Bali, Indonesia. Although it is largely accurate, in some cases it may be incomplete or inaccurate due to inaudible passages or transcription errors. It is posted as an aid to understanding the proceedings at the session, but should not be treated as an authoritative record.
>> Good afternoon, ladies and gentlemen. Welcome to workshop 32.
Next in eye DNS, Linguistic Diversity in the Internet Root.
This workshop is organised by ICANN in collaboration with AP ral lo,
with an a community of Internet users from the Australia region. My
name is -- I'm raim raip raim. We're going to discuss a project that
is being implemented by ICANN. This enables the introduction of IDN
into the root zone which allows access to IDN top level domains. What
we will do is share some information about the project, tell you why
ICANN has this project.
What the procedure is for enabling the introduction of IDN variance
into the root zone. What is the status of the project. And then we
will invite comments from community representatives on what they think
about this project and how it will affect the language communities
around the world.
And we will also get an idea what the var vants are for Arabic, the
Han script, the Chinese language and Japanese as well as indic. We
will start with executive vice president and chief technology user
of -- participating remotely.
RAM, if you are on line, #34r50es go ahoed.
>> RAM MOHAN: Thank you very much. I hope you can hear. So
Rinalia, thank you very much for inviting me to this session. It's --
both this session has important importance in terms of what the sense
of what we're trying to do but also the -- of what we're trying to do.
When only 27 of the world speaks English, which uses ASCII as its
underlying script, it seems obvious that the DNS needed to move to
support local languages and scripts.
Certainly through ICANN and the ICANN community the need to add
linguistic diversity to the Internet was established quite clearly.
But as with all things technical, it has taken us just over a decade in
order to achieve an overnight success.
In having IDNs, international domain names at the -- delegated at the
top level of the root system.
Let's speak for a minute about the strategic intent of the root zone
label generation root project. Before we get into speaking about label
generation, just a quick idea of what -- why they're really trying to
do label generations at the root.
The fact is that for each language it is represented underneath it by
a script, by a written form that is then converted into a digital wave
that is adapted DNS and resolvers can understand and interput. What
was clear was that at the root zone, swi a very unique resource, we
didn't have a list that clearly represented for each of the languages
that we wanted to have on the root to have what were the rules and what
were the representations in the digital format of these characters that
form the language.
The IDN variant TOD project was established by the ICANN board in
2010. And what this project allowed was the creation of a
multistakeholder project that was tasked to develop solutions and to
implement -- fine the implement rules of processing. So that we could
have the delegation of IDN variant top loader names in the root zone.
Now, the mult stakeholder model has been a key part of the creation
and the development and the deployment of the root zone label
generation rules procedure.
Now, as you know, ICANN in general works pretty hard on deploying
solutions, identifying solutions as well as deploying them by using a
community oriented multistake hold r model. The IDN TOD programme and
the variant part, IDN variant TOD programme is quite a good case study
in the development and deployment of the multistakeholder model and
multistakeholder system. To start with, various languages and
scripts -- script systems that were selected for study, analysis and
creation of the table, language tables and language rules, this pulled
in 66 experts from 29 countries and territories around the world. But
expertise in the area of DNS, IDNA, linguistic, security and stability
as well as policy, operations and registry and registrar perspective,
and to some extent, perspective from the end user and the Internet
users' point of view.
ICANN also created an issues report that looked at the risks and
looked at the methodologies for ruling out top level domains using IDNs
that had variants associated with them. And that too brought together
representatives from the various case study teams who were volunteers
and who were members from all around the world, from various
In addition to the participation that was -- that came together by
technical and linguistic experts and security experts from around the
world, the community at large has also been directly engaged. The at
large advisory committee has organised several extremely useful and
well attended workshops on the topic of IDN topical domains, usage of
top kag domains using wide bands, the deployment of variants using at
the IDN top level. And in addition to that there have been public
comment periods, conference presentations and discussions.
And all of this has happened not only inside of the ICANN context,
but also in other multistakeholder Flora such as the IPF.
So in conclusion, the -- this entire project is a strategic intent
for ICANN and the ICANN community, but most importantly ( it's of
urgent need for the world's multilingual community. Not deploying IDNs
at the top level has for years been a key criticism of the mono oral or
mono -- model of the DNS and for the first time in a long time we're
moving in a historic way from having only ASCII and only English or the
romance language that was entered at the top level, we're moving to
have local languages also available at the top level.
Now, technically keep in mind that DNS only knows ASCII, so even the
local languages eventually for computers, they get translated into an
ASCII equivalent, into a special code called quni code. That's a
technical detail. When it comes to the end user, with for the first
time we're looking at the ability to type in an entire website address
in local language, to send an email that is written completely in your
own local language, whether it is a left to right language or a right
to left language. That is historic, and that is also something that
has been built with the multistakeholder model at the core of it.
Back to you, Rinalia.
>> RINALIA ABDUL RAHIM: Thank you, RAM. I think that was very
valuable. I think -- she could type a domain name all the way in
Arabic and be able to use variants if this project is successful. To
understand what the procedure is, this famous procedure, I invite
Andrew Sullivan, principal art tekt of Dyn to share the procedure with
us. And he's here not because he's with Dyn, but because he's one of
the lead consultants that helped develop this procedure itself. So if
you do not like it, you can tell him so.
>> ANDREW SULLIVAN: That's right, it's all my fault. Thank you very
That's fun -- so I'm going to go very quickly here at the beginning
to give some reminder of the context of this before we go on.
So to begin with, the DNS is a tree structure and it's got all these
different levels and it was developed a number of years ago, in fact in
1980s, it's fundamental to the way everything works on the Internet.
U-can't do stuff without it. If you don't have the DNS, you're out of
luck and this is why people wanted labels other than simply ss ki in
there. Next, please.
Remember in the DNS they're made up of these little segments, called
labels. And these labels, whether it's way to the left or -- next --
even the right most one, they're just labels. All the same kind of
thing. So there's nothing special about any particular label. And
this is important to understand. The piece of the domain name is not
particularly important. It turns out of course there is a practical
consequence, technical consequences at the top level because of the way
the top level is used. The reason for that is that it's got this
So in the DNS we have these things delegations, and delegation can
happen anywhere. What happens is you take part of the name space and
give it to someone else.
This can happen, you know, anywhere in the tree, including even far
down in the tree. So this is an important other thing that is you give
away chunks of the name space and you don't have any control inside the
space that you've just given away. Another fundamental point.
Finally, we've got this one root, and this is one root by definition
when people talk about alternate roots they are amaking a complaint
about math. This is just a fact of directed graphs. And so there's
this one root. And that means this is a completely unique zone on the
Internet. And that's the key thing here that we have to have one
common set of rules for this zone because everybody in the world has to
share it whether they like it or not.
That's the reason that we need this.
All right. So we came up with this idea about the label generation
And what this is, we start with some fundamental things.
Yes? You want me slower. All right.
So we've come up with the label generation rules, and we're starting
with the basic facts of the DNS. The first thing is DNS names are not
words, they're mnemonics. They're useful things. But of course
mnemonics have to be useful to someone, which means that for you to be
able to use them, you need to be familiar, it needs to be a familiar
and recognized writing system and naturally if you don't use ASCII in
your everyday life, of course those letters are not very useful for you
and that's the reason why we need today do this.
We have to remember that the existing rules for the DNS already
restrict some labels. So in the DNS historically you weren't allowed
to use the word "can't with an apostrophe, you can't put the word argh
in there with an ex complamgs point because they are's not words.
There's just a bunch of mnemonics there.
We have new label, the IDNA labels, it's new, that means you need
more rules. That's the reason we need these rules.
Now, another important thing to understand is that these label
generation rules work on code points. So there's more than one thing
you could have done here. But the way that this actually works just
technically is it works on code points. Code points are a little bit
of of technology. Normally you think you're writing in characters or
in words, but when you encode this in a machine, you've got to encode
it in a character set. This character set that we're using is called
uni code and uni code is made up of code points and these code points
have funny names like this. U plus 0065, that's a code point. That
corresponds to an E. And Uplus 0638 is the Greek small letter Sy. So
these are just code points in every code, every letter that you can
write has one or more code points.
There can be multiples.
I said there can be multiples. Isn't this fun?
There is this problem when you have more than one code point and it
can be more than one code point as a reader, a competent reader cannot
tell the difference between one and the other, or it can be more than
one code point whereas a competent reader you can see the difference,
but you think they're the same thing.
One way or the other, you've got in some writing systems a case where
different code points can sometimes be interchanged one for the other.
They can be exchanged.
So one example is simplified in traditional try knee but there's
other examples, lots of other examples.
What we want to do in this procedure is present allocation of any
label to competing applicants. ( This is any label in the root zone,
only for the root zone, not making rules about further down the tree.
That stuff has been delegated away. And we also want to allow the
possibility of some variants, IDN variants that match each other and
going to be used by people always to go to the ofrj applicant. Both of
these features. That's what the label generation rules are about.
They define these variants and their possible disposition, in order to
do that you've got to have the list of all the code points.
So we developed a list of the allowable code points. Had is the
squalled repertoire. We developed rules for using this repertoire.
And the point of this is not to have a bunch of rules for whatever
people want right now. ( You don't want ad hoc rules that are subject
to political discussion every time. You want a rule set that allows
you to accommodate the pew it your developments, minimize the risk to
the root zone and make sure these rules are automatic. When something
new comes along, because new characters ged added to uni code from time
to time, you want to make sure they can be accommodated in the system
Now, it turns out that the Internet architecture board had a view
about what you should do in this case. And the reason for this is that
the Internet architecture board previously had something to say about
how the top level ought to be managed and prior to that there were very
old documents that said something about what should be in the root
zone. If we were going to expand, since this is something everybody on
the Internet needs to use all the time.
Came up with the principals on the side. The key one, the one that
is most important to take away, conservatism was the number one lelgd
pel to stick too here. When you Rand into any case where you weren't
shoe how it was going to work or whether it was going to work all the
time or useful all the time, the best thing to do was not to do that.
Not to use that code point. Not to use that label because everybody in
the world has to share this -- this resource.
So it's one thing to say way down in your local zone, you know, have
all kinds of crazy labels you want. But if you're going to have
something that everybody in the world has to share, what you have to do
is use the minimum thing that you can put in there while nevertheless
accommodating people so they can use labels according to familiar
writing systems, they can actually use them.
There's a flow chart here that gives you a picture of what the IDN
root zone works, this label generation rules procedure. The basic
thing is you have generation panels and they come up with proposals
much then you've got this integration panel. And the integration panel
is supposed to be universal world experts who are suppose today achieve
agreement among these competing proposals. The proposals are not
supposed to compete with one another, from time to time you're going to
get cases where different language communities either use the same
letters or use letters that sort of bump up against one another, and in
that case you need to make sure -- you don't need to decide one in
favor of the other, what you need to do instead is coordinate to make
sure that nobody's ox is getting gored to much. We want to make sure
that all the oxes wonder around happily. That sometimes mean you say
no to people, but the reason you have to do that is because you know,
this is a common resource and we've got to share it. And at the end of
this you spit out this label generation rules and it defines these
things there on the slide.
Okay. Why do we have only one set of rules? Is.
As I have said repeatedly but I'm going to hammer you with all of
this because it's been one of the things people keep complaining about,
it's only one zone and it's a common zone. We can't get away from it.
Everybody has to have it. And therefore we need one set of rules and
we need only one set of rules for the entire zone in case there are
collisions in the different rules.
The generation panels are volunteers and they're supposed to get
together. This is supposed o to be very much a bottom up process. The
goal of this is to represent community interests and also to make sure
that he have woo he particular writing expertise. Invite these outside
experts and so on, and that will work.
The integration panel is supposed to be really serious experts in the
various technologies that are being used here. So DNS, IDNA, uni code,
linguistics. They're supposed to accept these generation panel
proposals and supposed to put them together and finally come up with a
common set of rules. And importantly, they're supposed to make
decisions unanimously. So they're not allowed to make decisions -- I
know, I'm running out of time --
but I'm not going too fast, exactly.
Finally, you've got this output -- and this is the overall repertoire
for the roolt, divided into subrepertoires by script and
these labels are constrained to be wholly within a
subtagged repertoire. You've got these things that
somehow get a linguistic piece with it. I didn't write
these slides, so -- I would have been shorter.
Finally, and this really is the last thing I have to say, only some
labels, some writing systems have variants. And variants
are defined globally not by subrepertoire. Despite the
repertoire you says everything in this label has to be in
the same writing system, variants actually cut across the
entire set. And this is all in a machine readable format.
It can be processed automatically. I'm sorry I went over.
>> RINALIA ABDUL RAHIM: Thank you, Andrew. And ICANN has actually
started the implementation of this project. And acram ala is here to
tell us what the status is. And he is the president of the ICANN's
domain division, which coordinates the coordination of this project.
Go ahead, ak RAM.
>> Thank you for coming here and listening to this important topic.
I'll leave them to the end. The integration -- the implementation of
this procedure is actually well underway. We have actually started
with the integration panel, which has been launched. And melt already
earlier in October.
They are working on setting up the repertoire or the bigger set of
what the LGR set could be. They are also putting their -- you know,
putting their arms around the maximum set. They are looking at the
label evaluation rules so that everybody can do the same, follow the
same procedures. They are also looking at the format for submitting
LGRs to the integration panel. So that doing the guidelines for how
the generation panels will interact with the integration panel. On the
generation panels there was a call for generation panels to be formed.
We've received statements of interest already from different stricts.
Once these -- once a script or a group of people get around the
script and decide to form a panel, that panel will be seated and
immediately after that they can start their work.
So we're expecting the first panel to be launched before the end of
Now, that depends on the, you know, how quickly the committee can
organise itself around the scripts if it wants, and that if want toss
Today we have a lot of scripts inmremented in the DNS. We have nine
scripts that are included in the new GTLD applications and there are
already another eight that are included in the CCTLD eye DNS. We
expect the generation panel will be formed to make all of these and
there is no reason why we can't implement additional generation panels
if other scripts would like to start their work earlier.
I want to say that we're behind. There's no question about that.
Ideally all of this work should have happened before the DNS was
started. So that it would have been designed with all of the scripts
So that the rules that are set took into account all of the different
scripts. But we are where we are. And I think this is very important
work and we're just scratching the surface.
We talk about doing this work for only the root, but I think once
this work is done, then there will be a large implementation for this
work. I think a lot of the TLDs will take that aadopt these LGRs for
their second level and third level.
I think there is a lot of implementations where once we set the rules
for variants, these variants rules will also apply downstream. So
there is -- this work is just the beginning of a lot of advantages for
other scripts and the Latin script. And I'm looking forward to
actually seeing more progress on this. And hopefully we can take
advantage of these rules to start thinking in a lot of different areas
with multiple script mentality. I give an example. There is a lot of
rpns in the TMCH. These rpms are thought of in just ASCII. Rpms
stands for rights protection mechanisms for trademark holders.
So when you think about these mechanisms and they -- the way they're
developed, they're developed by a mentality and a thought of English or
Latin script. Once we get the same applications or -- of TLDs and IDNs
that go into TMCH, there will be an advantage because nobody's thinking
in those different scripts what are the variations that should be
protected. For example for a trademark.
So just start from there, you can see how we're so far behind. We
need to catch up.
So -- thank you very much. I will be happy to take questions later.
>> RINALIA ABDUL RAHIM: Thank you, ak RAM. Would I would like to do
now is invite comments from three representatives from end user
communities. They represent the language communities of Arabic,
Chinese and Indic script. That's you.
And we have Mohammed El about a shir, bMohamed El Bashir, he has some
slides. He waes supposed to be here. Unfortunately there was a dns
attack on his registry and he had to be in Qatar to take care of it.
Therefore he's participating with us remotely today.
Maureen, do you have his slides here?
Yes. Is he online he's not online. Okay. So he's not online right
Okay. The dns atacted and intervened and took him away. We'll go to
the next person, then. Hong Xue.
>> HONG XUE: Thank you, good afternoon, ladies and gentlemen. My
>> HONG XUE: A law professor from Beijing normal University. Where
time goes fast. I remember 13 years ago in 2000 when the word number
one, word first, language-based IDN consultant, consortium was
established in Beijing. I was one of the drafters of the charter along
with professor Wu, sitting over there across the table. But CDNC is a
first community based -- language community based IDN process to deal
with the variants and the other IDN variant technical issues. I guess
that's very good community based initiatives. And in 2000, ICANN stab
established a first working bored chaired by Mr. Katu osinabu. Made a
first submission to this working group and made the first policy
proposal on IDN TLD management. I was the pen holder of this first
mission but idea primarily came from madam hu, ching hunk who is
president of -- China and has been accredited to the hall of fame by
athought this year. We propose that for IDN variants management it
should being absolutely based on language communities proposals and
issues. And we propose rough policy issues such as for IDN TLDs, ICANN
which go to the easier part first, think about IDN cyst TLD first
before identifying -- after 30 years our proposal has become a reality.
We're so happy yesterday, the first group of Chinese ID N TLD has gone
So this is very much positive achievement.
I'd like to go to a few principles that's been experienced by Chinese
community, even though we're not very good at summarizing these
principles but it has been enshrined in practicing. One is
community-based. It must be based on the language community. Language
community is a concept first raised by Chinese language community. In
that first submission to ICANN. And I hope I can do -- ICANN retains
these historical documents. And we could refresh our institutional
memory. It seems it can be fun anywhere in ICANN that size.
Language community is open concept much it is not defined by language
sofrnt. That's ridiculous. If you speak that language, you are in
that community. So we are often joking that there is a bigger
English-xeeking community in China than United States. So as far as
you speak that language, you, that language community, and certainly it
should be a bottom up process. Think about the CDNC Chinese domain
name consortium. A he can it kal community. It's thot by government.
And thirdly it should be multistakeholder. CDNC is a very
interesting organisation. Professor Wu and I were the founders, among
the founders. We're now only observers. It is multistakeholder was
due there but we are now observers, in civil society it is now only
open for the full membership for registries. Primarily CCTLE -- but we
can call it a multistakeholder organisation. And also last but not
least it should be consensus based. I know from the readers how to
deal with disputes. I strongly dislike disparity resolution. Even
though I'm a lawyer. It is consensus based, it should find common
dominator accepted most widely in the community.
Even the code point permissible in this DNS system, especially root
level, it should be really acceptable to that community because it's
user in that community is really going to use those codes. Thanks.
>> RINALIA ABDUL RAHIM: Thank you, Hong. I think later in Edmon's
presentation he will give the example or case study how the Chinese
language in the Han script language came together to resolve their
differences. Next I would like to invite Satish Babu.
>> SATISH BABU: Thank you, I am from the international -- software
in India. I will be speaking from the perspective of a user, as --
especially from south Asia for the technology aspects we have senior
people from both the government and technology side of things from
So I'll steer clear of the technology aspect.
First of all I'd like to say that IDNs actually is a very important
compliment of multilingualism which reaffirms the universal access that
we have been talking about since yesterday.
As far as India is concerned, we have a lot of complexity with about
22 languages, with about 19 of them using 11 scripts. So again imagine
the whole idea of -- 11 ought mattic scripts and three Arabic scripts
much we have problems of one to many and many to one. Some languages
using multiple script, some scripts being used by several languages.
One for example is used by nine different languages.
Now, these actually kind of pose several complexities. In addition,
we also have issues with things like rendering with multi tear lifts,
baseline shifting, homo graphs and homo phones. We don't have the
issue of low word upper case. But we also have issues like with pretty
kind of unique to Indic languages, with 0s and so on. Some languages
do not have all the letters. Translation is sometimes difficult. One
language not from India but the Urdu language uses the same script, the
naslik script which is vertical, it goes up as you write. It's a very
beautiful kind of representation. And this last week we were reading
that that script is dying out because computers are not able to support
that particular script. And the community is actually really concerned
about the loss of the diversity.
So we have, you know, several issues of both encoding and rernding
which are -- because of the fact that we have these many languages.
Now, as far as the procedure is concerned, we have some general
recommendations. The first recommendation is the mechanism specified
by the procedure for the oversight of this whole process is the public
comments. We are aware that public comments causes a kind of
multistakeholder organisation, that is the only way we can go.
However, we would like to highlight the fact that there are some
weaknesses of this model as well. For example can be ensured that the
participation of all 11 stakeholders is effected. You know, all the
logistics and mechanics of this procedure. I would like to flag the
issue as one that requires perhaps a little more work to ensure that
there is transparent representative activity or action that goes on in
this public comment process.
The other issues that there is a lot of interest in India from -- on
this issue of the IDNs, international domain names, there is, as you
can see, has been mentioned already, we are quite active in terms of
the already GTLD representative right now and also delegated, they
have -- have already been delegated.
Now, in the issue of the panels, the problem is that the fragmented
kind of language communities in India, as very different from what Han
mentioned in terms of Chinese, for example, a fairly homogenous kind of
community, how are we going to ensure that the communities are aware of
these processes and how do we -- what are the facilities that we have
at hand to ensure that the participation of all these communities is
That I think is something that we have to -- we're not clear, but
sitting in India, in fact the corner of the country, we do not see a
process of facilitation that exists for the smaller language
communities. In the -- like in Hindi and all, are not very sure, but
smaller communities there is this issue that the process is not
transparent and participants as of now. I would like to flag that as
also an issue of concern. That in a very, very diverse country like
India, one has to take care of.
Thanks very much.
>> RINALIA ABDUL RAHIM: Thank you, Satish. After this we would like
to get the presentations from the expert panel and I would like you to
get ready. You're starting first. You want to come here and present.
And while he's setting up, do you have a response, ak RAM, in terms of
what is ICANN doing to facilitate, the smaller ones, how are they
getting to know about the project, and are we doing anything about the
weakness of the public comments?
>> Ak RAM: Weaknesses of the public comments. Yes, I can as looking
into the public comment process, ICANN in the community, we've done
multiple reviews on that and continue to improve the process. (.
We would like to see the public comment in multiple languages, but
right now the majority of the public comments that we get are actually
in -- in English and we haven't seen a lot of demand for other scripts
into -- in the public comment.
Nonetheless, an area that we're more than willing to investigate and
look into. Today as I mentioned on the -- on the LGR, there are about
17 panels that we're expecting to be working on different scripts. We
don't have any outreach programmes right now other than the grassroot
outreach programmes that you guys are doing to reach out to other
communities and see if there's anything interested. But we are more
than willing to participate and help if there are any communities that
want to do a -- form a panel on a script that's not -- that hasn't been
mentioned at this time.
So please let us know. And if you need any help, we'll figure out a
way to help you in it.
>> RINALIA ABDUL RAHIM: Yes, thank you, akRAM.
ROM would like to make a comment. Go ahead.
>> RAM MOHAN: For the previous comment for more communities and
languages, I guess my perspective is that the need and the interest has
to be reflected from the community into the process. As akRAM said,
the process is quite open for fulfilling these needs. When we -- what
I think a quite a bit of the initial start-up -- righting wrongs, even
in the local language community. If you look for example at the one
script, I think it would be important to get together and define what
needs to be done to represent it in the DNS. And then come into the
process. Because the process is welcoming and embracing of all the
various languages on the representations. You know, on the DNS, so
long as you can get to unique representations.
>> RINALIA ABDUL RAHIM: Thank you, RAM.
Are you ready now, Sarmad?
Sarmad Hussain is going to make a presentation about the Arabic
community and the work that they're doing and to give you some idea of
the variants in Arabic. He is professor of computer science and head
of the language of engineering, University of engineering, Pakistan.
>> SARMAD HUSSAIN: Thank you, Rinalia. I will give an overview of
what is the latest progress as far as IDNs and variants are concerned
for Arabic script. Just to start with a little bit of history, the
community work for Arabic script actually started long time ago, back
But the more recent work started again when the IDN RFCs were revised
in 2008 the Arabic script community came together again and formulated
a group to look at the relevant issues related to international -- it
was a develop phone group by the name of -- Arabic script idea group.
The group worked for a couple years. It had participation from
multiple countries, pull pel languages. And were able to come together
and do the relevant homework. Which as I will share later was then
taken up by other initiatives later in the stream. (.
In around 2009 the first track process was started, and many of the
communities, countries which were using -- which are using Arabic
script actually used the fast track process to apply for the local
strippings, strings in Arabic script.
The initial homework which was done by Asfik was eventually used by
these communities to develop language tables. They weren't called
language tables at that time. They're now called language generation
rules. And they were submitted to ICANN along with the applications.
And many of those obviously ccTLDs, have been approved and many of them
are now delegated and working.
So later on there was a start of Arabic variant issues project.
Arabic -- sorry, generally variant issues project and Arabic was one of
the languages selected as a case study. There was a team formulated in
2011 which worked in -- in 2010 and delivered a report on Arabic issues
with Arabic script as far as variants were concerned.
This work was actually in continuation with what the initial work,
which was started by aswig.
Further down once the issues were identified, they were -- the
community also contributed to the user experience study done by the
variant issues project. And currently it has now coming together. It
has actually come together again as a task force on Arabic script IDNs.
I will talk a little more about it towards the end of this
I think one of the things which I'm trying to present here is that
the Arabic script community actually has been very active for many,
many years now. It has done a lot of homework. And it's actually now
very ready to actually go and do the next step and develop the LGR and
start getting the variants.
Okay. Just to give an overview -- I'm not going to get into details
of this, this is all documented in reports. Elsewhere.
But there are lot of -- the idea of variants, which Arabic script
has. There's three large high level categories. You can have
characters which are duplicately encoded but have exactly the same
shape. They have some characters have shape in all context, same shape
in all contexts, some have same shape in certain contexts. And there
are also characters which have similar shapes, not same shapes but
they're still confusing for user communities. And then there are these
third kind of characters which are totally different in shape, but the
user communities consider them as the same.
So there are all these different kind of variants which exist and it
needs to be tackled with as far as generational label, generation rules
as concerned for Arabic.
So there is obviously a need for this. Soez you see Pakistan written
there. Even though it looks exactly the same way, it has internally a
different set of code points. So these two things will look the same
to the user, but will need to be -- the current system would consider
them as different strings. It should not be considered. They should
not be considered as different strings. So some mechanism through
variants should obviously need to be introduced to map these onto each
There are about 120 such cases in Arabic script so far which have
been identified for further discussion. And they need to be eventually
worked out for -- by the community. And then all the variants which
are generated, they need to be eventually -- some of them at least need
to be located because different user communities use different
keyboards. And so some people will be, for example, typing 0643 and
some peep will be typing 0689. So you cannot allocate one and block
the other and so on.
And then there is real need so out of the 16 CCID applications, with
ICANN right now, four have applicant -- four have requested for
variants. So that's like 25 percent. So variants are needed. Though
they are need, they also pose some challenges which need to be
obviously addressed. Again there are multiple layers of these
challenges within the processes, within the tools, within the user
applications. Obviously for example one of the key things is a string
may have more than 500, 600 variants. So how do you decide which
variants to activate and which variants not to activate?
Some of those challenges obviously need to be met eventually.
So let me now come to the last part of my presentation. Which is
focussed on what -- what are we doing now.
So as I said, based on the history, there has been homework done but
that work now needs to conclude into what is labeled generation rules
set for rule zone. But -- root zone. Generation are not only needed
for root zones, also for other notes down the tree.
So the community's actually come together through middle -- actually
a strategy group formed by ICANN. It's called middle strategy working
group. And it's actually formulated, dedicated task force to not only
look at LGR, but actually look at Arabic script ideas holistically in
larger context. LGRs is root zone LGR is obviously the first thing
which this task force is going to take up. But it is not going to take
this up in isolation. It's going to look at Arabic domain labels
for -- in other contexts as well. For example second level LGRs,
universal stablt of Arabic IDNs and so on. It's going to take up many
Just to give you a little more introduction of this task force,
it's -- its membership is open shall it's community based. There was
actually a public call done for it. ( In August and September time.
Applications were received. Everybody who had applied was incorporated
in the task force. It's a rolling process. Is' not something which
was closed in September.
To ensure -- so the task force was formally announced at Arabic IGF,
two in Algeria recently. We've actually been making sure that there is
diversity in this task force. So currently we have 20 members and 15
from 15 different countries. We started at about 15 members from about
12 countries. But we were missing some significant representation from
languages which are not covered. So we have been able to go out, we
reached out to people who worked with those languages, invited them to
join the task force and brought them on board. Now actually the task
force covers a reasonable variety of languages which include languages
across southeast Asia, south Asia, Middle East, north Africa and sub
Saharan Africa. And I will conclude here. Thank you very much.
>> RINALIA ABDUL RAHIM: Thank you. Akshat Joshi Joshi will present
>> AKSHAT JOSHI JOSHI: I will be giving you an overview of various
cases through the Devanagari study went. Before I get started I would
like to give you an overview of Miss Organisation that is Cdek. We are
based in India and we are working on multiple level computing. Most of
the operations are based on language processing. And why we are
working on IDNs is we had initially been working on the Indian IDNs and
IDN, CCTLD. And we have been working with the parent organisation with
the dot IDNcctld.
We have mrn planning on working on -- and we have done fairly good
amount of ground work for that. There were some issues that came up
when we talk about launching IDNs in Indian languages and subsequently
even when as the new programme launched, the need for identification of
issues for Indian languages was filled by ICANN as well and then this
So there's a bit of background. I have just roughly divided this
presentation into four parts. Initially overview, then we go into the
issues, solutions and some of the probable resolutions which will take
to the final groups on NGR for the Devanagari. Devanagari script is
basically a -- it has alphabets and syllables. The main components of
the writing system are consonants, which are standard -- stand alone
consonants. There are vowels, which are accompanied by associated die
creddic marks. I will just view -- this image over here, just using
glimpse of what -- where it is possible combinations that can be done
with a root character. I will just try to elaborate a bit on this.
This is the highlighted part, the base character. And what is
surrounding that, these are the various characters which can be
associated with this base character to form multiple shapes. This is
the Devanagari script as representative. And here are other scripts
like this is Bangla, and most of the other scripts. These all are
scripts basically having the same parent script that is Brami, the
founding principles of these scripts are almost similar, even though
individually they are a bit different.
So when the project started, there was discussion regarding whether
we should only go for the Devanagari or some associated scripts. But
then it was thought of that we'll start with the Devanagari and since
the Devanagari has the same structure and similarities as other family
based scripts, most of the issues will be applicable equally to the
other scripts as well.
Entering into the issues part, I will just try to stress upon the
point about why visual similarities are concerned for the Devanagari
script. When by the numbers, the Devanagari typically has 37
consonants which are general use. 15 vowels which combine with the
consonants. And 14 vowel signs. There is just a bit of math over
there. Let's say that with these many characters we have 6951 basic
shapes. Which a normal user can understand.
And then there is another concept of concern too. Base consonants
join with each other to form a different combination, visual
combination. If we add up that thing here, what we end up actually is
in 57,000 different shapes. Which a user can understand. Not all
57,000 are in use, but if you go by the -- whatever is the general
usage, it still stands at 25,000 unique shapes. A regular font has 500
basic glyphs, out of which the characters are composed.
And then there are even more complex levels that are not even going
into that level. But these are the number of shapes that are possible
in the Devanagari languages. And with these many shapes, the visual
similarities definitely becomes a prime concern.
Apart from visual thing, there are foe nettic variants in Devanagari
based languages. So the example over here is the word Hindi in two
different forms. It's just that it has different storage, but while
pronouncing, it is the same for everybody. There are additionally
linguistic variants as well. So recently Bombay has changed its name
from Bombay to mum bye. For many people this is kind of variant. When
it doesn't matter whether they are talking in terms of Bombay or mum
bye, they are talking about the same city and they know it. For them
it's not much of a different thing. (.
But what is the ground situation when it comes to the Devanagari
script since it is a complex script, there are many accents to play in
these scripts represented in the digital medium. And some of the prime
actors here are Internet browsers and the operating systems. For all
these to happen, it is not as same as like in script. There is an
original component that operating system inserts into the system that
is rendering engine and it varies from each operating system to
operating system. That amounts to the differences in individual
appearance of the characters. Coming to the solutions part, this was
one of the founding principles that whatever is the solution that would
be proposed, it has to be -- the decision has to be definitive,
nondisputed, and it has to be programmatically implementable. Because
the domain registration work, it's an automatic system and we cannot
have a manual intervention into it.
Ground relates about the kinds of variants we have is foe nettic
variants, those are not definite. Because dialect changes, phonetic
variants change for people. Those cannot be -- cognitive difference,
some say mom bay and mum bye are different -- but it may not make
difference for somebody else. Visual variants are something which can
be handled pro ma'am mat particularly but it calls for another thing to
be resolved. And had an is achieved through a term known as whole
label evaluation roots. I will try to touch upon that in my last
So what ultimately the resolution will turn to. It was that we can
do visual variants and they can be accommodated into this process.
But one of the key things that was discussed when we were discussing
the visual variants is there an already existing ICANN process which
deals with similarity. Whenever string is delegated, there is string
similarity tool that is -- which gives the similar look and feel of the
already existing -- a primary thought is if something needs to be added
it can be added to enhance that process. But this visual similarity
analysis calls for a given that is there are certain ways in which
these languages are represented. And if somebody wants to create
something which looks similar to an already existing thing, that can be
generated out if it is not a valid construct.
So having a valid construct for a popular domain in the Devanagari
based languages is definitely needed and that will be achieved through
this whole level evaluation tools for the Devanagari.
I have just given an example. Like the second word is not well
formed. Even the third one is. Whenever there would be some kind of
validation that would be performed on this labels, and only those will
pass the system which are valid as per the whole label evaluation
So these are two things that we have discussed and agreed upon that
may happen. Ultimately the decision will be they can recommend the
community comes together and they discuss whatever the possible
solutions. But we think this should be sufficient for the case.
>> RINALIA ABDUL RAHIM: Thank you, Akshat. I forgot to introduce
him. Quite a few. Akshat Joshi Joshi is project engineer from the
centre for advanced developing community in India where ICANN
established a centre of excellence for DNS security. Josh yosh yes.
>> RINALIA ABDUL RAHIM: Yes. Congratulations. Next is Edmon, are
Okay. And Edmon Chung is CEO of DotAsia and chief engineer of
society Hong Kong. Edmon Chung thank you, Rinalia, and as I bring up
my presentation -- one?
It's already open. Thank you.
>> EDMON CHUNG: ( I'm going to be going -- okay.
So thank you, Rinalia, and Saverages rmad.
I will talk a little about the experience from the Chinese community
especially on driving the development on the Han script IDNs. I
thought I would start out with talking about what is an IDN variant?
In fact unfortunately to disappoint you, one of the things that the
community has really found ought is that it's sort of an elusive thing.
So in the true spirit of the Internet and this multistakeholder
approach that we talked about, this is kind of a -- we're not achieving
full agreement on what an IDN variant is. But if we can have enough
agreement to work towards, you know -- to work together, that's really
what it is. But I still want to -- seeing some new faces around --
this is kind of the worst, easiest to understand way to talk about IDN
variants, I guess.
It's that imagine that the capital letters and small letters are
technically different on the DNS. We might need to have policies to
make them the same in a way.
So this is a situation with simplified and traditional Chinese where
we identified the issue. Don't take that analogy too far because it
will break down a lot of ways. But that's the easy way to understand.
So what they are, I guess a way to summarize that, these are things
that have linguistic origins. They're different characters that are
being used. Because of certain technical limitations of the DNS and of
how we use the DNS, there are policy implementations that are required
to implement IDN variants so that it is better used by Internet users
when they use the Chinese domain name, for example.
Hong already mentioned about the CDMC, the Chinese consortium formed
in 2000 and a couple IETF RFCs were -- were created from the work.
And -- along with other people as well.
One is called the jet guidelines for IDN, another focus more on
Chinese domain names.
Another thing that is of importance, I guess, is a couple of IDN
tables were submitted by C. N. Nick and T. W. Nick respectively. And a
couple years ago dot Asia ourselves also submitted a table that
essentially put together the CN table and TW table. And here is why.
And I explain it because it's very relevant for our discussion at the
root. Which Andrew mentioned. So as a basic, the policy is that if
you applied for a simplified Chinese string or domain name, you would
get the traditional Chinese string as well.
As a variant. And you would have reserved other types of strings
that are basically generated from the table. The challenge then for
operating as a GTLD versus a CCTLD is that in the CN, TW, and also in
this case Japanese tables, they have a context based on the TDL, krfrjs
cTLD, like dot J. P., you would expect the Japanese, dot c n. That's
Chinese. In the case of Asia, or TDLdsz. There is no such context.
And therefore additional considerations need to be made. And such
considerations need to be made both on utilizing simplified Chinese
together with traditional Chinese as well as the overlap with Japanese
Condi characters. Here's a quick example of one of the characters
which is somewhat interesting. And this is a character that can mean
here or development. And there's also a Japanese congi character
related to the set of Chinese characters. And these are -- this is
some of the issue -- one of the issues or actually one of the main
issues that the -- when we talk about ( I guess Han script or Han
characters are being used in the IDN in the root or in a GTLD context,
we will probably need to consider the simplified Chinese context,
traditional Chinese context, as well as Japanese congi context. And
although I've, you know -- talk about this as if there's a lot of
problem, I think the community has spent the last 13, 14 years working
out the solutions. And I'm glad to -- well, at least I'm hopeful to
say that we're quite confident that we have a pretty solid solution set
based on policy implementation for IDN variants much.
But that being said, I actually just before that -- one of the things
that I wanted -- did want to bring out as well that you heard about
Chinese both simplified and traditional and you heard about Japanese
congi, one somewhat popularly used Han character usage in Korea, which
is Korean Honja is not discussed. Thaus that's because there is a very
strong consensus in the community from Korea that Korean honja will not
be aused or allowed for registration in the Korean IDN context and
therefore they're not included.
As a summary, the Han character IDNs really we're talking about --
when we talk about in the GTLD context and that I guess that relates to
the root context as well, we're talking about the sort of intersect
or -- intersection or union of simplified Chinese, traditional Chinese
and Japanese congi characters.
And that brings me to I think what -- something that's even more
important, I think, for this programme as well. Which is the user
experience. Because ultimately the IDN variants are implemented,
policies are implemented to enhance the user experience. There are
certain challenge, Internet user, registrants, registrars, hosts, how
do they deal with the different variants that are essentially distinct
DNS entries but how do they host it so that it's considered the same
domain by policy or by somewhat with the same applicant -- with the
How do registrars and registries handle it?
With that actually it relates very much to a problem which generally
called the universal acceptance of DLDs or universal acceptance of
IDNTDLs in this process?
Similar problems, similars points of failures where ISPs might choke
on IDN variants or TDLs. There's a common interest being built between
the ccTDLs and the country code domains and top level domains shall the
key message I want to bring forward is this really requires
industrywide collaboration. And it's not just an ICANN issue and it is
the whole user community and the technical community issue.
So really what we're talking about is that a lot of times interfaces
or applications, they have preset certain lists of TLDs. You see a
drop down box and if the new top of domain or new IDN top level domain
is added, that field needs to be compatible. Another type of scenario,
if you try to sign on to a social network, for example, your email
address or your URL, will that database accept IDNs?
There's also the search engines and search engines have different
components, the search results, the advertising results, and you know,
some other results. Will they accept IDNs especially variants, IDN
variants as well?
How do they relate?
Emails of course, that's one of the top usage or domain names as
And how would they -- how would email clients react?
Why are they not accepted?
A number of reasons why. A lot of them are based on technical
origins. One of the reasons that we found is that a lot of
applications or interfaces utilize hard coded list, they're not easily
updated. They might use different lists that are out there. That is
not fully synchronized with the ICANN root, the single root that Andrew
mentioned about as well.
And there are certain applications that check this length of the
string. So you know applications expect that top level domains are
either two characters or three characters long. But with an IDN
because of the Puni code, the technical implementation it would be much
longer. How would these play?
And of course there are other sort of gatekeepers as well. Like spam
filters, like invalid email addresses or invalid domain names. Systems
are out there that would need to know about IDNs that would need to
know about IDN variants as well.
With that, what has been done?
Actually the ICANN SACK, this is not an entirely new issue, it's an
issue that has been anticipated for a long time. When new GTLDs were
introduced, info and dot museum, some of the issues surfaced. And the
SCAK came out with a report, with a number of recommendations. ICANN
has implemented a number of them. Not all of them have been
implemented. A couple of them that -- that has been implemented
inclusion a TLDverification code that ICANN has produced and hopefully
more people will be using it many there's also a draft set of outreach
materials that are being developed. And frankly, a joint working group
between the CCNSO, and GNSO is putting out a number of recommendations
to -- and Hopefully this will be -- the process will be completed and
the two councils will be presenting this -- these set of
recommendations to -- back to the board, ICANN board. One of the key
recommendations there is to at least get our own act together. Because
what is interesting is that we look at some of the registries and
registrars who offer IDN TLDs, they themselves have their own systems,
may not be fully compliant or may not be fully embracing IDN TLDs or
especially IDN variants in like email addresses or like name server
records for domain names. This is an issue. Beau the acceptance of
IDN TLDs, and especially the accent tans of IDN variant TLDs. Or
variants in general. This is an issue that unless we address it as a
whole, will continue and will be amplified, especially when we see IDN
ccTLDs being implemented now and of course we recently heard -- know
that IDN GTLDs are also being implemented into the root. So with that,
>> RINALIA ABDUL RAHIM: Thank you, Edmon. I think it would be fair
to say that universal acceptance is probably the highest on the end
user community agenda in terms of problem.
So I'd like to go around the room and see if there are any questions
or concerns. And I know we're running out of time, but I will take a
little bit more time.
Is your hand up?
I see Olivia and then Huru.
>> Owe life yo: . Of lecture. We've spoken about universal
acceptance and user -- user ability by the user community. What's the
status with regards to the actual applications running and their
ability to use those new IDNs?
Email, Web browsers, et cetera?
I sew know some perform some verification and some might not call for
any more. Is there any status on this as well?
>> ANDREW SULLIVAN: The short answer is that on the Internet,
because it's a permissionless system, there's end to end, the
innovation is really at the edges.
It's very difficult to guarantee universal acceptance of anything.
What we do know is that we went through a round of this back in 2001
when we added some top level labels that were longer than
traditionally. And they haven't worked consistently everywhere, some
of them still to this day.
So I think we should expect that there are going to be some barriers
and there's going to be some difficulty. Not because they won't work
in the DNS, but because they won't work in certain applications or
something like that. There's nothing to do about that except to
encourage people not to do that.
I will say there are some technical work going on to try to
discourage some of the sis at the presents that have traditionally been
used in order to do this. Including some work just to toot my own
horn, some work I have tried to push through the ITF in order to
suggest a new way of tracking what is a legitimate top level label and
what is not.
>> RINALIA ABDUL RAHIM: Thank you, Andrew. I think RAM also wants
to respond to that question. Go ahead, RAM.
>> RAM MOHAN: Just a wrap-up, not a question itself. So I can
take -- raim thank you for that question. Huru, you had a question?
>> Thank you. This is Huru, from the J. P. I have a question about
the requirement for the variants. Today's session I think is mainly
focussed on the definition of IDN variants.
On top of that, there should be some requirements such as -- as
Andrew said, allowing location of some IDN variants to the same
So it's related to the last part of Edmon's presentation. Or they
may be touched on Edmon's presentations in a way.
But on top of that, then a need of some requirement, or is there any
possible further requirements for the resolution of the variants?
Of the domain name such as variants of a domain name should be
reserved to the same IP address?
Which may be good from the aspect of user experience.
Was this kind of topic discussed?
Maybe I'm wrong but universal acceptance seems to be now focussed on
the unique user experience across TLDs, but how about the user
experience among variants?
>> EDMON CHUNG: If I got your question correctly, you're talking
about a potential discussion about a requirement for handling IDN
variants and how it's put into the DNS.
The current -- at least my current thinking or at least the Chinese
experience is to say that on a registry point of view, to allocate it
to the same applicant, and also to delegate to the same set of name
As to the IP address that is being used, if you are talking about an
end resource like a website, or a Web -- resource, I personally think
that might not be what -- at least at the ICANN level, registry level
we should be regulating or trying to at least make a definitive
I think if we allocate it to the same applicant and delegate to the
same set of name servers, that should provide the -- enough kind of
package for users and registrants as well.
I put out an example. Like for example in simplified Chinese and
traditional Chinese nooez, it is quite possible, in fact we are seeing
that happen is that the -- the registrant for a domain name would set
the simplified Chinese to Web servers in China and set the traditional
Chinese to Web servers in Hong Kong or Taiwan. So the end record, the
IP address of the resource may not be the same.
But in set of name servers on the registrant should be the same.
>> RINALIA ABDUL RAHIM: Thank you, Edmon. I think RAM wants to
respond to Huru's question, is that right?
>> RAM MOHAN: Thank you very much. I think this is an area where
one size does not fit all. Depending on the local, depending on the
registry, and most importantly, depending on the user community (, the
decision needs to be made as to whether variants should point to the
same place or to other places.
In general I agree with Edmon that it's not an area for regulation.
But at the same time I think it's important to note the distinction
that within the registry it might be very useful to have consistency
over policy about what happens to variants. But across registries,
there probably ought to be a space for variation depending on locale,
community, and type of TLD.
>> RINALIA ABDUL RAHIM: Are you happy with that response, Huru?
Any other questions around the table?
I'll look to this side first.
Go ahead, clep clep clep.
>> OLIVIER CREPIN-LEBLOND: Thank you, very much. I understand the
Chinese one has reached the end of its work -- there might not be an
end to the work. Ongoing work in the Chinese one. An Arabic one
started. Is there a calendar of the start of other task forces with
regard to other scripts as well?
>> We just talked about that. We opened, we made a call for
application for the panels. That are going to form the LGR for each
script. And that just happened in July. So we'll see -- we received a
few. We expect the first panel will be formed before the end of this
year. And so we expect about 17 scripts that will participate. So
we're waiting for that to happen. So it's just happening now. So...
>> EDMON CHUNG: Just to clarify, I think owe life yea, you are
you're asking there has been a lot of community work done in different
communities and Chinese started way -- a long time ago. But the LGR
process in the root, that is just beginning. (.
So each of those panels are just being formed. So none of them -- I
don't think any of them have been formed yet. So it will be formed.
And -- but the work will not be wasted. I mean work from the
community from long time could be utilized and hopefully quickly come
to conclusion with those panels.
>> ANDREW SULLIVAN: A key piece of this, though -- I just wanted to
emphasize this because I don't think I made it clear earlier. A key
part of the design and part of the reason there's this complicated
two-Phase sort of permit procedure is that the integration panel can
actually start producing label generation rules before all of the
characters in the world have been considered.
So the -- part of the point of the design is to make it possible that
if, for instance, people -- the Chinese community and the Arabic
community and -- maybe just those two -- are ready. And nobody else
has done any work yet. You know, everybody in the world doesn't have
to wait until all of the languages in the world have been solved.
Because the truth of the matter is we know that there are some
languages that are active in the world and they're encoded in Uni,
code, their writing is in Uni code, there are no speakers on the
Internet and though don't care about those labels and they're not going
to show up. We wanted to have a system that allowed that.
>> RINALIA ABDUL RAHIM: You have a follow upquestion, owe life yea?
>> OLIVIER CREPIN-LEBLOND: It's very short. Who to contact or where
to go if you want to get involved. There's a lot of people who have no
idea but they know something's happening and I think it would be good
to make it clear what's their first point of contact?
>> So the team in charge of that in ICANN staff is Niela and
Nicoletta, if I'm not mistaken. They are able to facilitate this.
There is a lot of information online on the ICANN.org website on that.
>> RINALIA ABDUL RAHIM: Any other questions around the table?
Before we go, Andrew, can you clarify -- because some people have
commented on it -- there seems to be the lack of an appeal process.
For example, in a generation panel submits proposal, it is rejected by
the integration panel and integration panel provides an explanation.
And somehow the community is not happy. What is the recourse?
>> Sul there are three thing toss say about that. This is actually
the expression of the conservatism principle. The point of having this
integration panel and its unanimity provision is there is this
conservatism principle. If you have people who have doubts and they're
presumably widely regarded experts, not just random people, then
they're in a position to say, you know, there's this problem and the
conservatism principle says that we think there's a problem, we can't
go ahead. That's the reason for it. You're right near's not an appeal
process but there is sort of an endless loop that can go there. (.
(Sullivan) so there is intended to be actually public negotiation of
this. And this is the reason that it depends on the public comment
period and so on. Because the integration panel doesn't just get to
say no, go away. They have to defend themselves in public. And if
they can't defend themself, then at some point the integration panel is
ill legitimate and the answer is you file the integration panel.
So the idea is really genuinely that this be a multistakeholder
process that is held in public and open and transparent. And if
openness and transparency doesn't solve our problem for the operation
of the root zone, then we don't have a recourse. We're out of luck at
that point. And I think that that's actually just the truth about
this. There is no way that we can come along and say no, we're going
to cut the baby in half and make the decision. You don't get to do
So unfortunately you know, that's not a very satisfying answer. Veng
we would like to have an appeals process many but my feeling when I was
working on this -- because I remember having discussions about this at
the time, my feeling always was, as soon as I -- as soon as we invernt
an appeals process the next day it will be to invent the appeals
process for the appeals process and eventually we get to the turtles
all the way down. So I thought we could stop at the first turtle.
>> RINALIA ABDUL RAHIM: Thank you. We've come to the end of our
session and RAM would like to wrap the session up. Go ahead, RAM.
>> RAM MOHAN: Thank you.
While many items roo he main in local languages, as in natural home
domain system, the need for the full expression of humankind, language
system and the Internet domain name system is critical. This is
important work. But it's also complex work, as you saw from the
panelists. So therefore we should expect this work will take some time
to come to fruition. But of the very large number of things that
organisation ought to do in the public interest, nothing else feels as
important as enablement of languages in the domain name system. After
all, what is more natural than being able to express yourself in your
own language and in your own script?
So Rinalia, thank you for putting this together and I hope the
session was a value to everybody.
>> RINALIA ABDUL RAHIM: Thank you, RAM. Please join me in thanking
the panelists and also for your patience in joining us today.