Gisella Gruber-White: We’ll get that started. We’ll start the recording as of now. Good morning, good afternoon, good evening to everyone on today’s IDN Work Group on Wednesday, the 11th of January. We have Edmon Chung, Olivier Crépin-Leblond, Cheryl Langdon-Orr, Tijani Ben Jemaa, Lutz Donnerhacke. We have apologies from Rinalia Abdul Rahim. From staff we have myself, Gisella Gruber.
If I could also please remind you all to state your names when speaking for transcript purposes. Thank you, over to you, Edmon.
Edmon Chung: Thank you, Gisella and thank you, everyone, for joining. And this is sort of the first call for the IDN Working Group I guess restarted since Dakar, and we do have a particular item for discussion. I think it’s a good central point for us to sort of rally more and more discussion and participation on which is the IDN Variants Issues Project – it’s called the IDN VIP report that came out. But before that I guess I wanted to thank Gisella and the staff team for helping me to put together this first call and also the agenda for this call.
There are a number of items I wanted to highlight. First of all, before the recording started I mentioned that we have a fairly tight timeline because we have until the 30th of January, the end of this month to respond and in order to circulate our comments if any to the ALAC we will pretty much need to have something drafted by tomorrow. But in any case, so I guess the idea is I’ll sort of have a quick highlight of the issues report and I will try to keep it fairly open and see how people feel we should take it on especially for this particular comment period; and perhaps for a long-term perspective on this issue, because this report is not the end of the Variant Issues Project. In fact, it’s almost just the beginning because it only talks about the issues rather than actual solutions.
So I guess with that, and I guess everyone can see the draft agenda – we’ll talk about the report itself, some next steps and how we will try to steer or navigate the response from ALAC. I wonder if anyone has anything to add or thinks the agenda needs any additional things or something to be taken away?
Cheryl Langdon-Orr: The agenda’s fine.
Edmon Chung: Okay. Hearing no objection to it I guess I’ll jump right into talking a little bit about the actual Variant Issues Project integrated report. I guess the first question actually to the group is whether you’ve had the chance to read through the fairly long document. Has anyone had the chance to actually read it through or…
Cheryl Langdon-Orr: Not in any depth but scanning and that’s about it.
Edmon Chung: Okay.
Cheryl Langdon-Orr: What I tend to do, to be absolutely honest, is just keep an eye on what’s happening on the VIP list. So I’m somewhat recalcitrant in the VIP area I’m afraid.
Edmon Chung: Okay. I’m guessing that most have not read the about 100-page document.
Tijani Ben Jemaa: I didn’t.
Edmon Chung: You did? You read it?
Tijani Ben Jemaa: No, I didn’t.
Edmon Chung: Oh you didn’t, okay. So I guess I’ll sort of base my assumption-
Lutz Donnerhacke: Lutz here. I just read the Latin script document, it’s enough for me.
Edmon Chung: Okay.
Olivier Crépin-Leblond: Yeah, Edmon, it’s Olivier here. I think if you can just run us through it that would be helpful since it looks like most of us have just either had the time to scan it or have not read the one for the IDN scripts that you’re speaking about.
Edmon Chung: Right. I guess, I believe the best use of time is I’ll just generally give a sense of what the report is about and then I’ll highlight some of the things that might be of interest to ALAC and our discussion. So…
Olivier Crépin-Leblond: Yep, and if I could add, Edmon, you don’t need to repeat what you went through in Dakar. Of course you’ve gone through a fair bit in Dakar as well, so just follow on from there.
Edmon Chung: Right. So I guess I’ll focus on the integrated report because that was developed pretty much after Dakar, and most of the work before Dakar has been the study team reports. Okay, I guess I’ll jump right into it. Just feel free to jump in and ask questions or ask for clarifications, and until it gets to chaotic I’ll take the queue then. But just feel free, if you have any questions to just jump right in.
So right after Dakar the whole project was split up into six study teams and so the six languages or scripts that were being studied, and then those reports were created by community efforts, and I guess headed up by the staff VIP Team which was created by the Board. So we created the six study team reports. Thereupon, especially since Dakar, a team to integrate those six reports was being formed. The big difference between the former and the latter is that the latter, which is the integrated report, is much more driven by staff and by the consultants retained by the staff team.
So the report was mainly written by staff instead of previously when the reports were written by the community. So what currently is being published for public comments is the integrated report driven I guess mostly by staff. The approach it has taken, if you read through it, you would see that there has been fairly substantial work that’s been done trying to classify the different types of variants to try to consolidate them into different types and classifications of variants. I think that represents a fairly substantial piece of work, and personally, having looked at it and…
Okay, sorry for jumping back and forth but while the integrated report is primarily driven by staff the community was involved in sort of providing some advice to the development of the report. So throughout I think it was a fairly substantive piece of work and also quite well done in terms of how the types of variants are being consolidated between the different languages and scripts; the types of variants from Chinese, from the Indic scripts, the Arabic scripts, the Latin and Cyrillic scripts. I think it does represent a fairly substantive piece of work.
Reading further into it I guess the reader would find that while there are some similarities, I think it is probably a fair statement to conclude that there are probably more differences than similarities between the languages. So that being said, the large classifications are quite well-established. With anything to do with ICANN or anything else the devil is in the details, and that could make a big difference in terms of the actual implementation of IDN variants, especially at the top level, at the root.
So there is some additional discussion: besides the classification it then follows into the types of issues that need to be considered especially at the root, because one significant issue is that the root zone itself is a shared resource if you will around the globe, and therefore a relatively consistent approach is quite important. And the report goes on to talk a bit more about just the importance of maintaining the security and stability of the root and how the eventual consistency in terms of user [execution] is sort of paramount when ICANN makes a decision eventually on a longer-term set of policies for IDN variants.
So the first third of the report is mainly around this. Then it moves on to talk about one, it isolates and expands on one type of variant which is kind of interesting especially for policy discussion, which is the I guess somewhat fuzzy situation between visual similarity cases versus IDN variants, and a more in-depth discussion on whether visual similarity should be considered IDN variants. There has been quite some discussion from the group that was helping with the draft as well and I think the general realization is that there are cases where visual similarities are IDN variants but there are also cases where they aren’t. Where they are not, whether existing policies are already enough to handle those situations is one of the issues that was raised in the report as well.
Following from that the report goes on to talk about how variants could be generated, and the whole of Section 4 if you look at it is almost a proposal but it’s not quite a proposal for solution just yet, but a sort of deliberation on possible approaches for solutions to be created. And then following from that, well basically Section 4 is one of the core, sort of “meat” parts of the document driving towards eventually a solution – Section 4 as well as Section 7, I’ll come back to that. So the report goes on to talk about what types of solutions might be considered.
An important thing to remember is that the report does not recommend any solution at this point, and the idea of the issues report is to identify the issues, identify possibly approaches for solutions but it wasn’t the job of the VIP to come up with recommendations on solutions or implementations. So Section 4 talks about what is called label-generation rules, and essentially what rules should the root identify and adopt for these types of variant label generation rules? What are the possible ways to go about this, and also some of the issues surrounding?
Then Section 5 and in fact Section 6 are focused on some of the operational issues including both the root and the registry itself. So in cases where TLD registries request for an IDN variant, what are the potential considerations for ICANN to evaluate before it’s being delegated or before it’s being allocated to the applicant? And also what types of technical policy and related requirements should be considered and implemented by the applicant, by the TLD registry?
So that’s really including like additional registration processes, how end users can interact with the system, impact to WHOIS, impact to other types of security and stability issues; how hosts or websites need to be aware of some of the issues in order for them to set it up correctly, because for example, if a variant is being implemented are web hosts’ email capable of handling that and what some of the impacts are. So that’s the Section 5 and 6.
Section 6 particularly is more and more technical I guess, and especially on the types of [code points] that shouldn’t be allowed. I guess for me it’s kind of part of the policy that needs to be in place by registries and by the zone, by the root zone in order to allow IDNs and IDN variants.
And eventually Section 7 points to, as I mentioned Section 4 talks about the possible approaches for generating IDN variants and Section 7 goes on to a more detailed discussion about what types of processes ICANN should put in place especially for implementation of IDN variants, including certain policy aspects as well as operational aspects. So that’s sort of identifying some of the items that will require decision as well as consideration in terms of the actual implementation recommendation. That should come right after the Board, if it accepts this report, and point towards additional work.
And then the Appendices generally included the case studies and some terminology. The terminology is quite important for the overall project just to make sure that we use the same sort of vocabulary for the discussion, but I guess for our specific purpose that’s perhaps not the most important part. But quite a bit of time was spent on sort of consolidating the terminology as well, because different language case studies actually used different terminology; and in some cases they actually sort of mean the same thing or either using two different words by different teams and trying to mean the same thing, or using the same word but actually meaning different things. And that, overall, in the longer-term discussion, is problematic. But one of the achievements of this report is trying to come to terms with a more unified terminology.
So that’s I guess the quick walkthrough of the document. Before I guess I highlight some of the items that perhaps ALAC should especially weigh in I wonder if anyone has any questions or points of clarification about the report, or wanted to add anything that you saw.
Lutz Donnerhacke: Lutz here.
Cheryl Langdon-Orr: …obliged if you like.
Edmon Chung: I heard Cheryl and someone else. I’m sorry, I didn’t quite get the name. There was somebody before Cheryl.
Lutz Donnerhacke: Lutz, Lutz here.
Edmon Chung: Oh Lutz, go ahead and then Cheryl.
Lutz Donnerhacke: Thanks for the walkthrough. A major amount of work has been done on this subject, but my question for us is can we do anything? I don’t think so. We can only insist that all these various issues need to be considered and only on new gTLDs there needs to be a closed inspection of the applications if they are creating some problems which is already done in the current policies. So I do not see any need for a special attention on the subject by ALAC. Have I missed something?
Edmon Chung: Okay. Cheryl? Before I respond, Cheryl, you were going to…
Cheryl Langdon-Orr: Thank you, Cheryl for the transcript record. I’m actually keen to hear what you think we should weigh in on as At-Large and ALAC, but more importantly what in this particular integrated document because it really is a sort of – other than the labels, I didn’t think anything new had come out as concept on this integrated document for us to react to. So beyond the “Hail fellow, well met, thank you for looking at the individual groups that the VIP has been working on,” which we’ve already sort of dealt with already, what do you think we should be digging our teeth in? An then I guess we can answer the question “Now or later?”
Edmon Chung: Okay. So I guess I’ll come back to Lutz’s question first. I think, and I guess it’s somewhat similar in the vein with Cheryl’s question of it seems like nothing new has come out so it doesn’t seem like we need to weigh in at this point. So the question is what this report actually does.
I guess the boring way to think about it is that it’s actually good to see that nothing new has come out. I’d be much more concerned if we found a whole ton of worms as we go through the issues, the different languages and trying to integrate the issues. One of the key things I think people need to realize is that the Board especially and also the staff was quite worried about this IDN variant issue as what we see as just the tip of the iceberg type of issue and we might dig up a lot of things. But after a lot more in-depth study into this it seems like we do have a good grasp on what this sort of [beast is], and I think this is something that should be commended.
Even though it seems boring that we found nothing new, but the fact that we found nothing new is a big step forward, very much so. Personally I think we should have been able to implement this a long time ago but there has been different people from the community casting doubts and questions about the thoroughness of the issue being thought out.
So this is one of the things I think that is useful to highlight and perhaps this is also one of the messages that I’d like for ALAC especially to point to as well, because from our view – I guess from our collective perspective it would be useful if we also think that it didn’t uncover something new or things. I think that this actually gives staff and Board a stronger comfort level to move forward into implementation.
That being said, on the second part of the question on what other things that we should highlight, I think given what I just said I see two other key items that perhaps is appropriate for ALAC to weigh in, one of which is that even though nothing is being raised I think that there are still a number of core languages – bigger languages in the world – that were not included in the study teams. And I think it’s probably appropriate for ALAC to raise that whilst in implementation it’s good that we uncover nothing new, there are certain languages like even a number of different Indic languages because we only looked into Devanagari; so other Indic languages, Hebrew; some of the other Asian languages like Thai and others have not been…
It’s a very different set of scripts and languages that were not included in the case study teams and not included in the integrated report. While we think nothing new has come out I think ICANN should not stop there. Not to be an obstacle for the implementation of the scripts that are identified but it’s important that ICANN doesn’t give itself a pat on the back and say “We’re done.” There are still a number of languages and types of writing systems that would require some study and that actually I think would help build an even better case for the IDN variants issue, that we have uncovered the broad strokes and that is very solid for ICANN to implement the IDN variants at the root level.
So this is one thing, and the other part that I think perhaps ALAC can weigh in and that’s appropriate for ALAC to weigh in, is that it is also apparent from this report that the different languages and different scripts are in different maturity levels in terms of actual implementation for IDN variants. If you look at the report and the consensus from the community for example from the Chinese and Latin case versus the Greek and the Cyrillic case versus the Arabic and Indic case you would see a spectrum of readiness and maturity in terms of actual implementation.
To be more exact, to be more specific it’s fairly clear from the Latin and the Chinese discussion that a very well-established implementation approach is identified and has been put in place; and to a slightly lesser degree Arabic and Indic, and to a much lesser degree Greek and Cyrillic. So and the reason why I point this out is because if you look at the different study reports and also the integrated report you would see that there are diametrically opposing sort of suggestions by certain languages because they haven’t reached a final consensus yet, versus some languages like in the case with Chinese and also somewhat in the case of Latin that a consensus approach has been arrived at.
What is important is that ICANN understands that even given this that IDN variants is very much important and we should not be waiting for all the different languages and scripts to be fully ready before the actual implementation. So I think that is an important point that perhaps is appropriate for ALAC to weigh in on as well. I guess us representing the users… IDN variants are very important for at least a good number of internet users and the earlier that it’s implemented into the root and the new gTLD as well as the IDN ccTLD processes the better for the bulk of those users in need.
So three things, one of which is I guess to commend the work that was done and to highlight the fact that we didn’t uncover anything new and therefore we should be much more comfortable to actually go into implementation. Secondly is not to forget about some of the languages that might still need study; and thirdly is that the different maturity levels should not stop ICANN from implementing those that are more ready and rollout a timeline for it.
So those are at this point my feeling for the three areas that perhaps ALAC can weigh in on.
Olivier Crépin-Leblond: Edmon, it’s Olivier. May I add a few comments? Or does Cheryl want to get in before me?
Cheryl Langdon-Orr: Go ahead, Olivier. I’ll do a follow-up if you don’t magically say what I was going to.
Olivier Crépin-Leblond: Okay, thanks. Right, well I’ve been following the IDN issue for quite a while but I must admit from a distance since the involvement, both technical and in the knowledge of scripts and characters and semantics, etc., is something that I think exceeds my knowledge by several magnitudes. And it can get very, very involved and certainly this report I think has gone to quite a depth to report on the variants issues which is possibly one of the most complex issues of IDNs since there are so many one-off cases, so many exceptions to the norm.
I have followed the IETF IDNA Working Group discussions and so my first question to you, Edmon, was whether much of the work that was done by the IDNA with IETF Working Group was taken into account because I certainly see some familiar text here. But I’m a little concerned that ICANN is reinventing the wheel when a lot of these discussions have taken place in the IETF.
Edmon Chung: Good question but I guess it’s exactly the opposite if I’m not mistaken, because in the IDNA original discussion as well as the IDNA [Bis] discussion the idea is that the IETF has punted this issue about specific languages and scripts because the IETF is focused on technical protocols for making it possible to transport these characters in a protocol format. And the biggest difference between the IDNA original and the IDNA [Bis] is to take away, even further take away the mapping of different maybe capital and small letters, and to take it completely away from the protocol.
And in both cases, both the original discussion and the [Bis] discussion, the issue of policy implementation especially on variants and where there is human ambiguity is being punted to a policy level. So I don’t think we’re reinventing the wheel; in fact, we’re picking up from where the IETF Working Group has decided that it’s not within their expertise and have tried to pick it up from the ICANN and zone management policy perspective, and to take it from there. That’s my interpretation.
Olivier Crépin-Leblond: Thank you, Edmon, it’s Olivier again. I guess my question was whether the discussions, so not the actual IDNA 2008 or IDNA 2003 documents were taken into account but whether the actual discussions in the IDNA [Bis] were taken into account because I see some similarity. And you’re absolutely correct – I think one of the reasons why IDNA 2008 was if you want reduced in size in some way, or I don’t have the exact term for it, but it was because the discussions started coming close to being intractable. I remember Vint leading that group and having a very hard time trying to keep people in focus, and certainly keeping people from ending up at each other’s throats.
Edmon Chung: Right. So in response to that, I think the answer at least from my point of view is yes, we have progressed – yes. However it is also yes to your question in that yes, we are repeating some of those things but we are progressing in terms of as for the IETF, the discussions were all over the place as you said. I think a really nice piece of work is trying to put it back into a framework and consolidate it into a set of common vocabulary and a framework that has a kind of classification of the different types of IDN variants.
So I think this, we did repeat a number of things that were raised in the IETF discussion which I guess were unavoidable, but I think we did progress in terms of putting it together, integrating it as it’s being advertised by the group, and putting it into a common framework between the different languages.
Olivier Crépin-Leblond: Okay, thank you, and it’s still Olivier – may I follow up with further comments?
Edmon Chung: Please go ahead.
Olivier Crépin-Leblond: Thank you, Edmon. I have seen actually a request on the IDNA Working Group for people over there to bring some comments to ICANN, so I gather that the main people who were involved like Vint Cerf, Patrik Fältström, John Klensin, Pete Resnick – that most of these guys will comment separately.
As far as the ALAC is concerned, I think that what you’ve mentioned, what you’ve put your finger on is very, very, very good indeed. I especially like the fact that you’ve pointed out the spread in the range of maturity. Some scripts are more likely to engage in a variety of variants that might complicate things especially with regards to visual similarity whilst others are more into their own space and are less similar and maybe will open less of a Pandora’s box in some way. So I would absolutely support, and this is not as the ALAC Chair but I’m saying as participant and someone interested on the sideline of the IDNs, I would absolutely support that we shouldn’t wait for readiness on all IDNs.
The question though is how would you deal with things? If you don’t wait for the readiness of all IDN variant cases and launch only for specific types, how do you get around the… I mean do you just shelve the ones that are currently complicated to resolve or do you not allow them in the meantime in browsers? Or how does that work?
Edmon Chung: This is a very good question. I think however this is a question that needs to be resolved by the next group that considers solutions. (laughing)
Olivier Crépin-Leblond: Ah-hah!
Edmon Chung: But I think what might be important as you pointed out, what is important I think for ALAC to perhaps weigh in on is that we feel that the solutions team, the next team that would be tasked to come up with solutions and recommendations should not be restricted to try to find a perfect solution for everyone because that has been one of the… There are people in the community that have raised that particular perspective.
So I think it might be useful for us to at least give the next group a strong sense that it is okay to consider an approach whereby some of them go first and then the others, as more work is being done and as their solution is being matured, will be put in place. So I think it is pointing out that simple fact that is perhaps what is appropriate for us to do at this point rather than to come up with the actual solution for doing it.
Olivier Crépin-Leblond: Okay. Thank you, Edmon. And then a final thing, it’s still Olivier here. I have seen various problems that were raised due to not variants but due to visual similarity on the ccTLD level – the IDN ccTLDs where there has been refusal for some proposed IDN ccTLD applications based on visual similarity. And I wonder whether we would be completely out of focus if we mentioned the need for more transparency in any examination process, or whether we’re completely out of the picture here. I’m not quite sure whether such a comment would have a space in relation to the report here.
Edmon Chung: I guess personally I think this is a good addition to it. Even though this report doesn’t talk about the actual implementation yet, in my third point in terms of that some could go first I think we could add the transparency issue into it and point to some of the cases where especially visual similarity… Actually, I take that back. I was going to say that yes, we should raise the issue of transparency.
The issue of visual similarity, at least at this point, I don’t feel comfortable weighing in strongly I guess in terms of a user perspective at this point because it’s somewhat that different people have different views on that. So instead of drawing the attention specifically to visual similarity I think it’s a very good idea to add in that as we go into implementation unavoidably there will be some panels or committees that are being formed to evaluate these issues through the application process and the delegation process.
The work of those panels and committees should be more transparent. I think this is definitely something that is very appropriate for ALAC to weigh in on and I think this is the right timing as well, as just before the next team considers the actual recommendations for solution.
Olivier Crépin-Leblond: Edmon, if I can just add to this actually – looking specifically at 5.2.4, “What users expect and what they get” is one specific large-ish paragraph that shows that users expect to have things that are predictable and working well somehow or be able to distinguish as to how things work, and certainly I think transparency across the whole process would be one thing; predictability of course is another one; and the third one I think is also the ability to come back if there is a disagreement – an appeals process of some sort.
I know we’re not reaching that level but certainly the recent rejections that we’ve read about and seen with effectively a decision coming out of a black box with no appeals process was particularly problematic on a diplomatic level. Thank you.
Edmon Chung: Right, I completely agree. If we go into a very detailed area in this particular report, I’ve forgotten exactly where but it does talk about – besides what you mentioned it does talk about that user behaviors change and user behaviors are shaped by policies eventually. So if certain policies are put in place users eventually change their habits. So the interesting thing about that is that while that is true, I guess as an ALAC point of view it’s probably as much an excuse for setting policies that are friendly to the policy setters as it is true in terms of the actual user behavior. I don’t think we need to highlight this; I guess I just want to mention that there was a little bit of discussion that the cases raised the issue that user habits will change over time, and it might be more important to be consistent technically and for the DNS to operate securely and stably and I guess for the operators to be able to do it rather than to cater to every user expectation.
We can of course pick it up as an issue but I don’t know; I guess I’m open to hearing if you think that’s something we want to pick on. That’s certainly something that sort of raised my eyebrows as I was reading through. But I think overall, as you mentioned, user expectations are important but as we go down into implementation, because different users might expect different things it’s important to consider those situations and I guess come up with policies that are in a way conservative for the security and stability of the DNS; and also somewhat in balance for the protection of end users. Cheryl? Please go ahead.
Cheryl Langdon-Orr: Cheryl here. Thank you, Cheryl for the transcript record. A couple points; I’ll start by building on what you were just saying and what Olivier was suggesting. From my perspective, At-Large and ALAC needs to hold paramount the stability and security of the DNS and we also need to make very clear that ongoing support in the very early days of IDNs and these scripts is to allow a much larger end using audience as well as operators of services and of course the various things that will happen when more people are connected to an internet in a script language that they understand and can use.
And from my perspective we keep getting caught up with some of the visual similarity issues and some of the rule and policy development issues. From the perspective of ASCII use and the principles we run now, and I would like to think that if we’re going to say something at this level of the integrated issues report that we should perhaps remind the fact that more than half the world doesn’t use Latin scripts so it’s about 5 billion or 6 billion people who will be facilitated by non-Latin scripts being in use, and that means literally at the keyboard; and general usage [also] for software, etc. etc.
And from their user experience, they’re not going to have the challenges of a visual confusion that for example we have seen discussed recently in a number of lists, including the governance list because when one looks at an upper- or lower-case image that looks somewhat similar to an ASCII “B” or “C” or whatever it might be, there is no concept of the ASCII use. Therefore there is no issue as far as I can tell to the high risk of visual similarity and confusion from that.
So I think I’d like to do a little bit of reminding that it’s the stability, the technical issues and the integrity and the security of it has to be paramount, but I think we need to not get overly concerned about some of these similarity and confusion issues. Maybe I’m in a minority here but I just get very annoyed at the assumption that the end user is going to be fundamentally an idiot. They’re far more likely to be pharmed, phished or otherwise misled by something far more sophisticated than misreading the script for another letter.
The other thing I was going to ask is if memory serves me from the integrated document, there was a number of hypotheticals, or I think they called them “scenarios,” “options,” whatever as they were in the previous documentation on IDNs on how the rules and policies on labels particularly might be developed going from the formal one set of tables developed by a set of experts through to all sorts of variations on that theme. Edmon, is there a sense from you at all as to what the rank and file At-Large person would be seeing as the best of those options?
I know that that’s something that they’ll be looking at in the solutions and next [spot] but I thought a reasonable amount of this particular input would have been integrated in what was talked about, “If we do this then these are the risks, and if we do that then these are the risks or limitations or benefits.” Do you have a feeling to go for Option 1, 2, or 3 or does it really not mater as long as it’s predictable, consistent, and above all of course transparent. I guess that’s all I have to say.
Edmon Chung: Thank you. And I guess on your first point I think it’s certainly very, very important; especially what I call the ASCII bias especially as Olivier brought up the issue of transparency in panels. I think the ASCII bias in the panels or committees that are to be formed by ICANN eventually as we implement these things needs to be voiced out. If the panels have a strong ASCII bias then the results might be quite different than if they’re not. So certainly I think it’s appropriate and there’s room for that.
On your second question, I think the report actually came up with four sort of hypothetical possible approaches. Personally I do have a view in that to me I think it’s #3 if I’m not mistaken; it’s the third option that I think is the most appropriate. And that points towards having sort of these tables and [marrington] and character tables developed from the community and adopted by ICANN, but for the root zone we take an approach to create a sort of superset so that specific communities can have their way, anyway. But it also sort of maintains the consistency across the board.
Other ways are just to treat it being based on from the community, and the other side of the spectrum is that it’s completely determined and created by ICANN – all the tables. So I think Option #3 is the one that I think is most appropriate. Whether at this point, and I guess ALAC as a whole perhaps should weigh in, I’m not so sure about it because it contains a lot of technical details that still need to be worked out by the solutions team. Right now these are four possibilities that are being brought up.
I have personally some inclination towards Option #3, which I think in a way there was some discussion about it in the group as well that that seems to be the direction; but at this point the issues report wanted to just lay it out as these four possibilities. So I don’t know. I’m personally comfortable saying that I think Option #3 is more appropriate but I’m not 100% sure we should at this point because we still can weigh in on the next (inaudible) reports that will come out in the next months, and [head] then instead of now.
Cheryl Langdon-Orr: Yes, I think we need to keep our [counter dry] on some of those issues then. I also think that we probably need to decide at this point in this call exactly how far we’re going and a response to the integrated issues report.
Edmon Chung: Right. So yeah, I guess coming back to that particular item and we are already over the top of the hour, if I may be so bold to suggest that perhaps hearing that there’s at least some support and not hearing anybody jumping up and saying they object to it that I’ll draft a fairly short response with the three points that I mentioned, one of which is just commending the work and highlighting that nothing new means it’s high time that we go forward; the second one is that even though that being said don’t forget about the other languages that ICANN should spend time and effort to work on; and the third one is the spectrum of maturity requires ICANN in the implementation to consider that and to implement those that are ready so that people can use IDNs in a way that’s appropriate as soon as possible.
I can help draft that probably fairly shortly, and I’m hoping, I’m wondering if Cheryl or Olivier would have some time to perhaps draft one component which is focused on the ASCII bias and the transparency required as we go into implementation – that part, because I think, Cheryl, if you have the time…
Cheryl Langdon-Orr: Well, to some extent I think the transcript from this meeting here will have put some [creditable] words together. I think there were some very printable words that Olivier put down in his presentations to us as well.
Olivier Crépin-Leblond: If we can try and obtain the transcript quite fast, Olivier here, and take it from there. I don’t know how long it takes for it to be ready. I know time is of the essence of course.
Edmon Chung: That’s okay. I guess in view of time it’s probably fastest if I put the four points together in probably a two-thirds page kind of format and then circulate it.
Olivier Crépin-Leblond: Yes, and we can add to it – Olivier here. I was going to just add one more thing with regards to the spread in the range of maturity, I understand – and I might be wrong, actually, so let’s put this as a question. Is it possible to mix scripts in a domain name?
Edmon Chung: This question is one that requires a long answer but the short answer is that there are languages like Japanese that do mix scripts, so when you use the term “script” there are different languages that mix it. And for most languages, I shouldn’t say “most…” A lot of the languages ASCII is being mixed in, even for Chinese, Japanese, Korean, and some other cases as well – ASCII characters are being mixed in.
Olivier Crépin-Leblond: So we have to be mindful of the fact that scripts can be mixed when saying that there is a spread in the range of maturity, because one answer we might be given would be “Oh no, we have to link them all together since they can be mixed with each other.”
Edmon Chung: Ah. That’s a good question. In my view, though, the charter of the VIP and I think the [immediateness of sequenced work] is very focused on the top level. In top-level cases we can probably narrow it much further down to having a single script. The only case that I can think of that would definitely require a mixed script is Japanese, but the so-called “mixed script,” a lot of people would view it as one Japanese script. So I think it is an issue that requires a long discussion or else if we ever bring that up, which way we bring it up, it would raise more questions and eyebrows than try to resolve it. Because I envision a relatively high-level sort of advice from the ALAC rather than sort of going into details.
Olivier Crépin-Leblond: Okay. Yeah, in Appendix 6 there’s a survey of IDN practices and it mentions that a small number of TLDs responded that they were mixing code points from multiple scripts in the same label. In the way that you write the statement, just be mindful of this so we don’t have this set on the side, saying “Well, maybe it’s another special case,” as usual.
Edmon Chung: Understood. I’m very aware of that.
Olivier Crépin-Leblond: Okay.
Edmon Chung: Okay. So I guess… Cheryl, please.
Cheryl Langdon-Orr: I was going to ask if this is going to be on a (inaudible) Wiki page from the agenda we’re working on, the agenda page we’ve got or what?
Olivier Crépin-Leblond: I understand there’s already a page that Matt has put together, At-Large IDN Variant Issues Project draft integrated issues report workspace. And this is where I believe this will have to go.
Cheryl Langdon-Orr: Okay…
Olivier Crépin-Leblond: Do you have it?
Cheryl Langdon-Orr: That’s full of all the VIP stuff and that’s got the variant, it’s got the case study comments on it.
Edmon Chung: That is the last one. The link goes to the…
Cheryl Langdon-Orr: We need a new one certainly.
Olivier Crépin-Leblond: Yeah, the one on the agenda is wrong unfortunately. The one which Matt has put together is here. I can send it to you. Either should I send it by email or should I just send it to Edmon and then Edmon can publicize it.
Edmon Chung: Either way is fine. I guess both probably so everyone can have it immediately. And I’ll work with staff to update the draft there within the next 24 hours so we can have something to circulate.
Olivier Crépin-Leblond: Okay. Now there’s the second one of course, the universal acceptance of IDN TLDs – there’s also a workspace that’s been opened for that. So if you want I can send both over to you or should I put them separately?
Edmon Chung: I think on that I was hoping Sala could join because she had expressed an interest to help head that as I mentioned because on a different capacity I helped chair the group that created that report.
Cheryl Langdon-Orr: We’ve got a bit more time on that one, haven’t we?
Olivier Crépin-Leblond: We have a little more time, yes, we have until the 7th of February.
Edmon Chung: Right. So I guess I’ll start the discussion, try to get Sala on the case as well and maybe we’ll take that over the mailing list which we’ve created for this IDN Work Group; and see if we need to coordinate another call between now and then so that we can put something together. But I think Sala had mentioned that she’s willing to help on that.
So I guess with that and we’re fifteen minutes past the hour…
Cheryl Langdon-Orr: You didn’t start the meeting until ten minutes past the hour to begin with so I don’t think you’re doing too badly. (laughing)
Edmon Chung: And any final items that people want to raise? If not, I guess thank you everyone for joining. I think we had a very constructive meeting and I will send out a draft within the next 24 hours and have it circulated.
Cheryl Langdon-Orr: Alright, thank you.
Edmon Chung: Thank you, everyone, bye-bye.
[End of Transcript]
1 Comment
Salanieta Tamanikaiwaimaro
Thank you for the transcripts, it was very useful reading to see the interactions that took place.