IDNs - An Overview
 ICANN Meeting - Cairo
 Sunday, 2 November 2008
 
 >>TINA DAM:   So we're starting in just one minute.  I'm just starting on my computer.  So just hang on.  Is there -- so we're having some technical problem.  Is there anybody on staff in the room?  I just can't see if there's anybody hiding in the back.  No?
 My laptop doesn't seem to work on the monitor.  So do you -- can you -- is it possible to send it from over there?  Can you -- can we put the presentation on your laptop and then send it from over there?
 >> This laptop is actually doing the streaming.
 (Discussion).
 >>TINA DAM:   Is there anybody who would like to lend me their computer for a quick presentation?
 No?  Great.  I'll send it to you.  Patrik, are you online?
 I'll have to admit, I haven't had this problem before, so I really apologize for the wait.  But we're trying to see if we can solve it.
 >>PATRIK FÄLTSTRÖM:   Is there anyone THAT can -- anyone who has a computer that can come over here?  Thank you.
 >>TINA DAM:   Thank you.  Amazing, give Matt a hand.  Thank you, we'll be just one second while we get the presentation on the new computer, and we'll be right there.
 So as we're getting the slides up, thank you for being patient and for joining the session.
 This is about IDN basic information.  So it's -- you know, it's -- if you've seen me give this presentation before, if you've been at one of the other ICANN meetings and you've seen any basic presentations of IDNs, that is what it is.  So let me just ask out, is there anybody --  Who here knows what an IDN is?  Raise of hand.  And I'm not going to have you come up and say anything, so -- so that's pretty much everybody.  So that's good.
 And I don't know if anybody was here in the previous session, but Baher Esmat is my colleague and actually here from Cairo, Egypt, just gave the same presentation, but in Arabic.  So this is now going to be a repeat of that, but in English.  And my slides are also mostly English.  So....
 Okay.  So -- all right.  So I apologize.  I'm going to have to look away from you once in a while, because I actually don't have the slides in front of me.  And now I think that they're okay.
 So this is what the agenda is going to be.  We're going to look at IDN definitions and some basic stuff.  Then we're going to look at how IDNs actually work and some examples of how that has been implemented in applications.
 Then we're going to look at the IDN Wiki.  And I'm going to go over a little bit on what's going on on the policy side and what technical requirements we're putting into the policy side.
 So, this is very basic.  Back when the DNS was developed, it was developed to be functioning on ASCII characters.  And if you do a search on the U.S. ASCII character set, you get this whole list up.  So you see there is both the letters A, B, C through Z, and there's also a		 lot of other signs or characters in there.  And the list is longer than it is here.  It's just a set of examples of it.
 So the DNS can actually handle all of these.  But one of the things that the TLD registries did when they defined the rules for what kind of characters you can use in domain name registration is they implemented what is referred to LDH, letters, digits, and hyphens are what you can use.  Sometimes it's LDH, sometimes it's called ASCII.  It's a little bit different from time to time.
 But all of this, of course, was before things were internationalized.
 Because internationalized names are names with characters other than these letters, digits, and hyphen.  So there is an example there.  As you will see, this is a line to the right-hand side of the screen.  It's because it's Arabic.  And it just gives you an idea of a different complication, because Arabic is written from right to left.  So it can be hard to have Arabic and Latin in the same slide, so to speak.
 But this is an Arabic dot TLD.  And you see the TLD also, because it's right to left, is on the left-hand side of the domain name.  They are actually switched around.  That is how you type it in if you type in Arabic.
 But it gets converted into this xn-- string that then has a lot of ASCII characters following it.  And as you'll see in just a minute on the next slide, that's how IDNs work.  You get the local characters, and you convert them into a sequence of ASCII characters.
 So you may be sitting, thinking, "Well, I don't know how to type in these Arabic characters, or Korean, or things like that."
 Well, the intention also is not that everybody should be able to type everything in.  It is a localized solution.  That is creating a difficulty, because the DNS is global, and it has to work for everybody.  So even though IDNs are intended for local communities, it has to work on a global scale.
 All right.  So IDNs have existed in the second level since 2003 under protocol standards.  And, actually, the first IDNs that came about, at least that I'm aware of, was in 2001, under a test bed.
 The standard that came out in 2003 was for WEP protocols.  And there's another standard on the way that is for e-mail.  All of these standards, of course, are developed in the IETF.  So it really has nothing to do with ICANN staff other than the fact that some ICANN staff participate in the work that takes place in the IETF.
 The IETF is open organization.  If you're interested in technical development of standards, you can go and participate in this.
 So second level, we have.  But we also need IDNs at the top level.
 So we're taking the experience from the second level, and we're building it onto the top level.  And things are going to function essentially the same way.  We just learned a lot of things during the second-level implementations that we now can have at the top level.
 The little box there is really just intended to show you why this is obvious, the extension to the top level, so that the whole string can be represented in a local language.
 We have had --  Something I probably should have put on this slide is that we have actually had IDN top levels in the root -- sorry about that -- in the root since last year.  It has been just over a year.  The first IDN TLDs were put in October 9th of last year.  That was for testing purposes.  We don't have any for production.  You cannot go and make registrations yet.  But, of course, that's what we're aiming at.
 So why do we want things to be internationalized?  And interestingly enough, that's a question that keeps coming up.  I think the region that we're in this week does not really, you know, need an answer to that question.  It's very obvious to them.  It's what they need in order to express themselves and communicate in their own local language.
 Oops.
 And so I....
 So it's really just a natural expansion of the DNS, and on the fact that the DNS is used as a global functionality.
 What that means is that, you know, a lot of new TLDs are potentially going to be available.  And that is done so that we can have more user choice.
 Sorry about that.
 All right.  Okay.  Here's one example of how IDNs are working.
 We start out on the left-hand side with the -- where the client sits.  So you sit at your computer, and you type in, for example, in a browser, an address that is an IDN, meaning something that doesn't solely consist of the ASCII characters or the letters, digits, and hyphen.  If the browser has the IDNA protocol standard implemented, it will recognize this and it will say, "Oh, there's something here that is not A, B, C through Z, and so forth."  And it will apply the IDNA algorithm.  If it doesn't have that, you'll get an error.  But if it has, it will say, "Okay, I need to apply the IDNA algorithm."
 It does.  And it converts the local characters that you have typed in or that you clicked on or you copied from somewhere and entered in your browser, it will transfer those or translate them into xn.  And then it's the request for the xn-- in an ASCII character's address that is being sent off to the local ISP.  And the local ISP will either return the answer right away, if it has the address as cached information, or it will go and have the communication with one of the root servers or one of the TLD servers.  And the page will resolve as it always has been doing on your computer.
 So you might think, well, okay, so the entire communication takes place in ASCII characters, and that's how it always has been, so, obviously, this should be working; right?  And it is.  And it does work, because we've tried it out, and we can see that it works.
 The complication, of course, is that when you move from the letters and digits and hyphen, which is a total of 37 characters, to all the characters that are in Unicode, which is about 100,000, there's a lot of them that look alike.  That creates some complications with addresses.  Even though the computer knows that they're unique, the users might not know that they're unique, because they look the same.  So you might go to an address that you didn't really want to go to.  That's just one of the complications that we get with IDNs.
 But this is how it works.  So, as you can see, this whole conversion sits on your client.  It sits on your computer.  So you need to have browsers, for example, or other application software on your laptop that can handle IDNs in order for it to work for you.
 And here are some examples of how different browsers have implemented that.
 So in the top one, Internet Explorer, and so I heard a little bit of laughing.  Actually, the first thing that happens when you try to go to a different script or language site in Internet Explorer is that it will -- and you don't have that language set, so if I wanted to go to Cyrillic, I don't know what Matt's computer is set to, but if I wanted to try to go to a Cyrillic address, it's probably going to pop up and say, "This language setting, you're trying to access a site that isn't the language setting of your computer.  You have to change it."  If you then change it, it will go to the address and display up in the address bar the characters.  In this example, it's Arabic.  But that's only the domain name part.  For the path, it displays, as you could see, a lot of escape signs.
 So this is not as easy as if it was -- there.
 So you see all the escape signs.  That's because the path has not been internationalized in Internet Explorer.
 If you look at OPERA'S implementation, you will see that the path actually is internationalized.  I'm just going to point one thing out.
 So if you see -- you see underscore right here?
 So we're resolving the same address.  So this underscore is the underscore right here.
 So this is -- because it's Arabic, it's displayed from the right to the left.  So this piece is the path, whereas the path is up here as -- so if you are a native English or -- you know, left-to-right language speaker, you see the domain name going this direction (indicating).
 If you are Arabic, it's the other direction.  It starts over here.
 So this is example.test in Arabic, and then slash and here is the path.
 So here the direction is correct all the way through.
 Up here, you don't get the direction because the path stays over in this side because it's not internationalized.
 Sorry to the scribes for not speaking in the microphone.
 So that's a couple of different ones.  Firefox is further different.  They have white listed some TLDs.  So if you are a TLD registry operator and you have implemented IDNs, you may want to check out, for example, if Firefox have white listed you or not.  If they have not white listed you, it means that it's the top box that your users are getting.  Display of xn-- in the address bar.  If they have white listed you, you get the bottom box where you can see the local characters are displayed in the address bar.
 So a lot of different kinds of implementations, and what we would like to see is that things are standardized a little bit more so that users get the same experience.  But this is just an example to you that regardless of where you are in the industry, users will have different experiences, and you probably need to do some user education if you are a registry or registrar in IDNs.
 All right.  So I wanted to talk a little bit more about this because it's the displayed form versus the stored form.
 So as I said, there is the local characters and they be there is the xn--.
 So xn-- is the stored form.  That is what is put in the zone file in the registries.
 So if you go and make a registration, that name is stored in the DNS.  And that's why as you saw the different errors between the different servers, the DNS can communicate and talk and resolve pages in ASCII characters, because that's what's in the zone file.
 But the user, of course, have an understanding that it's the local characters that have been registered and that's what they want to use.
 So historically, before we had IDNs, everything was the same.  An ASCII domain name is what a user is registering and it's what is stored in the zone.
 But with IDNs, we have these two forms.
 Usually, this stored form, the xn-- does not give any meaning, and it actually also was never really intended for us to sit around and talk too much about the stored form.  It was just an engineering way of making IDNs available.
 However, xn-- is now being displayed, as you saw, for the user.  And because of that, we spent some more time on it.
 There were, for example, exceptions where stored form, the xn--, actually means something.
 So you see the example up there in Arabic where it doesn't mean anything.
 There's other ones, xn-- gibberish is one of the common examples of where if you do the decoding, it decodes into a set of Arabic characters.
 In this example -- so if there is anybody in the room that speaks Arabic or can read it, you will see that this doesn't mean anything.
 And I actually think it's not displayed right here, either, and that may be because of the local software on this laptop.
 But what if it was a trademark, xn-- and a trademark that suddenly was displayed for users?  Well, that's just another problem and consequence of IDNs.
 So that's the displayed form and the stored form.
 This slide, I really just put in for a purpose of encouraging you to go and try things out.  So the slides are available online and you can go and test things and try it out, if you haven't done so already.
 It actually suddenly gives you a completely different meaning if you try this out.
 So the top link is for the IDN Wiki.
 So, for example, if you don't have the capability on your computer to type in something that's an IDN, you can go to the Wiki and there's -- I think we are up to 16 different languages in there right now, and you can click on the links and you can see how things are working.
 If you want to try to do the conversion between the local characters and the xn, you can, for example, go to the second link.  That's -- there's all kinds.  This is just one example.  There's all kinds of different conversion tools online, so this is just one of them where you can convert back and forth between the two.
 So if you can't type in an IDN, maybe you can go to a Web site that is a newspaper or where there is local content, local content has been around for a long time and you can copy and paste it and try things out.
 So try it, and try to copy and paste between applications that you use, see how it works.  Send an e-mail to, you know, a friend or a colleague or yourself with an IDN link in it and see how that works.
 And it doesn't always work, but it depends on the application.
 And then when you have done that, please come back to the IDN Wiki and report back your results, because all of that information is actually very useful, both for application providers but also for TLD registries and registrars as IDNs are implemented further.
 Here is just a screen shot of what the Wiki looks like.
 It is a completely standard Wiki.
 We took the strings example and test translated into 11 different languages initially and put the test version in the root, if you can see it there.  So you have Arabic, Persian, Chinese, Russian, Hindi, Greek, Korean, Yiddish, Japanese, and Tamil, and then there have been additional languages that have been added since.
 So this Wiki showed us, first of all, that it works when we have TLDs in the root, but it also gives an indication how complicated things are in the application space.
 This Wiki is a completely normal Wiki, in the sense that it has user accounts.  You can go in and get your account, you can set up your own page, meaning that you can have a page that has an address that's a full IDN string.
 Try things out, see how it works.
 Please be aware that it is for testing purposes only, so you shouldn't start up your company or anything like that.  But also example.test probably doesn't give such a good meaning as an address for that.
 You cannot make registrations in it, on these TLDs.  And one other thing, because I get this question if we want our language in the root, does that mean we have to be in the Wiki first?  No, you don't.
 This is not testing out and it's not intended to test out all languages.  That's not how the protocol works for IDNs.
 It works for not all the characters in Unicode, but as many as we can fit in there that are used for specific languages.
 So it doesn't have to be tested this language versus that language and so forth.
 So no, you don't have to be in the Wiki.  But if you would like to be in the Wiki, you can contact us and we'll put up an additional address in this Wiki for a language that may not be there yet.
 So you can get that.
 All right.
 So this is the IDN TLD introduction processes of the.
 So if you have followed all of the policy development that's going on, you will know that there's essentially three processes that leads to IDN TLDs.
 One is the to one in the green there, is the fast track.  So that is country code IDN TLDs in a limited fashion.  So there are some specific requirements.  For example, it cannot be based out of the Latin scripts.  Those who are requesting IDN fast tracks have to be countries or territories that are represented in the ISO 3166 list, and there is a number of different limitations in there because it's a fast-track process, meaning that it is intended to go faster than what is listed in the blue, and that is the long-term development process.
 So in the ccNSO, it was reviewed that deciding on overall long-term policies for IDN ccTLDs would take a number of years.  And there were a lot of countries and territories who felt and expressed a stronger need for getting their TLDs in a faster manner.  That's why the fast track came about, and that's why there are limitations in it as well.
 So the blue one will be for the future proof.  But the green one will be for the initial IDN TLDs in the root.
 And then of course, the last one is for the new generic TLDs, so the new gTLDs.  And that is because we have a policy that actually was developed by the community and approved for implementation that is just going into final stages.  And that's the policy for introduction of new gTLDs.
 The guidebook for how to go about that was just posted, and it includes IDN gTLDs.
 So if you are a country or a territory and you are not Latin and you fulfilled the other requirements, you will go through the green process.
 If you are generic term, you will go through the orange process.
 So that's saying it pretty short.
 There is a lot of meetings going on this weekend on both -- this week, both on the green and orange process.  Just a lot of them.
 They are aiming at coming out at the same time, which currently is scheduled for sometime Q2, Q3 next year.
 And then, of course, I guess the question would be, well, they be when can we make registrations, and that obviously depends on how long does the evaluation phase take and how quickly can the operator launch after that.
 But I could imagine that we could have IDN registrations available under IDN TLDs by, you know, sometime next year, potentially early in 2010.
 So that's sort of like the time frame.
 It's really hard for us to give, like, specific deadlines and times on that, but it's around that time.
 Technical requirements.  So one of the things that staff has been spending some time on in those couple of processes is to make sure that regards of whether you apply for an IDN ccTLD or an IDN gTLD, the technical requirements needs to be the same.
 And that's because from a technical standpoint, there is really no difference.  And that also means that in terms of string evaluation, you will be evaluated in the same way.  The same requirements count and the same evaluation is going to count.
 So these things have been posted, too, in both the gTLD guidebook and also the ccTLD fast track draft implementation plan.
 But we thought this might be a good idea to go over them here, at least briefly, and then see if there are any questions on it.
 So, first of all, the label or the string, the TLD string, has to be in compliance with the IDNA protocol.  And that protocol is under revision today.
 The preference is that the revision will be completed before we get IDN TLDs in the root for production purposes.  However, we don't have a deadline for when that revision is going to be completed.  So if we are not -- If it isn't completed, then we are going to have to put up some additional restrictions.
 So these are, you know, initial drafts.
 For example, the string can only contain codepoints that are defined as valid, and valid is something that comes out of the protocol.  So you cannot have anything else.
 It has to be a fully normalized form per Unicode standards.
 You cannot have characters that have a mixed direction.  And the reason for that is that it simply just won't work.
 For example, if you have Arabic mixed with a digit, then that digit -- and if that digit is a leading or trailing digit, it might jump to the other side of the dot.  And as you can imagine, then we suddenly have a completely different address, and that doesn't work.
 Some of these things are still under discussion in this protocol revision, so as it's being finalized, you know, you will see more details on it.
 But I am going to say that if it doesn't get finalized before we put IDN TLDs in the root for production, then it means that we're going to ask the technical community for some guidance on what is sufficient in terms of technical requirements for this.
 The other thing that has to be complied with is the IDN guidelines.  And the IDN guidelines traditionally have been what gTLDs have been obligated to follow, but ccTLDs have been recommended to follow.
 When we move into IDNs at the top level, it is going to be a requirement for all.
 One of the things the guidelines say, and this is just one example out of there, is all of the examples have to be taken from the same script.
 And "script" is defined, in our case, by how Unicode is defining a script.
 Now, there is exceptions to this, because, for example, Japanese, if you want to express yourself in the language of Japanese, you have to mix-up to four different scripts.
 So in those cases, we would allow mixing of scripts.  But it really has to be an overriding linguistic reason for mixing of scripts if that is going to take place at the top level.
 So, for example, you cannot mix Latin and Cyrillic because that creates too many confusions.
 So this is my final slide.  Internationalization is really something that we need and it means that the Internet is equally accessible from all languages and scripts.
 I think we're getting really close.
 As I said, we have had IDN TLDs in for testing purposes for a year.  We are getting really close to having something in for production.
 There are some really sensitive topics for discussion, policy-related, this week.  We have to reach compromises on this.  It's not going to be a solution that's going to work for everybody, so we have to accept that there has to be a process for it.  And not everybody is going to be happy about it.
 If we don't reach sort of like an agreement on this, then this equal accessibility won't happen, and that would be a shame.  It really is something that we need.
 So that's going to be good to get some community feedback and continue to work on.
 And then, of course, there is the technical side, too that also needs to be done and dealt with.
 So that's all I have.  This says "thank you" in Arabic, and my e-mail address is up there.
 I think we have time for questions.  I can't see the screen so I don't know what time it is, and I know we started a little late.  So do we have a little time?  The scribes are nodding so they are not too tired yet.
 Questions.  And is there a microphone for questions?
 Yeah.
 And if you can state your name before you ask your questions, that would be great.
 >>BRITT LYSAA-NOKIA:  My name is Britt Lysaa.  You said that IDNA is going through some revision.  Did you say anything about when you expect to have it done?  Or any idea?
 >>TINA DAM: Yes, so we have been hoping for a while that the revision would be completed within this calendar year.
 The way that development of technical standards work in the IETF is that there is no set deadline for it.  And that, of course, is because technical standards have to be developed in the time that it takes.
 Now, Patrik, I am not wrong when I am saying that because it has -- the revision has not gone into last call yet, that means that it will at least go through to the first IETF meeting in the year 2009.  Is that right?
 So Patrik Fältström is actually one of the main authors behind that protocol revision.
 >>PATRIK FÄLTSTRÖM:   Hello.  There.
 Patrik Fältström.  Yes, you're right.  But on the other hand, you cannot say that it has to wait until the next IETF meeting either, because the way the development in the IETF works is that the discussions go on until you have rough consensus in the room.
 And unfortunately, we don't have any hard deadlines for protocol development, just like you pointed out.
 But let me try to make people more comfortable and say that the issues that we are currently discussing, given the other restrictions that you have on potential top-level domains that you are listing, nothing of what we are currently discussing has any impact on the selection of actual codepoints.  It's more a formality on the approval and review process that, as you also pointed out, that ends up being different depending on whether the standard is actually cast in stone or not.
 But in reality, regarding selections of the codepoints, I don't see anything drastic happens.
 >>TINA DAM:   Right.  And that's why you also hear me saying that the preference is that it's completed, but if it's not, then we can find a way to go ahead anyway.
 It's pretty unusual together with something where there is not a technical standard on it, but in this case, it actually appears that we can put up some additional restrictions and be pretty technically safe.
 But completion, of course, is....
 So are there any other questions?
 >>CHRISTOPHER CROWTHER:  It's Christopher Crowther, and it's more of a clarification request.
 With the IDN dot TLD, does that represent a new extension or is that a conversion of an existing extension?  So for example, will dot CN become Jungwa (phonetic) or would that be you would now have a new extension in the Chinese space?
 >>TINA DAM:   I think it will be a little different in terms of gTLDs and ccTLDs.  Some countries may wish to run these things together by the same operator and potentially with the same zone, although there is no technical solution for how to do that in a scalable manner.  Whereas on the gTLD side, things are much more specific in the sense that just because you are an existing gTLD operator does not mean that you have a pre-right to an IDN version of that, if such a version would exist.
 It's hard to translate some of the gTLDs or transliterate them.
 So -- But all in all, if your question is more technical, it is new extensions.
 >>CHRISTOPHER CROWTHER:  So would it be up to a ccTLD, then, if you want -- I know currently you can register IDN at the second level and then the dot -- you know, dot CN or dot TW.  It would be up to them if they want to migrate that themselves or release now a new IDN dot TLD?
 >>TINA DAM:   So it wouldn't be up to the ccTLD operator, but it would be up to the country or territory whether they would like to have an IDN ccTLD extension.
 >> Okay.  Fair enough.  Thanks.
 >>TINA DAM:   Sure.
 There is a question in the back.
 And I know, as he walks down with the microphone, I see a lot of familiar faces, obviously, in the audience.
 This was really a session for basic stuff.  So -- and I know a lot of you already knew about it.
 So go ahead, question.
 >>MATT MANSELL:  Yeah, Matt from Mesh in the U.K.
 Just following on from that last question, obviously there are country codes that would be a logical progression into an IDN.  Is the sort of 185,000 fee to create a new gTLD still going to be the case with IDNs where there's country code levels that just want to migrate or use an IDN?
 >>TINA DAM:   I'm sorry, say that one more time.  Is it --
 >>MATT MANSELL:  So there's country code TLDs right now like dot NY or whatever the country code TLD is that would translate into an IDN, and are those guys going to be forced to follow the full gTLD procedure and pay the 185,000 pound fee to do so?
 >>TINA DAM:   No, so that's the differences between the two -- the three processes that I had.
 You can, if you can a country or a territory, you can apply as a gTLD.  You have to prove that you have the government support or the national authority support from that country or territory.
 If you do want to pay that 185,000 then apply in the gTLD round, you get a TLD.  But you are not forced to do that. That's why we have the fast track, so that you can apply it as an IDN ccTLD.  In that case it would become a ccTLD.
 Things such as relationship to ICANN, compared to what we have with gTLDs, application fees, yearly fees, all kinds of things like that are currently open issues in the fast track.
 So if you look at the draft implementation plan that was posted, it's posted in different modules.  Module 7 contains an overview of all of those open topics that has been put on the table that we believe needs a decision on in order for the fast track to be finalized.
 So -- But no, you don't have to pay the 185,000 if you are a country or territory.  You can go into fast track.
 But if that would cost anything and, if it would, how much, is an open question.
 >>DR. GOVIND:  I'm Dr. Govind from India.
 So now you know we are working on -- we have the most complicated case of the 22 languages.  So is the process when this certain string is evaluated and it is approved, then even then the policy-like agreement with the ICANN will be in the process or it will go ahead with the implementation?
 >>TINA DAM:   So if a contract is required?
 >>DR. GOVIND:   Yeah.  If a contract will be a working situation or if it will go ahead with the string and the script is approved by the evaluation process.  And what will be the situation in the Q2, Q3, what you said earlier?  Or Q4.
 >>TINA DAM:   So in the gTLD process, there is a standard contract that has to be signed, and that's the gTLDs.
 In the fast track, that's an open question.
 What staff has -- So let me back up a little bit.
 So the fast track policy process or methodology or recommendation from the community that came back at the ICANN meeting in Paris in June did not contain anything about what are we going to do with contracts or accountability frameworks or relationship between an IDN ccTLD operator and ICANN.
 There was nothing in it about that.
 The community, obviously, have talked about it, but the working group decided not to put a recommendation in.
 On the other hand, there is a requirement that technical stability needs to be fulfilled.  So when we initiated the implementation, we -- I'm going to unplug this, because it just keeps beeping.
 So when we did the draft implementation, we said, "Well, if we want to make sure that things are stable and secure, then these technical requirements have to be fulfilled."
 And then the question, really, this week, and also after the Cairo meeting, is, to the community, how are we going to make sure that, for example, technical requirements are fulfilled?  Should it be in an accountability framework?  Should it be in some sort of lightweight agreement?  Or what should it be?
 So staff right now is looking to the community to actually discuss that and come back with their opinions to us.
 But somehow, we have to find a way to make sure that technical standards are fulfilled.  That's a minimum.
 >>DR. GOVIND:  So, in a way, it is going to be to avoid the future conflicts in the IDNA to follow the IDNA protocol.  From that point of view only the agreement is there, or is it from some other angle it is also there?
 >>TINA DAM:   No, it has to do with the IDNA protocol and the guidelines, for example.  I just came from the GAC meeting, and they discussed the topic as well.  And so the question is, could it just be a letter -- exchanging letters, saying, "We agree" -- you know, "We would like this IDN ccTLD, and here we agree to follow the standards."  Is that sufficient?  Or should there be a compliance mechanism in place for those that then break their promise?
 I'm sorry, but I -- you're not going to get an answer from me, because this is something that we want the community -- staff wants to listen to the community and hear what you think about it so that we don't just sit around and make decisions on this.  It's a sensitive topic.  It is something that we need to get a resolution on.
 Is there any other questions?
 >>PATRIK FÄLTSTRÖM:   Patrik Fältström again.
 I just want to point out and emphasize what you said earlier, Tina, that I think that people who really want to have internationalized ccTLDs really should start working locally on this.  Because, for example, as we heard one example in one question earlier, if you have IDN.TLD today and would like to have IDN.IDN in the future, there is -- let me point this out -- zero technical features in the DNS that can ensure that, for example, the same domain name holder has the same second-level domain.  That is something that only can be handled by synchronization, administrative synchronization locally.  And that is a typical example of a policy that needs to be sorted out locally, because I don't think there will be any general agreement on how to handle those cases.  And that is where I think, personally, much, much more of the policy discussions regarding introduction of new ccTLDs will happen, and not on the ICANN level.
 Although, as you say, there are various different kind of questions regarding contracts and not contracts, whatever, that has to be resolved.  But that's, from my point of view, peanuts compared to how to handle the local policy.
 >>TINA DAM:   Right.  We get the questions all the time -- or I get the questions from users all the time.
 I registered my IDN dot some TLD.  Can I also now have IDN dot, and then the IDN version of that TLD?  Well, there -- I mean, there's no -- there's no policy or procedure in places.  And there's no technical solution in place to guarantee that you can get that.  So that is something that sits out in the local communities, as it stands today.  And there's going to be no rules around it.
 The technical solution that you referred to, I mean, that's kind of like -- you know, there is none; right?  Other than copying the zone file.  And that's not really scalable.  So....
 >>PATRIK FÄLTSTRÖM:   Yes.
 So Patrik Fältström again.
 Yes, specifically, one might think that it's pretty easy to register a domain name and get, for example, both versions in both TLDs or all 23 of them, when you register a domain name.  But think about the situation that someone wants to do a domain name transfer in one of the TLDs, specifically, if it is the case that the TLDs are run by different operators.  Then one might end with a very complicated situation that actually needs to be resolved locally in various contracts, agreements, and also handovers between the potential operators, specifically if there are more than one.
 >>TINA DAM:   Right.
 Is there any other questions?
 And if not, then, yeah, my e-mail is not on the screen anytime, but I'm also around.  And, you know, you can catch me anytime this week and ask any follow-up questions you want.
 So -- or send me an e-mail.  But thank you for your time and attention.  And apologies again for the late start and technical difficulties.
 So thank you.
 [ Applause ]